>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), torben has done a couple of small test releases to people he communicates with via IRC. >and it's never been properly licenced. the license situation is never going to be clear until Steinberg clean up their act. its more complex because libfst gets linked into your application and your application requires the VST headers to be around during compilation. my impression is that other solutions do not. >> 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). the problem is that there is no single answer. if you want to run 1 or 3 VSTi's then i would agree with chris' assessment (for now, anyway). but you cannot use this model to put a VST EQ on 12 tracks and a VST delay unit on 2 others and a VST looper on another. the architecture doesn't scale. so you have to define the problem before you can really way what the best answer is. >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. the way wine now handles threading makes this point mostly moot. wine completely overrides the pthread "vfunc" table for any NPTL system and even (i think) newer linuxthreads ones. you may think your app calls pthread code, but if its linked using winemaker, its not (at least, not directly) :) and of course, the new version of fst will require winemaker compilation as well. >developers or example code. What we really need is the equivalent of >VST's SynthEdit. (I don't want to hear arguments that SynthEdit what he said :) >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 and support within ardour is planned, we're just too busy right now trying to get 1.0 out the door. --p
