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.
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
7:43 p.m.
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.
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
15 Apr
15 Apr
9:48 p.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Tue, Apr 12, 2005 at 05:01:20PM -0400, Paul Davis wrote:
>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).
one point that should be taken is that you CANT link to a header file ;)
but it will stay like it is: i will tell the FSF if i find binarys of
xfst !
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
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
16 Apr
16 Apr
6:28 a.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Saturday 16 Apr 2005 01:00, torbenh(a)gmx.de wrote:
but it will stay like it is: i will tell the FSF if i
find binarys
of xfst !
Why would the FSF care? It's not as if xfst can be GPL. If it was,
then people would be able to distribute binaries.
It would be misleading at best to distribute software under a licence
that offers rights that you know no user can legally exercise.
Chris
11 Apr
11 Apr
8:46 p.m.
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.
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.
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
12 Apr
12 Apr
2:30 a.m.
On Mon, 2005-11-04 at 22:43 +0100, Chris Cannam wrote:
FWIW, I'll be writing a DSSI sampler, oscillators, and miscellaneous
other stuff Real Soon Now(TM). Just overly busy with LCA2005 stuff,
debugging, etc.. I guess these kinds of plugins aren't that useful
outside a modular though.
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.)
There was some talk a while ago about making Om (my modular synth) able
to create DSSI plugins. I don't think it would be (easily) possible to
have it actually build a normal DSSI shared library from a patch, but
something like that max-ladspa hack (that allows a max patch to run as a
ladspa plugin) should be easily possible, since the whole thing is
already controlled via OSC anyway.
Not quite the same thing, but maybe better than nothing..
-DR-
11 Apr
11 Apr
10:16 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
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
10:34 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
Btw, I like the DSSI API, but it seems slow in
catching on with
developers. Is that perception correct ?
I'll just put my hand up as someone who's at least interested in DSSI
(for what it's worth!):
I'd like to rewrite my academic research project (a genetic algorithm
type thing) as a DSSI host. If that comes together I'll write a couple
of synth plugins as well. Unfortunately the "real" research has to
continue whatever the software architecture, so time is limited.
It's great to hear that DSSI support is planned for Ardour (on
whatever timescale) and that VST work continues in one form or
another. I wish I had the time and especially the expertise to
contribute to one of those.
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
3:53 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
On Tue, Apr 12, 2005 at 01:16:39AM +0100, Steve Harris wrote:
On Mon, Apr 11, 2005 at 09:14:58 -0400, Dave Phillips
wrote:
if you want vsts then use xfst.
it works out of the box.
builds with a make.
but remember: using vst is using the dark side.
and therefore xfst will by stay underground.
its only distributed via irc/mail !!!
i am tired of people using my programs without feedback !
the only thing i get feedback for is this stupid vst stuff.
dssi needs jacktransport awareness.
i will not waste dev-time badly needed for jack-midi and distributed
jack on vst !
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
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
5:49 p.m.
Torben,
On Apr 12, 2005, at 11:05 AM, torbenh(a)gmx.de wrote:
dssi needs jacktransport awareness.
To me, DSSI's neutrality with regard to audio input/output
and MIDI input is one of its advantages: the same plugin
will work whether running under JACK and ALSA, or OSS,
or CoreAudio and CoreMIDI, or whatever -- only the host
need be aware of the particular implementation.
So I'm curious: what sort of uses do you have in mind for a
DSSI-like plugin system, that it would need JACK transport
awareness?
-Sean
10:52 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
On Tue, 2005-12-04 at 20:05 +0200, torbenh(a)gmx.de wrote:
dssi needs jacktransport awareness.
I agree very much.. the question is whether to add some sort of explicit
transport support, or just a standard set of ports that convey the
necessary information.
If it would only take a port or two to get the req'd information, I'm
for that approach, particularly since it's backwards-to-LADSPA
compatible. Might not be sufficient though?
Should we take it to the DSSI list?
-DR-
14 Apr
14 Apr
5:14 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
On Wed, Apr 13, 2005 at 10:51:39AM -0400, Dave Robillard wrote:
On Tue, 2005-12-04 at 20:05 +0200, torbenh(a)gmx.de
wrote:
could be done with 2 ports (what i want)
transmit sample_count and bpm.
this does not handle tempo changes and non 4/4 meters.
well i dont think it works with controls.
dssi needs jacktransport awareness.
I agree very much.. the question is whether to add some sort of explicit
transport support, or just a standard set of ports that convey the
necessary information.
If it would only take a port or two to get the req'd information, I'm
for that approach, particularly since it's backwards-to-LADSPA
compatible. Might not be sufficient though?
Should we take it to the DSSI list?
yes please...
-DR-
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
13 Apr
13 Apr
9:51 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
torbenh(a)gmx.de:
but remember: using vst is using the dark side.
and therefore xfst will by stay underground.
I'd agree with "shady side". But apart from that: VST is a bridge for
people. They can come over easily. Getting VST plugin developers check
out this side of town might be a very good thing in the long run.
Yes, and I want to look at xfst. Mail?
Wolfgang
7104
days inactive
7109
days old
linux-audio-dev@lists.linuxaudio.org
23 comments
11 participants
participants (11)
-
Brad Fuller -
Chris Cannam -
Dave Phillips -
Dave Robillard -
James McDermott -
Paul Davis -
Sean Bolton -
Shayne O'Connor -
Steve Harris -
torbenh＠gmx.de -
Wolfgang Woehl