[LV2] Ui update rate

[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?

> 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?


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