DSP Robotics Support

Hello All,

I wanted to test some capabilities in flowstone. Does anyone know if globally in Ruby can you query modules that are connected to each other? I assume that each module and components have some kind of ID for each instance that is placed onto the schematic.

Example - I placed 3 modules onto the schematic. Each one could be the same or different doesn't matter. Let's say they are connected module 1 - 2 -3. I want to know module 1 is connected to module 2 vice versa and Module 3 is connected to module 2 and vice versa. Is there anyway of knowing this globally or even local to each other?

Thanks in advanced.

Every module is an instance of RubyEdit class. You can scan ID of the instance by casting "self"


There is no way to tell to which modules it is connected, without editing the ruby module, to send its ID to following modules. You may for example add this code to each module's code, and in the end it will contain the module IDs in the order they were executed. This will naturally need the module to have specific input and output for the IDs (or they will have to be inside rubyvalue that is transmitted).

Thanks that helped, I also found something called "BUS" which could pass any value I need with the ID. I haven't tried it yet, but looks promising. Not very much documentation on the "BUS" and I am new to ruby. I have programmed in at least 10 other languages, but I never had the desire to try ruby until now. I hope the fact that it is a non-compiled language that it still has enough speed. I know the SSE calculations help, but is it as fast as other compiled code?

-Patrick

pshannon wrote: I hope the fact that it is a non-compiled language that it still has enough speed. I know the SSE calculations help, but is it as fast as other compiled code?

Unfortunately no... ruby is considerably slower than Flowstone streams (the blue and white connectors and modules associated with them). If you plan on processing something like sound in real time (generally @44.1kHz or more), you should avoid ruby if speed is a concern. Ruby in flowstone is mainly meant as supplement/improvement of "green" and GUI calculations which happen at maximum of 100 updates per second (although higher speeds are naturally possible).

To process sound with maximum efficiency you should stick with DSP code component. It has quite limited capabilities, but is sufficient 80% of the times. Assembler component has slightly higher capabilities and offers some features which are not present in DSP code component, but they come at a price of coding them in assembler (which is quite hard to do/learn and also buggy code usually results in instant crash). If you are interested, you may have a look at http://flowstone.guru/ - recently I've written a chain of tutorial articles, that cover assembler features in Flowstone.

KG_is_back wrote:Ruby in flowstone is mainly meant as supplement/improvement of "green" and GUI calculations which happen at maximum of 100 updates per second (although higher speeds are naturally possible).

Hey KG,

I'm walking on thin ice here, because I never tried what I'm now talking about. But doesn't Ruby sync to ASIO? It's said so in the manual that it will sync to any speed from ASIO if that prim exists in the schematic. Together with the audio frame access it should be able to do quite some performance, shouldn't it?

tulamide wrote:

KG_is_back wrote:Ruby in flowstone is mainly meant as supplement/improvement of "green" and GUI calculations which happen at maximum of 100 updates per second (although higher speeds are naturally possible).

Hey KG,

I'm walking on thin ice here, because I never tried what I'm now talking about. But doesn't Ruby sync to ASIO? It's said so in the manual that it will sync to any speed from ASIO if that prim exists in the schematic. Together with the audio frame access it should be able to do quite some performance, shouldn't it?

Yes, you are right - that is exactly one of the cases when ruby updates more than 100 times per second. However, that has nothing to do with the actual performance.
ASIO processes audio something like this:
soundcard input fills a buffer sample by sample and once its filled, the buffer is send to audio application for processing. In case of Flowstone, this buffer is processed by stream connectors. Although Flowstone seems to be processing audio "sample by sample", what is actually happening is, that the entire stream system is in one big "FOR" loop.
Once this buffer is processed Flowstone sends it to the ASIO output buffer, which waits until previous output buffer has finished playback.
Until that happens, your computer is free to do other tasks including Green, GUI and ruby calculations. If it hasn't enough time to finish them before next ASIO buffer arrives, Windows simply pauses them, switch to streams (which are of higher priority - you'd rather have GUI freezing than sound dropouts, right? ) and resumes after the buffer is done.
When ruby is used to process streams via ruby frames, what actually happens is, that Flowstone fills/plays the ruby in/out frames (mono to frame and frame to mono prims) while processing the streams. Once the streams are done, ruby is used to process these frames in between ASIO buffer calculations. This naturally means, that whatever you do in ruby (or green), it will have an effect not sooner than in next ASIO buffer - zero latency with ruby is not possible in flowstone.
However, that says nothing about the actual performance of Ruby itself (in terms of CPU cycles consumption). It may or may not be efficient in processing the sound. Only way to tell, is to compare CPU load of similar code in stream vs ruby version. Such tests show, that ruby is very poor compared to compiled code produced by streams, in terms of CPU load. That is not a surprising, interpreted languages are generally more cpu consuming, because the interpretation is quite CPU heavy process on its own.