[gmpi] Re: Inter-parameter linkages

On Wed, Apr 28, 2004 at 12:48:35AM -0700, Chris Grigg wrote:
> A - How would circular links be handled?  Haven't seen this discussed 
> yet.  In other words, param B is a listener to param A, but param A 
> also happens to be a listener to param B.  Insert as many 
> intermediate links in the chain as you like, the problem is similar.

Real example?  I don't know that this is a real problem.  Or rather, I
don;t know that this is an API issue.  Don't do that :)

> B - All discussions of morphing/crossfading seem to assume that a 
> simple linear change curve is always going to be sufficient for all 
> parameters of all plugs forever, but is this -really- true?  Seems 

no.

> morph functionality would have to belong to the plug, where each 

yes.  I agree with that totally. :)

> C - It seems the Actor idea might be conceptualized more cleanly as 
> an Parameter Event Processor method (or methods) of the plug object, 
> not a helper plug-in or a separate object per se.  This would seem to 
> come closer to auto-packaging it with the plug binary.

Well, the actor needs to be called repeatedly somehow.  In the case of a
morph, the actor know the future of the events (unless something changes).
It has to be called for each process() loop.

The simplest answer is to make it a helper plugin, though we could end up
with a method that is called just before a plugin executes.  Same net
effect.

Either:
        actor->process();
        plug->process();

or:
        if (plug->preprocess)
                plug->preprocess();
        plug->process();

Keeping it as a separate plugin makes the host semantics easier.  keeping
it as a method may make plugin bundling easier.  Details details.  :)
Either way, there needs to be a synchronous method which UIs call.

> Every plug may optionally provide parameter event preprocessor 
> methods to transform received raw parameter-setting events (from any 
> source) into massaged, final events for use by the plug's process() 
> method.  This transformation may include value limiting (including 
> min/max range, or enum value allow/disallow), parameter linking 
> (using a listener model, and generating new parameter setting events 
> for the linked targets), certain self-automating plug functionality 
> (parameter morphing, randomization, etc.), and/or optional rejection 
> of events that request disallowed values for the parameter.
> 
> The plug may furnish two different Preprocess Parameter Event 
> methods, which are called in different ways and at different times:
> 
> 1) gmpiPlug::PreprocessOneParamEvent( ... ): The parent gmpiHost:: 
> calls this method on a per-event, synchronous basis as a validator 
> for UI-generated events (arriving from any GUI or hardware control 
> surface).  It sets the host-managed target parameter to the corrected 
> value [**or does it enqueue an event?**]. It also generates any 
> needed dependent events, for example parameter change events for any 
> linked parameters, and/or parameter change events to move hardware 
> control surface widget positions or update value displays to the 
> corrected value (if there are any UI listeners for that parameter). 
> (This method does not generate any events in support of 
> self-automation functions, though it may initiate and/or terminate 
> self-automation modes based on the received events.)
> 
> 2) gmpiPlug::PreprocessParamEventQueue( ... ): The parent gmpiHost:: 
> calls this method on a frequent periodic basis for processing 
> enqueued parameter events, typically immediately prior to each 
> process() call to transform all parameter events scheduled for that 
> timeslice, and also to generate and enqueue any needed 
> self-automation parameter events (for example, to implement parameter 
> morphing or randomization).  This method performs a process-in-place 
> operation on the queue, and may add events to the queue or remove 
> events from the queue.  Internally, the plug is free to call its 
> ProcessOneParamEvent() method to handle each enqueued event, if it is 
> written to be safe for use in the process() thread.
> 
> Plugs not interested in preprocessing their parameter events should 
> be able to provide the host with null ptrs for these methods, to 
> allow the host to avoid unnecessary plug method calls."

> Warm?  Cold?

I'm fine with the concept, but it's far too detailed for the req.  But now
it's on the record for spec fodder. :)  Come spec time, we need to add
something about the synchronous method returning additional events which
would occur at the exact same sample frame only.  Anything else is
enqueued internally and will be delivered by the regularly scheduled
method.

I'll revisit the language to accommodate some of the generalities :)

----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: