FMOD or other sound libraries...anyone?

[David Casal]

I'm looking for a good Ruby sound library...

I've been looking for Ruby bindings of FMOD the last few days, but it
looks like very little is available, if anything.

Does anyone know of someone working on FMOD bindings? I can see there
is at least two bindgins of SDL (RUDL and ruby-sdl), but I'm having no
luck trying to run either in OSX.

Any advice appreciated...

 

[Richard Lyman]

I'm looking for a good Ruby sound library...

I've been looking for Ruby bindings of FMOD the last few days, but it
looks like very little is available, if anything.

Does anyone know of someone working on FMOD bindings? I can see there
is at least two bindgins of SDL (RUDL and ruby-sdl), but I'm having no
luck trying to run either in OSX.

Any advice appreciated...

I think I remember Jamis mentioned something once... something about
Ruby and FMOD, but it might have been a different sound library...

-Rich

 

[Jamis Buck]

I think I remember Jamis mentioned something once... something about
Ruby and FMOD, but it might have been a different sound library...

It was FMOD. I wrote some simple bindings for my Vimscriber
transcription application, using Ruby/DL, but...alas...I can't get it
to work on OSX, which is what the OP seems to want. If only FMOD were
opensource, I could compile it to a shared library, but as it is the
OSX version of FMOD is only distributed as a static lib. (Someone,
please correct me if I'm wrong!)

I, too, would be very interested in Ruby bindings to a sound lib for
OSX. Would ruby-cocoa work? Anyone know?

- Jamis

 

[David Plans Casal]

It was FMOD. I wrote some simple bindings for my Vimscriber
transcription application, using Ruby/DL, but...alas...I can't get it
to work on OSX, which is what the OP seems to want. If only FMOD were
opensource, I could compile it to a shared library, but as it is the
OSX version of FMOD is only distributed as a static lib. (Someone,
please correct me if I'm wrong!)

I, too, would be very interested in Ruby bindings to a sound lib for
OSX. Would ruby-cocoa work? Anyone know?

Are you talking about http://www.fmod.org/files/fmodapi3741mac.sit ?

Their website says 'Carbon based. Codewarrior CFM and GCC Mach-O
Compatible.'

Also, I see that there's been some work here:

http://onesadcookie.is-a-geek.net/cgi-bin/blosxom.cgi/2004/05/
22#openal_ruby

on OpenAL bindings, but it looks seriously alpha...

Jamis, please do let me know what you find! I'm urgently looking to
start work on Ruby audio...

cheers,

david casal

 

[David Plans Casal]

Just as an added note to that, I've just tried RubyCocoa from
http://www.fobj.com/rubycocoa/doc/build.en.html .... version 0.4.0 was
made for ruby 1.6.7, so 1.8.x on OSX is complaining...can't seem to
compile at all.

Jamis : however, rubycocoa does look like an alternative (if one could
actually install it ;-) )


david casal

 

[Jamis Buck]

Are you talking about http://www.fmod.org/files/fmodapi3741mac.sit ?

Their website says 'Carbon based. Codewarrior CFM and GCC Mach-O
Compatible.'

That's the one. However, my bindings are Ruby/DL based, which means
Ruby tries to load the library and execute the code directly, without a
compiled glue-layer. I'm sure an enterprising individual could write a
C extension to Ruby that used the FMOD routines...but I'd rather not
have to.

- Jamis

 

[David Plans Casal]

That's the one. However, my bindings are Ruby/DL based, which means
Ruby tries to load the library and execute the code directly, without
a compiled glue-layer. I'm sure an enterprising individual could write
a C extension to Ruby that used the FMOD routines...but I'd rather not
have to.

Heh! Completely understand...I just plain cannot write the bindings
since I know -no- C at all...oh well.

On the other hand, to correct what I said earlier about RubyCocoa, the
HEAD tag out of cvs installs just fine on OSX and ruby 1.8.1...all the
sound examples play fine.

I did:

cvs -dserver:[email protected]:/cvsroot/rubycocoa login

cvs -z3 -dserver:[email protected]:/cvsroot/rubycocoa co -P -r
HEAD -d rubycocoa-panther src

then

cvs update -d -P

Now I guess that RubyCocoa isn't really as straightforward as FMOD to
play with sound and Ruby, but...

Anyone have any alternative suggestions?

david casal

 

[Dave Baldwin]

I, too, would be very interested in Ruby bindings to a sound lib for
OSX. Would ruby-cocoa work? Anyone know?

- Jamis

Yes, one of the sample programs is:

require 'osx/cocoa'

snd_files =
if ARGV.size == 0 then
`ls /System/Library/Sounds/*.aiff`.split
else
ARGV
end

OSX.ruby_thread_switcher_start(0.001, 0.1)
Thread.start { OSX::NSRunLoop.currentRunLoop.run }

snd_files.each do |path|
snd = OSX::NSSound.alloc.initWithContentsOfFile_byReference(path,
true)
snd.play
sleep 0.25 while snd.isPlaying?
end


Don't know if this give the OP what he wants.

Dave.

 

[Mathieu Bouchard]

I'm looking for a good Ruby sound library...

I am maintainer for the Ruby bindings to PureData, which is a realtime
visual programming language for audio. I am also the author of a video
plugin for PureData, and actually those things are bundled together under
the name GridFlow.

I use GridFlow for interactive setups in art galleries, museums, and music
shows, under contract with local artists (mostly in Montréal and
Ottawa/Gatineau). I'm doing that stuff part-time while struggling with a
degree (the degree is over now, so I'm going to do this full-time now,
hopefully)

It would be cool to have more elaborate bindings because the ones I have
coded are rather minimal (that is, only what I need to have for the video
plugin). In the future it would be cool to be able to have complete
access to PureData objects, in the same way that the Python bindings to
PureData can. Especially missing are ways to access audio buffers. I think
it wouldn't be that difficult to implement, but I haven't needed them yet.

What do you think about it? Is it overkill for your needs? What do you
want to achieve with the audio library?



PS: The big problem with audio and Ruby, though, is that the garbage
collector takes too much CPU in one chunk, so that low-latency audio just
fails horribly. For ordinary audio needs that's not really a problem
unless the computer is slow, but many people want low-latency so that they
can replace their expensive and unflexible guitar pedals by something
extremely versatile, the computer.

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

 

[David Plans Casal]

Hi Matju,

I am maintainer for the Ruby bindings to PureData, which is a realtime
visual programming language for audio. I am also the author of a video
plugin for PureData, and actually those things are bundled together
under
the name GridFlow.

The world's so small. Met you on IRC last saturday ;-) (nick: pland)

I use GridFlow for interactive setups in art galleries, museums, and
music
shows, under contract with local artists (mostly in Montréal and
Ottawa/Gatineau). I'm doing that stuff part-time while struggling with
a
degree (the degree is over now, so I'm going to do this full-time now,
hopefully)

Does this mean that Ruby-PD bindings might get deeper (audio buffer
access?), if you have time?

It would be cool to have more elaborate bindings because the ones I
have
coded are rather minimal (that is, only what I need to have for the
video
plugin). In the future it would be cool to be able to have complete
access to PureData objects, in the same way that the Python bindings to
PureData can. Especially missing are ways to access audio buffers. I
think
it wouldn't be that difficult to implement, but I haven't needed them
yet.

Ah! Ok I understand now. In my case, because of my music background and
the fact I wanted to learn Ruby, I thought it would be great to be able
to -hear- my study of Ruby, if you see what I mean.

So, what I was after was a way to exemplify concepts from the second
edition of the Pickaxe, in sound.

I played with PureData during my degree, and I guess having access to
PD objects from Ruby would be as close as I get to heaven! ;-) But I
suppose I need to find an intermediate solution for now...

What do you think about it? Is it overkill for your needs? What do you
want to achieve with the audio library?

So, see above, but here's a summary : I think Gridflow is an amazing
idea and project (got some osx compilation trouble I'll address
ex-list), and would love to start learning it.

But browsing the pd flow ruby examples in there got me kinda lost.
Firstly because I couldn't run it (compilation), but also because I
didn't quite get how PD would pick Gridflow up and viceversa (other
than -lib)

What I'm looking for, I guess, is the ability to play with sampled
sound for now (similar to Cocoa's NSSound, but a bit deeper), in a way
that allows me to explore ruby by ear. So simple sample loading,
playing, buffering, maybe some DSP...perhaps some MIDI (though I see
midilib)...like I said, PDRuby would be of course ideal, but the basics
through pure Ruby and Gridflow would be even better right now, since
I'm a complete n00b to Ruby.

Is that too vague?

PS: The big problem with audio and Ruby, though, is that the garbage
collector takes too much CPU in one chunk, so that low-latency audio
just
fails horribly. For ordinary audio needs that's not really a problem
unless the computer is slow, but many people want low-latency so that
they
can replace their expensive and unflexible guitar pedals by something
extremely versatile, the computer.

I see. Of course.

Well I aim to get to a point where I can do that too. And so, I -will-
need a low-latency, probably C-implemented (like PD) engine behind me,
and I guess I see Ruby as the higher-level, 'thinking' language for
composition, and pedal-making.

My guess is you do too?

What can I do to help? I'm studying the Pickaxe now, and I'll download
tarball of Gridflow (tried CVS unsuccessfully) and try on OSX
(10.3.8)...is there a short summary of how to get GF and PD talking
anywhere (other than website docs?)

Thanks for you reply, Matju, I look forward to working in Gridflow.

Cheers,

David

 

[Robert McGovern]

Speaking of Ruby bindings for FMod, Lorien Dunn created one which
worked against Ruby 1.6.8. It was part of a package called Hail which
was available for Linux and Windows

This was the announcement for it on Ruby Talk

http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/66871

Unfortuantly it appears to have disappeared from the web & RAA.

If anyone is interested I have a copy of 0.6 that Lorien sent me back
in April 2003.

Rob

 

[Bill Kelly]

I am maintainer for the Ruby bindings to PureData, which is a realtime
visual programming language for audio. I am also the author of a video
plugin for PureData, and actually those things are bundled together under
the name GridFlow.

Awesome !!!!!

It would be cool to have more elaborate bindings because the ones I have
coded are rather minimal (that is, only what I need to have for the video
plugin). In the future it would be cool to be able to have complete
access to PureData objects, in the same way that the Python bindings to
PureData can. Especially missing are ways to access audio buffers. I think
it wouldn't be that difficult to implement, but I haven't needed them yet.

PS: The big problem with audio and Ruby, though, is that the garbage
collector takes too much CPU in one chunk, so that low-latency audio just
fails horribly. For ordinary audio needs that's not really a problem
unless the computer is slow, but many people want low-latency so that they
can replace their expensive and unflexible guitar pedals by something
extremely versatile, the computer.

I'm interested in both low-latency audio and MIDI... I've just
learned about PureData from your post, so haven't seen the
internals yet. I presume having "access" to audio buffers
from ruby for any kind of real-time work is probably somewhat
pointless anyway - unless ruby is making very high level calls
to perform operations on the buffers?

My inclination (again, not knowing PureData yet) would be to
want to put the real-time audio processing in a separate
thread, unaffected by ruby's GC. Then have ruby be able to
configure what the audio thread is doing, without interfering
with it.

. . .

GridFlow looks very, very cool. I've been wanting to do something
similar (although different

From your web page:

- Adding MSWindows display support (GDI or DirectX or SDL or...)

I'm writing a ruby extension at the moment called GLWindow.
The primary difference between SDL's OpenGL or GLUT is that
GLWindow supports multiple windows, all having a *shared* GL
context. Also, it can open/close additional windows very
rapidly, and can continue updating while a window is being
moved/resized; basic stuff like that needed by my app.

So maybe it could be potentially useful for GridFlow?
(GLWindow is being developed on win32 now, but I want my
app to run on Linux and OS X too, so, eventually it'll be
on those platforms as well.)


Regards,

Bill

 

[David Plans Casal]

Speaking of Ruby bindings for FMod, Lorien Dunn created one which
worked against Ruby 1.6.8. It was part of a package called Hail which
was available for Linux and Windows

I've been looking everywhere for Dunn's FMOD bindings, but as you say,
they seem to have dissapeared...

Unfortuantly it appears to have disappeared from the web & RAA.

If anyone is interested I have a copy of 0.6 that Lorien sent me back
in April 2003.

I'm interested! Please do make them available and/or send to me.

I do wonder if Dunn ever worked on this anymore?

Cheers,

David

 

[David Plans Casal]

It would be cool to have more elaborate bindings because the ones I
have
coded are rather minimal (that is, only what I need to have for the
video
plugin). In the future it would be cool to be able to have complete
access to PureData objects, in the same way that the Python bindings to
PureData can. Especially missing are ways to access audio buffers. I
think
it wouldn't be that difficult to implement, but I haven't needed them
yet.

What do you think about it? Is it overkill for your needs? What do you
want to achieve with the audio library?

Hi Matju,

I replied to your email on the ruby-lang list, but perhaps you missed
it? I'll forward it in case.

Meantime I have a question about gridflow 0.7.7 compilation. If I
download the binary 0.7.7 release and just co ./configure, make, make
install, then make test, here's what I get on 'make test':

waldorf:~/Desktop/gridflowBinary/gridflow dc$ make test
rm -f core
(ruby -w base/test.rb math) || ([ -f core ] && gdb `which ruby`
core)
objc: failed objc_getClass(NSObject) for GFView->isa->isa
objc: please link appropriate classes in your program
make: *** [test] Error 1
waldorf:~/Desktop/gridflowBinary/gridflow dc$

The install seems to have gone ok, but I get the same message from IRB
if I try "require 'gridflow' "...

Any idea what I might be doing wrong?

cheers,

david

 

[David Plans Casal]

If anyone is interested I have a copy of 0.6 that Lorien sent me back
in April 2003.

Sorry to bother you again with this...but I'd be really interested to
look at a copy of Lorien's 0.6 bindings, if you don't mind sending me
one...

Cheers,

David Casal

 

[Robert McGovern]

Sorry about that, I've been away for a few days.

I'll mail you off list shortly.

Rob

 

[Mathieu Bouchard]

I replied to your email on the ruby-lang list, but perhaps you missed it?

I've had a major hard disk crash yesterday, but I also have my regular
delays... too busy.

waldorf:~/Desktop/gridflowBinary/gridflow dc$ make test
rm -f core
(ruby -w base/test.rb math) || ([ -f core ] && gdb `which ruby` core)
objc: failed objc_getClass(NSObject) for GFView->isa->isa
objc: please link appropriate classes in your program
The install seems to have gone ok, but I get the same message from IRB if I
try "require 'gridflow' "...
Any idea what I might be doing wrong?

You are on MacOSX, you have Quartz support enabled, and then something
went wrong, and I don't know what it is.

Btw, even though i coded gridflow/format/quartz.m, i don't really know
what I'm doing there. I asked someone else to fix my bugs. I'm not a
MacOSX programmer and basically sticking to Linux for the foreseeable
future. I expect other programmers to take care of porting to other OSes.

Your options are either to ask James Tittle to help you, or do ./configure
--no-quartz and instead use the X11 part (which anyway is more powerful)

Come to the #dataflow channel on FreeNode, which is the same network where
#ruby-lang is.

.-----------------------------------------------------------------.
/ The Diagram is the Program (TM) ,--------------------------------}
{----------------------------------" http://artengine.ca/matju /
`-----------------------------------------------------------------'

 

[Mathieu Bouchard]

I'm interested in both low-latency audio and MIDI... I've just learned
about PureData from your post, so haven't seen the internals yet. I
presume having "access" to audio buffers from ruby for any kind of
real-time work is probably somewhat pointless anyway - unless ruby is
making very high level calls to perform operations on the buffers?

GridFlow has those high-level calls ready to be wrapped for Ruby, but the
wrapping hasn't been done yet. GridFlow offers fast whole-array operations
similar to what is found in NArray, but they're currently still much
easier to use from PureData than from Ruby.

My inclination (again, not knowing PureData yet) would be to want to
put the real-time audio processing in a separate thread, unaffected by
ruby's GC. Then have ruby be able to configure what the audio thread
is doing, without interfering with it.

You can use PureData's [netsend] and [netreceive] classes to coördinate
multiple separate PureData processes. I've used that recently so that I
could run both audio and video at once (and reliably) on the same machine.

So maybe it could be potentially useful for GridFlow?

GridFlow currently doesn't have anything to do with OpenGL. If you handle
everything starting with some form of RGB or RGBA buffer then I can do the
rest of the integration.

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

 

[Mathieu Bouchard]

The world's so small. Met you on IRC last saturday ;-) (nick: pland)

You're welcome if you want to come back. The next PureData developers
meeting is on FreeNode #dataflow on April 1st, UTC 17:00.

Does this mean that Ruby-PD bindings might get deeper (audio buffer
access?), if you have time?

Yes, that and making GridFlow's C++ side more accessible from Ruby,
which should help getting decent performance for audio processing. However
Ruby is a major pain for low-latency audio, as I said previously,
and I know people who don't want to run GridFlow because it makes
the sound skip because of too-long garbage collection times.

Ah! Ok I understand now. In my case, because of my music background
and the fact I wanted to learn Ruby, I thought it would be great to be
able to -hear- my study of Ruby, if you see what I mean. So, what I
was after was a way to exemplify concepts from the second edition of
the Pickaxe, in sound.

I think you can do lots of interesting music programming in Ruby with the
current GridFlow if you restrict yourself to event generation. E.g. the
Ruby code could handle complex combinations of scales, chords,
polyrhythms, while PureData would do the actual signal synthesis.

I have an example with GridFlow and audio buffers, but it's rather slow
because the audio buffer has to be sent to PureData one number at a time
(one per message i mean!). Still I have been able to achieve nice results,
such as:

http://gridflow.ca/gallery/spectrogram.gif

http://gridflow.ca/gallery/photo_pianoroll.pd.gif

The first is a spectrogram with a temporal low-pass filter post-processing
the video-stream, in such a way that changes appear in reddish and
bluish colours while non-changing parts are more black-and-white.

The latter is an inverse-spectrogram, that is, synthesising sounds from a
picture.

Both use the FFT filters built into PureData.

So, see above, but here's a summary : I think Gridflow is an amazing
idea and project (got some osx compilation trouble I'll address
ex-list), and would love to start learning it.

GridFlow is not so stable on OSX, and it's very slow on PPC for
semi-unknown reasons.

But browsing the pd flow ruby examples in there got me kinda lost.
Firstly because I couldn't run it (compilation), but also because I
didn't quite get how PD would pick Gridflow up and viceversa (other
than -lib)

"pd -lib gridflow" picks up gridflow.pd_linux, which starts libruby.so and
then gridflow.so. There is a config file ~/.gridflow_startup in which you
can put your Ruby scripts because it's being parsed as a Ruby file.

What I'm looking for, I guess, is the ability to play with sampled
sound for now (similar to Cocoa's NSSound, but a bit deeper), in a way
that allows me to explore ruby by ear. So simple sample loading,
playing, buffering, maybe some DSP...perhaps some MIDI (though I see
midilib)...like I said, PDRuby would be of course ideal, but the basics
through pure Ruby and Gridflow would be even better right now, since
I'm a complete n00b to Ruby.

There's unfortunately no tutorial or doc for writing PureData classes in
Ruby, because I wanted to improve the API, and still haven't got around to
finishing that completely. However it's not too hard, you mostly just have
to subclass FObject, export the class using
self.install(name,inlets,outlets), embed inlet-numbers in methodnames,
like def _0_bang(), and use send_out(outletnumber,selector,*args) to send
messages.

Well I aim to get to a point where I can do that too. And so, I -will-
need a low-latency, probably C-implemented (like PD) engine behind me,
and I guess I see Ruby as the higher-level, 'thinking' language for
composition, and pedal-making.
My guess is you do too?

I'm not very much into audio. 95% of what I do is video.

What can I do to help? I'm studying the Pickaxe now, and I'll download
tarball of Gridflow (tried CVS unsuccessfully) and try on OSX
(10.3.8)...is there a short summary of how to get GF and PD talking
anywhere (other than website docs?)

This message (see above). If you have any questions on how do to specific
things, just ask. I would recommend joining the gridflow-dev mailing-list:

http://ns.artengine.ca/mailman/listinfo/gridflow-dev

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju