27 Jul
2004
27 Jul
'04
4:23 p.m.
On Tue, 2004-07-27 at 12:33, Paul Davis wrote:
I heard that mentioned on the list, but without a link to the code. I
was interested in it for artistic reasons, but now technical as well..
where's that code?
I've been thinking about the MIDI->OSC part quite a bit, whether to have
the engine support MIDI, or do an out-of-process MIDI->OSC mapping. I
figure a MIDI->OSC control mapper would be a pretty useful thing to have
around for numerous reasons other than this project alone.. but then
voice allocation (for polyphonic synths) would be in that app, which
is.. sketchy
Hmm.. okay. I'm glad you said that, because in the mean time I've put
together a prototype using liblo, and I rather like the API.
Thanks
-DR-
I'm writing
an audio engine that will communicate with the outside world
exclusively via OSC (and perhaps MIDI, but I digress..) It's much more
generic, but for the sake of argument let's say the engine is a synth
and it needs to talk to a GUI.
I need realtime appropriate performance for parameters, and two-way
communication (though the synth -> GUI is really simple and not
performance critical - error reporting etc.)
so lets just say thats its basically identical in all gross ways to
jesse chappell's latest incarnation of sooperlooper, which uses OSC to
connect an out-of-process GUI to the sooperlooper jack client engine,
and also does MIDI->OSC bridging from an ALSA sequencer port. it works
great. it uses liblo. The question
is, which implementation is best? All I can find is
Steve's liblo, libosc++, and the 'official' OSC kit. What are the
afaik, libosc++ just wraps the sdk distributed by stanford. and that
sdk is just a total nightmare. the 2nd worst code i have ever
read. use liblo.