Question about Ruby

[Halon]

Im interested in learning to code. So my question is:

Can Ruby be used for audio programming, like coding a simple filter etc. or should you use DSP Code instead? Im a bit confused by the difference of Ruby and the DSP Code 'component'.

Cheers.

[tulamide]

The difference is the execution speed.

If you just ask wether you can use Ruby for such tasks, the answer is yes. It has access to the output buffer (via Frames), so theoretically you could build a whole synth in Ruby.

But Ruby is an interpreted language, not a compiler. Everything you type in the Ruby editor is interpeted at runtime. And because it is a complete language,it is not optimized for sound manipulation (=slow).

The DSP editor also is interpreted at runtime, but it is a specialized tool for just the task of manipulating the sound buffer as quickly as possible. Therefore it is superior to Ruby. A lot faster, one could say.

The fastest way to manipulate the sound buffer is using the ASM component. Assembler is closest to the real machine language, a processor understands, as you can get. It is blazing fast.

Ruby can work in all areas of plugin creation, while the others are only for sound manipulation. I once made an example to show how it works, when using Ruby for sound manipulation, so you might want to have a look at that for a starting point. But I highly recommend not using it, but DSP or ASM.

http://www.dsprobotics.com/support/viewtopic.php?f=3&t=5669&p=27322

[Halon]

Thank you for your explanation tulamide. I'll have a look at the link you posted.

[Spogg]

Just to add to what tulamide said, the DSP component’s code is interpreted and pre-compiled into assembler, behind the scenes so to speak.

You can see what’s been compiled if you display the S output pin in a text module.

If you copy this text into an assembler component, and you know what you’re doing (so that’s me out), you then have the possibility to optimise the assembler code generated. This means you have a good starting point and don’t have to write the whole routine natively in assembler.

capture.png (526.47 KiB) Viewed 16520 times

I recently made a test additive oscillator in Ruby; very simple and of course mono (blue) only. Ruby can’t operate directly in the poly (white) parts. The CPU usage was over 10 times that of a single voice DSP version in a polystream.
Also I would add that if you want to do anything with MIDI which is time-critical, then Ruby is the only way to go. DSP doesn’t deal with MIDI and green is too slow and unpredictable for all but the simplest MIDI function.

Cheers

Spogg

[tulamide]

Thanks, Spogg, I totally forgot that the DSP editor transscripts to Assembler!

I recently made a test additive oscillator in Ruby; very simple and of course mono (blue) only. Ruby can’t operate directly in the poly (white) parts. The CPU usage was over 10 times that of a single voice DSP version in a polystream.

While there would be no reason to argue on Ruby being slow in sound manipulation, there is one conceptional mistake, people make. Both, DSP and ASM work on the concept of 1 sample at a time. They are optimized for it.

Ruby works with frames, that's -depending on the used sound out- something betwen a few dozen samples (ASIO), a few hundred samples (ASIO4ALL) or even a few million samples (DirectSound) at a time. The concept behind this is a double buffer: You work on the next buffer, while the current buffer is played. That means, you have a lot more time to do calculations, before the next buffer is due. So, you don't reduce processor load by reducing the concept of your oscillator for example, and you don't increase processor load by adding functionality (to a certain degree, you know when you reach the limit as soon as drop outs occur). So, when using Ruby, the general rule is the opposite of DSP/ASM: put as much code in as you can.

You can see it in the info line of Flowstone (bottom right), using your oscillator (maybe), or my example (for sure): Remove all functionality but the frame conversion. You will see no difference in processor load.

What I mean is: You access the frame only and it is already at -for example- 10% cpu load. Terrible. But now you can add a lot of code, without further increasing it by a notable margin. And it takes a lot of code calculations to get to 11%. Because of the wait time in between buffer access.

[Halon]

Thanks for the information Spogg and tulamide. When you guys say that Ruby is slow in sound manipulation / coding, do you mean that it needs more lines of code ?

[nix]

Hi Halon!
What's meant is that it takes more CPU cycles(more CPU percentage) to process audio with Ruby than the DSP codebox. It just doesn't function in the same way, no matter how tricky you are at coding.
However Tulamide is saying there's something of a baseline cost to Ruby, if it must be used for audio.

I like Ruby, it's a huge difference to FS to have it in here, though I am not great at it. If you'd like to practice- I recommend doing some graphics, float/int/bool stuff or MIDI. But if you'd like you can try and process the audio frames.

I started by wanting to build a sequencer with it, so I tried things like sample and hold, and last module in Ruby

[Spogg]

You access the frame only and it is already at -for example- 10% cpu load. Terrible. But now you can add a lot of code, without further increasing it by a notable margin. And it takes a lot of code calculations to get to 11%. Because of the wait time in between buffer access.

You explained this to me before (privately) and I thought I'd got it, but this proves I didn't. I had thought that the Ruby CPU use was in some way proportional to the complexity and amount of code, but this has cleared it up, so many thanks.

To sum up, there is a big offset or "cost" of say 10% CPU, just by using the frame system. Then you have loads of space for code before the CPU increases significantly. Good to know

Cheers

Spogg

[tulamide]

You access the frame only and it is already at -for example- 10% cpu load. Terrible. But now you can add a lot of code, without further increasing it by a notable margin. And it takes a lot of code calculations to get to 11%. Because of the wait time in between buffer access.

You explained this to me before (privately) and I thought I'd got it, but this proves I didn't. I had thought that the Ruby CPU use was in some way proportional to the complexity and amount of code, but this has cleared it up, so many thanks.

To sum up, there is a big offset or "cost" of say 10% CPU, just by using the frame system. Then you have loads of space for code before the CPU increases significantly. Good to know

Cheers

Spogg

I really don't want to confuse you, but basically it is proportional to the complexity. However, if you already have code that stresses the CPU, but also have short downtimes in between those calls, the filling of that downtime doesn't add much to the load. Unless, of course, you add code that is as stressful as converting a memblock that is reserved for (say) ASIO to a Ruby array and back once every 10 ms.

Imagine you work on a farm and have to load 200 apples on your back and bring them from the tress to the farm house. 12 times that day. Would you feel any difference if it were 208 apples? Would you feel any difference when on the way back to the trees you calculate how much you earned so far, and watch the other people passing by, and drink some water?

Something like that. Well, actually not, but it is a picture that makes it easier to understand

[Spogg]

To stick with your lovely rural image, I thought it was the bag itself which was very heavy (= using frames) so you wouldn’t notice the apples much unless you put lots in the bag.

So unfortunately I’m less clear than I should be and now weighed down by freshly picked fruit.

Cheers

Spogg