[gmpi] Re: 3.15 MIDI (What does it mean to be a plugin)
- From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 22 Jun 2004 10:14:47 +0100
On Tue, Jun 22, 2004 at 01:20:19 -0700, Chris Grigg wrote:
> >Also, your comparison with OSC is not quite right, a GMPI control event
> >would be more like (/some/control/path set 10.0),...
>
> Ah so, parameter name as part of path, then method name. Got it,
> thx. Of course this needs to be extended to work with note-ids for
> note-linked params, etc.
Dont read too much into that, its just an example - there are plenty of
systems where OSC messages are implicitly "set value" instrucitons (eg.
super collider IIRC), thats just an example of what you could use if you
had multiple operations on a path.
> >... just because the GMPI
> >events could be regarded as messages doesnt mean thier intended to be an
> >arbitrary IPC mechanism, just like VST's parameter setting function is not.
>
> Sure, but since there has been no firm picture of the message/event
> model, all we can do is illustrate what we think it might tirn out to
> be, and only by analogy to other, older things.
I think we agreeded them to be timestamped events call(backs) with ramps.
That may not have been captured though.
> >I also dispute your statement that its unusual to have control change
> >'commands' (events, calls, or whatever) be isomorphic to parameter value
> >setting in any plugin system. In many systems its explicitly so, the only
> >difference here is that thier timestamped.
>
> I agree with you, because that isn't what I meant. A control change
> command -is- parameter value setting. The distinction I was making
> is between parameter value setting (named in whatever way) and other
> kinds of command, like whatever the GMPI equivalent of note-on will
> be, or reset, etc.
Ah, I see. But it seems highly likely those will be ditinct things - I
think thats the only solution that satisfies the existing requirements.
> > > More pertinently, I see problems with the fundamental assumption that
> >> plug P's state at arbitrary time T is always adequately represented
> > > by state of P's published parameters at T.
> >...
> >
> >I understand your concern, but we have sustantial eveidence that it /does/
> >work (~200 LADSPA plugins). It doesnt really matter if the occasional
> >plugin doesnt use set(/some/path, val) to mean /some/path = val. In
> >practice it will stil be automated otherwise the control behaviour would
> >just be plain wierd in normal use.
>
> ?? -- My point there wasn't to do with the message model, it was
> about whether param state is a good enough proxy for true plug state.
> What's the link?
Thats what LADSPA does - it has no sPA() call, and the host mediates (and
hosts) all parameter values, and its automation is done by the host
replaying parameter changes.
- Steve
----------------------------------------------------------------------
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:
