[gmpi] Re: Inter-parameter linkages

Hi all, sorry to grouse and run earlier. Great discussion on this point, and I'm just coming back up to speed. Sorry this is late, but I do have a couple comments on this topic:

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.

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 like a big assumption to me, and if it's not true, then it seems morph functionality would have to belong to the plug, where each param can be handled with the appropriate curve, not the host. (Unless you did e.g. a default library linear version in the host and allowed the plug to optionally override it by providing the host with a function pointer to a custom morph param handler.)

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.

Here's an alternate whack at a write-up, avoiding 'Actor,' splitting the two parts (per-event & periodic) up, and making it part of the plug object -- I think it's more specific than Tim's current 'Actor model' language, though it might also have some errors:

"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."

Warm? Cold?

-- Chris

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