[gst-devel] "bounties"/...

[Jonathan LIGER]

> > It seems to me that only GstData can be routed through pipelines.
> So the GstMidiEvent data would need to be encapsulated by GstData.

Sorry, what I meant was that there is currently only 2 classes of GstData
(Buffer and Events) and as many GstElements only know those 2 classes, Midi
data has to be one of those. I though for a while about adding a new type of
event and using the GstStructure field to pass Midi events data. It
eventually seemed not efficient at all. The last solution is using buffers,
and then serialized events. My idea was to use a 8 byte structure close to
raw midi data: 1 byte of flags (might need it one day), 3 bytes for the midi
message, and 4 bytes for the Midi tick.

> That looks like some useful info. Thanks for the link. At this point,
> what code has been written in regards to MIDI?

As much as I know, Nothing :). I wrote a Midi source/sink pair using the
alsa sequencer. It definitely needs to be re-written but it was a first
test.

> Should we use the GStreamer devel email list for discussion of this
> topic?

Yes. Anyone could then have a look and give feedbacks.

> Defining GstMidiEvent is step one and getting it encapsulated in
GstData.

See above.

> GStreamer MIDI could be modeled after the ALSA sequencer, since its
pretty sweet.

What do you mean? The interface is already imposed by the GstElement class.

> The MIDI proposition document you gave me the link for above mentions
> that blank events need to be sent at regular intervals, this seems
> hackish.

I didn't like that one neither.

> A proposal was in there for control type pads, has this been
created yet?

I don't think so.

> Some thought needs to be put into the idea of immediate MIDI events
versus queued (emitted at a specific time) events.

I though about a "nearly immediate" way of routing event with a loop-based
source element polling the alsa sequencer and calling gst_pad_push each time
an event is received. This would result in the creation of small data
buffers. To avoid fragmentation, data could be allocated by a memory pool
(events are constant sized, we just need to overload the default "free" and
"copy" method fields of GstData).

Cheers.