Re: Reality of v3's Ruby in Real-Time Applications
Posted: Sat Sep 08, 2012 9:15 pm
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.
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.