#504 Control VST-Plugin from LMMS host

Current Release
Crash (127)

I have noticed since this feature was introduced that any attempt to move a knob to control
any VST/(i) setting will freeze up LMMS almost right away, I know that there was more work
to do on this feature, but looking through the commits i havn't noticed anything new done here.

I have tested on ubuntu 32 and 64 bit and the results are always the same, with every VST/(i)
that i have tried, heres the pastebin link of the "freeze", it doesnt segfault, but i kill it manually
from the terminal with CTRL > c


and the thread (1) for quick reference as i dont want to spam the mailing list ...thanks Mikobuntu

Thread 1 (Thread 0xb6088740 (LWP 4182)):
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb6a1ce77 in syscall () at ../sysdeps/unix/sysv/linux/i386/syscall.S:30
#2 0xb7210638 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#3 0xb720c038 in QMutex::lock() () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#4 0xb0f46987 in lock (this=0x8f86adc)
at /home/ubu/lmms/include/RemotePlugin.h:758
#5 VstPlugin::setParam (this=0x8f86ab8, i=35, f=0.099999994)
at /home/ubu/lmms/plugins/vst_base/VstPlugin.cpp:575
---Type <return> to continue, or q <return> to quit---
#6 0xb0d14bf4 in manageVestigeInstrumentView::setParameter (this=0x88e2740)
at /home/ubu/lmms/plugins/vestige/vestige.cpp:944
#7 0xb0d15f0d in manageVestigeInstrumentView::qt_static_metacall (
_o=<optimised out>, _id=<optimised out>, _a=<optimised out>,
_c=<optimised out>)
at /home/ubu/lmms/build/plugins/vestige/moc_vestige.cxx:126
#8 0xb733d6b1 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#9 0x080d2125 in Model::dataChanged (this=0x904fe60)
at /home/ubu/lmms/build/include/moc_Model.cxx:103
#10 0x0810e9b8 in AutomatableModel::setValue (this=0x904fe60,
_value=0.100000001) at /home/ubu/lmms/src/core/AutomatableModel.cpp:204
#11 0x081b6522 in knob::setPosition (this=0x904f430, _p=...)
at /home/ubu/lmms/src/gui/widgets/knob.cpp:585
#12 0x081b745d in knob::mouseMoveEvent (this=0x904f430, _me=0xbfffe764)
at /home/ubu/lmms/src/gui/widgets/knob.cpp:475
#13 0xb765d1e8 in QWidget::event(QEvent*) ()
from /usr/lib/i386-linux-gnu/libQtGui.so.4
#14 0xb7602ed4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
from /usr/lib/i386-linux-gnu/libQtGui.so.4
#15 0xb7609024 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/i386-linux-gnu/libQtGui.so.4
#16 0xb732697e in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
---Type <return> to continue, or q <return> to quit---
from /usr/lib/i386-linux-gnu/libQtCore.so.4
#17 0xb7603e95 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) ()
from /usr/lib/i386-linux-gnu/libQtGui.so.4
#18 0xb7690074 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#19 0xb768ec0d in QApplication::x11ProcessEvent(_XEvent*) ()
from /usr/lib/i386-linux-gnu/libQtGui.so.4
#20 0xb76bbeac in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#21 0xb6832d86 in g_main_context_dispatch ()
from /lib/i386-linux-gnu/libglib-2.0.so.0
#22 0xb6833125 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#23 0xb6833201 in g_main_context_iteration ()
from /lib/i386-linux-gnu/libglib-2.0.so.0
#24 0xb7359887 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#25 0xb76bbaaa in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#26 0xb732550d in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#27 0xb73257a9 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/i386-linux-gnu/libQtCore.so.4
#28 0xb732aeba in QCoreApplication::exec() ()
from /usr/lib/i386-linux-gnu/libQtCore.so.4
#29 0x080ada84 in main (argc=139731208, argv=0x882a1b0)
---Type <return> to continue, or q <return> to quit---
at /home/ubu/lmms/src/core/main.cpp:509


  • mikobuntu

    • labels: --> Crash
    • milestone: --> Current Release
    • assigned_to: nobody --> tobydox
  • Mike Choi
    Mike Choi

    Well I hardly can call this a fix, because I really don't know what am I doing, but this has fixed that for me ( though it would be good if automation was less CPU intensive):

    RemotePlugin.cpp @ RemotePlugin::process
    - sendMessage( IdStartProcessing );
    + sendMessage( IdStartProcessing ); waitForMessage( IdProcessingDone );
    - lock();
    - waitForMessage( IdProcessingDone );
    - unlock();

  • Mike Choi
    Mike Choi

    Well from my personal tests of that code
    src/core/RemotePlugin.cpp @ RemotePlugin::process

    between those two locks for message send and wait, there is a special condition but which hardly ever happens, never happened in my tests prior or after that change.

    But I guess it would be okay too, in case the condition or sequence was something crucial here in the workflow, to rewrite it in the other way, seems to work as well:

    sendMessage( IdStartProcessing );

    if( m_failed || _out_buf == NULL || m_outputCount == 0 )
    return false;

    waitForMessage( IdProcessingDone );

  • Mike Choi
    Mike Choi

    New patch proposal attached, I noticed there is still a problem, but
    different on Linux and Windows. On Linux, whenever there is automation
    connected and if you try to move with VST plugin (not via lmms plugins
    wrapper, but with VSTs internal window) than it freezes, on win32 build it
    will freeze whenever you connect automation and than if you move your mouse
    above this VST plugin window.

    This is caused probably by a message processing thread slowdown and the gui
    update loop slowdown
    DWORD WINAPI RemoteVstPlugin::processingThread( LPVOID _param )
    DWORD WINAPI RemoteVstPlugin::guiEventLoop( LPVOID _param )

    And while the VstPlugin::setParam() function is waiting for ack or
    confirmation that this parameter was set it will freez lmms after some
    time, when there is no reply due to that slow gui / message processing
    thread, I believe, if there are no other dead locks..

    As a workaround is to remove ack / wait from this function

    So to not wait that VST parameter setter process finished after automation
    changed, because there is either no feedback from plugin that parameter has
    changed, the gui was updated etc. I believe there is either no need for
    such confirmation at this point.

    I am attaching new patch which should prevent those freezes..

    So this seems to prevent the freeze in both situations above (Linux and
    Win32 build), anyway this VST gui update loop slowdown is still noticeable
    in following situation, because VST plugin automation changes are all going
    via this GUI update / message processing loop.. which has some timers etc
    and slows down. I think this message flow via this GUI loop should be

  • Mike Choi
    Mike Choi

    New patch proposal added:

    This should fix also problems with destructor of VST automation
    panel window(LMMS-host window in vestige.cpp).

    When you load some new VST plugin, while this automation is already
    connected and active, this should not result in LMMS crash or reuse of this
    old automation connections and automation window destructor should not
    leave zombie VST plugins on application exit.


  • Fixed as of commit c2e9918c8ab402c04b29c54ae72ad2f88e48e635.

    • status: open --> closed-fixed