[gmpi] Re: Decision time: 8.2
- From: Marc Poirier <fipnid@xxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 24 Aug 2003 13:31:47 -0700 (PDT)
--- Steve Harris wrote:
> On Sun, Aug 24, 2003 at 05:59:03 -0700, Marc Poirier wrote:
> > I'm not following you anymore. What exactly is "the UI" in your mind
> > in this scenario? The interface for setting up automation modes? The
> > interface for changing parameter values? Something else?
>
> By UI I mean the controlling code that cause parameters in the (DSP)
> plugin to be changed.
>
> > So, I don't know if I'm responding to what you're actually saying
> > since I don't know what you're saying, but I'll try to clarify what I
> > was saying:
> > In order for a host to do something like "touch automation", the host
> > needs to be informed of when a parameter change gesture is about to
> > begin and when it has just finished. For example, if we're talking
> > about a typical context where the plugin has a GUI and the user is
> > moving sliders around with mouse to change parameter values, then the
> > begin notification would occur upon mouse down in a slider control and
> > notification would occur when the mouse is released. Maybe by saying
> > "the host includes the UI" and you meant the GUI with sliders? If
> > that's what you meant, then my response is, no, it could also be a
> > custom GUI for the plugin. And so there needs to be a way for the
> > plugin to say when a parameter gesture begins and ends.
>
> Right, and I dont see what that has to the with the DSP plugin - it
> doesnt know when the user has let go of the mouse - and if it cares then
> it can be informed by the UI - if would be a pramater of some kind (eg.
> the Z-axis on a touchpad).
>
> I am expecting automation to be handled by the host (this is the norm in
> the linux world), so the host cares about wether the user is trying to
> override exiting automation recordings or not, but the interaction is
> between the UI (be it hardware surface, GUI, whatever) and the host, not
> the DSP plugin and host, surely.
Okay, I'm starting to think that maybe I just don't know what issue you're
talking about on a more basic level. I've just been saying that there
needs to be a way to mark the beginning and end of parameter gestures in a
general way, so that anyone can produce those notifications: host, GUI,
DSP plugin, whatever. You seem to agree. So why was this even an issue
to begin with? I can't figure out anymore at this point...
> > > Undoing is a host feature, but I dont see why this is helps for
> > > undo.
> >
> > If helps because the host can query the current parameter value when
> > the gesture begins, remember that, and then use that as the value to
> > undo to, if the user wants to undo. If the host is only aware of
> > parameter changes as descrete events, then the host only knows the
> > value before the last nudge. So lets say that you just swept a
> > parameter from 3 to 9, and as you moved it, it generated parameter
> > values along the way: 3.3, 3.9, 4.5, 5.4, 6.3, 6.9, 7.2, 8.1, 9.
> > Without a notion of a parameter gesture, then the best that the host
> > could do to undo this parameter change would be to revert to 8.1. But
> > that is not what the user would be expecting. She would be expecting
> > it to revert to 3. Does that make more sense now?
>
> No, because I thought we had agreed that the host, UIs and whatever
> would be able to subscribe (in some way) to parameter changes, so the
> automation value could only be out by the range of one parmaeter change
> interpolationi, and even then its arguable wich value the use would want
> to be record in the undo data.
Sorry, but could you please be more clear? What on earth does "out by the
range of one parmaeter change interpolationi" mean?
> I strongly believe that the plugin should
> not asked to back-calculate the value of a parameter at arbitrary points
> -
> its quite a lot of work, and I dont see what its good for.
I'm not following you again. What "back-calculation" are you talking
about? I'm just talking about a scenario like this:
1. parameter adjustment begins
1a. the entity doing this generates notification of that beginning
1b. host hears the notification, checks the current value, remembers
it
2. parameter adjustment carries on
3. paramemter adjustment ends
3a. notification is sent that it's done
...
4. user decides to undo parameter change
4a. host sets the parameter value to the one that it remembered in
step 1b.
So the only extra work that I see here is checking the parameter value in
step 1b and setting it in step 4a. Getting and setting parameter values
should be normal stuff and not quite a lot of work. But again, I'm just
clarifying what I said before since I can't figure out what you're trying
to say.
Marc
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
----------------------------------------------------------------------
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:
