[gst-devel] MIDI/OSC update

[Josh Green]

A question to veteran GStreamer developers (who don't want to read the
whole email).

Is GstEvent, in its current state, adequate for networking MIDI events
or control values using GstStructure? Or would it be better to create a
new GValue based GstData type?


On Fri, 2004-09-10 at 17:00, Leif Johnson wrote:
> Hi Josh -
> 
> Thanks for your response ! I was just reading over the mails you posted
> earlier.
> 
> On Fri, 2004-09-10 at 12:28 -0700, Josh Green wrote:
> > The method I am using to pass MIDI is using the previously mentioned
> > GValue event object (which looks a lot like a GStreamer event or
> > buffer, except the payload is a GValue).
> 
> The GValue concept is cool, but I'm wondering if we couldn't just use
> the GstStructure that's already in GstEvent ? A GstStructure is pretty
> much a collection of named GValues, so it's perhaps a bit more complex
> than the single GValue-in-a-buffer (mmm, pig-in-a-blanket ?), but it
> might still work.
> 
> With a GstStructure approach all the parameters contained in a MIDI
> event can be stored in fields in the GstStructure, and in your approach
> it sounds like there's a dedicated GObject holding the parameters.
> Either way it's helpful to have a support library for interpreting all
> the MIDI parameters in the event.
> 

I hadn't noticed that GstStructure in the GstEvent before. Sounds like
your method could be implemented with GStreamer as it is now, which is a
plus. It looks like the GstStructure stores the parameter names as
GQuark integers, which means it is fairly efficient in regards to
allocation. Speed critical code could also cache the GQuarks for the
individual MIDI fields to save on having to look them up.

Like I mentioned before, I'm not really familiar with GStreamer yet.
Here are some questions I currently have in regards to using a GstEvent:

- Are GstEvents adequate for passing around MIDI data?
- I notice there is a GstEventType enum field, would we need to add an
additional enum or could one of the existing ones be used?
- Is the rest of the GStreamer architecture ready for additional
GstEvent types to be added? Or would it cause problems?

I think an advantage of going the GstEvent route is that we could
leverage off of already existing architecture (perhaps not have to
change existing API). On the other hand, we should make sure this system
is adequate, and decide if it makes sense to instead create a new
GStreamer GstData type. Note that the GValue container could contain a
GstStructure since it is a boxed type :)

> > I then created a MIDI GBoxed type which is modeled off of the ALSA
> > union structure that the ALSA sequencer uses to pass around MIDI
> > events. This boxed structure can then be sent using the GValue event.
> 
> This sounds really good to me ; I think I was going after a similar
> approach, but I wasn't using the ALSA union for inspiration. (Actually,
> I was looking at Java's MIDI and sequencer libraries [1] ...) It sounds
> like we could combine a lot of our efforts on this point and come up
> with a nice MIDI library.
> 

Sounds great! I'd really like to see GStreamer with support for MIDI. I
think a system of networked value/event controls could also be nice
(connect arbitrary GObject properties, etc to controls, like GUI
widgets, external MIDI gear, etc). Maybe this type of event network
could also use the GstEvent.

> > I like the idea of adding GValue event capabilities to GStreamer, but
> > perhaps it is overkill?
> 
> I also like the idea of being able to pass around GValues in events ...
> but it seems to me like GstStructures would be functional enough.
> Perhaps the only concern might be speed : Reducing a GstEvent to a
> single GValue could help minimize the need for lots of allocations.
> 

Allocation for a GstEvent using GstStructure would look like:

- GstEvent gets allocated
- GstStructure gets allocated
- Individual fields get allocated using a GArray (GQuark and GValue),
this would likely be a single allocation in our case (I think GArray's
have a minimum array size which gets allocated??)

The method I was discussing would look like:
- GstValueEvent gets allocated (contains a GValue structure)
- GstMidiEvent union gets allocated

So the solution I was proposing is probably a bit less overhead.

In my opinion, if GstEvent seems adequate for this task (without
breaking current API), lets use it. If for some reason it needs to be
extended or changed (thereby breaking current API), lets just start with
a new GstData type? This is just my current thinking though, and coming
from a n00b GStreamer developer :)

> > I'd like to help with this effort. I'm new to the GStreamer
> > architecture, but I'm very familiar with the GObject/glib/GTK+
> > programming model, since this is what Swami is built on as well. It
> > would be nice to have a CVS branch where those of us interested in
> > working on this, could pool together efforts and make it happen.
> 
> That would be cool !
> 
> leif
> 

I think our first task is to decide, GstEvent or some new GstData type
like "GstValueEvent".

Its exciting to have someone else to work on this with. Looking forward
to seeing GStreamer get MIDI support.
	Cheers!
	Josh Green

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040910/0f3fda4f/attachment.pgp>