[gmpi] Re: Inter-parameter linkages

> C - It seems the Actor idea might be conceptualized more cleanly as
> an Parameter Event Processor method (or methods) of the plug object,

Yes, that's a clearer name. "Parameter event processor"

> 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,  We talk about DSP, GUI, and Actor 'objects', but they're all the same
binary.

Just like in VST, it's all a single dll, but conceptually you can imagine 3
'objects' in there..
-GUI
-DSP
-Parameter store

I like this, could this be in the spec?...

> "Parameter Event Preprocessing
>
> 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."

Jeff



----------------------------------------------------------------------
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: