[LV2] Ui update rate
robin at gareus.org
Sun May 5 04:31:26 PDT 2013
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.
>>> 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
--- 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.
I've reported it upstream on IRC and different related context:
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.
More information about the Devel