Reality of v3's Ruby in Real-Time Applications

[infuzion]

Ok, seems DSPR wants we SynthMaker owners to migrate to FS v3 by adding VST2.3 (or 2.4?) support. For those focused on the robotics part of FS, a "VST" is a DSP plugin for audio applications/hosts; think of a Photoshop plugin, but to be used with streaming multichannel audio.

I also semi-expect that v3 will have Ruby support for MIDI & real-time audio since you blogged about them here:
http://dsprobotics.blogspot.co.uk/2012/ ... -midi.html
http://dsprobotics.blogspot.co.uk/2012/ ... dules.html
It would be handy to have Ruby to code MIDI & perhaps even audio. There is one problem that I'm not sure if FS users discovered using Ruby with real-time operations (which would be a current sub-set of existing FS users, & I doubt there are many due to the quiet nature of this board).

Ruby is a garbage-collected language, which means pauses in operation while it frees up memory.
"No Ruby code can run while GC is running"
This is bad for real-time applications, especially if your have 10+ plugins all using Ruby. Pauses in streaming audio live in front of 10,000 people is not a good thing. I see alot of people questioning using Ruby for games, which is semi-real-time (20-60FPS):
http://chrismdp.github.com/2012/01/why- ... plus-plus/
"garbage collection is still too stuttery...even with Ruby 1.9.3"
http://gafferongames.com/2009/01/11/rub ... velopment/
"ruby garbage collects once every 5 seconds or so, and each time it caused a frame hitch of 35 – 100 milliseconds on my macbook air"

I guess there are some improvements, but I don't know if they will be enough, or even attempted to be implemented in FS3:
http://patshaughnessy.net/2012/3/23/why ... -ruby-2-0#
http://www.rubyenterpriseedition.com/faq.html

Or perhaps programming straight with Ruby is better?
https://github.com/thbar/opaz-plugdk
https://groups.google.com/forum/?fromgr ... /ruby-midi

[DSP]

As a beta tester I've played with the new Midi and audio to Ruby Modules and can report that the Ruby interface side doesn't appear to slow things down with audio, but the audio processing can. The midi stuff works really well with now actuate timing thanks to the events system.

The Ruby integration isn't meant for pure audio processing which is why the DSP Code (or Code module as you know it in SM) modules exist to process multiple steams of real-time audio efficiently, and this is still the way to go for this.

Ruby can handle audio I/O efficiently but is not recommended for processing audio (use the DSP Code Module for this), however it has a nice little trick up it's sleeve and that is to take the FlowStone blue audio signals and send to through external dlls (usually written in C). Whilst this isn't for everyone it really opens the door for more advanced programmers to make their own highly optimized audio dll processes and then integrate it into the nice friendly FlowStone environment to add midi, GUI, etc. and finally create the VST plugin or stand alone EXE.

I understand that with the release of FlowStone V3 there will be some example C++ DLL frameworks a bit like an SDK, so people that need this can get going quickly making there own audio processing dlls.

Again this is an advance feature and I would imagine that most people will just use the DSP Code modules for DSP and audio processing.

On a more general note the version of Ruby used in FlowStone has been made by DSPRobotics and compiled into their own Ruby DLL. This means that they have total control and can fix any bugs etc. But I can report that so far we haven't found any bugs in Ruby and would like to add that Ruby is a much more modern, efficient, and easy language to program in than Python!

[infuzion]

1 As a beta tester I've played with the new Midi and audio to Ruby Modules and can report that the Ruby interface side doesn't appear to slow things down with audio, but the audio processing can. The midi stuff works really well with now actuate timing thanks to the events system.
...
2 Ruby can handle audio I/O efficiently but is not recommended for processing audio (use the DSP Code Module for this),...

3 however it has a nice little trick up it's sleeve and that is to take the FlowStone blue audio signals and send to through external dlls (usually written in C). Whilst this isn't for everyone it really opens the door for more advanced programmers to make their own highly optimized audio dll processes and then integrate it into the nice friendly FlowStone environment to add midi, GUI, etc. and finally create the VST plugin or stand alone EXE.... I understand that with the release of FlowStone V3 there will be some example C++ DLL frameworks a bit like an SDK, so people that need this can get going quickly making there own audio processing dlls.

4 On a more general note the version of Ruby used in FlowStone has been made by DSPRobotics and compiled into their own Ruby DLL. This means that they have total control and can fix any bugs etc. But I can report that so far we haven't found any bugs in Ruby..

Thanks for the insightful reply DSP! Please excuse my terseness:

1. I figured Ruby would be better than the old green-system for MIDI, & so this is good news. But now (unless there is a flood of new modules coming) learning Ruby adds an additional layer of complexity & time; why not just learn C++/JUCE & drop FS at this point? Then one can export into any platform, & not be stuck with Windows. I know Ruby is a scripting language so you don't have to learn pointers, etc, but I'm looking at cost+time/reward_profit_margin ratio here...

2. DSPR's CEO/marketing guy Carl was insinuating I think that Ruby-audio was the (part) solution for a 6-year request for double-floats (SSE2/3) to be added to the ASM block, if not Code. http://synthmaker.co.uk/forum/viewtopic ... =a&start=3
As you confirmed (thanks), this is not acceptable. It will take about 1 day's worth of programming to add SSE2-4 to the ASM primitive. Adding it to Code is likely to be longer, understandably, but can be worked around by letting users make modules out of ASM code.

3. Interesting... but I don't see any reference to this anywhere on the forum or blog, or in the discussion at SM/Outsim. But again, see my reply 1

