18 Nov
2006
18 Nov
'06
12:35 p.m.
So, if I understand this correctly, there is no API out there that simply
translates common GUI VST calls into any of the libre toolkits which are
also available on Linux, other than the full-fledged Wine implementation? If
so, that *really* sucks.
It would be interesting to see just how many different drawing API calls
most of the VSTs utilize for their GUI (since it is predominantly 2D
drawing, my guess is there should not be that many, unless some dev goes all
out and does DirectX eye candy/graphs/envelope
editors/oscilloscopes/whatever). If we could produce a lib that can
translate those API calls into FLTK or some other totally free toolkit, we
may have a good case at convincing VST makers to start recompiling their
VSTs even if that means commercially-only available VSTs for Linux (FWIW,
although indirectly, I may be able to get a hold of the Cakewalk founder,
and, provided that we do have the aforesaid prerequisites in place, would
gladly like to discuss with him jumpstarting this idea). Otherwise, native
Linux VST is IMHO a lost cause--our market share is too small for the
overhead unless this overhead simply means recompiling.
Ico
how do i know all this? because we use this in ardour2
(and the current
version of FST) to provide the most robust VST support that we can. how
does it work? we compile the code that normally makes up the executable
for ardour as a shared library, with an special entry point called
ardour_main(). then we compile a tiny win32 app that does nothing but
start up and call ardour_main(). this is compiled using winegcc. the
result is a shell script and a small win32 shared object/.exe file. you
run the shell script, it starts wine, which runs the tiny win32 app,
which is linked against libardourgtk and calls ardour_main(), and
voila ... ardour running inside wine with the best VST support that wine
can offer. note that you can substitute cedega for wine and it works
slightly better ;) baroque? yep. but this how it actually works ...
--p