[gmpi] Re: New Reqs 3.8 - Events
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 19 Dec 2003 11:57:59 +1300
> the sequencer that's driving a synth plug-in already has all the
> future note events stored in the track. And .could. make them
> optionally available to the plug...
>Yes, there are some hosts that allow the
> insertion of MIDI processors, but for the most part you just insert
> an instrument and the track MIDI events are fed directly to the
> instrument, nothing intervening. So no time paradoxes.
Unfortunately my host is modular, so it's quite common to have something
like....
[MIDI In]->[MIDI Transpose]->[MIDI Apegiator]->[Soft Synth]->[Soundcard]
I can't promise a synth direct access to the track. Even non-realtime I
can't stop the user inserting MIDI effects.
So I'm just saying that for me, it's very difficult. I don't want to
dissappoint my users by not fully supporting GIMPI.
> Not agreeing with your premise that a pure offline plug is necessary,
> but let me ask for clarification: Would that be a GMPI plug, or not?
Hopefully, yes.
> If so, doesn't there still need to be a way to feed the plug the
> whole timeline in GMPI anyway?
I fully agree with your need for this feature....
My gut feeling is that an offline-plugin is the right way to provide it. An
offline plugin has full access to the music track, without compromise.
without 'hacks'. Offline, you can even chain MIDI effects, and still have
everything work as expected (the host does multiple passes).
My guess is that an offline plugin will be 99% the same as a realtime
plugin, but will need a few extensions to the API to allow the offline
plugin to make multiple passes over it's input events ( a kind of decoupling
of it's output stream timing from it's input stream).
Also remember, a clever host can make an offline plugin just as convenient
as a real-time one (by pre-calculating it's output). Provided the plugin is
applied to a pre-recorded sequencer track, the user need never know.
I've never written an offline plugin though, so I'll leave this discussion
for more experienced people here.
Best Regards,
Jeff
----- Original Message -----
From: "Chris Grigg" <gmpi-public@xxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Friday, December 19, 2003 10:16 AM
Subject: [gmpi] Re: New Reqs 3.8 - Events
> Jeff said:
> >Hi Chris,
>
> Hey Jeff.
>
>
> > > One possible compromise would be to allow any plug that wants it to
> >> request a second event queue... and have
> >> lookahead well beyond the current process() frame.
> >
> >"Non-causal systems exist in theory, but they cannot exist in the real
> >world". - Digital Filter Designer's Handbook.
>
> Heh heh heh.
>
>
> >The only way a real-time plugin can look into the future is via
> >host-provided 'delay compensation'.
>
> That's one way, but take off the 'real-time' blinders and obviously
> the sequencer that's driving a synth plug-in already has all the
> future note events stored in the track. And .could. make them
> optionally available to the plug, .if. that's something we think
> worth adding to GMPI.
>
>
> >The plugin requests a certain latency,
> >the host provides events in advance, and delays all other plugins to
> >compensate. ( VST does this ).
> > The disadvantage is that delay-compensation increases the overall
system
> >latency, so playing soft-synths in real-time becomes sluggish.
> >
> > Any less rigid system falls apart as soon as you chain two or more
> >plugins (where each wants to peek into the previous event queue). Like
the
> >plot of "TimeCop", the more you think about it, the more impossible it
> >seems.
>
> Sure, but recall that I'm suggesting limiting the use of this to
> music control events. Yes, there are some hosts that allow the
> insertion of MIDI processors, but for the most part you just insert
> an instrument and the track MIDI events are fed directly to the
> instrument, nothing intervening. So no time paradoxes.
>
>
> >My guess is that host-provided-delay-compensation is most suitable for
> >short-term lookahead ( typically less than 1 second ).
> > For longer lookahead, the best solution is a pure offline plugin,
where
> >the plugin has access to the song's entire timeline, and can even perform
> >multiple passes over the musical and audio data.
>
> Not agreeing with your premise that a pure offline plug is necessary,
> but let me ask for clarification: Would that be a GMPI plug, or not?
> If so, doesn't there still need to be a way to feed the plug the
> whole timeline in GMPI anyway?
>
> Also I'm not suggesting a 'processReplacing()' for the track data,
> which what you're describing above kinda sounds like. (Much as I'd
> like to see something along the lines of OMPI standardized and widely
> used.)
>
> -- Chris G.
>
> >Best Regards,
> >Jeff
> >
> >
> >----- Original Message -----
> >From: "Chris Grigg" <gmpi-public@xxxxxxxxxxxxxx>
> >To: <gmpi@xxxxxxxxxxxxx>
> >Sent: Thursday, December 18, 2003 10:44 AM
> >Subject: [gmpi] Re: New Reqs 3.8 - Events
> >
> >
> >> Sorry to do this, but can I revisit an earlier decision?
> >>
> >> I said:
> >> >This seems to imply that when the plug receives events, all event
> >> >times are expressed in sample numbers, as opposed to musical time or
> >> >anything else. Was this intended?
> >>
> >> Tim said:
> >> >That's right - that's what was decided the first go-round with these.
> >>
> >> I said:
> >> >I know we had a long, painful discussion on all this once but don't
> >> >remember the resolution. There was one efficiency issue that
> >> >musical time events sitting in a queue that the plug could look
> >> >ahead into would of course have to wiggle around in
> >> >sample-time/abs-time space in the event of tempo changes, and that
> >> >that could mean a lot of wasted cycles and maybe reordering in the
> >> >event buffer.
> >>
> >> I'm concerned that having no possibility for look-ahead is going to
> >> limit GMPI, and my intuition (sorry, that's the best I can offer) is
> >> that this will be more of an issue for musical performance events
> >> streams than it will be for mix automation style events. Maybe I'm
> >> just wrong about this, but I would like to hear what some of the
> >> experimental music advocates have to say about the matter.
> >>
> >> One possible compromise would be to allow any plug that wants it to
> >> request a second event queue, which would be different from the main
> >> event queue, in that it would use musical timestamps and have
> >> lookahead well beyond the current process() frame. The host would
> > > add future note (and other performance controller) events to this
> >> second queue as soon as they became known. Once added to the queue
> >> the events would not change (because their musical times do not
> >> change with tempo changes as happens with sample timestamps) so queue
> >> maintenance work would be minimal (and only for plugs that request
> >> it). With this kind of queue, the plug is free to look as far ahead
> >> as it cares to, but the host and system burden is kept small. In
> >> fact, the musical queue could be just an index of { musTimestamp,
> >> eventID } pairs, i.e. references to event message records stored
> >> elsewhere, including in the main event queue.
> >>
> >> Now, i's quite possible that the use cases for musical look-ahead
> >> aren't strong enough to justify this kind of thing, but I felt the
> >> idea should be at least mentioned during this pass.
> >>
> >> -- Chris G.
> >>
> >> ----------------------------------------------------------------------
> >> Generalized Music Plugin Interface (GMPI) public discussion list
> >> Participation in this list is contingent upon your abiding by the
> >> following rules: Please stay on topic. You are responsible for your
own
> >> words. Please respect your fellow subscribers. Please do not
> >> redistribute anyone else's words without their permission.
> >>
> >> Archive: //www.freelists.org/archives/gmpi
> >> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to
unsubscribe
> >>
> >>
> >>
> >
> >
> >----------------------------------------------------------------------
> >Generalized Music Plugin Interface (GMPI) public discussion list
> >Participation in this list is contingent upon your abiding by the
> >following rules: Please stay on topic. You are responsible for your own
> >words. Please respect your fellow subscribers. Please do not
> >redistribute anyone else's words without their permission.
> >
> >Archive: //www.freelists.org/archives/gmpi
> >Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
>
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules: Please stay on topic. You are responsible for your own
> words. Please respect your fellow subscribers. Please do not
> redistribute anyone else's words without their permission.
>
> Archive: //www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
>
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
