[gmpi] Re: Requirements
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sat, 15 Nov 2003 12:02:31 +1300
> Just to clarify, we're talking about something like (examples):
> * host provides a gui engine
> * plugin calls gui engine for things like "add a knob at (x,y) with
callback
> function foo"
>
> Is that right? Then the host is responsible for actually displaying the
UI
> and sending GUI events to the plugin callbacks?
Oh, no :-), I was thinking something totally different. I'll explain
properly....
(as usual, feel free to comment/disagree...)
I'm not really talking about how the GUI is drawn (whether via a
cross-platform toolkit or whatever). I'm talking about simplifying the
plugin, and cleanly seperating the GUI into an abstract entity.
So how is this implemented?
You write an audio plugin. A 'black-box' with all it's parameters exposed.
There is only one way to set a parameter, via the host. The plugin knows
nothing about GUIs.
You (optionally) write a GUI class. Think of it like a MIDI control
surface, it has knobs, sliders, readouts whatever, but all it's interaction
with the plugin is 'down a wire' via the host.
It says to the host:
-"I'm a GUI for 'Johns_Reverb_plugin"
-"Send me the plugin's current state"
( host sends....
"Param-1 (Volume) = 5.0",
"Param-2 (Mix) = 3.0",
etc.....)
The GUI set's itself up to reflect the state of the plugin.
The user moves a knob on the GUI.
The GUI says to the host:
"Set Param-1 (Volume) to 9.0"
The host sends a Set-Parameter message to your plugin.
Why?, why? why, Mr Anderson.
I use VST, the current state of affairs is a big pain...
-Your plugin must expose it's parameters for automation.
-It must also expose it's parameters to it's GUI.
So, right away, you've creating two interfaces to do the same thing. (bad)
Also, there's no rules about when the host will set parameters, or what
thread is setting your parameter(UI or Audio-engine).
So, any non-trivial plugin has to deal with thread-safety, serialising
access to internal parameters via mutex locks etc. What a pain.
My scenario above is saying, make the plugin super-simple. make it expose
all it's parameters, and promise the plugin won't have to deal with multiple
threads (at the same time).
- You write your plugin's set-parameter code once. LESS work for the plugin
writer.
- The host can record the events for automation ( the plugin needn't notify
the host via 'doAutomation' events). LESS work for the plugin writer.
- The host can ensure parameter changes are all sent 'between' calls to
DoProcess(). So the plugin dosn't have to implement complicated thread-safe
locking mechanisms. LESS work for the plugin writer.
- The GUI can run in a seperate address space (think VST System Link, think
rack-mounted DSP boxs with GUI running on your PC).
But, of course, for backward compatiblilty with VST, we have to also support
the VST-way.
oh well,
Jeff
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Saturday, November 15, 2003 10:50 AM
Subject: [gmpi] Re: Requirements
> On Sat, Nov 15, 2003 at 10:00:34AM +1300, Jeff McClintock wrote:
> > > you cannot write Halion with XML+layered bitmaps. i want to be able to
> > > write GMPI plugins like Halion.
> >
> > agree, a good thing about VST, is that you have two options:
> > -use the VST GUI SDK which provides a cross platform GUI framework.
> > -ask the host for a native window, and handle all drawing yourself.
> >
> > The VST GUI SDK is a seperate SDK. That's important. You arn't forced to
use
> > it.
>
> I agree, and I had actually written something like that in an early draft
:)
>
> > How we draw graphics isn't important, What's important is a standard
> > interface/protocol between the GUI and the plugin.
>
> How do I describe this for the reqs?
>
> Just to clarify, we're talking about something like (examples):
> * host provides a gui engine
> * plugin calls gui engine for things like "add a knob at (x,y) with
callback
> function foo"
>
> Is that right? Then the host is responsible for actually displaying the
UI
> and sending GUI events to the plugin callbacks?
>
>
>
> ----------------------------------------------------------------------
> 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:
