Xref: utzoo comp.sys.mac.programmer:19081 rec.music.synth:17188
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!rochester!miller
From: miller@cs.rochester.edu (Brad Miller)
Newsgroups: comp.sys.mac.programmer,rec.music.synth
Subject: Re: MIDI Manager programmers - anybody home?
Message-ID: <1990Nov16.002819.27468@cs.rochester.edu>
Date: 16 Nov 90 00:28:19 GMT
References: <1991@skye.cs.ed.ac.uk>
Reply-To: miller@alabaster.cs.rochester.edu (Brad Miller)
Organization: University of Rochester, Department of Computer Science
Lines: 72

In article <1991@skye.cs.ed.ac.uk> nick@lfcs.ed.ac.uk writes:

|So. I want to talk about MIDI Manager programming, if anyone else is
|interested. Last year I wrote a generic editor/librarian using it, and I'm
|just finishing a complete re-write using the THINK Class Library. It uses a
|big chunk of the MIDI Manager facilities; for example, to transmit a patch
|bank, it does buffering of its output and allows MIDI Manager to send the
|MIDI data asynchronously into the future (up to the capacity of the output
|buffer) using a WakeUp task - a lot more sexy than busy-loops and
|spin-waits.
|

Well, I'm certainly interested, and I have been using it. While I
don't (yet) have code or products to share, I expect to have a number
of MIDI manager utilities out next summer as shareware (probably).

What I've been up to:

1) Interface the MIDI manager to MACL, since most of this stuff is too
low level for Lisp this really involves coming up with higher level
abstractions for the MIDI stuff that is reasonable for lisp, yet
allows the sort of things that absolutely has to be done quickly get
done in efficient C code (usually at interrupt time).

2) Writing a set of MIDI tools to be used with the MIDI managers much
as filters are with UNIX, i.e. a number of specialized lightweight but
configurable modules that can be copied, or hooked up in any order
under the auspices of patchbay. In particular I'm cooking:

a channelizer (move from one channel to another with optional control)
a control remapper (change one sort of control to another)
a general effector (use a specified control to change some other
control or signal, e.g. aftertouch effects note)
an arpeggiator (a tad more functional than Arpeg, for instance)
a delay (variable length, with triggering)
and several others I've been paying less attention to (so far)

The idea is similar to UNIX's top level, have a large set of simple
tools that you KNOW what they do, and be able to hook them up in a
particular order you need for a particular job.

3) A meta-module that will provide a simplified language interface to
the musician, so they don't have to write C code, but instead can use
a high level language to write a simple module to effect the data
stream, e.g. sort of like AWK (the language will be more like scheme
on the other hand, since I'm a lisp programmer, and I'm still
convinced lisp type languages are easier to learn than C type).

4) Something I'm keeping under wraps, is somewhat related to my "real"
job, but will take considerably longer.

5) Editor/librarian for Kurzweil's 1000 series

#1 will likely be released shortly, and be free #2 I expect to be
beta-testing before next summer, and be cheap #3 next fall, also cheap
and #4 is in the 1992 timeframe, with commercial possibilities... I
haven't been working too hard on #5, and I might just blow it off and
buy Opcode's at some point, but I may yet change my mind if I somehow
get convinced that there's a market.

So, Nick, some of us just took a little longer to get a head of steam
programming on the Mac (when you're used to Symbolics machines, it
takes some getting used to-- let me tell you!)

Yours for more interesting MIDI software on the Mac...

Brad Miller
miller@cs.rochester.edu
-- 
----
Brad MillerU. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}