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

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