[erlang-questions] help: Erlang MIDI driver for MAC OS X

Jakob Cederlund jakob@REDACTED
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 <erlang@REDACTED> 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.
> -bob
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080201/9903bea8/attachment.htm>

More information about the erlang-questions mailing list