[gmpi] Re: 3.15 MIDI (goals.undo vs. playing)
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 19 Jun 2004 16:52:56 -0700
On Sat, Jun 19, 2004 at 01:24:34PM -0700, Chris Grigg wrote:
> It seems like one thing to say that if a plug is written a certain
> way, then the author needs to be aware that undo will not be possible
> and all the user issues that that implies, and another thing to say
> that all hosts must always provide undo functionality and all plugs
> must be 100% undoable and outlaw certain plug writing approaches in
You've missed the in-between. All GMPI operations must be possible to
undo. Whether the host chooses to undo them or not, is totally host
specific.
I'd like to outloaw writing plugs in such a way as to not be undoable, but
the truth is, someone will find a way and a justification.
So we just make it easy to do "right" and discourage doing it "wrong".
That's all we can do. Or we can revoke their GMPI license :)
> That model is perfect when there is a known set of controls, as in
> simple effects plugs, but it's not so clearly perfect for more
> command-like events like notes, or state reconfigurations that can
Undoing a note is nonsensical. Now, if noteOn happens to map to a switch,
as your example, then it makes sense. But if a note maps to a note, there
is nothing to undo. The host might have some concept of undoing a
recorded note, but that is totally different. It doesn't affect the
plugin.
> Blobs are different, but maybe settled enough to concretely
> illustrate some issues. What is the state of a blob parameter before
> the first blob is sent? (How does the host know the initial state of
> .any. parameter, for that matter?
I'd think it was reasonable to expect the plugin to provide default
values.
> And, since the plug is allowed to
> alter its parameter set at runtime, is the plug obligated to also
> provide the host with the initial value of every newly created
> parameter when it makes the new name available?)
Short answer - yes. Why not?
> What the state of a
> blob parameter when multiple blob types are received on the same GMPI
> parameter? Wouldn't you at least need one GMPI parameter name per
> command? Etc.
This is a limitation of blobs, which potentially makes them un-undoable.
If you can receive multiple types on a blob, it's trixy. Which is why I
am not against special-casing SysEx.
----------------------------------------------------------------------
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:
