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

Close

#25 Fix for 3594830 Control VST-Plugin from LMMS host

closed-fixed
None
5
2013-01-06
2012-12-27
Mike Choi
No

This is supposed fix problem (3594830) "Control VST-Plugin from LMMS host"

Discussion

  • Mike Choi
    Mike Choi
    2012-12-27

    • assigned_to: nobody --> tobydox
    • summary: Fix for 3594830 --> Fix for 3594830, Control VST-Plugin from LMMS host
     
  • Mike Choi
    Mike Choi
    2012-12-27

    • summary: Fix for 3594830, Control VST-Plugin from LMMS host --> Fix for 3594830 Control VST-Plugin from LMMS host
     
  • Mike Choi
    Mike Choi
    2012-12-30

    Done some more testing now, 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 that 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
    VstPlugin::setParam()

    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 somehow rewritten.

     
  • Mike Choi
    Mike Choi
    2012-12-30

    Attached new patch, which should prevent below mentioned freezes

     
  • Mike Choi
    Mike Choi
    2012-12-30

    It seems there is a small bug still, having VST automation on, while changing, or loading different VST plugin.

     
  • Mike Choi
    Mike Choi
    2012-12-30

    New patch version added:

    This should fix below mentioned problem with destructor of VST automation panel(LMMS-host window, 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.

     
  • Mike Choi
    Mike Choi
    2013-01-01

    New patch v4 added

    Bug fixes:
    After project load, all knobs states, which are not stored in that project file are now set according VST plugin-after load state (should not be set to zero by default, when you load your project).

    Sync button for knob sync from VST plugin is now not affecting undo / redo functionality, amended are only knobs which are not automated.

    Fixed various destructors especially after project save/load, causing seg. faults, removed old signal connections to automated values on deleted knobs.

    New features:
    Filter to display only automated / all knobs (new button).

    Window title for VSTi parameter controlling window should be changed to actual track name, not to VST plugin name, it is hard to get to know which window belongs to where when same plugin is e.g. opened several times, so with the same name. Now this is handled in paint event, but TBD whenever is that track name changed.

    When you double-click on some knob to change its VST parameter value manually, new dialog window now has same title as what was that knobs name. (instead of "lmms" title string)

    ToDo:
    Better graphics layout for all knobs, change Window title adhoc whenever track name is changed, it would be also good to dynamically change VST plugin window title itself to name of actual track, so users could edit this and distinguish them as well.

     
  • Mike Choi
    Mike Choi
    2013-01-01

    Patch is against current GIT stable branch

     
  • Mike Choi
    Mike Choi
    2013-01-02

    New patch v5 added

    Brings changes from v4 (for VSTi) also on VST effects.

     
  • Thank you very much for your patch and your helpful investigations! I'd really like to apply them ASAP. However could you please strip out the different changes into individual patches (crash fixes, lock/freeze fixes, automatable knob filter etc.). Also a title and short description for each patch would be helpful. Use git commit and git format-patch to provide files which can be applied most easily.

    Also, if possible, care a little bit more about coding style conventions. It's not a big issue, but at least opening blocks via { should always happen on a new line. Also "if (foo(x))" should be written as "if( foo( x ) )" - but that's all and should have been changed quickly.

    Thanks again! I'm awaiting your patches :-)

     
  • Mike Choi
    Mike Choi
    2013-01-03

    Hello, I have uploaded new archive with separate patches.

    So far I have done testing mostly on Linux and Win32 bit.

    I managed to compile on 64bit Linux Mint 14.1 Mate. But there are problems with automation not even using VSTs, and it seems to be related to chosen audio interface, which possibly is source of my problems, I have tested Alsa (here any automation was extremely fast ) and SDL (not working at all, FLO Controlers nothing), well I have to say that Linux distribution possibly not good choice for testing (also Wine 1.2 from Jaunty, GCC 4.6, on VirtualBox).

     
    • status: open --> closed-fixed
     
  • Many many thanks for the great patchset! Everything has been applied and committed. 0.4.14 is going to be a great release! :-)