Reality of v3's Ruby in Real-Time Applications

[support]

Sorry for the delay in responding. We will be doing daily rounds from now on.

Ruby in FS is mainly provided as an alternative to green triggered data. It works really well for UI stuff, string and array handling and soon also for MIDI too.

In FS3 we do have components that will convert Mono stream data to a frame of floats so that it can be passed to a Ruby component. Frames of floats can also be passed back to Mono too. This will allow you to do audio processing in Ruby code but you will get a performance hit. You will also be able to pass a frame to an external dll for processing. This is much faster than doing the processing inside the Ruby component but still not as fast as doing it using streams (via Poly and Mono).

Garbage collection isn't going to cause stutters or degrade performance. FS is multithreaded. The audio runs in a separate thread from the Ruby. As long as any processed frames are available when requested from the audio side you won't have any clicks or stutters.

As soon as we have something we can give you to try you'll be able to test this all for yourself.

Regarding CINT - it's certainly an interesting proposition. However, C/C++ is alot harder for non-programmers to pick up. You can do most things in Ruby much easier than in C/C++ and you can learn it as you go along - you don't need to know much to get started. Ruby is implemented in C too so it's very fast to execute. That said, just having Ruby doesn't mean we can't support other languages in the future.

[infuzion]

In FS3 we do have components that will convert Mono stream data to a frame of floats so that it can be passed to a Ruby component. Frames of floats can also be passed back to Mono too. This will allow you to do audio processing in Ruby code but you will get a performance hit. You will also be able to pass a frame to an external dll for processing. This is much faster than doing the processing inside the Ruby component but still not as fast as doing it using streams (via Poly and Mono).

That sounds neat! Seems like the Audio-Ruby would be good for non time-critical things like visual meters & running motors. Not ideal for audio streams.

So, since Carl offered Ruby as a solution to double-floats, & it clearly is not for audio, the 64bit ASM question/request still needs to be answered please:
viewtopic.php?f=2&t=523

Garbage collection isn't going to cause stutters or degrade performance. FS is multithreaded. The audio runs in a separate thread from the Ruby.

Ah great, thanks for that architecture feature!

I do hope there will be good documentation for the Audio-Ruby, "frames", & the DLL connection please.