Frame to Ruby: CPU consumption

[user_fm]

Hello,
When I send several audio streams to ruby component by frames there is already a high CPU consumption, even there is no code inside yet.
Is it ok?

[Drnkhobo]

Hmm that doesnt sound right! Although I could be wrong, I do
know that processing with Ruby's frames
are indeed more CPU intensive.

I wouldnt say its ok, maybe someone here knows more?

You are right , it seems the mono2frame primitive and the ruby module itself EAT CPU. . . .

[MyCo]

That's because Raw floats (that the CPU understands) have to be converted into Ruby Floats wich are objects, and each object has more informations than just 32bits.

[Drnkhobo]

ouch, that means it still no better than handling in 'blue' form

[trogluddite]

Well, to be fair, even the developers themselves have said that stream audio processing is not really what Ruby was introduced for. Interpreted object-oriented languages are simply not a sensible choice for DSP - you might just get away with it for a bit of basic mp3 playback, but for a VST plugins in multiple instances it ain't gonna work.
Apart from anything else, frames must be buffered - you can't write multiple samples back together with a regular "sample-by-sample" stream until the buffer has filled up, so you will always get a buffer's worth of latency - and just like ASIO, I'd expect the CPU load to rise as the buffers get smaller due to the extra events. That problem would get quickly worse if you had to do several stream=>frame=>stream conversions in order to mix Ruby "audio" modules freely with regular stream/code/assembly, especially if the relative phase of streams were important to the sound.
I think that having Ruby is fantastic, and am loving the ease of coding - but not every tool fits every job. If they had intended Ruby as an audio coding language, the DSP Code primitive would have been discarded - that and the assembly module are there for a reason; because low level compiled code gets the job done. The answers for more advanced DSP routines will have to come from enhancements to the Code/ASM primitives, or some kind of SDK that allows primitives to be written in C++ etc.

[Drnkhobo]

some kind of SDK that allows primitives to be written in C++ etc.

Now thats interesting Trog! Any ideas?

Oh dont get me wrong here I absolutely LOVE the addition of Ruby in FS and would never want to trade it for anything.

[trogluddite]

Now thats interesting Trog! Any ideas?

A very old idea that has been floating in the SM ether for many years.
I can see why the dev's have resisted it - modules built with an SDK would most likely end up being something rather like the built in primitives. You can't look inside compiled binary code, so unlike designs made from the current modules, the source code isn't there for all to see. That could be a big headache for technical support - people wanting help with broken schematics that the dev's have no hope of fixing because it isn't their code, and no hope of forum 'gurus' fixing it either. If the original developer doesn't hang around to offer support and fixes, you're stuffed.
This is partly why I asked the dev's about whether the "Modules" area of the forum would be open to user submissions. Not only would a central source for the best stuff be easier than searching posts with funny thread titles, but it would open the door to some sort of quality control - which would make releasing an SDK for the real hard-core developers a much safer prospect. A bit like the way that some mobile app's work - if you download approved ones, then some help and support is available; you can still load other ones if you like, but then you must accept "buyer beware" and use at your own risk.
The process itself really shouldn't be too hard - the necessary libraries and resources must already be available to the developers, as they must use those tools themselves. It is just a case of wrapping it all up into an SDK that it simple to use (for C coders at least!), and also secure, so that it doesn't lead to their software being easier to hack or pirate.
We shall see - they have never said never, so it is still an open question. If we can come up with some constructive suggestions about how it might work, or benefit DSPr , then maybe we can convince them. I for one, would be prepared to pay a premium for access to an SDK, and maybe "Officially Sponsored" modules could be traded for a small price to be shared between the "user dev's" and the company as a bit of encouragement for everyone.