[gst-devel] Midi and GStreamer
Christian Fredrik Kalager Schaller
uraeus at gnome.org
Mon Jul 14 22:48:06 CEST 2003
Ok, I am just making sure Nick is getting this as I am not sure he is on
gst-devel yet :)
On Mon, 2003-07-14 at 21:56, Leif Johnson wrote:
> Hi all -
> It seems like GStreamer could benefit greatly from a different subclass of
> GstPad, something like GstControlPad. Pads of this type could contain
> control data like parameters for oscillators/filters, MIDI events, text
> information for subtitles, etc. The defining characteristic of this type of
> data is that it operates at a much lower sample rate than the multimedia
> data that GStreamer currently handles.
> GstControlPad instances could also contain a default value like Wingo has
> been pondering, so apps wouldn't need to connect actual data to the pads if
> the default value sufficed. There could also be some sweet integration with
> dparams, it seems like.
> Elements that have control pads could also have standard GstPads, and I'd
> imagine there would need to be some scheduler modifications to enable the
> lower processing demands of control pads.
> Unfortunately, as is probably obvious, I don't know enough of the GStreamer
> core to tell if this is a good idea or not, but I'd really appreciate
> comments. This would be cool if it worked out.
> On Wed, 09 Jul 2003, nick wrote:
> > Hi All
> > The thing I am thinking about is how a gstreamer plugin would handle
> > MIDI and audio at the same time... In my mind, this requires the midi
> > and audio buffers to be processed on a 1-to-1 basis (so 1 buffer of
> > audio and 1 buffer of midi cover the same duration of time).. Does what
> > I'm saying make sense to you?
> > (For me, I would want to be able to write amSynth as a plugin - this
> > would require that when my process function is called, I have a midi
> > buffer as input, containing how ever many midi events occurred in, say,
> > 1/100 sec for example, and then I generate an audio buffer of the same
> > time duration...)
> > Any ideas? Maybe this will indicate the kind of problems to be faced.
> > Nick
> > On Tue, 2003-07-08 at 13:43, Benjamin Otte wrote:
> > > On 8 Jul 2003, Christian Fredrik Kalager Schaller wrote:
> > >
> > > > 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 don't really know why it were necessary to have a near-constant
> > > dataflow.
> > > Subtitling surely works with a very non-constant dataflow and the
> > > presentation from Thomas at GUADEC showed that it works.
> > >
> > > The only part of GStreamer that might need filler events would be realtime
> > > processing, where you want to know that nothing happened for some time.
> > > But it should not be necessary for midi file reading or anything else
> > > described in that post.
> > >
> > >
> > > Benjamin
> > --
> > nixx at nixx.org.uk | amSynth lead developer
> > JabberID: nixx at jabber.org | http://amsynthe.sf.net
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Parasoft
> > Error proof Web apps, automate testing & more.
> > Download & eval WebKing and get a free book.
> > www.parasoft.com/bulletproofapps1
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
More information about the gstreamer-devel