DSP Robotics Support

“RUBY INTERFACE” vs “FLOWSTONE RUBY INTERFACE”.

Some would make you believe that there is absolutely no difference between the two, but I disagree to that. In "plain Ruby interface" I can construct a small program and save it in a *.rb file (which is a nuisance to do every time anyway, just to test your code), then call up that Ruby *.rb file BUT the code would AT LEAST run step-by-step exactly in the correct sequence as PREDICTED.

However, if you stuck that exact same code meant for the Ruby *.rb file into the "Flowstone Ruby interface", then you’ve got problems as it would not run because of certain differences which are not clearly spelled out neither even touched in the Flowstone Users Guide.

If Flowstone Admin would just provide a simple clear working example (which can be tested in the real world, not some obscure non-working Ruby code, but a complete working example) first for the "normal Ruby interface", and then show us by means of a corresponding example how it should be done in the “Flowstone Ruby interface” – that would be a great help to “Flowstone Ruby” noobs like myself.

Just to show what I mean, I provide the following “plain Ruby interface” example which works perfectly well when placed inside a Ruby *.rb file and saved and then called up from the plain “Ruby interface”:

def say_goodbye # (6) Program execution continue from here as instructed in item (4).
x = "Goodbye" # (7) Now, Ruby is instructed to assign to “x” a value of “Goodbye”.
puts x # (8) Ruby instructed to print out the value assigned to "x" i.e. "Goodbye".
end
def start_here # (2) Execution of the program thus starts from here.
x = "Hello" # (3) Then Ruby is instructed to assign to “x” a value of “Hello”.
puts x # (4) Next Ruby is told to print out the value assigned to “x” (valid for this method definition)
say_goodbye # (5) Next, Ruby is send back to the method defined as “say_goodbye”.
puts "Let's check whether x remained the same:" # (9) program execution proceeds, and it prints out this code.
puts x # (10) Ruby prints out the value assigned to "x" for this method definition.
end

start_here # (1) The call to the method defined as “start_here”.

And the output result from this plain Ruby *.rb program would be exactly in the correct sequence as predicted above (see items numbered (1) through (10)) in the program instructions:

Hello # (a)
Goodbye # (b)
Let's check whether x remained the same: # (c)
Hello # (d)

From the Ruby programming code meant for the “plain Ruby interface” above, every step of the program execution is absolutely clear to me – BUT, try and do THAT in the “Flowstone Ruby interface” and it becomes like spaghetti programming to me.

On a side note: A Ruby expert (however, not part of the Flowstone group, neither a member of the Flowstone Forum) referred in an article to non-OOP structured programming as “unclear spaghetti code”. Well, I differs from him with regard to that statement since if you have the block diagram available to that so-called “spaghetti code” then that code is just as clear to me. I can do in “spaghetti programming code” in clear step-by-step instructions exactly what I intend to do, and in many instances ten times faster than with the unclear “POOP structured programming code” (not a misspelled word).

But, really Flowstone Admin, PLEASE use my "plain Ruby Interface code" example above or something similar to explain to us “FLOWSTONE RUBY” noobs how things should be correctly done (as a recommendation: In your Flowstone Users Guide) in a clear concise manner. A short clear concise descriptive example is worth a thousand English words.

NOTE: Please keep in mind…opinions differ, and so does people and their working methods too.

whats the problem? just use an output instead of puts and trigger the start methode somehow....

@Nubeat7 It would output both so fast, that Tiffy will never see "Hello". You'd need a console that's logging all commands.

@tiffy Sorry, but there's a huge issue with your post. You want to program just like they did back in the early 80s - which is FIFO, a standard sequence (first in first out). OOP doesn't work that way. The only reason you have the feeling of seeing it working with a console is because the console allows for step-wise checking of your code. This of course is impossible in a realtime environment like Flowstone. Your options are:
1) Use Ruby standalone and try to mimic the ancient way of programming. It will lead to programs that only you can use, because they rely on the console's debugging features.
2) Learn and get used to OOP, where everything has a defined place and the program structure is clean, tidy and very managable.

