11 Apr
2005
11 Apr
'05
11:06 a.m.
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. :(
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 ?
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 ?
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 ?
Best,
dp
11 Apr
11 Apr
5:25 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
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 ?
its not up for grabs. work on it is slow, but torben has a new version
that is Wine-version-independent.
this is harder for application authors to use, because their apps have
to compiled using "winemaker". but i had a long conversation with the
head of CodeWeavers (the primary wine sponsors/company) and he
convinced me that the hackish approach torben and i had taken was
never going to be be sustainable.
both of us regret not having more time to work on it; hopefully the
logjam will break soon.
--p
5:59 p.m.
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. :(
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 ?
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 ?
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 ?
Best,
dp
Dave,
My thoughts on this are perhaps scattered but:
I'm still using wine 20040505 for libfst. In working with Thac some months
ago and trying different versions of Wine it seemed this one was the only
reliable version for fst..but according to Shayne in an email similar to
this theme I wrote Sunday, dssi doesnt work with this version nor does the
Ardour vst suport but Muse support does.
All that regurgiated, I'm left wondering why the versions of Wine change
such that this can even occur in the first place?? There must be somewhat
significant code changes to cause it?? (I'm no coder and as ignorant as
one can be about it)
Perhaps we could buddy up with the Wine Dev team and try to get them to
focus on the audio api for just one release that is up to date and that
allows all of the vst tools we have to work! Then at least we might gain a
modern baseline to start from again? I know it prolly represents a lot of
talking and I dont know how the Wine devs would perceive the small numbers
of LAU and Dev but I do know this....VST is a valid option in what we do
and is not going away! LADSPA is AWESOME~~~ But so is VST. We have it in
some form...that makes it viable and valid.
If it took some finacial contributions of reasonable nature to get
someones attention at Wine dev, then maybe thats what it takes!
THis comes at a relevant time as I have started to get involved in
PClinuxOS and with Thac starting to package for them with Live personally
tailored bootable LiveCDs on the near horizon, it's sure be nice to have
a full working suite of vst capability there too. But I dont want to ask
Thac to do the foot work...he does more than his share IMHO....I would
rather dedicate to the footwork and help create Inertia.
Just a thought.
Cheers
R~
7:43 p.m.
New subject: [linux-audio-user] 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
8:14 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
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). 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
8:32 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Monday 11 Apr 2005 23:19, Paul Davis wrote:
Ah. No point talking about it here then.
No, the licence situation is clear enough I think. It just isn't very
satisfactory. You can't legally link anything that uses the Steinberg
headers into a GPL application and distribute the results as a binary,
with or without source. dssi-vst is a plugin with very particular
licensing -- this legal situation is one reason it is a plugin in the
first place, instead of being something built-in to Rosegarden.
People from Steinberg have indicated on several occasions that they
would happily change the VST SDK licence to BSD or similar. (Well, you
know that, and probably more for all I know.) It just never seems to
have actually happened.
Chris
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.
11:11 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
Ah. No point talking about it here then.
this is LA*D*, where we are free to ramble about every stillborn idea
that shows up in our wacky little minds, isn't it? :)
No, the licence situation is clear enough I think. It
just isn't very
satisfactory. You can't legally link anything that uses the Steinberg
headers into a GPL application and distribute the results as a binary,
with or without source. dssi-vst is a plugin with very particular
well, actually, thats not quite true. *I* can do that for Ardour, and
I suspect that the Rosegarden group could do that for RG as
well. Ditto Werner with MusE; since we are the copyright owners, we
can do whatever we damn well please :) However, 3rd parties cannot, and
in this day and age of O(N^2) Linux distributions, that is a bit of an
issue.
--p
12 Apr
12 Apr
5:30 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Tuesday 12 Apr 2005 02:16, Paul Davis wrote:
Except it's a bit of a pointless ramble if nobody reading you knows what
you're talking about. Talking about code on a free software mailing list
without the code being available to the list's readers seems a bit futile.
No, you can't. If your application has to link with third-party GPLd
libraries, such as libsamplerate, liblo, or the KDE libraries, then you have
to respect their licences. And that means you can't link with Steinberg's
headers and distribute the results (at least as they're licensed at the
moment).
Chris
Ah. No point
talking about it here then.
this is LA*D*, where we are free to ramble about every stillborn idea
that shows up in our wacky little minds, isn't it? :) You can't
legally link anything that uses the Steinberg
headers into a GPL application and distribute the results as a binary,
with or without source.
well, actually, thats not quite true. *I* can do that for Ardour, and
I suspect that the Rosegarden group could do that for RG as
well. Ditto Werner with MusE; since we are the copyright owners, we
can do whatever we damn well please :)
6:57 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
No, you can't. If your application has to link
with third-party GPLd
libraries, such as libsamplerate, liblo, or the KDE libraries, then you have
to respect their licences. And that means you can't link with Steinberg's
headers and distribute the results (at least as they're licensed at the
moment).
this is true. i had forgotten about that little detail. thanks for the
reminder.
chris - i wish you could be at LAC2005. i sense that we could spend a
good couple of hours of verbal jousting and then get something really
cool done :)
--p
13 Apr
13 Apr
2:48 p.m.
New subject: [linux-audio-user] problem with cs46xx and recent alsa drivers
Hi,
I used a hercule game theater with a 2.6.8.1 kernel and the builtin
alsadriver and it worked well. Now i upgrade my kernel to a 2.6.11.7 and
it seems that this driver dont work anymore with my soundcard. cs46xx
module loads well but there is no /proc/asound/card0 that appear. i
tried the nforce2 chipsound of my nf7s and the intel8x0 driver and this
one works.
Anybody have this problem with recent alsa drivers and cs46xx boards?
Guillaume
11 Apr
11 Apr
8:46 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Monday 11 Apr 2005 23:19, Paul Davis wrote:
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.
The VST-per-server implementation might not, but there's no very
compelling reason not to have multiple VSTs in a single server serving
multiple clients. That would be less reliable than a dssi-vst type
service can be, but no less reliable than fst, and it should scale
nearly as well. It's been on my todo list for ages...
Chris
11:13 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
The VST-per-server implementation might not, but
there's no very
compelling reason not to have multiple VSTs in a single server serving
multiple clients. That would be less reliable than a dssi-vst type
service can be, but no less reliable than fst, and it should scale
nearly as well. It's been on my todo list for ages...
i still don't think that scales. the cache might still be warm, since
the server is repeatedly invoked, but its still 2 context switches
per-plugin invocation, and i don't think this is reasonable over the
long haul. the point of a plugin is that "its just a function call
away", and whether its a context switch to the *same* server or N of
them, its still a context switch.
12 Apr
12 Apr
5:21 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Tuesday 12 Apr 2005 02:18, Paul Davis wrote:
DSSI has a mechanism for coalescing these (which is what I was thinking of)
but of course it's for synths only, and makes no sense (in the host) for
effects.
Chris
The
VST-per-server implementation might not, but there's no very
compelling reason not to have multiple VSTs in a single server serving
multiple clients. That would be less reliable than a dssi-vst type
service can be, but no less reliable than fst, and it should scale
nearly as well. It's been on my todo list for ages...
i still don't think that scales. the cache might still be warm, since
the server is repeatedly invoked, but its still 2 context switches
per-plugin invocation 
11 Apr
11 Apr
10:32 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
hey
thanx for jumping onto this one dave! the vst thing, while holding less
and less interest for me, should definitely be reviewed and brought up
to date ... as usual, if the developers are keen to churn out some
updated code, i'm more than keen to test it out :) .... more comments below,
Chris Cannam wrote:
just to repeat - from my experiences, jack_fst appears to work with
*most* versions of wine. the only problems i've had with jack_fst have
been getting ardour compiled with vst support - in this case, you have
to use wine20040505. however, i've just managed to get the latest muse
stable release (can't compile cvs) working with jack_fst vst support
enabled on wine 20041201.
so now my vst situation stands like this:
wine20041201
*jack_fst (and muse w/vst)
*dssi-vst (and rosegarden w/vst)
(a seperate vst path for each, as jack_fst *within* muse appears to be a
bit more picky about which vst's work - still fine-tuning how to call
rosegarden and muse from a script that will give them both the
appropriate VST_PATH)
*jack_fst, getting audio piped from ardour and piping it back in.
it would be great if dssi-vst would work with wine20040505 .... however,
any eventual solution would be best served by dssi, i think. when it is
up and running it is very stable, and then there's the cool synths like
hexter and x-synth (which have allowed me to cease sometimes fruitless
quests to get a VST plugin working). jack_fst is just as good, if not
better, with VST plugins, but doesn't seem to be as extensible ...
On Monday 11 Apr 2005 14:14, Dave Phillips wrote:
i've never even been able to build vstserver on the wine package that is
available from the same place as the package :(
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.
i think this is where vst-server comes apart - so much seems to have
changed in wine since its release that it is dead in the water.
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.
might give that version a try with jack_fst and ardour ...
shayne
10:16 p.m.
On Mon, Apr 11, 2005 at 09:14:58 -0400, Dave Phillips wrote:
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 ?
Well, we dont really have any basis for comparison. There aren't legions
of instrument developers clamoring for a plugin API, so theres no way to
tell it its OK or not yet.
I'm not particularly worried because LADSPA took some time ot tkae off,
but it is one of the best plugin APIs IMNSHO. OSC seems to be gaining
popularity, and thats a selling point of DSSI.
- Steve
12 Apr
12 Apr
8:52 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
Greetings:
My thanks to everyone who has responded to this thread. As you can
see, the issue is important to many users, and there is a desire to see
a more stabilized approach to resolving it. A few random further comments:
Regarding project persistence here's what I've gleaned from the
replies so far:
The vstserver project is defunct, and Kjetil implies that it may not
be worth pursuing.
The libfst project is still alive but development activity is
necessarily stalled. (I have this image of Paul as Dr. Henry
Frankenstein, repeating "It's alive, it's alive !". :)
DSSI and its dssi-vst bridge looks like a best choice for everyone,
although IIUC it doesn't resolve Paul's concerns for multiple plugin
instances.
Interestingly, all the developers of these neat utilities are also
heavily involved in much larger projects.
I really would like to see a coherent approach defined and organized
to study and maintain VST/VSTi compatibility under Linux. Matters to be
considered include :
Keeping current with WINE development (ongoing).
Trying to resolve licensing issues with Steinberg (if they're
willing to alter their licensing, perhaps they just need some more
prodding?).
Folding existing work into a single codebase (get Kjetil's tools
working with DSSI, resolve differences between libfst and dssi-vst).
I'm sure there are other matters I've not included. However, it
appears that maintaining VST/VSTi compatibility is a project very much
desired by the user community. Speaking for myself, I've got used to
running Crystal, Hypercanvas, and a few other VSTi plugins for which
there are no equal or better native plugins. I would also like to test
new versions of WINE without the fear of blasting compatibility (though
as I said earlier, I do understand that repairing WINE is not a LAD
priority).
So, are there any lurking newbie (or oldie) LAD coders who want to
undertake a much-desired project that is already off to a good start ?
In the beginning stages activity is likely to be a bit diverse, but
perhaps things will smooth out after deciding upon a single codebase and
creating a focused group of developers.
And to all who reminded me how small the LAD group is: Yes, I know the
numbers, and I'm trying not to pressure the original developers. What
I'd really like to see is what I've described: A new group formed to
focus on VST/VSTi plugin compatibility under Linux. Is there anyone here
who will take up the flag for this project ?
Or is there a feeling that we don't need such a group (where "group >=
1") ?
Thanks again,
dp
9:36 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
Dave Phillips wrote:
So, are there any lurking newbie (or oldie) LAD
coders who want to
undertake a much-desired project that is already off to a good start ?
Years ago, I was a C and C++ freak doing lots of low level programming
on embedded systems. Right now I am a Java Card programmer, which is
kinda high level --though not Visual Basic, certainly. I've never taken
part in any open source project and this seems a very nice one to start
with and give some help.
Is there anyone here who will take up the flag for
this project ?
What I was trying to say is: I can be useful for helping development,
but most probably not for "taking up flags" at this time, if for "taking
up flags" you mean performing some kind of leadership.
So to any "leaders" outta there, feel free to contact me. :))
Cordially. Ismael
1:35 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
Dave Phillips wrote:
I'm sure there are other matters I've not
included. However, it
appears that maintaining VST/VSTi compatibility is a project very much
desired by the user community. Speaking for myself, I've got used to
running Crystal, Hypercanvas, and a few other VSTi plugins for which
there are no equal or better native plugins. I would also like to test
new versions of WINE without the fear of blasting compatibility
(though as I said earlier, I do understand that repairing WINE is not
a LAD priority).
Count me as one of those users who has plenty of VST plugins that I
would love to use in Linux.
It seems to me that it would benefit users, in the long run, if
developer(s) of a VST plugin wrapper would grab WINE and not look back.
Take it as a starting point for the win32 interface of a VST wrapper;
mold it to work and go from there. It would be difficult at first, but
not impossible. The communication between the WINE team and this wrapper
team could occur on the level of a knowledge transfer of future
WINE/Win32 development; but not on the level of trying to synchronize
code development (that's too many moving targets in 2+ teams - teams who
are not paid to be on a schedule to synchronize. Plus, it sounds like
people are darn frustrated with changes in WINE).
I know it sounds tough. Maybe one of the current WINE coders can come
over to the wild side of audio dev. Seems worth considering.
brad
--
Brad Fuller
(408) 799-6124
** Sonaural Audio Studios **
(408) 799-6123 West San Jose
(408) 799-6124 Cambrian
________________________________
Hear us online: www.Sonaural.com
7158
days inactive
7160
days old
linux-audio-user@lists.linuxaudio.org
17 comments
9 participants
participants (9)
-
Brad Fuller -
Chris Cannam -
Dave Phillips -
guillaume Meurisse -
hanaghan＠starband.net -
Ismael Valladolid Torres -
Paul Davis -
Shayne O'Connor -
Steve Harris