[LV2] Ui update rate

[hermann meyer]

Am 05.05.2013 13:31, schrieb Robin Gareus:
> On 05/05/2013 05:53 AM, hermann meyer wrote:
>> Am 04.05.2013 20:36, schrieb 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.
>>>>
>> Well, I see I've ask the question wrong, I mean indeed the communication
>> rate from plugin to UI.
> Hi Hermann, Hi LV2devs,
>
> They are really the same.
>
> It does not make sense to update the UI more frequently than it can
> receive/send messages. - The only exception are display animations which
> operate independently on the current data.
>
> So screen "update-rate" should equal "message update-rate" and plugins
> that do want to do /fancy/ things should create their own threaded event
> loop (and get their own connection to the x-server to avoid xlib/xcb
> threading issues -- not a problem on win or OSX).
>
> Do you agree?
Hi

Yes, I agree here full!!
After I have checked my plug now in ardour and qtractor, I see that it 
is indeed only a problem in jalv.
So for my case i didn't need a own GUI thread, but I could very well 
imagine cases where it will be fortune.

>> Is your patch for jalv.gtk available somewhere?
> It's just one line, quick/dirty to help myself. With jalv this should
> probably become a commandline option:
>
> $ svn diff
> Index: src/jalv.c
> ===================================================================
> --- src/jalv.c	(revision 5105)
> +++ src/jalv.c	(working copy)
> @@ -1046,6 +1046,7 @@
>
>   	/* The UI can only go so fast, clamp to reasonable limits */
>   	jalv.ui_update_hz     = MIN(60, jalv.ui_update_hz);
> +	jalv.ui_update_hz     = MAX(25, jalv.ui_update_hz);
>   	jalv.opts.buffer_size = MAX(4096, jalv.opts.buffer_size);
>   	fprintf(stderr, "Comm buffers: %d bytes\n", jalv.opts.buffer_size);
>   	fprintf(stderr, "Update rate:  %d Hz\n", jalv.ui_update_hz);
>
>
> The issue originates from different midi buffer sizes: jack 1 uses (4 *
> period_size) - jack2 is using 32kbytes.
>
>    jalv sets update_hz to (sample_rate / midi_buf_size * 2.0);
>
> I think that ideally there should be a host feature akin to
> LV2_BUF_SIZE__maxBlockLength that announces the msg processing rate to
> both plugin and UI.
>
> Thoughts?
Thanks Robin, I will try that, jalv is the host I use for development, 
and the UI refresh / signaling rate limitation makes it hard to run 
analyzers therewith.
I think even if the host cant guarantee a frequent refresh rate (if he 
do it on idle), it will be helpful if the plugin (Ui) have a way to know 
about that.

greets
hermann

>
> I've reported it upstream on IRC and different related context:
> http://dev.drobilla.net/ticket/899
> jalv handles all Atom Ports as MIDI ports - even if they're only for UI
> communication and do _not_ atom:supports
> <http://lv2plug.in/ns/ext/midi#MidiEvent>. It's very easy to overflow
> the Atom msg queue with UI messages when using jack1: (4 * period_size)
> bytes can be quite low.
>
> Cheers!
> robin