[LV2] Ui update rate

[hermann meyer]

Am 04.05.2013 19:53, schrieb Robin Gareus:
> On 05/04/2013 07:38 PM, hermann meyer wrote:
>> Am 30.04.2013 16:10, schrieb Harry van Haaren:
>>> On Tue, Apr 30, 2013 at 3:00 PM, hermann meyer<brummer- at web.de
>>> <mailto:brummer- at web.de>>  wrote:
>>>
>>>      Is there a way to receive the UI refresh rate from the host?
>>> Currently, no there is not, if you're using the LV2UI_Idle_Interface
>>> to redraw your UI?
>>>
>>>      It could be helpful to now this for analyze plugs.
>>>
>>> I'll agree, there are many use cases where intended framerate of UI
>>> would be useful.
> +1
>
> as a side-note: I recently patched jalv.gtk. With jack2 its default
> plugin<>UI Atom message rate is 2Hz! Hence no matter how fast the UI
> runs that's a worse bottleneck.
>
>>> Most are for eye candy.. but your analyze plugs are a better example
>>> where its needed ;)
>> Eye candy is as well a other side of the strip, and I wouldn't put it
>> such below then a analyzer plug.
>> If LV2 ever would be a competitor to other plugin standards (and I
>> really hope it will), we need a better way to redraw the UI. Be it for
>> eye candy, for analyze, or for user feedback.
> If you must, just don't use the Idle callback and start your own thread.
> That's also what VST plugins do when they require rapid updates.
>
>> At minimum as a plug-in developer I need to know the UI refresh rate,
>> otherwise any calculation to give users a feedback running into a hole.
> Why would you do timing relevant calculations in the UI thread anyway?
>
> UI updates will never be as accurate as the timing you get in the
> audio-thread.
>
>> And it didn't differ here if it be just a eye-candy or the calculation
>> of a fallback parameter from a simple VU meter.
> Have a look at https://github.com/x42/balance.lv2. It includes a PPM
> meter according to IEC 60268-18: 5ms integration 20dB/1.5 sec fall-off.
> (NB run it in ardour or convince jalv to send messages faster than 2Hz).
>
> Cheers!
> robin
>
>
>
Hi Robin

Thanks for your response,

I wouldn't do the time critical calculation in the UI thread, but it 
drives me to to the nuts that I wasn't able to provide the results from 
the audio process to the UI in a reliable time shed.
I will have a closer look at your plug. It seems I could find the 
solution for my problem in your source.
As well it didn't come to my mind right now to run my own GUI thread, I 
will start to experience with that idea. :-)

greets
hermann