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: thudson_AT_cygnus.com
Date: la loka   09 1999 - 11:46:47 EDT


Paul Barton-Davis wrote:
>
> First, any program that only does I/O to /dev/midi should be shot at
> dawn. If it uses a user-selectable one of /dev/midiNN, it can live.
>
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.

> To get back to the default state of affairs: then you just need a
> small midirouting daemon that runs in the background, holds all
> /dev/mididev* device files open, and forwards data to and from
> /dev/midififo*. Note the inherent similarity to OMS here. I even wrote
> such a small daemon last year, but I rarely use it anymore. It even
> did channel splitting across ports, and I once had plans to do note
> splits across ports as well (i.e. if (noteNum > N) send_to (portA)
> else send_to (portB)). Fun stuff.
>
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

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...

Applets like MidiArpegiator of MidiEcho would be simpler to write
if they completely ignored channels and relied on user routing.
The routing app would "know" that the keyboard was set to channel
one and attached to midiC1D0:channel 1, and my external synth was
attached to midiC0D2: channel 5.

Enhance this with a nice graphical app that had a icon tray that would
allow drag and drop onto a canvas (launching apps when necessary), with
routing specified similar to Quasimodo with cabling. I drag and drop the
keyboard icon, the MidiArpegiator icon, connect them, etc.

> Also, the beauty of this kind of scheme is one of the things I have
> against the ALSA lib API for raw MIDI devices. Anything that tries to
> obscure or complicate the fact that a MIDI "port" is just a byte sink
> and source is evil :) Thats why I never use the ALSA lib API for MIDI,
> but just stick to regular Unix open/close/read/write on /dev/snd/midiCxxDyy
>
> Seriously though, I doubt the success of Linux for MIDI until the kind
> of facilities that OMS provides on the Mac exist *in the
> kernel*. There are people (myself included) who feel uncomfortable
> about having two context switches necessary to send MIDI data, have it
> delivered, and then get on with what I'm doing. Its not clear to me if
> the ALSA Sequencer can do all this, but it would be great if it could.
>
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.

Thomas


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