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

[Josh Green]

On Mon, 2004-07-19 at 04:16, Stefan Kost wrote:
> Another thought,
> 
> hardware-midi is contrained by the rate of the serial port, so you could model
> the midi in gstreame likewise, buffers with zero with the commands at the right
> time.
> 

I don't think that is a good way to do things though. Since while
hardware MIDI is constrained to 31.2k or so, any other medium is not
constrained by this rate. This includes routing of MIDI between
applications and over ethernet, etc. Also its a waste of bandwidth. Even
hardware MIDI doesn't have constant traffic (its not transferring 31.2k
at all times). And 31.2k is easy to saturate.

At this point I'm thinking of porting my implementation of SwamiControl
to a new GValue based GstData type. I have yet to hear any objections to
such an implementation, so please let me know if you think this is a bad
idea. One question I have is, what would be the side effect of adding a
new GstData type? This new type would be something that would not be
recognized by current GstPads, and perhaps never will be. It would be
useful to event/control oriented pads that want to pass around arbitrary
GValue events though. Along with this new GstData type would come a few
controls (naming convention not fixed in stone):

GstControlProp (arbitrary GObject property control)
GstControlFunc (attach function callbacks to a control)
GstControlHub (resends any received events to all connected controls)
GstControlMidi (a MIDI control helper that will use boxed GstMidiEvent
structures)

This matches the current implementation in Swami. Although the idea of
connected SwamiControl objects will need to be adapted to GstPads, caps
and such. I realize that I'm jumping on this without having a lot of
experience with GStreamer development. But I'd like to try and get
something started (regardless if its flawed or not) so as to get the
ball rolling with MIDI and event networks in general. Cheers.
	Josh Green