[Stk] Ruby extensions with STK

David Michael david.michael at gmail.com
Wed, 5 Dec 2007 12:59:14 -0500


Well I only have very preliminary results, but for a single sinusoid  
on a Core 2 Duo (Mac) I was getting about 1.9% - 2.0% CPU usage from  
Ruby. Comparatively, running crtsine.cpp natively compiled, I got  
1.8% CPU usage. This was with default buffer sizes. So the  
performance seems to be pretty spot on. There is CPU overhead for  
running the Ruby interpreter, but not that much. I am also curious on  
how fast it could go: that is, how many instances I can manage,  
etc... In general I would love to have this targeted to less-than- 
modern CPUs. I need to do much more testing.

So the reason that interpreted languages are not good at realtime  
synthesis seems to be that they are too slow to do the timely float  
calculations of realtime audio (handling streams and whatnot) - but  
if you offload the audio engine to C/C++ code, you should be able to  
get decent performance and get to use a nice high level language like  
Ruby to orchestrate objects.  Correct?

What would be really amazing would be a domain specific language for  
the STK built off of Ruby for manipulating audio objects, but I have  
yet to figure out how one would manage audio streams between Ruby  
objects...

Best
David

-
http://unnature.org



On Dec 5, 2007, at 12:25 PM, Stephen Sinclair wrote:

> Hi,
>
> Mind sharing some data about performance?
> I'm curious how fast it can go.. what kind of buffer size do you  
> need, for example, to generate a real-time sinusoid?
> How many filters can you run it through?
>
> Generally I usually assume that these interpreted languages like  
> Ruby and Python are not good for real-time sound synthesis, so I'm  
> curious what's actually possible on a modern CPU.
>
> Steve
>
>
> David Michael wrote:
>> Hello
>>
>> I just wanted to drop a line to tell the list that I was able to  
>> get the RtAudio and the STK running as a Ruby extension which  
>> basically allows calls to the sound engine via Ruby. I have not  
>> figured out the best way to wrap the library yet, but just thought  
>> I would let you guys know it was possible.
>>
>> Thanks Gary and Perry for stellar software. I have been  
>> experimenting with these libraries for about six months now and  
>> have been able to get them compiling and working just about  
>> everywhere I have tried.
>>
>> Cheers
>> David
>>
>> -
>> http://unnature.org
>>
>> _______________________________________________
>> Stk mailing list
>> Stk@ccrma.stanford.edu
>> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>
> _______________________________________________
> Stk mailing list
> Stk@ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk