[gmpi] Re: 3.11 topic: Spontaneous parameter changes
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 5 Apr 2004 19:28:13 +1200
Hi Tim,
> It was asked how to support plugin-originate parameter changes...
> The requirements do suggest a listener model....
> While this makes for good MVC seperation, it might be too much overhead.
A listener model is ideal. Many modern GUI frameworks use this method.
Whenever the parameter changes, the GUI element is infomed and gets
'repainted'. In a cleanly designed system, there is no 'overhead'.
> Parameters which might change spontaneously or which might
> reject some in-bound values should be flagged.
This is premature optimisation. There's no need for special 'in-bound only'
parameters. All VST parameter changes are bi-directional, there's no problem
there.
>GUIs can see set up
> listeners for only the parameters which might need them.
All GUI controls need to be 'listeners', parameter changes come from many
sources (program-change, MIDI CC's, plugin parameter-morphs etc) , not just
the GUI. The GUI can never assume it's in charge.
Best Regards,
Jeff
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: "GMPI list" <gmpi@xxxxxxxxxxxxx>
Sent: Monday, April 05, 2004 6:47 PM
Subject: [gmpi] 3.11 topic: Spontaneous parameter changes
> It was asked how to support plugin-originate parameter changes. This was
> expanded to include parameters which may not accept a value, even though
it
> is technically in-bounds.
>
> The use cases given were:_
> - two parameters knobs which are offset but locked. The maximum value of
> the smaller of the two is (max - offset).
> - plugin-based patch morphing. Many plugins are doing this today. The
> knobs move spontaneously in the GUI based on some morphing rules.
>
> The requirements do suggest a listener model, which alleviates a lot of
this
> problem. The plugin alerts the listeners that a parameter is changing.
> This means that all GUIs attach a listener to the controlled parameters.
> While this makes for good MVC seperation, it might be too much overhead.
>
> It was proposed that controllers can assume that an in-bounds value will
be
> accepted. Parameters which might change spontaneously or which might
> reject some in-bound values should be flagged. GUIs can see set up
> listeners for only the parameters which might need them. All other
> parameters can be assumed to succeed for in-bound values.
>
> Q: What does the requirements doc need to say about this?
>
> ----------------------------------------------------------------------
> 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
>
>
>
----------------------------------------------------------------------
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:
