> 2009/3/29 Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>></span><br>
><br>
> IIRC, lmms-vst supports native linux VST plugins, not win32/x86 VST<br>
> plugins. and qtractor-vst supports VST's out of process, so that<br>
> qtractor is not itself a win32 application (this is a nice solution if<br>
> you don't care about scaling to support many plugins per track).<br>
><br>> i could be wrong.<p>LMMS does *.dll so that's win32, no? But yes, it slipped my mind. Both of those execute differently than ardour at this point of time, as far as vestige and the primary executable are concerned. Qtractor (for the win32 support) goes through dssi -> dssi-vst, so that's even less of an issue.</p>
<p>It looks like packaging ardourvst will warrant a little more thought. I like the idea of a separate build (not building twice; different build depending on whether VST=1), where the names of every file should be different, or at least the names of the dirs. That's one rather simple way we can have both ardour and ardourvst installed.</p>
<p>Another thing is how we could make wine and the vst support _optional_ for binary distribution. This might give way to other ideas of packaging but it also requires a totally different build. For example, in LMMS the packager can install wine and build with VST support. The user, however, can install and run LMMS without wine. The only exception there is that clicking on the Vestige plug-in would cause a crash. In one sense this is not really something that can be called "professional behaviour", but it makes comfortable sense technically. Qtractor, well, dssi-vst is optional anyway. They both don't have to call wine if not needed. Ardour(vst) currently will not start as the primary executable (which is a script unlike the compared apps) depends on wine. Feasible someway?</p>