Re: [linux-audio-dev] MIDI routing, FIFO's etc.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST