Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: ma loka 11 1999 - 15:01:00 EDT
On Sat, 9 Oct 1999 thudson_AT_cygnus.com wrote:
> One specific app I had in mind was KeyKit. While it does allow you to
> specify a device file, it expects to be able to read and write from
> this single device. Unless linux pipes are different from standard
> unix ones, they can only be opened for read or write. It would be
> nice if apps let you specify a different device file for input and
> output, but the last time I looked at the KeyKit sources (it's been
> a while), it would require some work to do this.
The "rw" program from my MIDI Toys does the reverse of this... opens a
device "file" in read/write mode, and forwards it to one FIFO in read mode
and another FIFO in write mode, so that the device can be accessed
simultaneously by two unrelated processes. However, I never ran into a
need for the reverse operation. Offhand, I can't see a way to do this
without resorting to driver programming (or rewriting KeyKit, but I was
looking for a general solution).
> Something similar to this is a pet project for me. Rather than putting
> the intelligence in every app to deal with ALSA details, I would like to
> have an ALSA kernel client w/ a gui app as a controller that would allow
> me to specify the routing between oblivious apps. However, I tend to
> think of more fine-grained routing than ports. From a users perspective
> it would be nicer to specify:
>
> External keybord => MidiAppegiator => MidiEcho => Sequencer:Track 1 =>
> External Synth (responding on channel 5)
>
> External Drum Pad => KetKit => CSound
Hmm. If you replace those arrows with vertical lines, it looks a hell of
a lot like my MIDI Toys. Identical, in fact. <Grin> I just use the
shell to set it up rather than a GUI, but it would be pretty trivial to
whip up a graphical frontend. About 15 minutes in Tcl/Tk, I'd say.
> Rather than, let's see, my keyboard is set to channel one and is
> connected to the first port of my second Midi card. I need to set
> my MidiArpeggiator,MidiEcho, and Sequencer Track one to receive on
> channel one and output on channel 5 of the third port of my first midi
> card...
The more I think about MIDI, the more I think that channels should never
be used for routing. They're too important as the means by which to
attach controllers to notes. I'd like to be able to send a full 16
channels to the same patch, just in order to set the pitch bend separately
for each of the 16 notes in a cacophonous chord.
For routing, virtual (or physical too, I suppose) MIDI ports are a must.
That's why I like using FIFOs for the purpose... [practically] no limit on
the number of them you can have open at a time.
> Yes. In my above scheme, MidiArpegiator and MidiEcho are simple plugin
> applets. I just wonder about debugging such applets if I made them
> alsa kernel clients. However, if I could find a nice abstraction for the
> building blocks of things like arpegiator and echo, perhaps a limited
> set of primitives could be written and debugged once, and be combined
> in unlimited ways by the user.
Why does everybody like plugins so much? What's wrong with small,
coorperating, standalone apps?
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST