[linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst - Linux-audio-dev

11 Apr 2005

Dave Phillips:
...

 Greetings:

   Users are constantly wrestling with issues surrounding the software
 mentioned in the subject line, and I would like to find out what
 directions are planned for those projects. Here's what I see now:

     1. The vstserver project is functionally dead. It cannot work with
 newer versions of WINE, and it appears that Kjetil does not plan to keep
 it updated to accommodate the new versions. Alas, this also means that
 his nice vsti, ladspavst, and k_vst~ projects are also unusable. :(

Vstserver does actually works very fine with newer versions of wine, at
least the ones I have tried. But for compiling up vstserver, you
need the 9.12.2003 version. And worse, the 9.12.2003 version doesn't
work with newer versions of Linux, or something like that. (Ie. the
workaround is that you first have to install wine 9.12.2003 to be able to
compile vstserver, then install a newer versions of wine. The plugins will
then use the newest version of wine).

I think there exist a patch or something for the 9.12.2003 version of wine
to make it compile with newer versions of linux (not sure which part).
If anyone has such a patch, it would be nice if someone sent it to me.
I'm still on Redhat 8 myself, so I don't know what the problem is exactly.

...
      3. The dssi-vst bridge is still unknown to me
because of issues with
 RH9, and I've not had time to test it on FC3. But is there any general
 feeling that dssi-vst is a better route to take, at least for the normal
 user ? Btw, I like the DSSI API, but it seems slow in catching on with
 developers. Is that perception correct ?

I think dssi-vst looks very nice too (although I haven't tried it), and
its very similar to the way vstserver works. It should not be much work to
make vsti, ladspavst and k_vst~ work with dssi-vst instead of vstserver.
But I don't have the time / other more interesting projects.

...
    Please understand that I'm in no way criticising
the work done on
 these projects so far. In point of fact, I'm extremely happy they exist,
 but I'm also in considerable doubt whether they can continue to be
 useful without further maintenance. Users are writing to other users to
 figure out how to fix small problems (usually with libfst), but these
 repairs are not making their way back into the codebase, which seems
 rather non-optimal to me. I'm also aware that the greater problems exist
 because of WINE's inherent instability (WRT its development, not
 necessarily its usability) and that Linux audio developers can't be
 responsible for WINE fixes too. Perhaps more crosstalk between the WINE
 developers and the LAD folk (similar to the recent discussion re: the
 kernel list and LAD) would help smooth the way for a more consistent and
 more manageable VST/VSTi bridge for Linux ?

   So, any comments or useful suggestions ?

There are two fundamental different ways to get vst plugins to work in
linux with the help of wine. The fst-way and the vstserver/dssi-vst
way. Both "ways" are needed. One of them is very fast, but hard to set
up (fst). The other one is safer and slower, and a little bit less hard to
set up.

Problem is, that the releases most probably does now depend on a spesific
version of wine, or will depend on a spesific version of wine in the
future. It would be nice if the three projects (or at least fst and
dssi-vst) was coordinated to use only _one_ version of wine, and that
this version of wine is downloaded from one place, for example a
sourceforge project place.

But for this to happen, some person needs to step up, set up a sourceforge
account, do some coding, coordinate the coders, release things, do
some work. It might not seem like Thorben, Paul, Chris or myself is
the right person right now. Perhaps there is some coder with some free
time that wants to do this stuff?

--