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

Joe Armstrong erlang@REDACTED
Sat Feb 2 15:27:20 CET 2008

That sounds like fun - yes please send me a copy - don't bother to tidy it up.

<grumpy mode on>

I'm amazed that you think the API is "nice" . On a good day, I would
call it appallingly bad. The thing that it's better
than must be true awful.

I see absolutely no reason
why a /dev/midi interface should no both be exceedingly simple and
very powerful. Midi events
(in the midi file spec) have infinite timing precision (play this note
at exactly this time) - if I a
want to play note N at time T I should only have to write a handful of
bytes to a logical device
not mess around with a load of totally irrelevant call back routines
with obscure names and even more
obscure arguments.

Another grumble I have is that I was forced to read code to figure out
how the routines worked - the so-called
API "documentation" was not much help - I *hate* reading code to
figure out what things do. All I get is
one example of what the APIs do and not what they are *supposed* to do - sigh.

Just because certain code has to be responsive and even fast doe not
mean that the APIs have to be
a mess. The job of turning complex requirements into fast code is the
job of a compiler and not a programmer.


I have (finally) also made  a midi driver that can send and receive
events from a keyboard and play
things either via the keyboard or via an internal synt (Abletone live)
- although the code works it's a mess
- It would be nice to compare notes.

Actually once you get Erlang to control midi streams the code starts
fitting in with how I way to describe

When you play a note you get sent a note. To play a note you send a
message to the device.

Synth ! {playNote, Pitch, Time, Vol}   seems very natural.

The arpeggiators sound fun - I'm trying to make rolling hash functions
to recognise
riffs and trigger samples ...


On Feb 1, 2008 12:09 PM, Jakob Cederlund <jakob@REDACTED> wrote:
>  Hi!
>  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.
>  /Jakob
>  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

More information about the erlang-questions mailing list