[gmpi] Re: Reqs 3.8 Events - gesture start/end
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 1 Jan 2004 22:34:14 -0800
On Thu, Jan 01, 2004 at 11:06:16PM -0700, Mike Berry wrote:
> >If we send it to sub-hosts and plugins, then are we expecting them to have
> >a
> >DIFFERENT undo mechanism than the outermost host? I hope not.
>
> I diagree. I think that this is reasonable. The case that I have in
> mind as a test for the gesture system is a host which is nothing but a
> graph containing a host which is a sequencer. The top host does not have
> an event-related undo, because it is entirely "real-time." The sequencer
> does have event storage, and therefore event undo, and so it needs the
> gesture events because it is not directly hooked to the GUI creating the
> events.
OK, Fair enough. As I said towards the end of my (long) email - we SHOULD
be sending the gesture events, anyway. Someone will use them, and this is
a good example.
> As I think about it, I think that we do not need gesture IDs. All we
> need is for the gesture event to refer to a parameter. All events for
> that parameter become part of the gesture, once a gesture start is
> received. For the XY case, two gesture starts are sent, one for each
> parameter. The receiver then makes its own decision about whether they
> are part of the same undoable action.
Well, that MIGHT work, but then it makes the host ASSUME things that may or
may not be correct. If an X/Y GUI can announce it's intentions, we should
enable that. The alternative is something like "A plugin which sends
multiple gesture-start events always means those gestures to be the same".
Why presume, when we CAN make it explicit.
> In fact, perhaps all we need is a couple of bits in a standard
> parameter event. This way you could flag an event as a gesture start or
> gesture end. For the case where you touch the fader but don't move it,
> the host sends a value that is unchanged but with the gesture start flag
> set. This way, it would be trivial for plugins that don't care about
> gestures to ignore them. They simply wouldn't look at the flag - they
> would simply process the event as normal. That way there is no need for
> the plugin to notify its capability to accept gestures, no extra parsing
> of unwanted events, and so on.
I think gestures are the sort of thing that ALL plugins have to handle or
disregard. Your suggestion of making them flags on a normal event is
isomorphic to a gesture start/end pair, except that in saving two events,
you've forced the sender to query the current state of the recipient before
sending, which is inherently a race condition.
> So my proposal is:
>
> - Events can be marked as the beginning or end of a gesture, for the
> purpose of facilitating automation recording by plugins. A marked event
> is otherwise identical to an unmarked event, and the gesture markings
> can be ignored by the plugin.
I personally find the idea of a gesture start/end pair simpler, but neither
of those really matter right now.
Assuming we have the actual model and use cases correct, we need to
encapsulate those into the requirements, all this can be re-evaluated at
implementation or spec time. We really don't know enough to truly decide
that yet :)
I think we're converging on the correct use-cases and actual requirements,
though we'll see if anyone balks next in the next few days. Some BIG emails
(as in size) came thru over break :)
Based on this email, Mike, I assume you and I see mostly eye to eye on the
use case, and have slightly different ideas about the model?
----------------------------------------------------------------------
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:
