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

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
Received on Tue Apr 12 04:15:07 2005