[gmpi] Re: 3.14 UIs
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 31 May 2004 14:00:51 +1200
> >> On the other hand, are we sure param get/set a rich enough model for
> >> communication between the custom GUI code and the DSP code?
> So, displaying a frequency response plot of a filter .. then needs to be
done using parameters.
> Do you use a push or pull model for this? I mean: does the GUI have some
> "refresh-rate" (Idle method in VST world) and the GUI calls
getParameter... on the DSP part when it's allowed to do so, or does the DSP
part call setParameter... on the GUI? Or some different still?
Good question.
The DSP is sending updates to the UI. From the DSP's perspective it is
simply setting an "output parameter" (I think we're calling these
"controls").
The tricky bit is that UI and DSP are running in different threads, and
the DSP thread must NEVER wait on the UI thread, so DSP must be carefull not
to send more data than the UI can digest. The UI is refreshed on a regular,
timed basis (same as VST). So, even if the DSP sends many parameter
updates, they are processed by the UI thread at a fairly low rate ( 50Hz ).
I've moved my oscilloscope to this model. The scope captures a bunch of
samples into an array, then sends that to the UI for display. The scope is
capable of sending 1000's of captures to the UI per second, but you need to
limit the ammount of data being sent, else the entire GUI slows to crawl
trying to handle it.
My current solution is to use handshaking;
- DSP captures data, and sends to the UI.
- UI updates screen, then sends an 'acknowledge' signal to the DSP (via a
2nd parameter)
- DSP resumes capture..
This results in very nice 'load-balancing', whenever the GUI gets slowed
down or overloaded for whatever reason, the 'acknowledge' signal gets sent
less often, so the update rate reduces.
That's not an ideal solution though. What if you want two instances of
the GUI?. My current solution assumes only one. I would prefer a
multiple-listener type model.
I think the solution is for the DSP or Host to send updates to the UI at
a fixed rate. I
saw some stuff in the AU spec that seems to support this...
from http://developer.apple.com/technotes/tn2002/tn2104.html ...
"Listeners can be created to monitor changes in the parameters or properties
of an Audio Unit...While these notifications may be issued from real-time
priority threads, they may be received on another ...
... you must also specify the interval between calls to the event listener
proc, as well as the granularity with which the parameter value changes will
queued by the event listener proc. This will improve performance because it
defines the correct frequency for notifications to occur, which enables
Audio Units and hosts to react more appropriately to an event. For example,
when an event follows a previous one by a smaller time interval than the
granularity, then the listener will only be notified for the second
parameter change. This can be very helpful depending on the type of Audio
Unit or host being created. Please refer to AudioUnitUtilities.h for more
information and examples of notification intervals and value change
granularity."
I realise these type of implementation details are off-topic, apologies for
that, but hopefully my limited experience with this model can help us
understand the issues more clearly.
My own feeling is that this model makes sending parameter changes from
UI->DSP easy, but from DSP->UI more fiddly (but not impossible), and that
the advantages of having the host handle all the messy inter-thread
communication, locking etc, plus the ability to run the GUI over a network
makes it worthwhile.
Best Regards,
Jeff
----- Original Message -----
From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Monday, May 31, 2004 3:13 AM
Subject: [gmpi] Re: 3.14 UIs
> On Saturday, May 29, 2004 4:55 AM [GMT+1=CET],
> Jeff McClintock <xxxjeffmcc@xxxxxxxxxxxxx> wrote:
>
> >> On the other hand, are we sure param get/set a rich enough model for
> >> communication between the custom GUI code and the DSP code? I'm
> >> thinking about some of the great intricate signal displays we're
> >> seeing these days, seems like they could, perhaps, be needlessly
> >> cumbersome to express in those terms.
> >
> > Hi Chris,
> >
> > In anticipation of GMPI, I'm currently converting my code to use this
> > model. It does require a shift in thinking. To display say, a Spectrum
> > Analysis on the GUI, the data is passed from DSP to GUI via the host as
a
> > 'parameter', ( a binary-object parameter ).
> >
> > What i'm finding, is that by using parameters for all communication
> > between DSP and GUI, both DSP and GUI code become very straight-forward.
> > My plugin dosn't need locking code, or shared memory, It dosn't worry
> > about threading issues. ( The burden of inter-thread communication is
> > centralised in the host* ).
>
> OK, glad to hear you got things like that working that way. I was kind of
> worried about it too. So, displaying a frequency response plot of a
filter,
> or an ADSR envelope shape then needs to be done using parameters.
> Do you use a push or pull model for this? I mean: does the GUI have some
> "refresh-rate" (Idle method in VST world) and the GUI calls
getParameter...
> on the DSP part when it's allowed to do so, or does the DSP part call
> setParameter... on the GUI? Or some different still?
> Koen
>
>
>
> ----------------------------------------------------------------------
> 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:
