Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#19 LV2 Gtk2UI updates slowly

LV2 (3)
nick dowell

I have noticed this problem while testing the new LV2 version of amsynth.

When dragging any of the knobs on amsynth's custom (Gtk2) UI, the UI is very unresponsive. Both the plug-in UI and the application's UI become unresponsive.

It appears that GTK's run loop is being delayed somehow, resulting in events being fired at a much lower rate than expected.

The same problem is not present with the DSSI version of amsynth (which uses the same UI code) nor is it with other hosts tested - jalv and Ardour 3 beta 5.

Interestingly, Calf Monosynth's LV2 Gtk2 UI does not exhibit the same problem, so I investigated further...

I found that changing amsynth's LV2 UI so that it only calls the LV2UI_Write_Function from a timer (instead of from the "motion-notify-event" handler) the problem goes away.

But this does not feel like the correct solution, as it will slow down parameter updates. The UI really should be able to call LV2UI_Write_Function whenever it makes most sense (i.e. while the user is dragging.)


  • which qtractor version exactly?

    is it a(n old) debug build? are the stdout/err debug messages being captured on the qtractor messages log window, specially the ones related to lv2 plugin parameter changes?


  • On I don't see any parameter changes getting logged, neither in the log window nor on stdout/err. This is a build with debug enabled. lv2 UI updates very slowly when making changes in the lv2 UI. This doesn't occur when changing parameters with the Properties window of the amsynth plugin.

    Last edit: Jeremy Jongepier 2012-11-27
  • @Jeremy: and, do you notice any slowdown on the LV2 UI updates? because i don't.

    • Yes I do, it's terribly slow.

  • nick dowell
    nick dowell

    I observed this with qtractor svn revision 3070

  • looking from the screenshot in http://code.google.com/p/amsynth/issues/detail?id=42 it looks like View/Options/General/Capture standard output option is on--one can see some GTK warning messages--what happens if you try switching that off?


    ps. iirc. the triceratops author was reporting the very same slowdown on its lv2 ui under qtractor; eventually he got it solved somehow, so i'd suggest you to ask him what was the magic trick :)

    Last edit: Rui Nuno Capela 2012-11-27
    • nick dowell
      nick dowell

      I do have a workaround for this problem.

      The slowdown occurs if the Gtk2 UI calls LV2UI_Write_Function from its mouse event handler. By using a timer to schedule calling LV2UI_Write_Function outside of the mouse event handler, the slowdown goes away.

      The reason I am reluctant to ship this, though, is precisely because it is a work-around... this really does not appear to be a plugin bug.

      Is there something in qtractor's implementation of LV2UI_Write_Function that could cause this problem?

      • is the workaround already pushed to amsynth-git ?? as i've been testing it and never sensed any slowness :/

        Last edit: Rui Nuno Capela 2012-11-27
        • nick dowell
          nick dowell

          No I have not pushed the workaround yet. Strange that you're not seeing the slowdown...

      • nick dowell
        nick dowell

        I'm now going through the qtractor code, commenting out stuff to try and track down the slowness.

        So far I've found that commenting out 'emit updateNotifySignal(m_pLastCommand->isRefresh());' in qtractorCommandList::exec stops the slowness...

        -- EDIT --

        qtractorMainForm::stabilizeForm() is the culprit. It seems to be all the calls to setEnabled() and also QApplication::clipboard()->mimeData()->hasUrls() that are hurting performance.

        Is it really appropriate to call this method whenever a plugin parameter has changed? This method seems to be concerned with updating the main window's state, and its output doesn't actually appear to depend on plugin state...

        Last edit: nick dowell 2012-11-27
        • changing plugin parameters is an undoable command and the state of undo/redo must get updated accordingly.

          as said, i am not seeing any poor performance on my call. it must be something else- remember that qtractor is a qt host and (your) plugin is a gtk2 one. and both run in the same address space (as opossede to dssi uis). most likely, concurrent event-loops and threads. you just can't blame one of the sides, host or plugin.:/


          • nick dowell
            nick dowell

            Actually I would argue that moving the mouse by one pixel while dragging a continuous control should not be an undoable command, after all what use is there in undoing the last pixel's worth of change? Ideally undo would restore the parameter to the value it had before I started editing the control (i.e. undo the whole edit gesture.)

            I agree this problem is a complication due to how the Qt and Gtk runloops interact, and I'm certainly not trying to blame sides! But should every Gtk LV2 plug-in be required to implement this workaround in order to be compatible with qtractor?

            • if you look closer, there's this command aliasing when a plugin parameter value is either increasing or decreasing--you get undo/redo-ability of the inflection points only and not ever of every single pixel move.


              • nick dowell
                nick dowell

                Ah right, that was buried a bit too deep for me to see last night! ;)

    • I can't switch it off, it's greyed out?

      • because you are running a debug build.

        edit the configuration file ~/.config/rncbc.org/Qtractor.conf and change the following key line under [Options] section:



        • Ah check. This didn't make a difference initially. But then I closed down Qtractor, ran it from the cli which yielded the following:

          ** (qtractor:3514): WARNING **: layout.ini contains no entry for control 'portamento_time'
          ** (qtractor:3514): WARNING **: layout.ini contains no entry for control 'keyboard_mode'
          (qtractor:3514): Gtk-CRITICAL **: IA__gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
          (qtractor:3514): Gtk-WARNING **: A floating object was finalized. This means that someone called g_object_unref() on an object that had only a floating reference; the initial floating reference is not owned by anyone and must be removed with g_object_ref_sink().
          (qtractor:3514): Gtk-WARNING **: A floating object was finalized. This means that someone called g_object_unref() on an object that had only a floating reference; the initial floating reference is not owned by anyone and must be removed with g_object_ref_sink().

          And guess what, the knobs in the lv2 GUI of amsynth became responsive (though it's probably totally unrelated). Then I ran qtractor via the menu again and knobs still responsive. Then I edited Qtractor.conf again to set Display\StdoutCapture=true and restarted Qtractor, knobs still responsive. Now I'm checking a few minutes later with that same session open and the knobs have become unresponsive. Then I restarted Qtractor from the cli and knobs became responsive again. So maybe something else outside Qtractor is not working as it should? I'm using LXDE with Openbox, maybe I should try with a different DE (like KDE)?

          Last edit: Jeremy Jongepier 2012-11-28
          • the root of all problems is and will always be the promiscuousity of GUI toolkits, pervaded through libsuil. no doubt libsuil is a awesome facility, when things work right. but that's just apparent. no real problem gets actually solved,

            you should recall my rants about this kind of approach: you just don't buy this toolkit esperanto business in one fair and live happily ever since.
            more often than not, there comes some kind of blockade, misbehavior, unresponsicveness, deadlocking, you name it

            all this alleged unresponsiveness gets to happen randomly, non-deterministically, on only on some environments or circumstances perhaps, at the end of the day it's just a symptom of the original whole problem.: different gui toolkits are not likely to behave nicely on each other cleanly on all and every cases and code paths. even more not so if sharing the same address space. overall, a lot of wrong things can happen. just think the norm-of-the-day of multi-core processing and you're set for inconsistent behavior all around. nuff said.


            ps. anyone remembering my diatribes with drobilla's, pro and cons the lv2_external_ui interface? now you get one of the side-effects. although it is not affecting my case, but perhaps i am just lucky. Jeremy also got a good hand. it's a mysterious game :)

            Last edit: Rui Nuno Capela 2012-11-28
  • @nick dowell: i'll try to detach the lv2_ui_write() reactor from plugin's control/processing code and host-gui related code--it will be kind of a tricky change though, which will affect qtractor as a lv2 host in all or some new ways: automation being one foreseeable source of a problematic victim ...


  • done. svn trunk rev.3078+ (aka. v0.5.6.24+) commit-log:

    • LV2 UI parameter updates are now asynchronously detached from the source GUI widget thread, in attempt to improve cross-GUI-toolkit responsiveness, specially focused on LV2 plugins with a GTK based UI (eg. amsynth, triceratops, etc.). (EXPERIMENTAL)

    hth. please test && report

    • nick dowell
      nick dowell

      I have just re-tested with revision 3079 - the problem is now gone :-)

      Awesome, thanks!

    • status: open --> pending
    • milestone: 0.5.6 --> svn_trunk
    • status: pending --> closed