If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
Reality of v3's Ruby in Real-Time Applications
Re: Reality of v3's Ruby in Real-Time Applications
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.
Re: Reality of v3's Ruby in Real-Time Applications
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.support wrote: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).
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
Ah great, thanks for that architecture feature!support wrote:Garbage collection isn't going to cause stutters or degrade performance. FS is multithreaded. The audio runs in a separate thread from the Ruby.
I do hope there will be good documentation for the Audio-Ruby, "frames", & the DLL connection please.