On Wed, Apr 10, 2013 at 8:04 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote: fixed in git master branch. but i can't recommend this plugin as-is: (a) it does GUI stuff when instantiated, even if the user doesn't plan to use the GUI (or maybe is on an embedded box and has no GUI) (b) it crashes during shutdown (c) the GUI knob controls do not respond normally to my attempts to move them (if they respond at all) --p

On 04/10/2013 01:54 PM, Louigi Verona wrote: i managed to let qtractor locate, load and dang, freeze its own gui. somehow later i got the "demo nag screen" to show up, but nothing else... ah, it also crashes the whole show on close :S either linuxvst in general or glitch2 in particular are sure needing some more iterations, i guess :) byee -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On 04/10/2013 05:34 PM, Rui Nuno Capela wrote: one of those iterations is already in qtractor svn trunk (v0.5.8.2) glitch2 gui is now showing up fine and all controls and knobs that i tweak seem to respond as i think they should and, most importantly, it managed to get some noise out alas, still crash-prone on close with 99.9% probability :/ byee -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On April 10, 2013 08:42:25 AM Paul Davis wrote: Apologies for the dev-ish talk below... Thanks for the hints Paul. In MusE I had sound, GUI would open but just hang just like a couple of other of these native vst synths. Got me curious so I found a couple of bugs and rearranged a couple of things. Still nothing. Then I found the cause was I was not calling effEditIdle periodically. Luckily we've got such a leisurely-rate timer handy slot in our synth classes. So a one-line fix. Boom we got GUI now! (Rats, a few others still don't open.) I also tried calling effIdle periodically too which I've never done, just like the plugin asks. But it alone did not help. This forum helped in regard to the idle calls: http://www.kvraudio.com/forum/printview.php?t=349866&start=0 Neat plugin, tried the sequencing and so on, it works (nice to know my time callback is still working). ----- About Paul's item a) Yeah seems a little bit not like all the others I've tested... About item b) Yeah several do that here. About item c) No trouble here moving all controls. No trouble automating and playing back control movements too, in MusE. Paul, I had found a couple of plugins that had real odd behaviour with respect to stuck controls which I just couldn't move - they'd just jump back. One such plugin was called VEX. I think another may have been Discovery. Don't know if Glitch is another. So I had to be careful and add the following kind of section in our process, where I specifically have to write-back any new port value to the plugin. _controls is the port array, and v is an incoming GUI-control-initiated FIFO event buffer item: _controls[v.idx].val = v.value; if(dispatch(effCanBeAutomated, v.idx, 0, NULL, 0.0f) == 1) { if(v.value != _plugin->getParameter(_plugin, v.idx)) _plugin->setParameter(_plugin, v.idx, v.value); ... Tim.

Question is not closed vs open or anything - question is who is in error - the plugin devs or "us", Linux guys? If the Glitch guys made a genuine error in implementation, I see nothing wrong in telling that to them. On Fri, Apr 12, 2013 at 10:42 AM, Atte <atte(a)youmail.dk> wrote: -- Louigi Verona http://www.louigiverona.ru/

So you will encourage people to "have no fun" ? :-P :-D Am 12.04.2013 09:11, schrieb Atte:

Am 12.04.2013 12:02, schrieb Atte: Sorry, No, I haven't try it, nor do I plan to do it, it's simply not my kind of tool. Just, when you ask for be quiet about issues between close versus open software, I can't resist to make a joke, because at this point there wasn't any sign that the discussion will go in that direction. The opposite was the case, people try to find solutions to solve the issue with this plug. And they try first to found the error by there own implementation!! (so, yes, asking for be patient makes me feel a bit relegated, at this point), . . .;-)

Am 12.04.2013 12:32, schrieb Louigi Verona: Then just do it, and didn't call for purple elephants!

On 04/12/2013 12:28 PM, Johannes Kroll wrote: I (and others) have already notified him about this thread on the renoise forum. -- Atte http://atte.dk http://modlys.dk

On 04/12/2013 03:16 PM, Kieran Foster wrote: Hi, did you consider releasing a LV2 plugin for Linux, like Pianoteq did a few days ago? Afaik 'Falktx' from kxstudio has some kind of juce|vst-to-lv2-wrapper. Regards, \r

On Fri, Apr 12, 2013 at 7:51 PM, Tim E. Real <termtech(a)rogers.com> wrote: I did? :))

On Sat, Apr 13, 2013 at 9:34 AM, Dan MacDonald <allcoms(a)gmail.com> wrote: 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. 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: --- 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. So if qtractor and muse could be patched to call "effEditIdle" for all open plugin editors this would avoid a lot of hassle here. --- 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. Greets, Eduard / taktik / renoise.com

On 04/15/2013 06:06 PM, taktik wrote: qtractor svn trunk (v0.5.8.2) already calls effEditIdle iif GUI is open but not before nor later. oto. it doesn't call effIdle ever since long ago as it's been deprecated as of vst 2.4 it still crashes on host (qtractor) shutdown; the crash spot points into libX11 ultimately, which smells like some xcb or pthread locking conflict in the wild; any stacktrace is useless as i find the demo .so with no elf debug-symbols whatsoever cheers -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

Guys, for non-tech guys like myself who are otherwise very interested in issues such as this, is the reason in a VST protocol or plugin or Linux implementation of protocol? Or maybe Windows hosts actually do have all those special conditions for different plugins? Louigi. On Mon, Apr 15, 2013 at 10:00 PM, taktik <taktik(a)renoise.com> wrote: -- Louigi Verona http://www.louigiverona.ru/

On April 15, 2013 07:06:39 PM taktik wrote: No problem, glad to help. Still fairly fresh paint on the support in MusE, so we're learning too. Actually I did call it - but only once after opening the GUI, which turns out to be inadequate 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... 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.