27 Jan
2006
27 Jan
'06
8:51 a.m.
Screenshot:
http://www.kvraudio.com/forum/viewtopic.php?
t=114488&postdays=0&postorder=asc&highlight=linux&start=105
i will be interested to see just how good its audio handling
capabilities are.
--p
27 Jan
27 Jan
10:03 a.m.
As far as i see Jorgen only want to support the obsolet OSS driver model
and native VST Linux plugins... No chance for eXT on Linux...
Did you ever hear about a native Linux VST-SDK ?(LOL)
the screenshot that you can see there is only a w32.dll wrapped in
dssi-vst. I don't like dssi-vst so much, too buggy, no midilearn etc.
It dosn't work with fst 1.7 because of a graphical prob.
Michael
Screenshot:
http://www.kvraudio.com/forum/viewtopic.php?
t=114488&postdays=0&postorder=asc&highlight=linux&start=105
i will be interested to see just how good its audio handling
capabilities are.
--p
10:13 a.m.
On Friday 27 Jan 2006 14:03, Michael Bohle wrote:
I don't like dssi-vst so much, too buggy
Your bug reports and fixes have been invaluable.
It dosn't work with fst 1.7 because of a graphical
prob.
I notice jacklab.net offers a binary distribution of libfst, and says "an
experimental version of ardour-fst is in preparation". How do you deal with
the licensing problem?
Chris
10:22 a.m.
On Fri, 2006-01-27 at 14:13 +0000, Chris Cannam wrote:
On Friday 27 Jan 2006 14:03, Michael Bohle wrote:
an excellent question. i want to repeat and stress what is said within
Ardour, but probably not clearly enough:
It is illegal to distribute binaries of a GPL'ed application
compiled with VST support.
Illegal, OK? Don't do it. We didn't ask for this situation, but its the
situation we have and nobody is going to be helped by people breaking
licensing agreements. I would remind distributors that if you break the
license in any way, you lose all ability to distribute a GPL'ed
application at all. So please, don't do it.
--p
I don't like dssi-vst so much, too buggy
Your bug reports and fixes have been invaluable.
It dosn't work with fst 1.7 because of a
graphical prob.
I notice jacklab.net offers a binary distribution of libfst, and says "an
experimental version of ardour-fst is in preparation". How do you deal with
the licensing problem?
10:47 a.m.
OK, thank you Paul for saving our project... we cancel now vst support
in any way. The binary will be deleted. Also LMMS will be informed
because of the violation of the licences.
Michael
Am Freitag, den 27.01.2006, 09:25 -0500 schrieb Paul Davis:
On Fri, 2006-01-27 at 14:13 +0000, Chris Cannam
wrote:
On Friday 27 Jan 2006 14:03, Michael Bohle
wrote:
an excellent question. i want to repeat and stress what is said within
Ardour, but probably not clearly enough:
It is illegal to distribute binaries of a GPL'ed application
compiled with VST support.
Illegal, OK? Don't do it. We didn't ask for this situation, but its the
situation we have and nobody is going to be helped by people breaking
licensing agreements. I would remind distributors that if you break the
license in any way, you lose all ability to distribute a GPL'ed
application at all. So please, don't do it.
--p
I don't like dssi-vst so much, too buggy
Your bug reports and fixes have been invaluable.
It dosn't work with fst 1.7 because of a
graphical prob.
I notice jacklab.net offers a binary distribution of libfst, and says "an
experimental version of ardour-fst is in preparation". How do you deal with
the licensing problem?
10:57 a.m.
Am Freitag, den 27.01.2006, 14:13 +0000 schrieb Chris Cannam:
As I write to Paul... We giving up VST Support in any way.
Michael
On Friday 27 Jan 2006 14:03, Michael Bohle wrote:
Sorry for this harsh words: dssi-vst needing very old wine for compiling
and there is no development happens since long time. The "bugs" are
mostly because of missing impelentations of some vst standards like sync
to host or heavy freezes when activating any kind of midi learn within
the vst. u know that ;)
But anyway, VST on Linux is dead now, beause most of the user are not
able to compile it for themself. Thats pity, what can we do now?
I don't like dssi-vst so much, too buggy
Your bug reports and fixes have been invaluable. It dosn't work with fst 1.7 because of a
graphical prob.
I notice jacklab.net offers a binary distribution of libfst, and says "an
experimental version of ardour-fst is in preparation". How do you deal with
the licensing problem?
Chris
11:13 a.m.
On Friday 27 Jan 2006 14:57, Michael Bohle wrote:
Sorry for this harsh words: dssi-vst needing very old
wine for compiling
and there is no development happens since long time.
The "bugs" are mostly because of missing impelentations of some vst
standards like sync to host or heavy freezes when activating any kind of
midi learn within the vst.
Fixes, including build fixes, are always welcome. So are specific examples of
VST features that would be useful. Some VST features don't map well onto
DSSI at all (e.g. I haven't yet thought of a good way of handling VST chunks:
any ideas welcome) but others aren't there just because I haven't found the
time to deal with them.
But anyway, VST on Linux is dead now, beause most of
the user are not
able to compile it for themself. Thats pity, what can we do now?
Distribute binaries of dssi-vst. That's one reason it exists in the first
place. It won't solve all your problems, but it's better than nothing.
Honestly, none of this is news. Even the jacklab.net site itself makes
reference to the licensing problem... at the same time as ignoring it.
Chris
6:57 p.m.
Fixes, including build fixes, are always welcome. So
are specific examples of
VST features that would be useful. Some VST features don't map well onto
DSSI at all (e.g. I haven't yet thought of a good way of handling VST chunks:
any ideas welcome)
you mean the chunks of binary data that were permitted since the parameter structure in
VST is so limited that it cant contain anything beside a float bound between 0.0 and 1.0?
id hope one would expose that via OSC instead, so that it can be changed somewhere besides
the plugin GUI, and since its protocol should allow all the things that couldnt be
squeezed into a VST param: filenames, integers, patchnames etc...
2:39 p.m.
On Fri, 2006-01-27 at 15:57 +0100, Michael Bohle wrote:
But anyway, VST on Linux is dead now, beause most of
the user are not
able to compile it for themself.
Wrong. You just need to write a wrapper that handles the compiling.
Look how many people use the Nvidia driver, where the licensing also
requires it to be compiled during the install process.
Lee
10:42 a.m.
As far as i see Jorgen only want to support the
obsolet OSS driver model
and native VST Linux plugins... No chance for eXT on Linux...
From the KVR forum (http://www.kvraudio.com/forum/viewtopic.php?t=114488):
---
the midi/audio driver part of xt2 is open source, so anyone can add
jack support for it (knowing c/c++ and jack that is). xt currently
works with OSS only. Works great on kernel 2.6. I get very low
latencies with it over here.
---
I'm not sure about that... I thought there was no OSS in kernel 2.6?
Anyway, looks positive doesn't it?
10:56 a.m.
On Fri, 2006-01-27 at 14:42 +0000, James McDermott wrote:
fer cryin out loud, will you guys *look* at the screenshot!
it already has JACK working!
As far as i
see Jorgen only want to support the obsolet OSS driver model
and native VST Linux plugins... No chance for eXT on Linux...
From the KVR forum (http://www.kvraudio.com/forum/viewtopic.php?t=114488):
---
the midi/audio driver part of xt2 is open source, so anyone can add
jack support for it (knowing c/c++ and jack that is). xt currently
works with OSS only. Works great on kernel 2.6. I get very low
latencies with it over here.
---
I'm not sure about that... I thought there was no OSS in kernel 2.6?
Anyway, looks positive doesn't it?
11:10 a.m.
Am Freitag, den 27.01.2006, 09:59 -0500 schrieb Paul Davis:
On Fri, 2006-01-27 at 14:42 +0000, James McDermott
wrote:
fer cryin out loud, will you guys *look* at the screenshot!
it already has JACK working!
Hmm, must have something on my eyes, see only screenshots with dssi-vst
wrapping eXT. OK, dssi-vst working as a Jackclient... but where for hell
is the screenshot of a native build of a jackified eXT? Can you post the
exact url?
Michael
As far as
i see Jorgen only want to support the obsolet OSS driver model
and native VST Linux plugins... No chance for eXT on Linux...
From the KVR forum (http://www.kvraudio.com/forum/viewtopic.php?t=114488):
---
the midi/audio driver part of xt2 is open source, so anyone can add
jack support for it (knowing c/c++ and jack that is). xt currently
works with OSS only. Works great on kernel 2.6. I get very low
latencies with it over here.
---
I'm not sure about that... I thought there was no OSS in kernel 2.6?
Anyway, looks positive doesn't it?
11:25 a.m.
fer cryin out
loud, will you guys *look* at the screenshot!
it already has JACK working!
Hmm, must have something on my eyes, see only screenshots with dssi-vst
wrapping eXT. OK, dssi-vst working as a Jackclient... but where for hell
is the screenshot of a native build of a jackified eXT? Can you post the
exact url? 
12:25 p.m.
On Fri, Jan 27, 2006 at 10:28:26AM -0500, Paul Davis wrote:
*blush*
my mistake. i don't use dssi-vst, so i did not realize that the presence
of xt2 qjackctl's connections was created that way.
many apologies for being so rude.
in another thread, Jorgen said that the input/output part of eXT on Linux
will be Open Source, so the JACK wizards can JACKify it as soon as it is
released.
As for VST only, eek.
fer cryin out loud, will you guys *look* at the
screenshot!
it already has JACK working!
Hmm, must have something on my eyes, see only screenshots with dssi-vst
wrapping eXT. OK, dssi-vst working as a Jackclient... but where for hell
is the screenshot of a native build of a jackified eXT? Can you post the
exact url? 
1:38 p.m.
On Fri, 27 Jan 2006 08:29:51 -0800
thockin(a)hockin.org wrote:
in another thread, Jorgen said that the input/output
part of eXT on Linux
will be Open Source, so the JACK wizards can JACKify it as soon as it is
released.
Why would anyone do this? To generate more revenue for the author? This
is not really how open source works.
Well, people might do this to help out their fellow users, but for me
above would leave a bitter taste.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
1:57 p.m.
On Fri, Jan 27, 2006 at 06:38:16PM +0100, Florian Schmidt wrote:
On Fri, 27 Jan 2006 08:29:51 -0800
thockin(a)hockin.org wrote:
I would do it so that I have a potentially viable alternative to the
current state of affairs, which is that I boot windows to do music.
eXT is a decent program. The reason we don't get commercial apps on Linux
is because no one buys them. Linux folks want everything free.
I am as big a believer in Open Source as anyone else here. But I am also
a pragmatist, and until such time as a viable free alternative exists, I
have to use commercial apps. Given that, would I rather use and support a
commercial app that runs on Windows only or one that runs on Linux, too?
If you can't cope with the idea that someone makes a living doing
software, don't buy eXT, don't help Jorgen, and just ignore it. I, for
one, will do anything I can to help him make Linux into a competitive
migration path for Windows users.
Now, the problem is plugins - VST only? eek.
Tim
in another thread, Jorgen said that the
input/output part of eXT on Linux
will be Open Source, so the JACK wizards can JACKify it as soon as it is
released.
Why would anyone do this? To generate more revenue for the author? This
is not really how open source works.
Well, people might do this to help out their fellow users, but for me
above would leave a bitter taste.
5:29 p.m.
On Fri, 27 Jan 2006 10:02:06 -0800
thockin(a)hockin.org wrote:
I would do it so that I have a potentially viable
alternative to the
current state of affairs, which is that I boot windows to do music.
eXT is a decent program. The reason we don't get commercial apps on Linux
is because no one buys them. Linux folks want everything free.
I am as big a believer in Open Source as anyone else here. But I am also
a pragmatist, and until such time as a viable free alternative exists, I
have to use commercial apps. Given that, would I rather use and support a
commercial app that runs on Windows only or one that runs on Linux, too?
If you can't cope with the idea that someone makes a living doing
software, don't buy eXT, don't help Jorgen, and just ignore it. I, for
one, will do anything I can to help him make Linux into a competitive
migration path for Windows users.
Oh i can live perfectly well with the idea of people making a living
doing linux software. I myself code linux apps for money.
But i have a problem with opening parts of it as open source in the hope
that users fill in the blanks. Users that have to pay for the software
in the first place. Well you might argue that you can get the open
source part free. Yeah, but it's useless without the pay package.
But this is just my personal opinion.
Besides. Depending on the app design adding jack support is dead simple.
Have fun,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
2:42 p.m.
On Fri, 2006-01-27 at 08:29 -0800, thockin(a)hockin.org wrote:
in another thread, Jorgen said that the input/output
part of eXT on
Linux will be Open Source, so the JACK wizards can JACKify it as soon
as it is released.
It's frustrating that most audio application writers STILL consider OSS
a sane default, it just waste's everyone's time (see also Skype). OSS
has been deprecated for years...
Lee
3:43 p.m.
2006/1/27, Lee Revell <rlrevell(a)joe-job.com>om>:
It's frustrating that most audio application
writers STILL consider OSS
a sane default, it just waste's everyone's time (see also Skype). OSS
has been deprecated for years...
Well, honestly I have to admit that I'm guilty of that too. why?
Because of portaudio, it's propably on of the most convinient ways
to use an audio API. And unfortunatly it only provides OSS in Version
18, which is what I use. I took a peek into v19, that has ALSA Support,
but it became just too complex.
The only alternative would be jack, but since I'm only doing simple
applications, I don't need to run jack, and I do not expect my users to do
so either.
Writing against the native ALSA API is a pain, because it requires much
more low level stuff, that I don't really care for. And on top of that it'd also
require me to setup my own thread for the callback mechanism.
I guess I'm just to lazy. ;)
-Richard
4:02 p.m.
On Fri, 2006-01-27 at 20:43 +0100, Richard Spindler wrote:
2006/1/27, Lee Revell <rlrevell(a)joe-job.com>om>:
Um, I thought the whole point of portaudio is you don't write your
application to the OSS or ALSA API, you write to the PortAudio API and
don't have to worry about the low level sound system?
It's frustrating that most audio application
writers STILL consider OSS
a sane default, it just waste's everyone's time (see also Skype). OSS
has been deprecated for years...
Well, honestly I have to admit that I'm guilty of that too. why?
Because of portaudio, it's propably on of the most convinient ways
to use an audio API. And unfortunatly it only provides OSS in Version
18, which is what I use. I took a peek into v19, that has ALSA Support,
but it became just too complex.
The only alternative would be jack, but since I'm
only doing simple
applications, I don't need to run jack, and I do not expect my users to do
so either.
Writing against the native ALSA API is a pain, because it requires much
more low level stuff, that I don't really care for. And on top of that it'd also
require me to setup my own thread for the callback mechanism.
ALSA supports standard read/write access just like OSS.
I guess I'm just to lazy. ;)
-Richard
4:09 p.m.
2006/1/27, Lee Revell <rlrevell(a)joe-job.com>om>:
Um, I thought the whole point of portaudio is you
don't write your
application to the OSS or ALSA API, you write to the PortAudio API and
don't have to worry about the low level sound system?
Well, but there IS no ALSA backend in Portaudio v18
-Richard
5:08 p.m.
On Fri, 2006-01-27 at 20:43 +0100, Richard Spindler wrote:
Writing against the native ALSA API is a pain, because
it requires much
more low level stuff, that I don't really care for. And on top of that it'd also
require me to setup my own thread for the callback mechanism.
i thought this too until i actually tried to write a minimal OSS-
equivalent ALSA app. the number of calls vs. OSS is almost exactly the
same, the only difference is the length of the function names
(snd_pcm_read() vs. read()).
there are certain basic things that any app using a HAL has to control,
and the way ALSA and OSS do it doesn't change that very much at all.
--p
11:04 a.m.
Am Freitag, den 27.01.2006, 14:42 +0000 schrieb James McDermott:
As I heard from eXT on Linux, I bought a licence für eXT for my Windows
DAW. It is a fantastic little programm, very stable and full of nice
features. I really hope that the linux port will be a great one - but I
see Ardour with (hopefully soon with midisupport) and so I dont see so
much chances for an eXT without Jack support.
Michael
As far as i
see Jorgen only want to support the obsolet OSS driver model
and native VST Linux plugins... No chance for eXT on Linux...
From the KVR forum (http://www.kvraudio.com/forum/viewtopic.php?t=114488):
---
the midi/audio driver part of xt2 is open source, so anyone can add
jack support for it (knowing c/c++ and jack that is). xt currently
works with OSS only. Works great on kernel 2.6. I get very low
latencies with it over here.
---
I'm not sure about that... I thought there was no OSS in kernel 2.6?
Anyway, looks positive doesn't it?
2:37 p.m.
On Fri, 2006-01-27 at 14:42 +0000, James McDermott wrote:
the midi/audio driver part of xt2 is open source, so
anyone can add
jack support for it (knowing c/c++ and jack that is). xt currently
works with OSS only. Works great on kernel 2.6. I get very low
latencies with it over here.
AAARRRRRHRRRGGGGGHHHHHHH
6820
days inactive
6820
days old
linux-audio-dev@lists.linuxaudio.org
23 comments
9 participants
participants (9)
-
cdr -
Chris Cannam -
Florian Schmidt -
James McDermott -
Lee Revell -
Michael Bohle -
Paul Davis -
Richard Spindler -
thockin＠hockin.org