Re: Glitch 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On April 15, 2013 07:06:39 PM taktik wrote:
> On Sat, Apr 13, 2013 at 9:34 AM, Dan MacDonald <allcoms@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user




[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux