[LAD] VST and Qt

[Justin Smith]

On Mon, Apr 6, 2009 at 10:00 AM, David García Garzón
<dgarcia at iua.upf.edu> wrote:
> On Monday 06 April 2009 18:19:19 Grammostola Rosea wrote:
>> David García Garzón wrote:
>> > On Monday 06 April 2009 14:45:40 Grammostola Rosea wrote:
>> >> David García Garzón wrote:
>> >>> Hi, lads! Some news from the CLAM project.
>> >>>
>> >>> For anyone interested in that subject, we managed to build Qt based VST
>> >>> interfaces (from linux!). Not about integrating existing VST in Qt
>> >>> applications but building brand new plugins using Qt. This is an step
>> >>> to get visual prototyped VST from CLAM as we got from LADSPA and JACK
>> >>> on last releases. I don't think the integration could get into the next
>> >>> CLAM release, but i guess that just the Qt-VST integration could be
>> >>> useful to someone in the community.
>> >>>
>> >>> See more information here:
>> >>> http://vokicodder.blogspot.com/2009/04/vst-plugins-with-qt-user-interfa
>> >>>ce .html
>> >>>
>> >>> The code is available in the first link to the CLAM developers list.
>> >>> Not the proper distribution but i plan to make it available from clam
>> >>> or other repository in short. Any collaborative hacking to improve it
>> >>> is very welcome.
>> >>
>> >> I'm an programmer noob, but some questions.
>> >>
>> >> 1) what is your aim? Building VST plugins for Gnu/ Linux? Is a VST
>> >> better then an LV2 plugin?
>> >> 2) why is the focus in the Gnu/Linux work on VST and not on AudioUnit
>> >> plugins? Linux and OS X are both Unix like systems right?
>> >
>> > The principle we follow is "design once, generate many". We are aiming on
>> > building any kind of plugins or audio backends our users want to build
>> > using the CLAM framework. See:
>> > http://clam-project.org/wiki/Network_Editor_tutorial
>> >
>> > One of those targets is building VST plugins *for Windows* (crosscompiled
>> > from linux or natively from windows). The main advantage for linux users
>> > is that they can visually build their plugins or JACK applications in
>> > linux with CLAM, and then, if they want their plugin to be available for
>> > Windows users, just click a button and you'll have a VST plugin as well.
>> >
>> > LV2 is also on our roadmap, and I guess that having already support for
>> > Ladspa it won't be that difficult. But right now our interests where VST
>> > just because a project partners asked us for some vst's and, well, it was
>> > funny doing that from linux. We had vst code working for a couple of
>> > years but without GUI, and in order to make this code valuable we had to
>> > unlock the GUI front. That's what we did.
>> >
>> > The good news, if you are interested in AudioUnits, is that one of our
>> > coworkers, Ferran Orriols, already has an assigned time slot to implement
>> > AudioUnits in CLAM, after his eastern exams.
>> >
>> > Of course, any help on supporting whatever plugin/backend platform would
>> > be very appreciated as we have a limited number of hands. ;-)
>> >
>> > David.
>>
>> @ Paul, thanks for your explanation.
>>
>> @ David, Ok, thanks for information. I read often that people regret
>> that certain Free VST plugins are not available on GNU/Linux. VST plugin
>> authors don't want to make it for GNU/ Linux... maybe if it's easier to
>> build for both platforms this will improve. Also sometimes there is a
>> GUI for the Windows version and not for GNU/Linux (I think Freeverb3 is
>> such an example). Would be nice if such an Gui for Windows could be
>> easily build on GNU/Linux too.
>
> Yes, that's the point, reusing the same Qt interface for JACK apps, LV2 and
> VST. No need to use VSTGUI which is tailored just for VST and not even
> inventing a new toolkit, just taking a general purpose one.
>
> David.
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

I wish we had a better solution for the VST situation. We can use
reverse engineering to get around the stupid steinburg license
restrictions, but we still are using a proprietary format for our
plugins, which is primarily designed for the win32 platform. I am glad
that it is getting easier to make graphic plugins for Linux, it is
just sad to mess around with stuff like the steinburg SDK to do it.