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? --
