[gst-devel] Midi and GStreamer

[Christian Fredrik Kalager Schaller]

Hi Nick,
Regarding Midi in GStreamer Steve Baker dug up this message he had
written about it. I hope it might enable you to get some ideas of
who/what and so on. Hope to hear from you soon.

Christian

Midi could be thought of in terms of dataflow as a sparse non-constant
flow
of bytes. GStreamer works best with near-constant data flow so a midi stream
would probably have to consist mostly of filler events, sent at a constant
tick-rate.

I think the following 3 elements would be most useful initially:
- midifileparse
takes midi file format data on sink pad, and produces timestamped midi data
on output. A property will specify what the tick rate would be (default to
96 ticks per beat or something). If no data exists for a given tick, it can
just send a filler event. Timestamp would be derived from the bpm property,
and the time deltas of the midi file data.

- ossmidisink
could be added to the existing oss plugin dir, sends midi data to oss midi
sequencer. Makes extensive use of GstClock to only send out data when the
buffer/event timestamp says it should.

- alsamidisink
guess what this does. don't know whether alsa's sequencer interface would be
better than its raw midi one. My money is on raw midi.

- ossmidisrc, alsamidisrc
real time midi input.

It would be nice to be able to transform midi to audio which can be further
processed in a gstreamer pipeline. Timidity might be the best hope for this,
but I don't think they have any intention of libifying it, so any timidity
plugin would have to communicate with Timidity in some out-of-process way.
Hadess claims that there is a librarified version of Timidity out there, but
I have never looked for it.

Once we have midi streams, we can start doing fun things like writing a
midi2dparams element which would map midi data to control the dynamic
parameters of other elements, but lets not get ahead of ourselves.


-- 
Christian Fredrik Kalager Schaller <Uraeus at linuxrising.org>