[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