[erlang-questions] help: Erlang MIDI driver for MAC OS X
Fri Feb 1 12:09:36 CET 2008
I've written a simple coremidi-driver for erlang, but it's almost three
years ago, and it's 100% uncommented, undocumented code. If anyone wants
it, I can clean it up and send it over. Very simple stuff though: just
sending and receiving timed Midi data.
BTW, CoreAudio, while not really nice, is by far the nicest audio API
I've used, and I've used several. (Try doing music on a Wintel machine,
if you have strong nerves =). It's hard to program and even harder to
setup.) Having a /dev/midi would be nice for playing around and testing
simple stuff, and probably quite pointless for all other purposes.
PS I wrote the driver initially as an example for the OTP docs, but
dropped it in favour of the postgres-driver, since the latter is
cross-platform and simpler. I did use it though, to test some simple
music-related things, like arpeggiators and quantizing of real-time
midi-data. Erlang is nice for those kind of hacks, and midi:play is more
rewarding than io:format. =)
PPS Everything is not invented in UNIX... thank goodness!
Bob Ippolito wrote:
> On Jan 21, 2008 6:29 AM, Joe Armstrong <> wrote:
>> Thanks - I'd discovered this :-)
>> I have actually made great progress after about 9 hours of searching
>> and messing around suddenly things
>> bust into life.
>> I have now made a primitive OS-X midi driver - so now I can both send
>> and receive real-time midi events
>> and make horrible noises.
>> The interesting thing is that this really does bring home to me how
>> appallingly difficult it is to write even simple
>> code today.
> Well, the reason Apple's CoreAudio APIs look like that are because
> they're designed to have *very* precise timing, where you wouldn't be
> able to do that properly over a file-like device. The APIs are a pain
> in the ass and it sucks when you don't need that but that's why it's
> designed that way. I think that the CoreAudio stuff lives in the
> real-time parts of the kernel so when you get a callback it's at a
> very high priority and you're not even supposed to allocate memory or
> anything that might interrupt.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions