DSP Robotics Support

Just wondered if there is any command in ruby that puts the module into kinda standby mode.
Let's say we have a simple statement like:

def event i
if @in==0
then
output 0, @a
else
output 0, @b
end

end

but I would like it to do nothing as long as @in is not zero. something like:

def event i
if @in==0
then
output 0, @a
else
*do nothing*
end

end

Does the "else" part removal from the code is the correct way, or we should add some extra statement for that?

The way we work with Ruby in Flowstone is called "event-driven".
That means, any RubyEdit instance is automatically in a wait state if no event occurs. It also means that you don't have to think about how to make Ruby doing nothing. You only have to care about what it should do, if an event occurs.

In your example the event to occur is that the input gets 0. The event method gives you the source of the event (here called i), and the value of the event (mostly called v, here not used). If you use this event method correctly, it looks like this (given that the input to the module is named "myInput":



Now you have a event-driven control. If the value isn't 0, nothing happens (ruby stays idle).

Thanks again tulamide. overall, for the 3425th time, If I'm not wrong...

I'll tell you why its so critical to me:

I'm going to use those statements to pass midi sequence through a few midi manipulation modules, and to do that correctly, I must keep the midi signal path in ruby only (no green selectors, multiplexers or switches are added through this path, or I probably would end up with horrible midi jitter). Anyway, I know that the correct way to write this code is to gather the whole bunch of statements into a single ruby module (cheaper, faster, etc.) but before I do that, I'm going to use some smaller separate ruby statement modules and see how they handle this task (it's much easy for me and my coding skill... ).

For that reason, I found your comment extremely sedative; You ended it up with the words "ruby stays idle", and that's exactly what I've been looking for

you may use "return" command to prematurely end a method. If the method is not expected to return specific value (like most flowstone specific methods are, namely init, event, draw, mouseMove, mouseLDown,...) then it shouldn't interfere with the function.

... hmm ... wonder if I can use that command around the house ?

@RJ

@KG thanks for the tip. Could be great if you could give us a short example code how to use that command.

And one more question, a little off topic:

If I add midi (the red "M") inputs\outputs in a Ruby code to send out or receive midi signal, I actually convert those inputs\outputs into the green midi?...
If so, what's the prefered way to the keep midi sequence path in it's best and avoid of jitter and etc.?
Any benefits in keeping the whole midi inputs\output on the ruby modules (started at the ruby midi clock) with "V" (value inputs\output) instead of "M" (midi inputs\output) and use the "M" only at the path's final station, where the midi signal is about to be sent to the "outside" world?

It's my guess that M & V have the same time accuracy.
The MIDI and Ruby are supposed to be concurrent

Each method in Ruby always has an implicit "return" command. Otherwise it wouldn't return from the method

Using "return" only makes sense in certain situations to shortcut a lot of code that Ruby would otherwise execute. The return command is more often used in conjunction with an object, to be able to return different objects depending on the state of the method.

In your specific example, "return" would achieve nothing. Ruby calls the method when an event occurs. Let's see what happens if the event is the correct input and value:

1. Checking the input
2. Checking the value
3. outputting @a
4. returning

And what happens if the value is not correct?

1. Checking the input
2. Checking the value
3. returning

And if the input is not correct?

1. Checking the input
2. returning

No use for "return" here at all. So where does it make sense? Well, sometimes those if-clauses are hard to read if any long code is enclosed:



This could be simplified to



In this case, although there is a bunch of code after the if-clause it will not be executed if a is 1, because there's the return command. And if a is not 1, the if-clause is not executed but all the other bunch of code. It's the same as the original, just written differently (no executing advantages/disadvantages). You can use "return" also for debugging. Just place it at where you want to stop the execution of the method, for example to find out where it goes crazy.

Regarding MIDI, the only difference between green and Ruby is that Ruby runs a little faster (100Hz, while green is mostly way below that value). But both need to convert the incoming midi signal to an array. Considering this, it might be best to make an array copy of the incoming midi, then check for whatever you want to check, but send out the original signal if the check resulted to false. You save the second conversion (from array back to midi) this way.

Thanks tulamide. All is bright and clear.

Only one issue here:

Regarding MIDI, the only difference between green and Ruby is that Ruby runs a little faster (100Hz, while green is mostly way below that value). But both need to convert the incoming midi signal to an array

I've tried both methods with a quite simple midi manipulation code. The code works just fine with the "midi ins\outs"
version, while it fails with the "value ins\out". Seems like those 2 methods don't build the midi array in the same way??
If so, whats the proper way to build an array in the "value" version?

A describing schematic attached.

kortezzzz wrote:If so, whats the proper way to build an array in the "value" version?

They do build the array in the same way, but they also need the correct object (aka class) type to be present. With a midi input it is automatically the correct object type, but not with a generic RubyValue. And altough you have three inputs, you don't restrict the event method regarding what to react to and so the code is executed not only when midi data comes in, but also whenever lowest or highest note inputs are changed.

The "V" stands for RubyValue. This is no term from Ruby, but from Malc. And I don't think it's the best name for its purpose, because a RubyValue is no value, but a container. It can contain any object (aka class) that Ruby is aware of. An array as well as a number, a string as well as a hash table, even a graphics path. But, since it is a container, it won't be filled with the needed object type from the beginning. Instead it is filled initially with the nil class. And the nil class does not have a method called "to_a"/"to_array". And the first three times the method is called is from a empty V (so the nil class), the lowest note (it still looks at the v-input, so still the nil class) and the highest note input (again empty v-input/nil class)

Therefore you need to change two things:
1. It needs to be fed with a Ruby Midi class
2. It needs to only react to a midi event

The first one is important, since the red midi you know of is not a Ruby Midi Class. Luckily it is quite easy to convert it into a RubyValue that following modules will understand. I've created such a conversion module.
The second one is easily done by following the code examples I gave in my earlier posts...(think about it)...(think about it)...now be
I've also corrected the code of the modules to only react to midi events, following my own examples from my earlier posts...(yeah, I really enjoy seeing you go )

But there's more. The Ruby Midi Class can be directly manipulated, without the need for a conversion to and from an array. Just use the class methods "status", "channel", "data1" and "data2". I've also added a module that makes use of it.