What's the correct Ruby command for "do nothing"?

[Spogg]

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).

I hadn't realised this so thanks for the info

Does this mean that Ruby code is interpreted on the fly rather than compiled into assembler? Or does it just have a lower priority than Stream?

The order would then seem to be Stream (Prims, DSP, ASM) then Ruby and finally Green if there's time. Correct?

Cheers

Spogg

[tulamide]

Does this mean that Ruby code is interpreted on the fly rather than compiled into assembler? Or does it just have a lower priority than Stream?

The order would then seem to be Stream (Prims, DSP, ASM) then Ruby and finally Green if there's time. Correct?

Ruby is a script language, as are Python, Lua, JavaScript, to name a few others. The difference to programming languages like C/C++, Fortran or even Basic is that the latter are compiled to machine code (not Assembler, this is just another language to program machine code, although very close to machine code), whereas script languages are interpreted.

Interpretation can happen at runtime, so indeed they don't need to be compiled. The concept is hard to understand, so let me describe it this way:

Everything that Ruby offers -I'm talking of pure Ruby, not extensions or things you build with Ruby- is precompiled c-code. That means it is optimized for speed in terms of execution and everything exists as a kind of building blocks.

When we are scripting in Ruby, we basically put building blocks together in a certain order that is quite similar to a compiled application, but with the difference that the interpretation of our script code (the combining of the building blocks) takes some time (which you don't have in a completely compiled application, of course). It is always slower than a compiled application, but can get close to it, if scripted carefully.

The interpretation of the script code is done at 100 Hz in Flowstone, which is really fast.

Remember, this is just a simplified image of what a script language is like.

The second question can be answered with a simple yes. That's the order in terms of execution speed. In reality though it seems that green and Ruby are close together in terms of execution speed, which shouldn't wonder since the green prims are also precompiled.

Ruby will have advantages when it comes to managing things like arrays, but not for its speed advantage, but for the many tools it gives you at hand, that the green prims don't offer.

[kortezzzz]

WOW. That's kinda info we'll never find anywhere. Million thanks for your patience and ardor to teach us, tulamide. highly appreciated!!! Sorry for missing the context of your earlier posts, but that's an old problem of mine:

When it's about codding, I get kinda "cerebral vertigo" (don't google it, I've just made it up ).
No, really, I find it kinda difficult internalizing new stuff so sorry for that

Anyway, your fix works great as well, but following your last comments, I have a little hesitation about the changes I've just made:

The second question can be answered with a simple yes. That's the order in terms of execution speed. In reality though it seems that green and Ruby are close together in terms of execution speed, which shouldn't wonder since the green prims are also precompiled.

Well, considering this order, is it really good idea to change my sequence path into "V" ? Or... maybe it better to leave the path ruby based (ruby modules instead of greens), but use the red "M" inputs\outputs instead of "V" ?

That means it is optimized for speed in terms of execution and everything exists as a kind of building blocks.

On the other hand, I believe "blocks" or "containers" can be much faster since they being streamed in kinda Ruby internal format, without any extra conversions during the process. So, how do we actually skin this cat?

[tulamide]

WOW. That's kinda info we'll never find anywhere. Million thanks for your patience and ardor to teach us, tulamide. highly appreciated!!! Sorry for missing the context of your earlier posts, but that's an old problem of mine:

When it's about codding, I get kinda "cerebral vertigo" (don't google it, I've just made it up ).
No, really, I find it kinda difficult internalizing new stuff so sorry for that

Anyway, your fix works great as well, but following your last comments, I have a little hesitation about the changes I've just made:

The second question can be answered with a simple yes. That's the order in terms of execution speed. In reality though it seems that green and Ruby are close together in terms of execution speed, which shouldn't wonder since the green prims are also precompiled.

Well, considering this order, is it really good idea to change my sequence path into "V" ? Or... maybe it better to leave the path ruby based (ruby modules instead of greens), but use the red "M" inputs\outputs instead of "V" ?

That means it is optimized for speed in terms of execution and everything exists as a kind of building blocks.

On the other hand, I believe "blocks" or "containers" can be much faster since they being streamed in kinda Ruby internal format, without any extra conversions during the process. So, how do we actually skin this cat?

As long as I have to check my pc (third day without Reaper, third day without issue ), I can't do music and so I have a lot of time to spend on the forum currently.

Don't make it too complicated for yourself. The best way, if using RubyEdits (read: plural) chained, is to convert it once at the beginning of the chain and once when you need to output midi to the daw. Inbetween the RubyEdits you save the conversion from and to arrays and that is speeding things up (we're talking of milliseconds though). With red Midi ins you would need to convert to an array then do the changes and then convert back to midi.

If it is only one RubyEdit that does all of the midi changes, it doesn't matter if you use the V input or red midi.

The last question is easy to answer: You can't. It is the purpose of a script language to be scriptable at runtime. And please don't forget that it was just a simplified image, I gave there. It is a little more complicated than that. Maybe a real example will help more understanding the differences?

Code: Select all

i = 1
while i < 50
    i += 1
end

This counts up to 50. But, since we build this loop ourselves, it always have to check if the condition becomes true. It does so at each iteration. It will be slow, compared to a built-in method that's precompiled:

Code: Select all

1.upto(50)

This is calling the method upto from the numerical class. No further interpretation needed.
But, this doesn't do anything. I mean, a loop only makes sense if we use it for whatever. In the first example, after the while-loop is done, i is 50. In the second example, we don't even have an i. We would need to set it up.

Code: Select all

i = 0
1.upto(50) {|n| i = n}

Now we have an i and it will be 50 after the loop completed. But to achieve it we needed to pass a block, and in this block is user-defined code - it will be interpreted again on each iteration. Since the loop itself is not user-defined, it will still be somewhat faster, but not nearly as fast as it was before without our additional code.

[kortezzzz]

As long as I have to check my pc (third day without Reaper, third day without issue ), I can't do music and so I have a lot of time to spend on the forum currently.

Wish your computer a complete recovery, tulamide. You made my week with that deep detailed comments
I feel like I've earned 1 year of FS experience in a single week
By the way, Why aren't you formating your PC and restart with a nice brand new windows installation? Sometimes it better give up on fixing and just start over

Anyway, thanks a lot for the super-grande help!