4. This is both good & bad; Might be more stable with FS-Ruby usage, but looking at the spareness of the forum & the lack of a "Bugs" forum (so we observers can't see what bugs are reported), I doubt there is much FS-Ruby usage going on save a handful of hobbyists. Like I said before, crashing VSTs are not an option. Might be stable enough for hobbist usage, but pro usage is in question here.
Also, what version of Ruby is this FL-Ruby.dll please? Looks like Ruby1.9.? helps a little the garbage-collection issue, 2.0 (assume needs Github pull) moreso.

[DSP]

Thanks for the insightful reply DSP! Please excuse my terseness:

1. I figured Ruby would be better than the old green-system for MIDI, & so this is good news. But now (unless there is a flood of new modules coming) learning Ruby adds an additional layer of complexity & time; why not just learn C++/JUCE & drop FS at this point? Then one can export into any platform, & not be stuck with Windows. I know Ruby is a scripting language so you don't have to learn pointers, etc, but I'm looking at cost+time/reward_profit_margin ratio here...

2. DSPR's CEO/marketing guy Carl was insinuating I think that Ruby-audio was the (part) solution for a 6-year request for double-floats (SSE2/3) to be added to the ASM block, if not Code. http://synthmaker.co.uk/forum/viewtopic ... =a&start=3
As you confirmed (thanks), this is not acceptable. It will take about 1 day's worth of programming to add SSE2-4 to the ASM primitive. Adding it to Code is likely to be longer, understandably, but can be worked around by letting users make modules out of ASM code.

3. Interesting... but I don't see any reference to this anywhere on the forum or blog, or in the discussion at SM/Outsim. But again, see my reply 1

4. This is both good & bad; Might be more stable with FS-Ruby usage, but looking at the spareness of the forum & the lack of a "Bugs" forum (so we observers can't see what bugs are reported), I doubt there is much FS-Ruby usage going on save a handful of hobbyists. Like I said before, crashing VSTs are not an option. Might be stable enough for hobbist usage, but pro usage is in question here.
Also, what version of Ruby is this FL-Ruby.dll please? Looks like Ruby1.9.? helps a little the garbage-collection issue, 2.0 (assume needs Github pull) moreso.

1. C isn't interpreted, ie. it won't run in real time as you develop - you have to code, compile, test. While Ruby is interpreted so as with the other FlowStone modules it runs as you write it! Which is pretty cool. Ruby is really fast to learn and compared to using C, being able to have just one line (or as many as you want) of code when you really need it is a great feature.

2. The Ruby double precision is more for maths than audio, maybe they will add the extra op codes you need, I haven't checked. MY main concern it that if it goes 64 bit as everyone is pushing for, this whole inline assembler will be lost as it isn't possible in 64 bit windows!

3. As they said on the post - more to come. They can't post anything until it is release as it won't work with audio until V3.

4. so far it does seem stable, we have been testing for a year now. If you want to see a big Ruby project then check out Flowbotics Studio:
http://www.dsprobotics.com/support/viewtopic.php?f=71&t=416

This apparently has been used by 20,000 students from PLTW with stability no issues reported. Admittedly it's not audio but it shows what is possible.

[infuzion]

2. ...MY main concern it that if it goes 64 bit as everyone is pushing for, this whole inline assembler will be lost as it isn't possible in 64 bit windows!

4. so far it does seem stable, we have been testing for a year now. If you want to see a big Ruby project then check out Flowbotics Studio...This apparently has been used by 20,000 students from PLTW with stability no issues reported. Admittedly it's not audio but it shows what is possible.

2. I would find it hard to believe that switching the compiler to target 64bit OS would take too much work as far as the inline ASM goes. Unless the original programmers Malc/Jorge are completely cut off from programming V3?

4. I've seen Flowbotics, but have not seen any PR about its usage. Wow!

Thanks for the replies DSP!

[sal]

i think ruby is not for pro audio.

It's good to do many things, to work with text, to communicate with databases, but audio is very limited.

I think python can be much better, it is interpreted too and can handle audio calculations much better than ruby, but it think also that this is a shortcut to avoid developing flowstone natively.

[infuzion]

i think ruby is not for pro audio.
It's good to do many things, to work with text, to communicate with databases, but audio is very limited.

I think python can be much better, it is interpreted too and can handle audio calculations much better than ruby, but it think also that this is a shortcut to avoid developing flowstone natively.

If Python is better, it would be fractionally better IMHO due to both having their memory being garbage collected. Maybe you can link hard studies to prove me wrong please?

Number crunching is number crunching, & IIRC both will tokenize before running, so it is a bit faster than you think. & both have had years of optimizing for webservers, which need fast results also.

But I agree, my impression right now is that scripted languages are not for our level of DSP crunching.

[MyDogRamsey]

1. C isn't interpreted, ie. it won't run in real time as you develop - you have to code, compile, test. While Ruby is interpreted so as with the other FlowStone modules it runs as you write it! Which is pretty cool. Ruby is really fast to learn and compared to using C, being able to have just one line (or as many as you want) of code when you really need it is a great feature.

This is where they made a mistake IMO. They could have went with CINT which is interpretted C++. The code could have been added to the SM/FS exe and the user would have had the power of C++ at their disposal. Plus, they would have had the C++ codetotake with them to another compiler. Ruby does nothing for you in that regard.

[Warmonger]

I was hoping for Ruby to be a replacement for so called "green code". As for real-time DSP, we already have code component and asm. However, all the interface (which can get really fancy in synths) needs to be made with endless networks of green components.

Real-life example: non-linear tuning for my synth needs to be done like that:

Nonlinear tuning.png (62.66 KiB) Viewed 32548 times

This is confusing at least, as you see, writting it in code is so much easier. However, it causes excessive CPU usage.

Now, imagine tunable filter of arbitrary order done in such way. Nightmare. WIth dynamic arrays and mathematical expressions things would become easier.

What does Ruby offer here and what kind of performance cna we expect with controls sampled every 25ms?

[nix]

Can anyone help me with this->
What I would like to do is turn a stream bool into a
green bool, without using mono to float.
I don't want to send like 2000 ticks per second to the
'mono to float'
I would like to have one tick when the bool changes-hmm
--using Ruby?