And don't forget: Flowstone is a realtime environment, every action in Ruby will be processed, whenever Flowstone thinks there's enough time for it (audio is always preferred). Never rely on anything happening in a special order, unless you explicitly program it to do so. In an event based environment that means evaluating events and checking if action a was run before initiating action b.

[quote="Nubeat7"]whats the problem? just use an output instead of puts and trigger the start methode somehow....

Hi Nubeat, thanks for the reply.

Firstly, I'm aware that I should change the Ruby interface commands like "puts", "print", and "p" with the equivalent Flowstone Ruby command "output" in the Flowstone Ruby "Code Editor" (although not shown here in my example I provided), no problem with that and I have done so from my side in separate tests. But one of my problems is, if I do exactly that I do not get any output in the Flowstone Ruby Code Editor "Output Pane".

When no specific Flowstone Ruby "output" is referenced, that unreferenced output should be automatically printed in the correct sequence to the "Output Pane" of the Flowstone Ruby Code Editor, but when the example I provided is used as is (but, even with the converted "output" Flowstone commands put in place, as you have also indicated in your reply) - then there is absolutely no output at all to the Flowstone Ruby Code Editor Output Pane...although, no "errors found" are displayed. The question is a simple...why does it not print or "output" anything ?

My second issue with the Flowstone Ruby command "output" (when used in the specific Ruby code I provided in the example) when I want to refer to a specific reference for instance "output 0", with what command(s) would one then replace all those "puts", "print" and "p" command(s) with? Should one then still replace them all with "output 0"...isn't that going to overwrite all prior instructions also referenced to "output 0" and just print out the very last programming instruction to "output 0" ? Or should I additionally use (+ "\n" +) after the Ruby code at every "output 0" command in order to prevent overwriting of prior "output 0" commands in the program structure. This to me is also very confusing.

My last issue would be: Why that additional Ruby code you provided - what is that additional code doing and why is it necessary? What would the method call then be to get even that example with the additional Ruby code to execute? Even with the additional Ruby code you included I still can't get it to execute the method call? I'm still stuck with exactly the same issues...Ruby program code not executing.

Additional Ruby Code: ??
end
def event i,v
start_here if i==0
end

These are some of the biggest issues I experience when trying to execute Ruby code not specifically written for the Flowstone Ruby Code Editor.

Hi tulamide, I am currently trying to understand all that OOP-stuff as well but until then I have to understand how the Flowstone Ruby Code Editor interprets certain things/commands differently from the plain Ruby interface, regardless of whether or not OOP is used.

If certain valid Ruby code instructions can be executed in the plain Ruby interface from an *.irb file, but that same Ruby code cannot execute in the Flowstone Ruby Code Editor, then those issues should at least be addressed in the Flowstone Users Guide - for instance “puts”, “print”, “p”, “require”, and there may even be a lot more which I did not mention here. Or else, how would we know? Maybe the Old school Flowstone (Synthmaker) users heard about those issues over time through the ‘grape vine’, I don’t know, but how do they then know ?

If flowstone really want to sell their product, then in my humble opinion they should include a short chapter covering these issues by means of comparison in examples. One should not be left in the dark about such important issues. How must one then practice Ruby code examples for instance if that code cannot run through the Flowstone Ruby Code Editor?

If the plain Ruby interface can execute instructions which cannot be executed in the Flowstone Ruby Code Editor, what is such a software's future?

With that in mind, I rest my case.

WORKING EQUIVALENT FLOWSTONE RUBY EDITOR CODE FOR THE NOT WORKING EXAMPLE I POSTED PREVIOUSLY:

I now understand how Flowstone handles this differently, see the attached Ruby code.

Sorry for troubling all of you...my ignorance.