Re: [LAU] Glitch 2

On April 15, 2013 07:06:39 PM taktik wrote:
> On Sat, Apr 13, 2013 at 9:34 AM, Dan MacDonald <allcoms@email-addr-hidden> wrote:
> > This has been great to see the devs of Ardour, qtractor and MusE all
> > working on the same problem simultaneously! I can't say I've seen that
> > before so it proves this plugin has peoples interest.
>
> Indeed! Thanks for all the feedback and comments. VSTs on Linux are
> still pretty experimental. Would be great if we all (host and plugin
> devs) could try to help each others here to get things working.

No problem, glad to help.
Still fairly fresh paint on the support in MusE, so we're learning too.

>
> As Kieran pointed out, I'm responsible for some parts of the plugin
> backend in Glitch, so here are a few more comments and technical
> details about previously discussed stuff:
>
> ---
>
> > Looks cool, but someone's understanding of the VST spec is wrong. Probably
> > Ardour's.
> > This puppy calls audioMasterNeedIdle while being instantiated. Not cool.
> > Will fix A3 ASAP.
>
> From my understanding "audioMasterNeedIdle" should not directly result
> into an idle call, but informs the host that the plugin wants
> "effIdle" calls. The specs are not really clear here though. "effIdle"
> also is NOT "effEditIdle" which drives the plugins GUIs, but a general
> idle function which should be called even when the editor is not open.
> We ended up removing the "audioMasterNeedIdle" call in Glitch 2.0.1
> now, which got released a few hours ago, cause this obviously caused
> more troubles than fixing anything.
>
> We thought it's a good idea to call "audioMasterNeedIdle", to make
> sure that we do get idle calls at all from the host. We do rely on
> this on Linux, because we need to do some housekeeping in the UI
> thread, but found no way to get constantly called in the UI thread
> without relying on the host's idle calls. On Windows we do so via a
> "SetTimer", on OSX via "InstallEventLoopTimer". On Linux there seems
> to be no equivalent timer which gets called in the "XEvent" loop.
> Juce based plugins workaround this by creating a new thread for just
> this on Linux (a "message thread" in Juce terminology - if I remember
> correctly) which does general UI thread housekeeping and also drives
> the plugin GUI when the host does not call "effEditIdle". We wanted to
> avoid creating a new thread for just this, cause such a thread will
> then run concurrently with the host's UI thread which is a guarantee
> for unnecessary overhead and of course in general a hassle to setup
> and maintain.
>
> This is also the reason why the Glitch GUI does not work in qtractor
> and muse. qtractor and muse do not call "effEditIdle", even when the
> plugin GUI is open.

Actually I did call it - but only once after opening the GUI, which turns out
 to be inadequate here.

> So if qtractor and muse could be patched to call
> "effEditIdle" for all open plugin editors this would avoid a lot of
> hassle here.

So as I mention in my reply here and to the company, this is what I did:
We have a handy slow-rate QTimer slot in our synth classes, for GUI updates.
So I simply call effEditIdle from it. By default the timer is about
 20 times per second, and is user-adjustable.
I'll try to get that patch in soon...

> > it crashes during shutdown
>
> Tested this a lot during the last days on various systems, but could
> not really replicate this here. Would be great if someone who could
> easily replicate this before could test this again with the latest
> Glitch 2.0.1 update. And If it still crashes, give us some more
> details about the used system and host. A stack trace of such a crash
> would help a lot too.

Definitely some commonality here !

Without actually instantiating - just simple plugin discovery -
 I get this *identical* crash at host shutdown with these plugins:

 Glitch-2.0, DiscoveryDemo, HighLife-1.1, Tonespace

===================================================
*** glibc detected *** ./muse2: double free or corruption (out): 0x08824c88
***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0x5646ee2]
/usr/lib/i386-linux-gnu/libX11.so.6(+0x2431e)[0x485031e]
/usr/lib/i386-linux-gnu/libX11.so.6(XrmDestroyDatabase+0x7d)[0x486bdfd]
/usr/lib/i386-linux-gnu/libX11.so.6(_XFreeDisplayStructure+0x44b)[0x485256b]
/usr/lib/i386-linux-gnu/libX11.so.6(XCloseDisplay+0xd9)[0x483f039]
/usr/lib/i386-linux-gnu/libQtGui.so.4(+0x1c5c17)[0x109ac17]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN12QApplicationD1Ev+0x44c)[0x101aa9c]
./muse2(_ZN15MuseApplicationD2Ev+0x2b)[0x8050e7f]
./muse2(main+0x2402)[0x80503db]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x55ea4d3]
./muse2[0x804d5d1]
===================================================

These plugins do not cause the crash, even when they are all loaded:

AspectVST, BitMangler, Equinox, my_synth4, String_VST, String_FXVST,
 TAL-Dub-3, TAL-Reverb-3, TAL-Vocoder-2, VEX, ZR3.

Rui, if you are reading this, you mention this mysterious crash in your
 QTractor code, to avoid the problem you let Qt implicitly unload the
 plugins rather than explicitly unloading them.
But, I had no luck trying the same thing here for MusE.
You mention that these crashes may be related to JUCE-based plugins.

I would really like to solve this mysterious common problem.

Using Lubuntu 12.04 here:
Linux my-desktop 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:54:40 UTC 2012
i686 athlon i386 GNU/Linux

Thanks.
Tim.

>
>
> Greets,
> Eduard / taktik / renoise.com

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Apr 16 00:15:04 2013