[linux-audio-dev] Concerning libfst, vstserver, and dssi-vst

[Chris Cannam]

On Monday 11 Apr 2005 14:14, Dave Phillips wrote:
>     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. :(

This does seem to be the case.  There doesn't seem to be anything 
fundamentally wrong with vstserver, but its choice of threading library 
doesn't work well with recent versions of Wine for some reason.

>     2. The libfst project is essentially unmaintained. Again, WINE
> versions wreak havoc with users who want to keep both fst and WINE
> up-to-date. Paul and/or Torben: Is the libfst project going to see
> any more activity from your end, or should it be considered an open
> project and up for grabs ?

I think libfst in the form in which you can obtain it currently is also 
effectively dead.  It's very sensitive to Wine version and no longer 
easy to get working, it's apparently been superseded (has anyone 
actually seen xfst? I haven't), and it's never been properly licenced.
 
>     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 ?

Of the three, dssi-vst is I think the easiest to get working with 
arbitrary versions of Wine, and possibly the best supported (which is 
not saying much, as I don't exactly get much time to devote to problems 
on the DSSI list).

In my experience problems more often arise from winemaker build system 
changes or Wine configuration file layout changes than from actual 
library incompatibilities.  I don't know what your problems with RedHat 
or Fedora were (although RH9/CCRMA was one of my development platforms 
for dssi-vst, so I'm surprised you had problems with it) but I'll bet 
you a fiver it's something to do with the build system or config files 
rather than the library API.

We currently use dssi-vst with Wine 200407-something as the basis of VST 
support in Fervent Studio to Go!, and so I think it works pretty well 
and I do have a pretty strong incentive to keep developing it, although 
I don't necessarily always keep up with the very latest versions of 
Wine.

One thing that distinguishes dssi-vst from vstserver and jack-fst is 
that it manages threading in the Windows parts of the code using the 
Windows threads API rather than pthreads, which means it ought not to 
be sensitive to threading-related changes in Wine.  Of course, that's 
only theory.

> Btw, I like the DSSI API, but it seems slow in 
> catching on with developers. Is that perception correct ?

Yes, I think so.

I do think you have to bear in mind that the pool of Linux audio 
developers is also still rather small.  It's not like there have ever 
been many people writing LADSPA plugins either -- the situation there 
is just distorted by the few authors who have produced dozens.

Any system with a good supporting library for simple builds of pretty 
plugins is going to do better, and for some reason nobody has seen that 
as an interesting thing to develop for DSSI, or else has had the time 
to do it.  The API may be fairly simple, but it's apparently still a 
bit tricky to get going with, and there isn't a critical mass of 
developers or example code.  What we really need is the equivalent of 
VST's SynthEdit.  (I don't want to hear arguments that SynthEdit 
encourages low-quality all-icing plugins -- in my view it's a really 
effective enabler for people to do interesting DSP assemblies on their 
own with usable results, and I'd rather support the existing body of 
SynthEdit synths than a hundred glossy commercial offerings.)

That said, it's still the best practical option.  It has reasonably 
widespread support -- it's supported by Rosegarden and in CVS versions 
of MusE, there are two standalone hosts, it has a handful of dedicated 
plugins and a pretty decent VST bridge.  It has developers who although 
short of time will do their best to help out, and who do care about the 
project.  (If only I had more time, there are at least a dozen DSSI 
plugins and wrappers I'd like to be writing.  Maybe I should compile a 
list of ideas and implementation sketches and stick them on the DSSI 
website in case anyone else would like to have a go.  I know most 
people don't like working from other people's suggestions, though.)


Chris