DSP Robotics Support

kortezzzz wrote:I've abandoned the Ruby solution ... I'm using poly velocity solutions instead due to intensive CPU usage

There was some talk about this on Slack a few months back. MIDI via "real-time" Ruby does seem to hit the CPU pretty hard, so your code may be innocent! MyCo described this as being partly down to how the CPU threads have to be sychronised internally. Presumably, similar syncing issues would apply to MIDI going via "green" links, so the green "bouncing" problem might even be a similar kind of issue.

kortezzzz wrote:small & elegant code for that

It may help to combine the Ruby processing into a single RubyEdit rather than separate components, assuming that you can. There is quite often a penalty for converting between Ruby and red/green/yellow values, and values sent between RubyEdits by links require new "events" to be generated and queued.

Thanks for the answer. I see. So maybe the best way in that case is to stay with the poly solution without burdening the midi path with an extra process. And that's probably the reason why FS midi timing would never be accurate like a standard DAW or hardware machine like korg pa900 arranger organ. All those "penalties" cause timing issues, don't they?

lalalandsynth wrote:Nice !, thanks !

Thanks for the feedback. Have fun

Very intresting Kortezzz.

Is it not possible to make a simple arp. Just by make the pattern fixed set. By not make it able to change the pattern then just hide the pattern?

djbrynte,
If you mean fixed and un-changeable pattern, yes. Just draw your wanted pattern, export the notes information to a simple string box, then disconnect the preset module from the arp, connect the string box instead, hide the piano roll and you are done. It will always play the same pattern (but without the chords of course).

ok thanks mate

I'd noticed the weight on the cpu also and surmised that perhaps sending the signal from a code filter arp then to ruby might make an arpeggiator midi control more compatible with products like reason.

So, often midi will be routed to have many connections. if Ruby were that bridge and route to the voices primitive. It might supercede issues. But, of course it means falling back to older methods for arpeggios. Just a thought.