DSP Robotics Support

A question regarding ruby.

Is there a difference in performance (issues) between using one ruby window with complex green formula and using multiple ruby windows with simple green formulas? I just would like to know, if making dozens ruby windows (for green and rather static calculations) - makes some problem here.

That's an interesting point, and one worthy of a bit of investigation.

From our experience with Ruby-driven vs. Green-driven MIDI, it would seem logical that translating values from Ruby<->Green will have a small CPU overhead - communication between events scheduled by the the accurate Ruby clocks, and the 'green' trigger system.

That suggests that Ruby would behave much like DSP code and assembly - putting as much as possible into one block would have slightly lower CPU load.
If what we've seen with MIDI is any indication, keeping things 'Ruby native' as much as possible should also lead to tighter event timing - if you take a Ruby generated MIDI event, but then pass if to the green MIDI primitives, the event timing reverts to the less-accurate green version. Presumably this would apply to other 'green' values sent in and out of Ruby prim's - so again, it would seem that minimising the number of "translations" would lead to slightly better performance.

Something else that I have been meaning to test is that inputs/outputs from Ruby blocks are able to use the 'Ruby Value' (V), type of connector - allowing the direct passing of Ruby values between blocks in their native format, without 'translation' to the green data types. I would guess that this too would lead to slightly tighter performance with less CPU.

However, knowing the way that 'green' works, in terms of "forward vs. backward" triggers, it may not take many maths operations inside a Ruby prim' for it to be more efficient than the 'green' equivalent. Ruby is just an ordered list of operations to perform, whereas even a quite small 'green equation' can have a surprisingly large amount of 'handshaking' between the primitives - and even the 'blockers' etc. that we use for trigger optimisation must carry some CPU overhead which Ruby can eliminate entirely. The difference would be something like this...

Green - Prim' 1 value change -> Informs next primitive of the change -> next primitive sends a reverse trigger asking for the value (and also to any other 'input' primitives to which it is connected) -> first primitive responds by sending the new value (likewise any other 'input' prim's) -> second prim' can now start working.
Ruby - just execute the next code line (no 'signalling' required)

So - rather a lot of guesswork there; based on some practical experience, for sure, but not conclusive. Hopefully my ramblings will at least point the direction to what factors we need to test in detail to get some more accurate answers.
It is something that I intend to look at. I've made a start translating my "Trogz Toolz" collection - and some of those modules definitely will be improved by using Ruby (e.g. MIDI related). But I am wary of just blindly translating every little module to Ruby if there is going to be no significant benefit (or maybe even Ruby->Green->Ruby problems).