14 Jan
2011
14 Jan
'11
10:08 a.m.
Hi list,
I suppose I could've just addressed this to drobilla and got most of my
questions answered but it concerns us all really as even if A3 and qtractor
were to achieve feature parity with Cubase and buds tomorrow (obviously I'm
stretching things a bit there) we still wouldn't see vast droves switching
to Linux DAWs for a few reasons such as hardware support, people liking what
they know etc. but most importantly the dearth of quality native plugins
available for Linux seems to be a primary showstopper for most.
DSSI has a few things coded for it but not much and its still very early
days for LV2 so the open plugin format of the future is still anyones game
and it may not necessarily be either of those that succeeds and gets widely
used of course. I think a couple of VSTs have been ported over to LV2 but
I'm not aware of any that have been ported to DSSI and I think that the ease
in doing so is quite an important factor in the success of any such format,
if not the be-all and end-all. If anyone here has any experience with coding
and/or porting VSTis - what is currently lacking from LV2 or DSSI that could
potentially cause problems for someone wanting to port their big beefy synth
or snazzy FX from VSTi to LV2 or DSSI? I already know about the incomplete
persist LV2 extension but I'm pretty sure that won't be the only thing
needing work.
A very important factor for such a format would definitely be that the major
hosts (commercial, foss or otherwise) for all major platforms would be able
to easily implement support for it and that plugins would be easy to port
between the different platforms. I'm not aware of any DAWs for Windows that
support LV2 or DSSI yet but I could be wrong? There's nothing stopping a
closed source, commecial app vendor adding support for either format is
there? Another factor I see as increasingly important is that the plugin
format should be able to take advantage of OpenCL to take advantage of the
superior processing power of todays GPUs. Quite how we'd convince Steinberg
and co. we need a replacement for VSTi and get them to support an open
standard though is anyones guess :/
14 Jan
14 Jan
10:24 a.m.
On Fri, 14 Jan 2011 10:08:29 +0000
allcoms <allcoms(a)gmail.com> wrote:
Hi list,
I suppose I could've just addressed this to drobilla and got most of
my
questions answered but it concerns us all really as even if A3 and
qtractor
were to achieve feature parity with Cubase and buds tomorrow
(obviously I'm
stretching things a bit there) we still wouldn't see vast droves
switching
to Linux DAWs for a few reasons such as hardware support, people
liking what
they know etc. but most importantly the dearth of quality native
plugins
available for Linux seems to be a primary showstopper for most.
DSSI has a few things coded for it but not much and its still very
early
days for LV2 so the open plugin format of the future is still
anyones game
and it may not necessarily be either of those that succeeds and gets
widely
used of course. I think a couple of VSTs have been ported over to
LV2 but
I'm not aware of any that have been ported to DSSI and I think that
the ease
in doing so is quite an important factor in the success of any such
format,
if not the be-all and end-all. If anyone here has any experience
with coding
and/or porting VSTis - what is currently lacking from LV2 or DSSI
that could
potentially cause problems for someone wanting to port their big
beefy synth
or snazzy FX from VSTi to LV2 or DSSI? I already know about the
incomplete
persist LV2 extension but I'm pretty sure that won't be the only
thing
needing work.
A very important factor for such a format would definitely be that
the major
hosts (commercial, foss or otherwise) for all major platforms would
be able
to easily implement support for it and that plugins would be easy to
port
between the different platforms. I'm not aware of any DAWs for
Windows that
support LV2 or DSSI yet but I could be wrong? There's nothing
stopping a
closed source, commecial app vendor adding support for either format
is
there? Another factor I see as increasingly important is that the
plugin
format should be able to take advantage of OpenCL to take advantage
of the
superior processing power of todays GPUs. Quite how we'd convince
Steinberg
and co. we need a replacement for VSTi and get them to support an
open
standard though is anyones guess :/
They won't support a cross platform open standard. (Steinberg)
Good point about DSSI though. I've been trying a few, and they work
ok. I'd ask what's missing (if anything) in the DSSI protocol that
could enhance the opportunities for coders to build more plugins,
synths, etc... Perhaps strengthening DSSI (if needed), coupled with
LV2 would be sufficient for plugin/synth options/formats?
LV2 seems to be moving along, although i just installed Tom's new
ir.lv2 and it won't run at all with lv2_jack_host, or lv2jackrack. So
it's Ardour specific. (As he did indeed indicate.)
I have the mighty jconvolver though, so nothing is lost.
Alex.
Alex.
11:03 a.m.
On 14 January 2011 11:24, Alex Stone <alextone(a)bmail.ru> wrote:
LV2 seems to be moving along, although i just
installed Tom's new ir.lv2 and
it won't run at all with lv2_jack_host, or lv2jackrack. So it's Ardour
specific. (As he did indeed indicate.)
It should (and will) work with other hosts, but it does not ATM. The
problem you see is not a limitation of the LV2 plugin format, just the
fact that the plugin was not tested with anything but Ardour.
Tom
11:46 a.m.
On Fri, 14 Jan 2011 12:03:31 +0100
Tom Szilagyi <tomszilagyi(a)gmail.com> wrote:
On 14 January 2011 11:24, Alex Stone
<alextone(a)bmail.ru> wrote:
Tom, thanks for the heads up.
Alex.
LV2 seems to be moving along, although i just
installed Tom's new
ir.lv2 and
it won't run at all with lv2_jack_host, or lv2jackrack. So it's
Ardour
specific. (As he did indeed indicate.)
It should (and will) work with other hosts, but it does not ATM. The
problem you see is not a limitation of the LV2 plugin format, just
the
fact that the plugin was not tested with anything but Ardour.
Tom
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user 
11:08 a.m.
Am 14.01.2011 11:08, schrieb allcoms:
Hi list,
I suppose I could've just addressed this to drobilla and got most of my
questions answered but it concerns us all really as even if A3 and qtractor
were to achieve feature parity with Cubase and buds tomorrow (obviously I'm
stretching things a bit there) we still wouldn't see vast droves switching
to Linux DAWs for a few reasons such as hardware support, people liking what
they know etc. but most importantly the dearth of quality native plugins
available for Linux seems to be a primary showstopper for most.
DSSI has a few things coded for it but not much and its still very early
days for LV2 so the open plugin format of the future is still anyones game
and it may not necessarily be either of those that succeeds and gets widely
used of course.
I think it would be wise, to throw everything on LV2 and to abandon DSSI
and LADSPA in the long run. And to make that clear to everyone out there
who thinks about getting into plugin-programming for Linux.
LV2 has matured a lot and it has get a lot of new great plugins that
show its powers in the last year. Think of CALF, LinuxDSP or, just
recently IR.
There is still a lot to be done but see, what a normal user can actually
do today with LV2 -- this is exactly, what people are asking for if they
complain the lack of plugins on Linux.
I think a couple of VSTs have been ported over to LV2
but
I'm not aware of any that have been ported to DSSI
No suprise. While DSSI is quite nice, it did not do well in the real
world while LV2 has some quite impressing case-studies to offer. If you
think about porting to a native format, you will have a look upon
solutions made in that format.
So look upon the Invada or CALF plugins in LV2 and compare it with
WhysynthDSSI or other DSSI-plugins.
Of course, the CALF-plugins work more or less the same as great as
DSSI-variants. But this only proves, that there seem to be no
shortcomings in LV2 since it can do the same at least and is newer...
and I think that the ease
in doing so is quite an important factor in the success of any such format,
if not the be-all and end-all. If anyone here has any experience with coding
and/or porting VSTis - what is currently lacking from LV2 or DSSI that could
potentially cause problems for someone wanting to port their big beefy synth
or snazzy FX from VSTi to LV2 or DSSI? I already know about the incomplete
persist LV2 extension but I'm pretty sure that won't be the only thing
needing work.
A very important factor for such a format would definitely be that the major
hosts (commercial, foss or otherwise) for all major platforms would be able
to easily implement support for it and that plugins would be easy to port
between the different platforms. I'm not aware of any DAWs for Windows that
support LV2 or DSSI yet but I could be wrong? There's nothing stopping a
closed source, commecial app vendor adding support for either format is
there? Another factor I see as increasingly important is that the plugin
format should be able to take advantage of OpenCL to take advantage of the
superior processing power of todays GPUs. Quite how we'd convince Steinberg
and co. we need a replacement for VSTi and get them to support an open
standard though is anyones guess :/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:32 a.m.
Just to add a bit of an insight as a person who basically gave up Linux
Audio almost entirely due to the lack of plugins.
The problem, in my opinion, is not in the format itself. The way I see it,
there are 3 major problems, in no particular order:
1. Lack of documentation and tools that would ease development for LV2 and
JACK support.
I could, without being a programmer, put together an audio program or even a
basic plugin when on Windows. On Linux I couldn't even get started - it is
very complex programming and even setting up JACK is not very simple at all.
Of course, these are the words of the non-programmer, however, it does say
something. Besides, I am not the only one pointing out the lack of
documentation and tools for rapid development. A JACK library that would
allow to setup JACK support in an application easily, like JACK_Init() would
be great, but atm it is not even close to that.
Of course, this point is the weakest point I bring up, I am understand that
as a non-programmer I might not make sense here.
2. Most good plugins on Win and Mac are not just proprietary, they are
commercial and their producers offer them for pretty high prices.
It seems to me that most serious VST and VSTi programmers are ready to go
into audio development only if they are sure they get paid handsomely. At
least, on Linux we have Zyn and now also Phasex, two only serious VSTi-like
synths, which get ported all around, while in the VSTi world the amount of
synths of such quality and options is more than 2. In fact, much more. Many
serious DAWs come bundled with 2-3 of them at the very least and come with a
dozen of standard effects like Delay, Reverb, Flanger, Chorus, Phaser,
Compressor, EQ, usually of pretty decent quality. On Linux Audio I have
difficulty finding a reverb and delay that suit me, CALF being the closest
to a good delay.
I don't know if money is the only factor, but it is very much on the
surface, the difference in the offerings.
Also, there is a whole bunch of decent freeware VST plugins, but as far as I
understand this very much depends on what I said in problem 1 - I know
several people personally who had made pretty cool effects and synths of a
level that is a rarity on Linux, assisted by plugin making tools that ease
the development a lot, including GUI development.
3. Not a lot of people in the Linux Audio world seem to care much about that
particular type of music that requires a lot of synths and fancy effects.
On my site I wrote an article which many people have probably read, as I
referred to it often, which makes a distinction between two types of music
from a production point of view (
http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=…)linux_types).
It seems to me that this, by far, is the most important reason Linux Audio
does not have a lot of plugins - most musicians (many of them being
developers at the same time) here simply do not need them. They record their
guitars and vocals and are pretty happy. And those people that do need lots
of fancy plugins, come to Linux, hang around, see that nothing is in the
store and leave.
Again, I think that this is the main reason. If a lot of people would be
here who need a delay plugin with many options or a serious reverb or
whatever - it would pop up. Atm - I don't get a sense of that need. And last
year when I was very actively researching what Linux Audio can offer, it
seemed to be I was the only person who talked about electronic music and the
need for fancy effects. Obviously, I am not the only one in question, but I
am part of a very minor group, that's for sure.
Cheers!
--
Louigi Verona
http://www.louigiverona.ru/
12:02 p.m.
On 01/14/2011 12:32 PM, Louigi Verona wrote:
Just to add a bit of an insight as a person who
basically gave up
Linux Audio almost entirely due to the lack of plugins.
The problem, in my opinion, is not in the format itself. The way I see
it, there are 3 major problems, in no particular order:
1. Lack of documentation and tools that would ease development for LV2
and JACK support.
I could, without being a programmer, put together an audio program or
even a basic plugin when on Windows. On Linux I couldn't even get
started - it is very complex programming and even setting up JACK is
not very simple at all. Of course, these are the words of the
non-programmer, however, it does say something. Besides, I am not the
only one pointing out the lack of documentation and tools for rapid
development. A JACK library that would allow to setup JACK support in
an application easily, like JACK_Init() would be great, but atm it is
not even close to that.
Of course, this point is the weakest point I bring up, I am understand
that as a non-programmer I might not make sense here.
2. Most good plugins on Win and Mac are not just proprietary, they are
commercial and their producers offer them for pretty high prices.
It seems to me that most serious VST and VSTi programmers are ready to
go into audio development only if they are sure they get paid
handsomely. At least, on Linux we have Zyn and now also Phasex, two
only serious VSTi-like synths, which get ported all around, while in
the VSTi world the amount of synths of such quality and options is
more than 2. In fact, much more. Many serious DAWs come bundled with
2-3 of them at the very least and come with a dozen of standard
effects like Delay, Reverb, Flanger, Chorus, Phaser, Compressor, EQ,
usually of pretty decent quality. On Linux Audio I have difficulty
finding a reverb and delay that suit me, CALF being the closest to a
good delay.
I don't know if money is the only factor, but it is very much on the
surface, the difference in the offerings.
Also, there is a whole bunch of decent freeware VST plugins, but as
far as I understand this very much depends on what I said in problem 1
- I know several people personally who had made pretty cool effects
and synths of a level that is a rarity on Linux, assisted by plugin
making tools that ease the development a lot, including GUI development.
3. Not a lot of people in the Linux Audio world seem to care much
about that particular type of music that requires a lot of synths and
fancy effects.
On my site I wrote an article which many people have probably read, as
I referred to it often, which makes a distinction between two types of
music from a production point of view
(http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=…
<http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=linux_types>).
It seems to me that this, by far, is the most important reason Linux
Audio does not have a lot of plugins - most musicians (many of them
being developers at the same time) here simply do not need them. They
record their guitars and vocals and are pretty happy. And those people
that do need lots of fancy plugins, come to Linux, hang around, see
that nothing is in the store and leave.
Again, I think that this is the main reason. If a lot of people would
be here who need a delay plugin with many options or a serious reverb
or whatever - it would pop up. Atm - I don't get a sense of that need.
And last year when I was very actively researching what Linux Audio
can offer, it seemed to be I was the only person who talked about
electronic music and the need for fancy effects. Obviously, I am not
the only one in question, but I am part of a very minor group, that's
for sure.
@Louigi, People suggested you to learn SuperCollider, which you didn't
like because of the difficulty and time you have to invest to learn it.
But a while ago I came with the suggestion / idea to make plugins out of
Supercollider code. There seems to be some kind of Csound to LADSPA
plugin format / host, and there is SuperCollder to VST iirc.
Faust would be another option for such kind of stuff.
Anyway, here is that discussion
http://lalists.stanford.edu/lau/2009/09/0447.html
Regards,
\r
12:50 p.m.
On Fri, Jan 14, 2011 at 3:01 PM, rosea.grammostola <
rosea.grammostola(a)gmail.com> wrote:
Yeah, true, SC, also PD - all of them did not suit me. I tried Processing
and made a couple of audio apps, but Java does not see my USB soundcard so
Processing, which is VERY unfortunate, is not of use to me. But Minim (audio
library for Processing) is the kind of an approach for a non-programmer -
where initiating audio is basically one or two lines of code.
But for a programmer perhaps JACK documentation is quite well kept, though,
no criticism there.
--
Louigi Verona
http://www.louigiverona.ru/
@Louigi, People suggested you to learn
SuperCollider, which you didn't
like because of the difficulty and time you
have to invest to learn it.
But a while ago I came with the suggestion / idea to make plugins out of
Supercollider code. There seems to be some kind of Csound to LADSPA plugin
format / host, and there is SuperCollder to VST iirc.
Faust would be another option for such kind of stuff.
Anyway, here is that discussion
http://lalists.stanford.edu/lau/2009/09/0447.html
Regards,
\r
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2:08 p.m.
Am 14.01.2011 12:32, schrieb Louigi Verona:
Just to add a bit of an insight as a person who
basically gave up Linux
Audio almost entirely due to the lack of plugins.
The problem, in my opinion, is not in the format itself. The way I see it,
there are 3 major problems, in no particular order:
1. Lack of documentation and tools that would ease development for LV2 and
JACK support.
I could, without being a programmer, put together an audio program or even a
basic plugin when on Windows. On Linux I couldn't even get started - it is
very complex programming and even setting up JACK is not very simple at all.
Of course, these are the words of the non-programmer, however, it does say
something. Besides, I am not the only one pointing out the lack of
documentation and tools for rapid development. A JACK library that would
allow to setup JACK support in an application easily, like JACK_Init() would
be great, but atm it is not even close to that.
Of course, this point is the weakest point I bring up, I am understand that
as a non-programmer I might not make sense here.
2. Most good plugins on Win and Mac are not just proprietary, they are
commercial and their producers offer them for pretty high prices.
It seems to me that most serious VST and VSTi programmers are ready to go
into audio development only if they are sure they get paid handsomely. At
least, on Linux we have Zyn and now also Phasex, two only serious VSTi-like
synths, which get ported all around, while in the VSTi world the amount of
synths of such quality and options is more than 2. In fact, much more. Many
serious DAWs come bundled with 2-3 of them at the very least and come with a
dozen of standard effects like Delay, Reverb, Flanger, Chorus, Phaser,
Compressor, EQ, usually of pretty decent quality. On Linux Audio I have
difficulty finding a reverb and delay that suit me, CALF being the closest
to a good delay.
I don't know if money is the only factor, but it is very much on the
surface, the difference in the offerings.
Also, there is a whole bunch of decent freeware VST plugins, but as far as I
understand this very much depends on what I said in problem 1 - I know
several people personally who had made pretty cool effects and synths of a
level that is a rarity on Linux, assisted by plugin making tools that ease
the development a lot, including GUI development.
3. Not a lot of people in the Linux Audio world seem to care much about that
particular type of music that requires a lot of synths and fancy effects.
On my site I wrote an article which many people have probably read, as I
referred to it often, which makes a distinction between two types of music
from a production point of view (
http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=…)linux_types).
While I can understand you wish to sort out, what it is, when we talk
about differnt types of music, I think, your definitions do not
adeaqately reflect the reality.
It is true, that there is a lot of music produced in the way you
describe as "acoustic". In fact, this "acoustic" music is probably a
share higher than 50% of the music, that is being recorded actually.
But:
I own a copy of a Led Zeppelin Songbook from the early 1970ies and its
preface states: "Led Zeppelin is whithout any doubt one of the most
influencing groups in electronic music today."
While I do not remember the words exactly by now I am absolutely
positive about the term "electronic music" in that book.
It seems to me that this, by far, is the most important reason Linux
Audio
does not have a lot of plugins - most musicians (many
of them being
developers at the same time) here simply do not need them. They
record their
guitars and vocals and are pretty happy.
In fact most musicians, that play more or less "acoustic music" by your
definition also take advantage of effects far beyond dynamics/EQ, they
play guitartracks to accompany 4 layers of synths and vice versa. They
play their acoustic instruments, then they edit the recordings and loop
them or make them samples and play them using a sequencer.
Many rock-productions are based on drums from a sequencer etc etc
So I am quite sure, that most musicians on the list(and out there in
general) will be very very interested in the development of tools that
may or may not be primarily made for "electronic music". Look at the
bounty users have set on ardour.org for including a MIDI-sequencer.
I myself use to use the grid-snapping in ardour extensively though not a
extensively as others, that use to cut each and every track with rhythm
ferret before doing anything else...
And I use many strange and fancy effects and I automate them wildly
sometimes.
Again, I think that this is the main reason. If a lot
of people would be
here who need a delay plugin with many options or a serious reverb or
whatever - it would pop up.
True in a way but: many people may be fine with the delay-plugins that
are available for now. I agree, that it would e nice to have a more
komplex delay with bpm-recognition etc but I can do a lot of fancy stuff
with the ones available now and I guess many othes will be fine with
these also.
So while you say: "a better delay for Linux is a must-have!" I tend to
say such a plugin would be a nice-to-have.
Atm - I don't get a sense of that need. And last
year when I was very actively researching what Linux Audio can offer, it
seemed to be I was the only person who talked about electronic music and the
need for fancy effects. Obviously, I am not the only one in question, but I
am part of a very minor group, that's for sure.
Minor or not, Linux Audio should be capable for every aspect of modern
music-production.
At the other hand: it is actually, though not that convenient and
intuitive as with the most sophisticated tools for Windows/Mac.
But there is a differnce between inconvenient and impossible.
Cheers!
2:54 p.m.
I agree that the chances of Steinberg supporting LV2 are slim to nothing -
there is absolutely no need or demand for them to do so right now at least.
Renoise supports LV2 under Windows does it? I know Renoise is about the most
respected tracker available today and its certainly a start but we'd really
need to see LV2 support appearing in more conventional DAWs- renoise being a
kinda halfway house between something like Cubase and Csound it doesn't have
mass appeal to the point n' click brigade of which I'm largely a member of
when it comes to music apps.
It does seem that LV2 is winning in mind-share and support on this list and
that DSSI has largely been dismissed as an also ran now. I neglected to
mention native VSTs in my original post. I'm aware qtractor supports these
but I'm not really interested in qtractor until TYOQTA event/release
actually happens- I did have a quick go at getting the TAL VSTs working
under Dreamstudio's qtractor a while back but had no luck and didn't bother
pursuing it any further. Besides, I've just been searching my mail when I
quizzed Rui about the native VST support and he mentioned a problem or two
that I can't quite recall now that I presume still exists?
If we can get native VSTs working reliably under qtractor and hopefully A3 (
http://tracker.ardour.org/view.php?id=3278 ) then that'd be fantastic and
would certainly open the floodgates to many more good plugins, free or
otherwise. It was good to get some feedback from linuxdsp and I would expect
there'll be more demand for such products when A3 gets released and qtractor
matures to the point of being able to cater for a wider audience.
I personally see ladish and JS a stop-gap measures until we have a decent
collection of LV2 plugins- they ease what was a very tedious and complex
procedure but they're essentially solutions for a problem we hopefully won't
have in a few years. They are certainly a huge boon for people who want to
use the current linux synth offerings - none of which are planning LV2 ports
sadly AFAIK.
Multiple dozens of VSTs ported to LV2? Where? I think I can count the VST to
LV2 ports on one hand so far but none of them really grabbed my interest.
Led Zep 'electronic music'?? Erm, no.
10:24 p.m.
On 01/14/2011 02:54 PM, allcoms wrote:
It does seem that LV2 is winning in mind-share and support on this list
and that DSSI has largely been dismissed as an also ran now. I neglected
to mention native VSTs in my original post. I'm aware qtractor supports
these but I'm not really interested in qtractor until TYOQTA
event/release actually happens- I did have a quick go at getting the TAL
VSTs working under Dreamstudio's qtractor a while back but had no luck
and didn't bother pursuing it any further. Besides, I've just been
searching my mail when I quizzed Rui about the native VST support and he
mentioned a problem or two that I can't quite recall now that I presume
still exists?
re. qtractor issues with native linux vst:
the problem is only on the juce based ones. as it seems, the juce vst
framework is strongly tied with the gui infrastruture so that, in
practice, you are supposed to always open the gui editor no matter what.
i mean always, as soon as you load the plugin(.so) into address space
that is. if you fail to do so, the whole host environment gets hosed and
doomed to crash or, if you're lucky, just hang :)
that's the reason for this often strange qtractor option:
Dummy VST plugin scan (RECOMMENDED)
this will just make the perennial assumption that all native vsts are
all the same, namely a stereo vsti, with no further questions when
listing available native vst plugins. if you ever turn this off and in
any circumstance it happens to exist a juce based plugin in the search
path... well, you've been warned ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
3:21 p.m.
Hey, Hartmut!
"While I do not remember the words exactly by now I am absolutely positive
about the term "electronic music" in that book."
These are just terms. As pointed out in the article: "Since words
"acoustic"
and "electronic" are very broad, I am offering a definition of what I mean
in the context of my Linux Audio articles." Obviously, I am not giving
general definitions of acoustic and electronic music. Within my definitions
Led Zeppelin are definitely acoustic.
"So while you say: "a better delay for Linux is a must-have!" I tend to
say
such a plugin would be a nice-to-have."
So this is exactly my point. In my line of work a good delay is one of the
must haves, just as a good reverb. In your line of work it is just a nice to
have. This is exactly what I am saying. In a lot of electronic music time
effects such as delay and reverb are essential. And this is why many DAWs
have them by default and they are usually very well built. Take a look at FL
Studio and their Fruity Delay 2, Fruity Delay Bank and Fruity Reeverb. This
is really good stuff that comes by default.
"But there is a difference between inconvenient and impossible."
I also thought that there is. However, my experience shows that if something
is very inconvenient, you can do it one time, maybe two times, then you
understand that it is too much work to set up. A good example would be my
modular experience, which I did praise in this article (
http://www.louigiverona.ru/?page=projects&s=writings&t=linux&a=…)inux_modexp),
but which is such a fundamental experience, that I really have to dive into
it for the whole day in order to get even simple things done. Truth is, I do
not have the time for this as music is not my job and I cannot spend hours
just to synchronize several drum lines and find workarounds for various
bugs.
So in a practical sense, the difference between inconvenient and impossible
is not that big. Also, remember that this is not the 80s and not the 90s
where you had what you had - today you know that your friend, using Windows,
can accomplish what you work on for hours in several minutes time and it
might even sound better.
;)
--
Louigi Verona
http://www.louigiverona.ru/
4:25 p.m.
Louigi Verona wrote:
So in a practical sense, the difference between
inconvenient and
impossible is not that big. Also, remember that this is not the 80s
and not the 90s where you had what you had - today you know that your
friend, using Windows, can accomplish what you work on for hours in
several minutes time and it might even sound better.
;)
Hilarious. I always love reading Louigi's stuff. Blissful.
Best,
dp
5:03 p.m.
Am 14.01.2011 16:21, schrieb Louigi Verona:
Hey, Hartmut!
So in a practical sense, the difference between inconvenient and impossible
is not that big. Also, remember that this is not the 80s and not the 90s
where you had what you had - today you know that your friend, using Windows,
can accomplish what you work on for hours in several minutes time and it
might even sound better.
;)
True: some things can be so inconvenient, that they are quite nearly
impossible.
Given you want a synth in a song and a part in the very same song, where
the speed sweps from 112bpm to 142bpm whithin 2 bars. And the LFO of the
synth shall be synched to the speed of the song/drums etc...
Very inconvenient. For may people, that are used to work with plugins,
that recognize bpm automagically it might seem so inconvenient, that it
appeares impossible. And some will simply listen to the synthtrack and
wonder, why the hell it sounds so strange after the speed-change because
they never worked with a synth that does not catch up bpm from the
hosting DAW automatically...
What I am trying to say is, that even though you are totally correct
with finding Linux Audio imperfect, this does not mean, that it is unusable.
For certain things one needs the powers, Linux Audio Apps do not have to
offer yet. But if you use all the powers that are there already, you can
do a lot of things useful, even beautyfull even perfect.
To get back on topic:
I believe, that LV2 should be pushed and that all other formats should
be abandoned. Further I think, Louigi has a very strong point when he
asks for better tools and documentation for devs.
To have an intuitive point+click construction kit for LV2-plugins would
help a lot.
bets regs
HZN
12:25 p.m.
Excerpts from Hartmut Noack's message of 2011-01-14 12:08:09 +0100:
Am 14.01.2011 11:08, schrieb allcoms:
One thought that occurred to me:
The big advantage and disadvantage of LV2 is its extensibility.
I dare to guess that a big number of LV2 plugins exists that aren't
usable in every host out there. I'm not sure how many hosts there
currently are, but I guess around 5 popular ones. I dare guess that very
few plugins work in those hosts, and that those are only the most simple
plugins.
I dare not to draw a matrix of hosts and plugin compatibility, hence I
propose:
Each plugins author could work together with
b) authors of popular hosts
c) extension authors
to make his plugin work in at least the handful of popular hosts.
This would give the users choice and less frustration and also serve as a
base for plugin authors.
Regards,
Philipp
Hi list,
I suppose I could've just addressed this to drobilla and got most of my
questions answered but it concerns us all really as even if A3 and qtractor
were to achieve feature parity with Cubase and buds tomorrow (obviously I'm
stretching things a bit there) we still wouldn't see vast droves switching
to Linux DAWs for a few reasons such as hardware support, people liking what
they know etc. but most importantly the dearth of quality native plugins
available for Linux seems to be a primary showstopper for most.
DSSI has a few things coded for it but not much and its still very early
days for LV2 so the open plugin format of the future is still anyones game
and it may not necessarily be either of those that succeeds and gets widely
used of course.
I think it would be wise, to throw everything on LV2 and to abandon DSSI
and LADSPA in the long run. And to make that clear to everyone out there
who thinks about getting into plugin-programming for Linux.
LV2 has matured a lot and it has get a lot of new great plugins that
show its powers in the last year. Think of CALF, LinuxDSP or, just
recently IR.
There is still a lot to be done but see, what a normal user can actually
do today with LV2 -- this is exactly, what people are asking for if they
complain the lack of plugins on Linux. 
11:14 a.m.
On 1/14/11, allcoms wrote:
they know etc. but most importantly the dearth of
quality native plugins
available for Linux seems to be a primary showstopper for most.
Um, no. From my experience the main problem is in organization of your
setup and availability of conventional composition environments.
It wasn't until fairly recently that connecting apps and preserving
these connections was a nightmare, now partly solved by ladish.
And we are still lacking in the DAW department, because the "do one
thing and do it well" unix philosophy is ok for console apps, but
kills half the fun when you have an idea to try and you start
switching between windows all the time only because MIDI sequencers do
only MIDI related stuff well, and Ardour does only audio stuff well
(yes, I know about A3). Qtractor is quite of a hope there, though. I
won't even mention how much work many hosts need re usability and
design, cause I'd like to die old surrounded by grandkids, not be
brutally beheaded in my 30s.
The plug-ins, of course, indeed are important. I'd kill for an LV2
based UI for LinuxSampler that compiled (the existing one doesn't and
is abandoned anyway).
I think a couple of VSTs have been ported over to LV2
Few dozens actually
I'm not aware of any that have been ported to DSSI
LV2 can fall back to DSSI.
A very important factor for such a format would
definitely be that the major
hosts (commercial, foss or otherwise) for all major platforms would be able
to easily implement support for it and that plugins would be easy to port
between the different platforms.
There's no money for big commercial players there.
I'm not aware of any DAWs for Windows that support
LV2 or DSSI yet but
I could be wrong?
Check out Renoise
there? Another factor I see as increasingly important
is that the plugin
format should be able to take advantage of OpenCL to take advantage of the
superior processing power of todays GPUs.
Yeees, this is an important point. I'd like more attention given to
this as well.
Quite how we'd convince Steinberg and co. we need
a replacement for VSTi
and get them to support an open standard though is anyones guess :/
We couldn't. The industry tried getting away from VST back in early
2000s with GMPI and failed.
All in all, we are in a situation where we have to take care of
ourselves, Lately we saw some commercial apps been ported to Linux
(Guitar Pro, Pianoteq etc), but I don't see major hosts or plug-in
bundles ported -- big companies have a different approach to business.
P.S. I've seen this thread when there were less than 500 replies, yay :-P
Alexandre Prokoudine
http://libregraphicsworld.org
12:27 p.m.
On 01/14/2011 11:08 AM, allcoms wrote:
Hi list,
I suppose I could've just addressed this to drobilla and got most of my
questions answered but it concerns us all really as even if A3 and qtractor
were to achieve feature parity with Cubase and buds tomorrow (obviously I'm
stretching things a bit there) we still wouldn't see vast droves switching
to Linux DAWs for a few reasons such as hardware support, people liking what
they know etc. but most importantly the dearth of quality native plugins
available for Linux seems to be a primary showstopper for most.
Is that necessarily bad? Maybe there is a dearth of quality native
plugins, but I'm fine with the plugins that are available currently. And
I'm happy I don't have to make up my mind which plugins to choose from
the thousands of plugins available if I would use a proprietary OS.
DSSI has a few things coded for it but not much and
its still very early
days for LV2 so the open plugin format of the future is still anyones game
and it may not necessarily be either of those that succeeds and gets widely
used of course. I think a couple of VSTs have been ported over to LV2 but
I'm not aware of any that have been ported to DSSI and I think that the ease
in doing so is quite an important factor in the success of any such format,
if not the be-all and end-all. If anyone here has any experience with coding
and/or porting VSTis - what is currently lacking from LV2 or DSSI that could
potentially cause problems for someone wanting to port their big beefy synth
or snazzy FX from VSTi to LV2 or DSSI? I already know about the incomplete
persist LV2 extension but I'm pretty sure that won't be the only thing
needing work.
Don't forget native Linux VST's, their number is steadily growing also.
I think I have about 60 to 70 of those sitting on my harddrive.
Unfortunately there are very few hosts.
Best,
Jeremy
12:37 p.m.
On 01/14/2011 01:27 PM, Jeremy Jongepier wrote:
Don't forget native Linux VST's, their number is steadily growing also.
I think I have about 60 to 70 of those sitting on my harddrive.
Unfortunately there are very few hosts.
I'd rather like to use LV2 plugins, for VST plugins you need those
Steinberg stuff iirc, and mosts hosts you have to compile in a special
way. Not a big deal maybe, but LV2 and DSSI doesn't have these hassles
and are made for Linux.
About synths: Yoshimi is good, so is PHASEX, Ingen is interesting but
unstable afaik, Whysynth has some interesting patches (amsynth, akai),
but Louigi is probably someone who is better in judging this stuff then
I am.
\r
1:28 p.m.
On 1/14/11, Jeremy Jongepier wrote:
Is that necessarily bad? Maybe there is a dearth of
quality native
plugins, but I'm fine with the plugins that are available currently. And
I'm happy I don't have to make up my mind which plugins to choose from
the thousands of plugins available if I would use a proprietary OS.
It's easy to neglect alternatives when you never had many :) We do
have a good selection of native effects, but we are lacking in well
sounding instruments immensively. But then we are back to "what kind
of music do you do" discussion.
The issue goes a little further than quantity/quality relationship.
Some things are plain missing. Luckily gaps are being slowly closed.
E.g. maybe in 2011 we will finally have an LV2 drum sampler (over to
gabaug? :))
Don't forget native Linux VST's, their number
is steadily growing also.
I think I have about 60 to 70 of those sitting on my harddrive.
Unfortunately there are very few hosts.
The last sentence quite nails it :)
Alexandre Prokoudine
http://libregraphicsworld.org
1:44 p.m.
Alexandre Prokoudine wrote:
On 1/14/11, Jeremy Jongepier wrote:
Qtractor's been doing a pretty good job with the native VSTs I've tried
in it. What really needs done is a repair/rejuvenation of Lucio
Asnaghi's JOST. A working standalone host for native VSTs would be nice.
I recently purchased Loomer's Sequent, it's a lot of fun. I notice they
also have a nice-looking synthesizer in their catalog.
The LinuxDSP plugins - in all formats - seem pretty professional to my
ears and eyes.
Best,
dp
Don't forget native Linux VST's, their
number is steadily growing also.
I think I have about 60 to 70 of those sitting on my harddrive.
Unfortunately there are very few hosts.
The last sentence quite nails it :)
1:51 p.m.
On 1/14/11, Dave Phillips wrote:
Yes, I have a similar impression, however automation is still missing
(some prerequistite chunk of code seems to be in place tho).
The last
sentence quite nails it :)
Qtractor's been doing a pretty good job with the native VSTs I've tried What really needs done is a repair/rejuvenation of
Lucio
Asnaghi's JOST.
JOST needs some love indeed. I had some good fun with JOST indeed and
I'd have even more if it wasn't crashing all the time.
Alexandre Prokoudine
http://libregraphicsworld.org
2:07 p.m.
Dave Phillips wrote:
Alexandre Prokoudine wrote:
The plan is that the linuxDSP plugins should all be available in "all"
formats eventually - LV2 seems to be by far the most popular, although I
suspect that is in no small part due to ardour's support for it. There
are not many VST hosts, and I can understand that the steinberg license
causes problems for some open-source projects (although, I have been
testing the linuxDSP VSTs with builds of qtractor using the vestige
headers and everything seems to work, so perhaps that provides a way to
drive more support for VST - Rui has done a great job with qtractor,
creating a DAW is no small undertaking!)
As regards the perceived lack of plugins - I think actually there are a
wealth of capable plugins available, but as with any OS there are some
good and some bad, (think of the number of questionable synthedit
generated free VSTs on windows..) - from a (commercial) developer point
of view, I would add that developing reliable and useful (and perhaps
professional quality) plugins requires a lot of specialist knowledge,
and is a very significant amount of work. Often the commercial returns
are quite small - our most significant revenue last year came not from
downloads of linux plugins but from porting DSP technology to other
commercial products, and I suspect this is true for developers on other
OS too. Some of which might explain the reluctance of commercial
developers to support development for linux.
On 1/14/11, Jeremy Jongepier wrote:
Qtractor's been doing a pretty good job with the native VSTs I've tried
in it. What really needs done is a repair/rejuvenation of Lucio
Asnaghi's JOST. A working standalone host for native VSTs would be nice.
I recently purchased Loomer's Sequent, it's a lot of fun. I notice they
also have a nice-looking synthesizer in their catalog.
The LinuxDSP plugins - in all formats - seem pretty professional to my
ears and eyes.
Best,
dp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Don't forget native Linux VST's, their
number is steadily growing also.
I think I have about 60 to 70 of those sitting on my harddrive.
Unfortunately there are very few hosts.
The last sentence quite nails it :)
5:55 p.m.
Excerpts from Dave Phillips's message of 2011-01-14 14:44:32 +0100:
Alexandre Prokoudine wrote:
I'm rather happy to hear that JOST and with it native VSTs are on the
decline as they combine the worst problems of both worlds, the license
issues of VST and required porting. Hopefully developers will spend
their time porting to LV2 now.
On 1/14/11, Jeremy Jongepier wrote:
Qtractor's been doing a pretty good job with the native VSTs I've tried
in it. What really needs done is a repair/rejuvenation of Lucio
Asnaghi's JOST. A working standalone host for native VSTs would be nice.
I recently purchased Loomer's Sequent, it's a lot of fun. I notice they
also have a nice-looking synthesizer in their catalog.
The LinuxDSP plugins - in all formats - seem pretty professional to my
ears and eyes.
Best,
dp Don't forget native Linux VST's, their
number is steadily growing also.
I think I have about 60 to 70 of those sitting on my harddrive.
Unfortunately there are very few hosts.
The last sentence quite nails it :)
16 Jan
16 Jan
5:24 a.m.
On Fri, Jan 14, 2011 at 04:28:48PM +0300, Alexandre Prokoudine wrote:
On 1/14/11, Jeremy Jongepier wrote:
I can't stand the whole idea of closed-source VSTs and plugins and synths.
Yeah, I'm one of THOSE guys.
Seriously, I'm using linux becuase of the freedom, the open source, and the political
aspect of it. That's why I run it. I wouldn't bother with it otherwise.
If I wanted to use proprietary, closed-source software, why would I even try to get it
running on Linux at all?
Taking this a bit father: if convenience, "user experience", time, availability,
commercial support, etc were REALLY important, why wouldn't I just get a MacBook Pro
like everyone else has, and run that?
-ken
Is that necessarily bad? Maybe there is a dearth
of quality native
plugins, but I'm fine with the plugins that are available currently. And
I'm happy I don't have to make up my mind which plugins to choose from
the thousands of plugins available if I would use a proprietary OS.
It's easy to neglect alternatives when you never had many :) We do
have a good selection of native effects, but we are lacking in well
sounding instruments immensively. But then we are back to "what kind
of music do you do" discussion.
The issue goes a little further than quantity/quality relationship.
Some things are plain missing. Luckily gaps are being slowly closed.
E.g. maybe in 2011 we will finally have an LV2 drum sampler (over to
gabaug? :))
Don't forget native Linux VST's, their
number is steadily growing also.
I think I have about 60 to 70 of those sitting on my harddrive.
Unfortunately there are very few hosts.
The last sentence quite nails it :)
5:30 a.m.
On 1/16/11, Ken Restivo wrote:
I can't stand the whole idea of closed-source VSTs and plugins and synths.
I do genuinely believe that Autostatic was referring to open sourced VSTs.
Don't forget native Linux VST's, their number
is steadily growing also.
I think I have about 60 to 70 of those sitting on my harddrive.
Unfortunately there are very few hosts.
The last sentence quite nails it :) Yeah, I'm one of THOSE guys.
Seriously, I'm using linux becuase of the freedom, the open source, and the
political aspect of it. That's why I run it. I wouldn't bother with it
otherwise.
I can't possibly imagine political aspect of writing music. Oh wait,
Peter Gabriel did it with "Biko". Right :)
If I wanted to use proprietary, closed-source
software, why would I even try
to get it running on Linux at all?
Taking this a bit father: if convenience, "user experience", time,
availability, commercial support, etc were REALLY important, why wouldn't I
just get a MacBook Pro like everyone else has, and run that?
A tad too far, maybe? :)
Alexandre Prokoudine
http://libregraphicsworld.org
9:59 a.m.
On 01/16/2011 06:30 AM, Alexandre Prokoudine wrote:
I do genuinely believe that Autostatic was referring
to open sourced VSTs.
Yes I was. I barely use any closed source stuff on my machines,
especially when it comes to making music. The source code for basically
all native LinuxVST plugins is freely available (except for the
commercial ones), same for the VST headers, be it the Vestige ones
(which work fine for 32bit) or the Steinberg ones (which you need for
64bit). Yes, the Steinberg headers can't be redistributed freely but any
binary made with it can be.
Best,
Jeremy
12:06 p.m.
On Sun, Jan 16, 2011 at 5:30 AM, Alexandre Prokoudine <
alexandre.prokoudine(a)gmail.com> wrote:
On 1/16/11, Ken Restivo wrote:
I can't stand the whole idea of closed-source VSTs and plugins and synths.
I do genuinely believe that Autostatic was referring to open sourced VSTs.
Hehe!
Why does it always, whatever we're discussing, come back to PG/ Genesis on
this list? Very strange! I don't mind coz I'm a huge prog fan and my band
have a running gag about Genesis (and the Jesuit Order, who are every bit as
good for a gag).
I suppose that the whole PG/Genesis versus the Linux audio world came to a
head when PG flew Paul out to have him demonstrate Ardour to him. What song
was in your head on the flight over las- do you remember? Watcher of the
Skies? I can only presume it wasn't quite what Pete was after at the time
otherwise we'd have some marketing machine going right there.
Maybe we should have a separate LAU/LAD for those who prefer Collins
Genesis? ;)
> > Don't forget native Linux VST's,
their number is steadily growing
also.
I think I have about 60 to 70 of those sitting on my
harddrive.
Unfortunately there are very few hosts.
The last sentence quite nails it :) Yeah, I'm one of THOSE guys.
Seriously, I'm using linux becuase of the freedom, the open source, and
the
political aspect of it. That's why I run it.
I wouldn't bother with it
otherwise.
I can't possibly imagine political aspect of writing music. Oh wait,
Peter Gabriel did it with "Biko". Right :)
2:59 p.m.
On Sun, Jan 16, 2011 at 7:06 AM, allcoms <allcoms(a)gmail.com> wrote:
I suppose that the whole PG/Genesis versus the Linux
audio world came to a
head when PG flew Paul out to have him demonstrate Ardour to him. What song
was in your head on the flight over las- do you remember? Watcher of the
Skies?
on a red eye from the east coast, probably Michael Hoenig's Departure
From the Northern Wastelands and then an attempt at
sleep.
I can only presume it wasn't quite what Pete was
after at the time
otherwise we'd have some marketing machine going right there.
oh, they loved it. problem was that (a) they then went ahead and
bought soundscape as well, mostly for their hardware but it ended with
SSL having involvement (ownership, in one case) in two DAWs which made
no sense to anyone and (b) they didn't really have much of an idea of
what to do with an open source software "product" (no blame here - it
*is* a tricky question to answer for a company like that). Full
credits to Harrison here for actually coming up with a plan in that
area, but it doesn't change the fact that the answers are not obvious.
Maybe we should have a separate LAU/LAD for those who
prefer Collins
Genesis? ;)
and a separate one for those us who have correctly diagnosed "seconds
out" as the best genesis album ever, but didn't like anything after
that except for "mama" and "the brazilian".
17 Jan
17 Jan
12:17 a.m.
On Sun, Jan 16, 2011 at 09:59:20AM -0500, Paul Davis wrote:
On Sun, Jan 16, 2011 at 7:06 AM, allcoms
<allcoms(a)gmail.com> wrote:
A friend saw them on that tour, and said they opened with "Dance on a Volcano",
at the beginning of which, all of them except Collins simultaneously stomped on Moog
Taurus pedals for that first low note in the opening riff. He said it made his hair fly
back like that dude in the old Maxell tape commercials.
-ken
I suppose that the whole PG/Genesis versus the
Linux audio world came to a
head when PG flew Paul out to have him demonstrate Ardour to him. What song
was in your head on the flight over las- do you remember? Watcher of the
Skies?
on a red eye from the east coast, probably Michael Hoenig's Departure
From the Northern Wastelands and then an attempt at sleep.
I can only presume it wasn't quite what Pete
was after at the time
otherwise we'd have some marketing machine going right there.
oh, they loved it. problem was that (a) they then went ahead and
bought soundscape as well, mostly for their hardware but it ended with
SSL having involvement (ownership, in one case) in two DAWs which made
no sense to anyone and (b) they didn't really have much of an idea of
what to do with an open source software "product" (no blame here - it
*is* a tricky question to answer for a company like that). Full
credits to Harrison here for actually coming up with a plan in that
area, but it doesn't change the fact that the answers are not obvious.
Maybe we should have a separate LAU/LAD for those
who prefer Collins
Genesis? ;)
and a separate one for those us who have correctly diagnosed "seconds
out" as the best genesis album ever, but didn't like anything after
that except for "mama" and "the brazilian". 
16 Jan
16 Jan
7:17 p.m.
On 01/16/2011 06:30 AM, Alexandre Prokoudine wrote:
On 1/16/11, Ken Restivo wrote:
well, i wouldn't read ken's comment as fundamentalist open source
zealotry, but rather as "live and let live" - people who need a wider
selection of plugins and instruments and are willing to pay can always
use what's on the market. but why should open source users bother?
the open source community doesn't have to cater to all needs.
particularly since, in my book, the commercial plugin world is riddled
with dysfunctional chrome and marketing bs - actual innovations are
quite rare. what you can get is ok if you are using plugins as a source
of inspiration, tweaking a knob here and there to get interesting, new
results. if, on the other hand, you know perfectly well what you need
for your mix, then some magic little plugin with dials labelled "depth",
"crunch" or whatever won't help.
you can't sell bs as open source, because everybody can clearly see what
a plugin does, and if it's an hf shelf with some gentle harmonic
distortion, then people want the gui to say so, and not read "vintage
warmth".
I can't stand the whole idea of closed-source VSTs and plugins and synths.
Yeah, I'm one of THOSE guys.
If I wanted to use proprietary, closed-source software, why would I even try
to get it running on Linux at all?
Taking this a bit father: if convenience, "user experience", time,
availability, commercial support, etc were REALLY important, why wouldn't I
just get a MacBook Pro like everyone else has, and run that?
A tad too far, maybe? :)
7:38 p.m.
well, i wouldn't read ken's comment as
fundamentalist open source
zealotry, but rather as "live and let live" - people who need a wider
selection of plugins and instruments and are willing to pay can always
use what's on the market. but why should open source users bother?
the open source community doesn't have to cater to all needs.
particularly since, in my book, the commercial plugin world is riddled
with dysfunctional chrome and marketing bs - actual innovations are
quite rare. what you can get is ok if you are using plugins as a source
of inspiration, tweaking a knob here and there to get interesting, new
results. if, on the other hand, you know perfectly well what you need
for your mix, then some magic little plugin with dials labelled "depth",
"crunch" or whatever won't help.
you can't sell bs as open source, because everybody can clearly see what
a plugin does, and if it's an hf shelf with some gentle harmonic
distortion, then people want the gui to say so, and not read "vintage
warmth".
While I understand the main message and agree with it, I think you are
overgeneralizing.
VST plugin world has enough innovations and the amount of very capable,
serious
plugins is actually quite large. Not all of them use the word "Depth" or
"Crunch", although
in some cases Depth is not a bad term at all, but even if they do, very
often they have
instructions which explain in detail what each parameter actually is.
It is true that there are plugins which are just a joke, but on Linux I can
also find several weird
LADSPA plugins, which have parameter names even worth than Depth, something
along
the lines of S,Q,T,P1,P2 and some other unhelpful labels and which produce
strange noise, but
it really is not representative.
When it comes to VST world, the technical representation will not be in
favor of Linux, unfortunately.
I wish it was, but it's not. I can name many excellent plugins, both VST and
VSTi, which are both
great functionally and are well marketed.
Perhaps I misunderstood what you want to say, but if you try to convey a
message that VST is just
a bunch of cloned technology with good marketing and GUI, I would say you
are over simplifying things
enormously.
In fact, a couple of months ago on LAD list I did ask that same question and
all you guys who are
developers answered. The question was whether VST stuff is really unique or
whether there is not much
innovation, but just copying. I don't remember exactly what everybody said,
but I do remember people saying
that there are complex stuff in the VST world that at the moment do not
exist on Linux, particularly good
reverb algorithms. Some other complex DSP fields were also mentioned.
So, what I am saying is that VST world is some serious stuff and although
there are many free plugins made
with SynthEdit which suck ass, there is a huge number of great VSTs which
are not only marketing.
--
Louigi Verona
http://www.louigiverona.ru/
8:35 p.m.
On 01/16/2011 08:38 PM, Louigi Verona wrote:
While I understand the main message and agree with it,
I think you
are overgeneralizing.
certainly.
i guess my point is this: being a gearhead doesn't make you a good
musician, composer, arranger or mixing engineer. most of the commercial
audio world is targetted at gearheads. it has to be, because audio
technology has been "good enough" now for a few years, so what can we do
to sell new stuff? invent bs.
opensource is no less quirky, but it's closer to a do-it-yourself
mindset, which requires the user to understand the problem, understand
possible approaches to solve it, and then apply those approaches. for
that type of user, our toolset in linux audio is mostly complete,
although streamlining is always possible (and necessary).
It is true that there are plugins which are just a
joke, but on Linux
I can also find several weird LADSPA plugins, which have parameter
names even worth than Depth, something along the lines of S,Q,T,P1,P2
and some other unhelpful labels and which produce strange noise, but
it really is not representative.
true. but this is somewhat rare in open source plugins.
i think guitarix is a good representative example of the open source
mindset: it certainly wastes way too many pixels to look like some
actual piece of gear (for my taste), but: all knobs are labelled with
their function, not some fancy fantasy name. the plugin /wants/ /you/ to
understand what /you/ are doing.
many closed source plugins /don't/ /want/ /you/ to understand what
/they/ are doing. /you/ don't get to do much in the first place.
Perhaps I misunderstood what you want to say, but if
you try to
convey a message that VST is just a bunch of cloned technology with
good marketing and GUI, I would say you are over simplifying things
enormously.
well, vst by itself is nothing more than an api. i have nothing to say
of its technical merits.
In fact, a couple of months ago on LAD list I did ask
that same
question and all you guys who are developers answered. The question
was whether VST stuff is really unique or whether there is not much
innovation, but just copying. I don't remember exactly what
everybody said, but I do remember people saying that there are
complex stuff in the VST world that at the moment do not exist on
Linux, particularly good reverb algorithms. Some other complex DSP
fields were also mentioned.
true. heck, i wish i had a really good room simulator, almost every time
i start a new project. but that's a matter of convenience, not a
fundamental obstacle.
i tend to think of the entire set of plugins and tools i have (and know
how to use) as my instrument. at times, it might be tempting to desire
extensions of the instrument, but often it's more effective to just hone
my skills (yeah, mixing engineers have to practice, too, and a lot!) and
get better on what i have.
actually, i pity the "namm show" kids who go crazy over each new trend,
shell out money, tweak a few knobs, and still can't finish their debut
album for lack of artistic vision. it's of course not the fault of any
one plugin or manufacturer, but the overabundance of toys makes it very
easy to fall into that trap.
and the market pretty much consists of people sitting in this very trap,
or how else would you reconcile the gear sales figures with the actual
musical reality out there? i guess there's probably five mastering
plugins sold for every album that comes out...
heck, even highly respected tonmeisters fall for "bogus toys" bs. just a
few weeks ago, i had someone rave to me about 384khz sampling rate and
why sacd is so great. this guy had no idea of 24bit pcm vs. 1bit
delta-sigma, nor did he know about lipshitz and vanderkooy having
effectively buried the entire sacd technology years ago. he was (and is)
a true believer.
he's also a very skilled mixing engineer, but he doesn't know that he
makes great albums despite sacd technology, not because of it :)
So, what I am saying is that VST world is some serious
stuff and
although there are many free plugins made with SynthEdit which suck
ass, there is a huge number of great VSTs which are not only
marketing.
absolutely.
i'm a very ironic person - in face-to-face talk, people usually gather
from my tone of voice that i'm being a bit cynical and take it
accordingly. but if i were to use winkies each time i should, my mails
would double in size...
8:54 p.m.
Hehe. I hear ya.
Yeah, there are lots of toys. Brian Eno is saying that as a producer he
helps bands
to actually LIMIT the amount of technology they want to use on a record and
focus on
one or two things.
Taking into account all the irony, yeah, your point is well made and I agree
with it.
--
Louigi Verona
http://www.louigiverona.ru/
9:14 p.m.
On Sun, Jan 16, 2011 at 09:39:15PM +0100, Jörn Nettingsmeier wrote:
i guess my point is this: being a gearhead doesn't
make you a good
musician, composer, arranger or mixing engineer. most of the commercial
audio world is targetted at gearheads. it has to be, because audio
technology has been "good enough" now for a few years, so what can we do
to sell new stuff? invent bs.
An accurate summary. This started in the 'consumer' (hifi) world some
25 years ago, and today it has reached the 'pro' segment of the market
as well.
Ciao,
--
FA
There are three of them, and Alleline.
9:24 p.m.
On Sun, Jan 16, 2011 at 4:14 PM, <fons(a)kokkinizita.net> wrote:
On Sun, Jan 16, 2011 at 09:39:15PM +0100, Jörn
Nettingsmeier wrote:
well, yes and no.
there have been quite a lot of developments in the last 10 years that
represent phenomenal improvements in workflow for people who are paid
to create music on demand. their impact on aesthetics is less clear,
and probably negative, but if you're someone who writes soundtracks
for ads, tv shows or films, the tools available now totally outshine
what was available 10-15 years ago. and that part is not BS.
i guess my point is this: being a gearhead
doesn't make you a good
musician, composer, arranger or mixing engineer. most of the commercial
audio world is targetted at gearheads. it has to be, because audio
technology has been "good enough" now for a few years, so what can we do
to sell new stuff? invent bs.
An accurate summary. This started in the 'consumer' (hifi) world some
25 years ago, and today it has reached the 'pro' segment of the market
as well.
9:42 p.m.
On Sun, Jan 16, 2011 at 04:24:07PM -0500, Paul Davis wrote:
On Sun, Jan 16, 2011 at 4:14 PM,
<fons(a)kokkinizita.net> wrote:
it's very clear if you ask me
On Sun, Jan 16, 2011 at 09:39:15PM +0100, Jörn
Nettingsmeier wrote:
well, yes and no.
there have been quite a lot of developments in the last 10 years that
represent phenomenal improvements in workflow for people who are paid
to create music on demand. their impact on aesthetics is less clear, i guess my point is this: being a gearhead
doesn't make you a good
musician, composer, arranger or mixing engineer. most of the commercial
audio world is targetted at gearheads. it has to be, because audio
technology has been "good enough" now for a few years, so what can we do
to sell new stuff? invent bs.
An accurate summary. This started in the 'consumer' (hifi) world some
25 years ago, and today it has reached the 'pro' segment of the market
as well. and probably negative,
yes
but if you're someone who writes soundtracks for
ads, tv shows or
films, the tools available now totally outshine what was available
10-15 years ago. and that part is not BS.
True, but these are tools targeted at one particular type of output,
whatever marketing demands at any time. People are already getting
tired of overcompressed audio, re-aligned drums, and the endless
repetition of the same cheap effects. Much of this will be obsolete
sooner than you'd expect.
Ciao,
--
FA
There are three of them, and Alleline.
17 Jan
17 Jan
12:11 a.m.
On Sun, Jan 16, 2011 at 4:42 PM, <fons(a)kokkinizita.net> wrote:
i have 3 friends in the phila. area who do soundtrack and ad work.
they mostly layer their own performances on acoustic or electrical
instruments over rhythm tracks that they assemble from samples and
loops. they know all about the loudness wars, and it doesn't really
make much difference to them because their stuff is going to be merged
with voice-overs and FX work anyway, quite possibly ducked repeatedly.
they sometimes have to come up with 5 or 6 30 to 120 sec "pieces" in a
day, and tools that let them build rhythm tracks quickly, layer
repeated instances of their melodic/harmonic ideas throughout the
piece, quickly "master" it and move on are invaluable.
why does this matter? they get paid more, and get paid more frequently
to do this kind of work than other musician friends of mine. their
music has a larger "audience", but its an audience that isn't actually
listening to what they do - their work merely provides color or
texture or (often) some kind of geographic reference to a visual
experience. the tools they rely on have been created for what i sense
is now one the of the most common paid jobs a musician can have today.
i would guess that more music is written for this purpose than
anything else in contemporary western culture. i could be wrong, but
it has to be a close 2nd :)
the interesting part is that they prefer to use a quite different
workflow when they switch into "self-expression" mode (i.e. actually
playing music that means something to them).
On Sun, Jan 16, 2011 at 04:24:07PM -0500, Paul Davis
wrote:
but if
you're someone who writes soundtracks for ads, tv shows or
films, the tools available now totally outshine what was available
10-15 years ago. and that part is not BS.
True, but these are tools targeted at one particular type of output,
whatever marketing demands at any time. People are already getting
tired of overcompressed audio, re-aligned drums, and the endless
repetition of the same cheap effects. Much of this will be obsolete
sooner than you'd expect.
8:18 a.m.
On Sun, Jan 16, 2011 at 07:11:23PM -0500, Paul Davis wrote:
On Sun, Jan 16, 2011 at 4:42 PM,
<fons(a)kokkinizita.net> wrote:
i have 3 friends in the phila. area who do soundtrack and ad work.
they mostly layer their own performances on acoustic or electrical
instruments over rhythm tracks that they assemble from samples and
loops. they know all about the loudness wars, and it doesn't really
make much difference to them because their stuff is going to be merged
with voice-overs and FX work anyway, quite possibly ducked repeatedly.
they sometimes have to come up with 5 or 6 30 to 120 sec "pieces" in a
day, and tools that let them build rhythm tracks quickly, layer
repeated instances of their melodic/harmonic ideas throughout the
piece, quickly "master" it and move on are invaluable.
why does this matter? they get paid more, and get paid more frequently
to do this kind of work than other musician friends of mine. their
music has a larger "audience", but its an audience that isn't actually
listening to what they do - their work merely provides color or
texture or (often) some kind of geographic reference to a visual
experience. the tools they rely on have been created for what i sense
is now one the of the most common paid jobs a musician can have today.
i would guess that more music is written for this purpose than
anything else in contemporary western culture. i could be wrong, but
it has to be a close 2nd :)
'Twas ever thus. The main way for a musician to make a decent middle-class living 30
years ago, I'm told, was "jingles" (ad work) and soundtracks. Back then it
was violin players, horn players, as well as those playing drums, guitars, and other
rock-oriented instruments.
On Sun, Jan 16, 2011 at 04:24:07PM -0500, Paul
Davis wrote:
but if
you're someone who writes soundtracks for ads, tv shows or
films, the tools available now totally outshine what was available
10-15 years ago. and that part is not BS.
True, but these are tools targeted at one particular type of output,
whatever marketing demands at any time. People are already getting
tired of overcompressed audio, re-aligned drums, and the endless
repetition of the same cheap effects. Much of this will be obsolete
sooner than you'd expect. the interesting part is that they prefer to use a
quite different
workflow when they switch into "self-expression" mode (i.e. actually
playing music that means something to them).
Probably also true back then as well, but it'd have been more limited by price. The
big studios were expensive and only available for commercial work, but a TASCAM 4-track
was affordable.
-ken
3:16 a.m.
Am Sonntag, den 16.01.2011, 21:39 +0100 schrieb Jörn Nettingsmeier:
i think guitarix is a good representative example of
the open source
mindset: it certainly wastes way too many pixels to look like some
actual piece of gear (for my taste), but: all knobs are labelled with
their function, not some fancy fantasy name. the plugin /wants/ /you/
to
understand what /you/ are doing.
Some years ago I'm a analogue Instrument builder, during the development
of a Instrument comes two exiting points in the mind,
1.) how would it sound
2.) how would it look and feel
without the "look and feel" a Instrument could come close to useless for
a Artist. That could differ from what a engineer needs to work.
If you have a look at old Instrumental Building Books, you find a bunch
of stuff witch is only done for the "look and feel" of a Instrument.
So I guess the need to let something look good is older then Computers
are and Pixels are cheep this day's. ;-)
regards hermann
16 Jan
16 Jan
11:44 p.m.
On Sun, Jan 16, 2011 at 10:38:08PM +0300, Louigi Verona wrote:
So, what I am saying is that VST world is some serious
stuff
and although there are many free plugins made with SynthEdit
which suck ass, there is a huge number of great VSTs which
are not only marketing.
There are some VST plugins that are really high quality and
that don't have anything near in the free or open source world.
But they are the exception rather than the rule. And if you
want them, more often than not you can get them only by paying
for a full 'bundle' named after some shiny metal which will
then include 95% crap as well.
Ciao,
--
FA
There are three of them, and Alleline.
4:43 p.m.
Ken Restivo wrote:
I can't stand the whole idea of closed-source VSTs
and plugins and synths.
Yeah, I'm one of THOSE guys.
Seriously, I'm using linux becuase of the freedom, the open source, and the political
aspect of it. That's why I run it. I wouldn't bother with it otherwise.
If I wanted to use proprietary, closed-source software, why would I even try to get it
running on Linux at all?
Taking this a bit father: if convenience, "user experience", time,
availability, commercial support, etc were REALLY important, why wouldn't I just get a
MacBook Pro like everyone else has, and run that?
-ken
I'm very happy that there are closed-source VSTs and VSTi's, although
all the ones I use are non-native using Wine. Long may this be possible.
Yeah, I'm one of those OTHER guys ;-)
To be honest, I don't use any VSTs; I've only ever used LADSPA and LV2
effects.
Also, I'm using fewer and fewer VSTi's these days as I get more and more
hardware. But there are some things I'll never have the money or space
for and the only software alternative, or the best alternative (for me)
is some VSTi.
Only one of those VSTi's was bought before I started using Linux and I
don't use it any more as I have its successor. All the other plugin
instruments were bought knowing that they would work using Wine and
wine-asio. Yes, I've money invested and a bit of time to get them to
work initially, but it's not a throwback to mythical pre-conversion days.
In fact, I've never used Windows for music-making. I tried a little when
I was first starting out and didn't get far or get anything remotely
serious done, but very quickly moved to Linux, first DeMuDi and then
Ubuntu Studio. There are a number of things that attract me to Linux,
but most of them are probably pragmatic reasons rather than ideological
(although there are some of those).
If I wanted to use proprietary, closed-source
software, why would I
even try to get it running on Linux at all?
For me, it's all about running what I find to be the best (instrumental)
tools for the job, using the best (OS and software) tools for the job.
It's all about choice.
I hope Linux generally, and the Linux audio world specifically, never
becomes closed off, only open to those who want it to be totally free
and who want vigorously to maintain the purity of that essence :-)
Q
--
A musical collaborator: "Lethargy, hm really? Then it will be time for
me to get over there and just accidental idea the $h!t out of you"
5:13 p.m.
Q wrote:
Ken Restivo wrote:
I think there is (and should be) room for both commercial and open
source projects to coexist for linux, that way there is always the
freedom to make the choice about what to use depending upon
requirements, ideology, financial constraints etc.
As a commercial developer, linuxDSP has had to go down that particular
(commercial) road because we have significant costs associated with
maintaining the infrastructure required to produce, distribute and
develop the software, however, we started making audio software for
linux, first and foremost as enthusiastic linux users - who just wanted
to make some great tools to do what we wanted to do, and to bring them
to a wider audience in a way that enabled us to continue their development.
That said, we realise that although our software and applications
themselves contain no GPL'd code, they are indirectly dependent on many
projects (e.g. DAW applications) which may be open source, and where
possible we support those projects and - revenue permitting - hope to be
able to contribute some financial support back to some of those projects
too.
I can't stand the whole idea of closed-source
VSTs and plugins and
synths.
Yeah, I'm one of THOSE guys.
Seriously, I'm using linux becuase of the freedom, the open source,
and the political aspect of it. That's why I run it. I wouldn't bother
with it otherwise.
If I wanted to use proprietary, closed-source software, why would I
even try to get it running on Linux at all?
Taking this a bit father: if convenience, "user experience", time,
availability, commercial support, etc were REALLY important, why
wouldn't I just get a MacBook Pro like everyone else has, and run that?
-ken
I'm very happy that there are closed-source VSTs and VSTi's, although
all the ones I use are non-native using Wine. Long may this be possible.
Yeah, I'm one of those OTHER guys ;-)
To be honest, I don't use any VSTs; I've only ever used LADSPA and LV2
effects.
Also, I'm using fewer and fewer VSTi's these days as I get more and more
hardware. But there are some things I'll never have the money or space
for and the only software alternative, or the best alternative (for me)
is some VSTi.
Only one of those VSTi's was bought before I started using Linux and I
don't use it any more as I have its successor. All the other plugin
instruments were bought knowing that they would work using Wine and
wine-asio. Yes, I've money invested and a bit of time to get them to
work initially, but it's not a throwback to mythical pre-conversion days.
In fact, I've never used Windows for music-making. I tried a little when
I was first starting out and didn't get far or get anything remotely
serious done, but very quickly moved to Linux, first DeMuDi and then
Ubuntu Studio. There are a number of things that attract me to Linux,
but most of them are probably pragmatic reasons rather than ideological
(although there are some of those).
If I wanted to use proprietary, closed-source
software, why would I
even try to get it running on Linux at all?
For me, it's all about running what I find to be the best (instrumental)
tools for the job, using the best (OS and software) tools for the job.
It's all about choice.
I hope Linux generally, and the Linux audio world specifically, never
becomes closed off, only open to those who want it to be totally free
and who want vigorously to maintain the purity of that essence :-)
Q
17 Jan
17 Jan
12:02 a.m.
I think there is (and should be) room for both commercial and open source
projects to coexist for linux, that way there is always the freedom to make
the choice about what to use depending upon requirements, ideology,
financial constraints etc.
As a commercial developer, linuxDSP has had to go down that particular
(commercial) road because we have significant costs associated with
maintaining the infrastructure required to produce, distribute and develop
the software, however, we started making audio software for linux, first and
foremost as enthusiastic linux users - who just wanted to make some great
tools to do what we wanted to do, and to bring them to a wider audience in a
way that enabled us to continue their development.
That said, we realise that although our software and applications
themselves contain no GPL'd code, they are indirectly dependent on many
projects (e.g. DAW applications) which may be open source, and where
possible we support those projects and - revenue permitting - hope to be
able to contribute some financial support back to some of those projects
too.
+1
The best example here, even though it has nothing to do with plugins, is
Flash. I hate flash almost as much as Jobs and Stallman but the sad truth is
that I still have to use the hunk o' junk or suffer a problematic or
inconvenient web video experience. Yes, I know there will be a number of you
who never or rarely watch streamed videos just as there are those who never
or rarely use FX or softsynths but there are people like me who want all of
these and want them working as well as possible under Linux *now* and are
prepared to put up with non-free until the day arrives when a comparable
FOSS solution exists. Hence, I fully support LinuxDSP's efforts, will likely
be purchasing their plugins soon (long story still in progress..) and would
do the same if someone released a real good LV2 softsynth if it was
reasonably priced. Unfortunately I can't afford and don't have the room for
lots of good hardware synths and as for Flash I think Linux's popularity
would've suffered significantly if Adobe didn't support Linux (for Flash at
least- I suspect Apple+MS pay Adobe not to port CS to Linux as too many
would switch if they did a good job of that ;)
11:32 p.m.
On Sat, Jan 15, 2011 at 09:23:04PM -0800, Ken Restivo wrote:
I can't stand the whole idea of closed-source VSTs and plugins and synths.
Yeah, I'm one of THOSE guys.
Seriously, I'm using linux becuase of the freedom, the open source, and the political
aspect of it. That's why I run it. I wouldn't bother with it otherwise.
If I wanted to use proprietary, closed-source software, why would I even try to get it
running on Linux at all?
Taking this a bit father: if convenience, "user experience", time,
availability, commercial support, etc were REALLY important, why wouldn't I just get a
MacBook Pro like everyone else has, and run that?
While not half as militant, I basically agree with these assertions.
Maybe on a short-term basis, a proprietary OS or DAW is easier to get
started with, but in the long run, the serious user will likely invest a
surprising number of man-hours in getting their environment to perform
as they wish and familiarising with their toolchain. As has been pointed
out in previous threads, most successful "electronic" musicians (however
one defines the term) have invested much time and money to come up with
an original sounding rig. I personally know some more traditional
musicians/composers who have literally spent a year just to get their
Mac to work "just so" with their DAW and synth of choice.
Where open-source makes sense to me is that, if I am going to invest
time and money in creating a working rig, I would rather not rely on an
OS or application over which I have little control, and which might be
bought out, discontinued, or altered significantly at the whim of a
large corporation. I won't even go into the matter of accessibility and
how little corporations care about it, leaving customers more or less to
fend for themselves and take pot shots at workability.
Anyway, just my $0.02's worth of blab.
Cheers,
S.M.
-ken
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
14 Jan
14 Jan
1:20 p.m.
allcoms wrote:
Hi list,
Hi,
http://linux-sound.org/plugins.html
AFAICT, none of those plugins are responsible for failures of
imagination. :)
Best,
dp
7:47 p.m.
On 01/14/2011 11:08 AM, allcoms wrote:
Hi list,
I suppose I could've just addressed this to drobilla and got most of
my questions answered but it concerns us all really as even if A3 and
qtractor were to achieve feature parity with Cubase and buds tomorrow
(obviously I'm stretching things a bit there) we still wouldn't see
vast droves switching to Linux DAWs for a few reasons such as hardware
support, people liking what they know etc. but most importantly the
dearth of quality native plugins available for Linux seems to be a
primary showstopper for most.
DSSI has a few things coded for it but not much and its still very
early days for LV2 so the open plugin format of the future is still
anyones game and it may not necessarily be either of those that
succeeds and gets widely used of course. I think a couple of VSTs have
been ported over to LV2 but I'm not aware of any that have been ported
to DSSI and I think that the ease in doing so is quite an important
factor in the success of any such format, if not the be-all and
end-all. If anyone here has any experience with coding and/or porting
VSTis - what is currently lacking from LV2 or DSSI that could
potentially cause problems for someone wanting to port their big beefy
synth or snazzy FX from VSTi to LV2 or DSSI? I already know about the
incomplete persist LV2 extension but I'm pretty sure that won't be the
only thing needing work.
A very important factor for such a format would definitely be that the
major hosts (commercial, foss or otherwise) for all major platforms
would be able to easily implement support for it and that plugins
would be easy to port between the different platforms. I'm not aware
of any DAWs for Windows that support LV2 or DSSI yet but I could be
wrong? There's nothing stopping a closed source, commecial app vendor
adding support for either format is there? Another factor I see as
increasingly important is that the plugin format should be able to
take advantage of OpenCL to take advantage of the superior processing
power of todays GPUs. Quite how we'd convince Steinberg and co. we
need a replacement for VSTi and get them to support an open standard
though is anyones guess :/
This message comes at a time when I started to think, 'hey it seems that
the LV2 plugin format is getting forward'. The Calf and Linuxdsp plugins
show what is possible and also the concept of Composite looks promising
and now the release of the IR LV2 plugin.
Maybe this development is due to the fact that 'Drobilla' has cleaned up
the documentation for LV2? Maybe Tom can tell...
Nevertheless, minor point is that Renoise and Pianoteq for example,
didn't choose the LV2 plugin for their software yet... This should make
'us' think about what is missing in the LV2 format at the moment. How
can it made easier for developers (also on Windows and Mac probably) to
adapt LV2?
However, if the LAD community is able to show that you can make nice
plugins with LV2, other (commercial) developers will follow more easy
probably. I don't expect 'commercial' developers to pioneer with LV2.
Regards,
\r
8:15 p.m.
rosea.grammostola wrote:
On 01/14/2011 11:08 AM, allcoms wrote:
I think one of the reasons that (other) commercial developers might tend
to go for VST support on linux versions of their plugins might be that
it just kind of 'falls out' of developing using cross platform kits like
'JUCE'. IIRC last time I looked at coding with juce, it seemed that
building a version of a VST for linux was almost just a matter of
pressing another button on the compiler so to speak. So it's very
little extra effort for a developer who is mainly focused on other
platforms to add linux VST support. However adding support for another
plugin standard such as LV2 may require significant extra effort (for
example, for the linuxDSP plugins we coded up an entire UI 'engine' that
can be used for VST, LV2, JACK etc, since there were restrictions on
using other toolkits in commercial products and there were various
technical issues with using things like GTK in Qt hosts etc)
LV2 is much improved from its original incarnation, and the existing
documentation is perfectly adequate in my opinion - it requires a bit of
simple 'programming knowledge' to understand it, but realistically, if
you don't have that you won't get very far with developing any kind of
plugin anyway - and of course there are plenty of 'examples' out there.
The most significant step has been adding support for external UIs
which enables us to provide a consistent GUI look and feel regardless of
the UI toolkit that the host uses.
Hi list,
I suppose I could've just addressed this to drobilla and got most of
my questions answered but it concerns us all really as even if A3 and
qtractor were to achieve feature parity with Cubase and buds tomorrow
(obviously I'm stretching things a bit there) we still wouldn't see
vast droves switching to Linux DAWs for a few reasons such as hardware
support, people liking what they know etc. but most importantly the
dearth of quality native plugins available for Linux seems to be a
primary showstopper for most.
DSSI has a few things coded for it but not much and its still very
early days for LV2 so the open plugin format of the future is still
anyones game and it may not necessarily be either of those that
succeeds and gets widely used of course. I think a couple of VSTs have
been ported over to LV2 but I'm not aware of any that have been ported
to DSSI and I think that the ease in doing so is quite an important
factor in the success of any such format, if not the be-all and
end-all. If anyone here has any experience with coding and/or porting
VSTis - what is currently lacking from LV2 or DSSI that could
potentially cause problems for someone wanting to port their big beefy
synth or snazzy FX from VSTi to LV2 or DSSI? I already know about the
incomplete persist LV2 extension but I'm pretty sure that won't be the
only thing needing work.
A very important factor for such a format would definitely be that the
major hosts (commercial, foss or otherwise) for all major platforms
would be able to easily implement support for it and that plugins
would be easy to port between the different platforms. I'm not aware
of any DAWs for Windows that support LV2 or DSSI yet but I could be
wrong? There's nothing stopping a closed source, commecial app vendor
adding support for either format is there? Another factor I see as
increasingly important is that the plugin format should be able to
take advantage of OpenCL to take advantage of the superior processing
power of todays GPUs. Quite how we'd convince Steinberg and co. we
need a replacement for VSTi and get them to support an open standard
though is anyones guess :/
This message comes at a time when I started to think, 'hey it seems that
the LV2 plugin format is getting forward'. The Calf and Linuxdsp plugins
show what is possible and also the concept of Composite looks promising
and now the release of the IR LV2 plugin.
Maybe this development is due to the fact that 'Drobilla' has cleaned up
the documentation for LV2? Maybe Tom can tell...
Nevertheless, minor point is that Renoise and Pianoteq for example,
didn't choose the LV2 plugin for their software yet... This should make
'us' think about what is missing in the LV2 format at the moment. How
can it made easier for developers (also on Windows and Mac probably) to
adapt LV2?
However, if the LAD community is able to show that you can make nice
plugins with LV2, other (commercial) developers will follow more easy
probably. I don't expect 'commercial' developers to pioneer with LV2.
Regards,
\r
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
8:33 p.m.
On 01/14/2011 09:37 PM, linuxdsp wrote:
. However adding support for another plugin standard
such as LV2 may
require significant extra effort (for example, for the linuxDSP
plugins we coded up an entire UI 'engine' that can be used for VST,
LV2, JACK etc, since there were restrictions on using other toolkits
in commercial products and there were various technical issues with
using things like GTK in Qt hosts etc)
Thanks for responding.
Hmm maybe this UI 'engine' is useful for other developers? I know you
release your software as closed-source products at the moment, but as a
non-developer it sounds like there is no DSP stuff or whatsoever in the
UI 'engine'.
Could be that I think to simple here though ;)
LV2 is much improved from its original incarnation, and the existing
documentation is perfectly adequate in my opinion - it requires a bit
of simple 'programming knowledge' to understand it, but realistically,
if you don't have that you won't get very far with developing any kind
of plugin anyway - and of course there are plenty of 'examples' out
there. The most significant step has been adding support for external
UIs which enables us to provide a consistent GUI look and feel
regardless of the UI toolkit that the host uses.
Good to know, thanks for sharing. It might give other developers more
confidence to start coding LV2 without the fear to start a 'mission
impossible' and get trapped in 'spaghetti' at the end.
Regards,
\r
8:44 p.m.
On 14 January 2011 21:33, rosea.grammostola <rosea.grammostola(a)gmail.com> wrote:
Good to know, thanks for sharing. It might give other developers more
confidence to start coding LV2 without the fear to start a 'mission
impossible' and get trapped in 'spaghetti' at the end.
There is nothing wrong with the LV2 docs. I don't consider myself a
professional programmer (I'm an EE really, just need to write software
at times), but I found it quite easy to wrap my head around it.
What is really missing from LV2 is a standard way for plugins to
persistently save their own instance data. In essence, what is needed
is that the host provide the plugin with an "instance key" of some
kind (guaranteed by the host to uniquely, persistently identify that
particular plugin instance) so the plugin could save/restore whatever
data it needs based on that key.
Tom
8:58 p.m.
On Fri, Jan 14, 2011 at 3:44 PM, Tom Szilagyi <tomszilagyi(a)gmail.com> wrote:
What is really missing from LV2 is a standard way for
plugins to
persistently save their own instance data. In essence, what is needed
is that the host provide the plugin with an "instance key" of some
kind (guaranteed by the host to uniquely, persistently identify that
particular plugin instance) so the plugin could save/restore whatever
data it needs based on that key.
this does exist. unfortunately, there are two variants on the idea:
this is one of them (and the one that ardour supports best at
present): http://lv2plug.in/ns/doc/html/persist_8h.html
10:06 p.m.
On Fri, Jan 14, 2011 at 3:44 PM, Tom Szilagyi <tomszilagyi(a)gmail.com> wrote:
On 14 January 2011 21:33, rosea.grammostola
<rosea.grammostola(a)gmail.com>
wrote:
Hmm... I have to say that I noticed that the LV2 documentation has improved
alot recently, but when I first started programming LV2, I found it very
much confusing. A lot of confusion stemmed from the fact that the
connection between the "LV2 Specification" document, and what you actually
had to do to make a plugin wasn't clear. Now the website is better at
directing you to "This is how you start" sort of documents, rather than
"lv2:portspecification a lv2:urlProperty" sort of stuff. Because when I
looked at those documents, I had no idea *what* they were talking about, or
how to use any of the information they presented. I wanted to shout out *show
me the code! *And the only link to the *actual C header* was a small and
seemingly insignificant link, saying "you might also want to look at this".
Anyway, this rant is kind of useless, because the website is much improved,
at least from my perspective, although it may just be that now I understand
what it's talking about after learning through examples.
Jeremy
Good to know, thanks for sharing. It might give other developers more
confidence to start coding LV2 without the fear to start a 'mission
impossible' and get trapped in 'spaghetti' at the end.
There is nothing wrong with the LV2 docs. I don't consider myself a
professional programmer (I'm an EE really, just need to write software
at times), but I found it quite easy to wrap my head around it.
15 Jan
15 Jan
12:29 a.m.
On Fri, Jan 14, 2011 at 8:44 PM, Tom Szilagyi <tomszilagyi(a)gmail.com> wrote:
There is nothing wrong with the LV2 docs. I don't
consider myself a
professional programmer (I'm an EE really, just need to write software
at times), but I found it quite easy to wrap my head around it.
I'll chirp in here: I've only recently dabbled with plugin formats, and
while it really took
some time for me to understand LADSPA's, looking at SLV2 (a LV2 hosting
library)
and the lv2_simple_jack_host.c example file, it explains the proceedure of
finding,
loading & running a plugin exremely well!
+1 for good docs, they're essential to get a well established plugin format,
and LV2 has them.
-Harry
4:11 a.m.
I'm coming late to the conversation here but I wanted to bring this point up
a while back, probably the last time this conversation took place.
When I was first getting started with computer based music and sound
production I used windows, and from recollection, one of the early events
that led to an explosion of interest in and creation for the VST standard
was the graphical tool Synthedit. It enabled non-programmers, but people
willing to experiment with dsp development, or even people with dsp
knowledge but wanting a faster tool chain, to develop complex plugins, and
also share libraries developed for synthedit to allow a mixed community of
amateur and professional developers to emerge.
I may be overstating its significance in the rise of windows audio
production. Nor am I saying that everything created with such a tool was of
a high standard - it clearly wasn't. I do think though that such a tool may
spur development in linux based plugins.
The curious thing is that such a tool exists, at least in early stages, but
no one here ever talks about it much, which I think is a shame. I'm talking
about CLAM network manager, which is a QT based graphical tool for many
things. It is similar in some ways to other graphical patching environments
like PD. ingen or even AMS (another vastly underrated tool IMO). One feature
that makes it pertinent to this discussion is that it has been able to be
used to build ladspa plugins for some time now, and I believe the coming
release allows building LV2 plugins with QT UI. I've used it to build a
rudimentary ladspa plugin and it just worked.
Certainly I think if more plugins are desired, it wouldn't hurt to either
try using CLAM, or get involved in its development to make it a tool that
could spur linux audio development in general.
-michael
9:12 a.m.
michael noble wrote:
I'm coming late to the conversation here but I
wanted to bring this
point up a while back, probably the last time this conversation took place.
When I was first getting started with computer based music and sound
production I used windows, and from recollection, one of the early
events that led to an explosion of interest in and creation for the VST
standard was the graphical tool Synthedit. It enabled non-programmers,
but people willing to experiment with dsp development, or even people
with dsp knowledge but wanting a faster tool chain, to develop complex
plugins, and also share libraries developed for synthedit to allow a
mixed community of amateur and professional developers to emerge.
Rapid application development tools such as synthedit are good and bad
in equal measure in my opinion. Having used synthedit as a means of
prototyping ideas for windows VSTs I can say it IS very useful, but the
problems with such tools can be:
1) The building block approach is good for prototyping, and easy to use
even for people with no dsp knowledge, however...
2) Blindly using the 'black box' approach to constructing complex DSP
processing can have its pitfalls if you don't have a grasp of (at least
the theory) of what is going on inside the boxes - for example in
synthedit you might wire up a bunch of filters (say to make a multiband
compressor) without a clue about the correct way to manage the phase
alignment of the filters with the result that your great new plugin
actually has huge deep notches in the frequency response when it should
sum back to flat (Note: this is also a problem with just re-using
plugins and libraries in other ways - my recent tests using JAMIN
suggest exactly this problem happens when using the IIR multiband)
3) Synthedit's ability to just churn out a finished .dll meant that
everyone could start making plugins without any programming knowledge
and superficially, out of the resulting thousands of free plugins, you
wouldn't know the good from the bad (although if you look in your
vst_plugins folder after / while using a synthedit plugin you will
normally find the tell-tale signs of it dumping its little .dat files
and modules out all over the place)
All of this is not to say that the tools should not be available to do
such things, but perhaps people need to be aware of the potential
problems, and to appreciate that although such tools make DSP seem easy,
it most definitely is NOT and requires a great amount of knowledge and
experience to do (and understand) properly (and even then its easy to
get caught out!)
I may be overstating its significance in the rise of
windows audio
production. Nor am I saying that everything created with such a tool was
of a high standard - it clearly wasn't. I do think though that such a
tool may spur development in linux based plugins.
The curious thing is that such a tool exists, at least in early stages,
but no one here ever talks about it much, which I think is a shame. I'm
talking about CLAM network manager, which is a QT based graphical tool
for many things. It is similar in some ways to other graphical patching
environments like PD. ingen or even AMS (another vastly underrated tool
IMO). One feature that makes it pertinent to this discussion is that it
has been able to be used to build ladspa plugins for some time now, and
I believe the coming release allows building LV2 plugins with QT UI.
I've used it to build a rudimentary ladspa plugin and it just worked.
Certainly I think if more plugins are desired, it wouldn't hurt to
either try using CLAM, or get involved in its development to make it a
tool that could spur linux audio development in general.
-michael
------------------------------------------------------------------------
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2:03 p.m.
On Sat, Jan 15, 2011 at 6:35 PM, linuxdsp <mike(a)linuxdsp.co.uk> wrote:
2) Blindly using the 'black box' approach to constructing complex DSP
processing can have its pitfalls if you don't have a grasp of (at least the
theory) of what is going on inside the boxes - for example in synthedit you
might wire up a bunch of filters (say to make a multiband compressor)
without a clue about the correct way to manage the phase alignment of the
filters with the result that your great new plugin actually has huge deep
notches in the frequency response when it should sum back to flat (Note:
this is also a problem with just re-using plugins and libraries in other
ways - my recent tests using JAMIN suggest exactly this problem happens when
using the IIR multiband)
Well, saying there are pitfalls to blind black box dsp development begs the
question - where does one gain the basic knowledge as to eliminate some of
this blindness? I'd hazard a guess and say that there are quite a few people
here who are to some extent autodidacts, and who often learn from
experience. A well documented and precise example developed in a graphical
development environment would go much farther than a DSP textbook in this
case. I have a great deal of respect for the training and skill of a good
DSP programmer, but in reality, there are not that many of them, and most of
them are busy trying to eek out a living to pay for the knowledge that was
so hard gained. For the rest of us, we either have to wait for the gurus to
release stuff, or learn by experimenting. A GUI toolkit lowers the barrier
to entry significantly. Or to put it another way, given a choice between
having to learn DSP theory plus C/C++ or DSP theory through documented
visual examples in the same toolkit that will produce plugins, I'd choose
the latter given my time constraints, and given the fact that I find it much
easier to "read" the logic of visual patching than I do text based code.
3) Synthedit's ability to just churn out a
finished .dll meant that
everyone could start making plugins without any programming knowledge and
superficially, out of the resulting thousands of free plugins, you wouldn't
know the good from the bad (although if you look in your vst_plugins folder
after / while using a synthedit plugin you will normally find the tell-tale
signs of it dumping its little .dat files and modules out all over the
place)
Fully acknowledged, and many of them were/are CPU hogs to boot.
All of this is not to say that the tools should not be
available to do such
things, but perhaps people need to be aware of the potential problems, and
to appreciate that although such tools make DSP seem easy, it most
definitely is NOT and requires a great amount of knowledge and experience to
do (and understand) properly (and even then its easy to get caught out!)
I don't think there needs to be such a hard divide between users and
developers (though of course I've got nothing to lose and no frustration to
gain from cowboys riding into this particular town, mostly because it's not
my town). Even among amateurs, there will always be good amateurs and not so
good amateurs. The value of community is that people share not just the
plugins but their opinions about them. Among the synthedit users/developers,
certain of them gained a reputation based on the quality of their output.
And that quality was no doubt dependent on DSP skills and knowledge. Again,
I personally fully appreciate that DSP is not easy. But I do believe it can
be more fun and more accessible. For most people, it seems having fun is
more important than being exact, and may actually help them learn to be more
exact in the process.
All that being said, I have to admit to a certain degree of devil's
advocacy. I actually agree with Dave that even given the current set of
existing linux audio tools, one is only limited by one's imagination. The
tools that are out there now are more than technically capable of spurring
my imagination. The question is open as to how enjoyable that spurring might
be in the implementation.
-michael
16 Jan
16 Jan
9:30 p.m.
On Sat, Jan 15, 2011 at 09:35:05AM +0000, linuxdsp wrote:
... with the result that your
great new plugin actually has huge deep notches in the frequency
response when it should sum back to flat (Note: this is also a
problem with just re-using plugins and libraries in other ways - my
recent tests using JAMIN suggest exactly this problem happens when
using the IIR multiband)
True. After all those years none of the 'DSP experts' developing Jamin
has noticed anything wrong when listening to it (it's quite obvious
actually), let alone done a simple measurement that could have revealed
this problem even before the first release. I reported it to one of the
devs some months ago, but even that didn't help - the development version
I got for review some weeks later still had the same defect.
Ciao,
--
FA
There are three of them, and Alleline.
17 Jan
17 Jan
12:10 a.m.
On Sun, Jan 16, 2011 at 9:30 PM, <fons(a)kokkinizita.net> wrote:
On Sat, Jan 15, 2011 at 09:35:05AM +0000, linuxdsp
wrote:
OK Fons,
You can't carry on slagging off Jamin like this. Yes, you are renowned as
being the most knowledgeable person on the list when it comes to DSP but
constantly berating the poor Jamin guys isn't doing anyone any favours.
Please, either fork and fix Jamin, write a kick-ass alternative that works
how you think Jamin should work or just ignore its shortcomings and leave
the poor devs alone! (I'm def. rooting for the second of these options btw)
... with the result that your
great new plugin actually has huge deep notches in the frequency
response when it should sum back to flat (Note: this is also a
problem with just re-using plugins and libraries in other ways - my
recent tests using JAMIN suggest exactly this problem happens when
using the IIR multiband)
True. After all those years none of the 'DSP experts' developing Jamin
has noticed anything wrong when listening to it (it's quite obvious
actually), let alone done a simple measurement that could have revealed
this problem even before the first release. I reported it to one of the
devs some months ago, but even that didn't help - the development version
I got for review some weeks later still had the same defect.
Ciao,
12:52 a.m.
On Mon, Jan 17, 2011 at 12:10:20AM +0000, allcoms wrote:
You can't carry on slagging off Jamin like this.
Yes, you are renowned as
being the most knowledgeable person on the list when it comes to DSP but
constantly berating the poor Jamin guys isn't doing anyone any favours.
I'm not 'slagging off' anyone. All it takes to correct this bug is to
change one '+' into a '-'. Something like changing
out = low + mid + high;
into
out = low - mid + high;
This is an error that any DSP student is allowed to make once, during
his first exercise on xover filters. It's not one that should remain
undetected for six years or so. Not if you test your code, or just
listen to its output. Not if you claim to be 'experts' as the only
response to legitimate criticism.
Please, either fork and fix Jamin, write a kick-ass
alternative that works
how you think Jamin should work or just ignore its shortcomings and leave
the poor devs alone! (I'm def. rooting for the second of these options btw)
I'm not really motivated to provide an alternative for the simple
reason that I don't really like music recordings to be processed
the way Jamin or most mastering tools do it.
OTOH I had the same opinion on voice auto-retuning, but that didn't
stop me writing the only usable open source retuner. The difference
is that zita-at1 was an interesting exercise, while providing an
alternative to Jamin isn't.
Ciao,
--
FA
There are three of them, and Alleline.
8:10 a.m.
On Mon, Jan 17, 2011 at 01:52:07AM +0100, fons(a)kokkinizita.net wrote:
On Mon, Jan 17, 2011 at 12:10:20AM +0000, allcoms
wrote:
IIRC, Julien and some other folks were involved in writing an alternative to Jamin, called
NAMA, and it runs using ecasound and Perl. ISTR also that Fons offered them some advice on
how to do the xover filter correctly, and they accepted it and made use of it.
I'm looking forward to trying it out for the next Better Than Lahar album. The
mastering was the weak link in the first album, and I don't wish to repeat the same
mistake.
As for patching JAMIN, the offending code appears to be in process.c, around line #452 or
so, in the process_signal() jack callback function. But I don't understand what that
code is doing well enough to actually produce a patch, and I'm not going to use JAMIN
anymore anyway.
-ken
You can't carry on slagging off Jamin like
this. Yes, you are renowned as
being the most knowledgeable person on the list when it comes to DSP but
constantly berating the poor Jamin guys isn't doing anyone any favours.
I'm not 'slagging off' anyone. All it takes to correct this bug is to
change one '+' into a '-'. Something like changing
out = low + mid + high;
into
out = low - mid + high;
This is an error that any DSP student is allowed to make once, during
his first exercise on xover filters. It's not one that should remain
undetected for six years or so. Not if you test your code, or just
listen to its output. Not if you claim to be 'experts' as the only
response to legitimate criticism.
Please, either fork and fix Jamin, write a
kick-ass alternative that works
how you think Jamin should work or just ignore its shortcomings and leave
the poor devs alone! (I'm def. rooting for the second of these options btw)
I'm not really motivated to provide an alternative for the simple
reason that I don't really like music recordings to be processed
the way Jamin or most mastering tools do it.
OTOH I had the same opinion on voice auto-retuning, but that didn't
stop me writing the only usable open source retuner. The difference
is that zita-at1 was an interesting exercise, while providing an
alternative to Jamin isn't.
11:25 a.m.
On 01/17/2011 09:09 AM, Ken Restivo wrote:
On Mon, Jan 17, 2011 at 01:52:07AM +0100,
fons(a)kokkinizita.net wrote:
What will you use instead?
\r
On Mon, Jan 17, 2011 at 12:10:20AM +0000, allcoms
wrote:
IIRC, Julien and some other folks were involved in writing an alternative to
Jamin, called NAMA, and it runs using ecasound and Perl. ISTR also that Fons offered them
some advice on how to do the xover filter correctly, and they accepted it and made use of
it.
I'm looking forward to trying it out for the next Better Than Lahar album. The
mastering was the weak link in the first album, and I don't wish to repeat the same
mistake.
As for patching JAMIN, the offending code appears to be in process.c, around line #452 or
so, in the process_signal() jack callback function. But I don't understand what that
code is doing well enough to actually produce a patch, and I'm not going to use JAMIN
anymore anyway.
You can't carry on slagging off Jamin like
this. Yes, you are renowned as
being the most knowledgeable person on the list when it comes to DSP but
constantly berating the poor Jamin guys isn't doing anyone any favours.
I'm not 'slagging off' anyone. All it takes to correct this
bug is to
change one '+' into a '-'. Something like changing
out = low + mid + high;
into
out = low - mid + high;
This is an error that any DSP student is allowed to make once, during
his first exercise on xover filters. It's not one that should remain
undetected for six years or so. Not if you test your code, or just
listen to its output. Not if you claim to be 'experts' as the only
response to legitimate criticism.
Please, either fork and fix Jamin, write a
kick-ass alternative that works
how you think Jamin should work or just ignore its shortcomings and leave
the poor devs alone! (I'm def. rooting for the second of these options btw)
I'm not really motivated to provide an alternative for the simple
reason that I don't really like music recordings to be processed
the way Jamin or most mastering tools do it.
OTOH I had the same opinion on voice auto-retuning, but that didn't
stop me writing the only usable open source retuner. The difference
is that zita-at1 was an interesting exercise, while providing an
alternative to Jamin isn't.
11:40 a.m.
On 01/17/2011 12:25 PM, rosea.grammostola wrote:
He mentions NAMA. You could also try setting up a mastering chain with
the help of plugins in your DAW. Only thing that lacks then is a
spectrum analyser, or is there a plug-in that can do this?
Best,
Jeremy
IIRC, Julien
and some other folks were involved in writing an
alternative to Jamin, called NAMA, and it runs using ecasound and
Perl. ISTR also that Fons offered them some advice on how to do the
xover filter correctly, and they accepted it and made use of it.
I'm looking forward to trying it out for the next Better Than Lahar
album. The mastering was the weak link in the first album, and I don't
wish to repeat the same mistake.
As for patching JAMIN, the offending code appears to be in process.c,
around line #452 or so, in the process_signal() jack callback
function. But I don't understand what that code is doing well enough
to actually produce a patch, and I'm not going to use JAMIN anymore
anyway.
What will you use instead?
2:38 p.m.
On 01/17/2011 12:40 PM, Jeremy Jongepier wrote:
On 01/17/2011 12:25 PM, rosea.grammostola wrote:
He mentions NAMA. You could also try setting up a mastering chain with
the help of plugins in your DAW. Only thing that lacks then is a
spectrum analyser, or is there a plug-in that can do this?
jamin's spectrum analyser is ok'ish. there's also japa, which i
personally prefer.
don't forget the most important aspect of mastering: a second pair of
ears, in a very good listening room.
take that out of the equation, and all that's left of mastering is some
parametric eq and (if you must) multiband compression. lv2fil and the
new calf multiband compressor might suit your needs. the latter
especially is way more powerful than jamin, but watch it closely - i
wouldn't want to vouch for it to do the right thing in all settings, and
some controllers i plainly don't understand.
IIRC,
Julien and some other folks were involved in writing an
alternative to Jamin, called NAMA, and it runs using ecasound and
Perl. ISTR also that Fons offered them some advice on how to do the
xover filter correctly, and they accepted it and made use of it.
I'm looking forward to trying it out for the next Better Than Lahar
album. The mastering was the weak link in the first album, and I don't
wish to repeat the same mistake.
As for patching JAMIN, the offending code appears to be in process.c,
around line #452 or so, in the process_signal() jack callback
function. But I don't understand what that code is doing well enough
to actually produce a patch, and I'm not going to use JAMIN anymore
anyway.
What will you use instead?
9:31 p.m.
On Mon, Jan 17, 2011 at 03:38:48PM +0100, Jörn Nettingsmeier wrote:
don't forget the most important aspect of
mastering: a second pair
of ears, in a very good listening room.
Correct.
take that out of the equation, and all that's left
of mastering is
some parametric eq and (if you must) multiband compression.
And I wonder why these shouldn't be done when mixing instead.
In the 'old days' EQ and compression was required to adapt a
mix to the limits of the distribution medium (vinyl in most
cases). No such problem exists today. Why on earth should you
re-EQ a mix ? If the mixing engineer did a good job (by carefully
EQ-ing individual tracks), what chance do you have to improve this
by acting on the mixed signal ? If he didn't, the way to correct
for this is to redo the mix. Same for compression, it's much more
effective and less intrusive when done on single tracks.
Ciao,
--
FA
There are three of them, and Alleline.
10:11 p.m.
On Mon, Jan 17, 2011 at 10:31:41PM +0100, fons(a)kokkinizita.net wrote:
On Mon, Jan 17, 2011 at 03:38:48PM +0100, J?rn
Nettingsmeier wrote:
For the record, I hate mastering and compressed loudness-war mixes. I enjoy making use of
the dynamic range of 16-bit (or more) audio. And, I also put the mastering (multiband
compression, really) stuff in the chain while mixing, one of the wonderful things about
JACK. It's just an insert on the master bus in Ardour for me, and my exported mixes
are mastered.
However, today's popular music must contend with limitations of the listener's
equipment, just as it did in the days of turntables and
six-peices-of-particle-board-and-an-8-inch-speaker turntable/stereo combinations. The
limitations are different and so therefore are the solutions and workarounds.
Today, people listen to music on iPods and truly wretched laptop speakers in noisy
environments. And everything else they listen to is compressed out the wazoo. So when my
lightly-compressed mixes come up on shuffle, they are inaudible, not just in comparison to
other professionally-mastered mixes, but against the background noise they're
competing with.
So, next time around, I'm putting my mixes thorugh NAMA and squashing the holy hell
out of them, until they sound like whatever the major labels are pooting out these days.
-ken
don't forget the most important aspect of
mastering: a second pair
of ears, in a very good listening room.
Correct.
take that out of the equation, and all that's
left of mastering is
some parametric eq and (if you must) multiband compression.
And I wonder why these shouldn't be done when mixing instead.
In the 'old days' EQ and compression was required to adapt a
mix to the limits of the distribution medium (vinyl in most
cases). No such problem exists today. Why on earth should you
re-EQ a mix ? If the mixing engineer did a good job (by carefully
EQ-ing individual tracks), what chance do you have to improve this
by acting on the mixed signal ? If he didn't, the way to correct
for this is to redo the mix. Same for compression, it's much more
effective and less intrusive when done on single tracks.
10:20 p.m.
On Mon, 2011-01-17 at 14:11 -0800, Ken Restivo wrote:
On Mon, Jan 17, 2011 at 10:31:41PM +0100,
fons(a)kokkinizita.net wrote:
Unfortunately most mix engineers suck. That's why you need a real
mastering engineer to fix your mixes. Taking the tracks back to a guy
with tin ears isn't going to help.
Most people making records today are inexperienced and doing it at
home.
Having said that, when a world class mix engineer does a mix, the
mastering engineer doesn't have to do much, as someone pointed out. But
unless someone like Dave Reitzas or Ed Cherney is mixing your tracks,
take it to a qualified mastering house. Even those guys take their
mixes to guys like Bob Ludwig. Running your mix through a Farichild 670
isn't going to hurt it. :-)
Ricardus...
On Mon, Jan 17, 2011 at 03:38:48PM +0100, J?rn
Nettingsmeier wrote:
For the record, I hate mastering and compressed loudness-war mixes. I
enjoy making use of the dynamic range of 16-bit (or more) audio. And,
I also put the mastering (multiband compression, really) stuff in the
chain while mixing, one of the wonderful things about JACK. It's just
an insert on the master bus in Ardour for me, and my exported mixes
are mastered.
However, today's popular music must contend with limitations of the
listener's equipment, just as it did in the days of turntables and
six-peices-of-particle-board-and-an-8-inch-speaker turntable/stereo
combinations. The limitations are different and so therefore are the
solutions and workarounds.
Today, people listen to music on iPods and truly wretched laptop
speakers in noisy environments. And everything else they listen to is
compressed out the wazoo. So when my lightly-compressed mixes come up
on shuffle, they are inaudible, not just in comparison to other
professionally-mastered mixes, but against the background noise
they're competing with.
So, next time around, I'm putting my mixes thorugh NAMA and squashing
the holy hell out of them, until they sound like whatever the major
labels are pooting out these days. don't forget the most important aspect of
mastering: a second pair
of ears, in a very good listening room.
Correct.
take that out of the equation, and all that's
left of mastering is
some parametric eq and (if you must) multiband compression.
And I wonder why these shouldn't be done when mixing instead.
In the 'old days' EQ and compression was required to adapt a
mix to the limits of the distribution medium (vinyl in most
cases). No such problem exists today. Why on earth should you
re-EQ a mix ? If the mixing engineer did a good job (by carefully
EQ-ing individual tracks), what chance do you have to improve this
by acting on the mixed signal ? If he didn't, the way to correct
for this is to redo the mix. Same for compression, it's much more
effective and less intrusive when done on single tracks.
10:50 p.m.
On Mon, Jan 17, 2011 at 05:20:15PM -0500, Ricardus Vincente wrote:
On Mon, 2011-01-17 at 14:11 -0800, Ken Restivo wrote:
Yep. I guess that's what mastering engineers spend most of their time doing: fixing
bad mixes.
Not that I'm any great expert mix engineer myself, but, when in doubt, I run mixes by
people who have better ears than me to get their feedback. Once in a while I deliberately
choose to do things "wrong" because I like the way it sounds, but most feedback
is very valuable.
On Mon, Jan 17, 2011 at 10:31:41PM +0100,
fons(a)kokkinizita.net wrote:
Unfortunately most mix engineers suck. That's why you need a real
mastering engineer to fix your mixes. Taking the tracks back to a guy
with tin ears isn't going to help.
Most people making records today are inexperienced and doing it at
home. On Mon, Jan 17, 2011 at 03:38:48PM +0100, J?rn
Nettingsmeier wrote:
For the record, I hate mastering and compressed loudness-war mixes. I
enjoy making use of the dynamic range of 16-bit (or more) audio. And,
I also put the mastering (multiband compression, really) stuff in the
chain while mixing, one of the wonderful things about JACK. It's just
an insert on the master bus in Ardour for me, and my exported mixes
are mastered.
However, today's popular music must contend with limitations of the
listener's equipment, just as it did in the days of turntables and
six-peices-of-particle-board-and-an-8-inch-speaker turntable/stereo
combinations. The limitations are different and so therefore are the
solutions and workarounds.
Today, people listen to music on iPods and truly wretched laptop
speakers in noisy environments. And everything else they listen to is
compressed out the wazoo. So when my lightly-compressed mixes come up
on shuffle, they are inaudible, not just in comparison to other
professionally-mastered mixes, but against the background noise
they're competing with.
So, next time around, I'm putting my mixes thorugh NAMA and squashing
the holy hell out of them, until they sound like whatever the major
labels are pooting out these days. don't forget the most important aspect of
mastering: a second pair
of ears, in a very good listening room.
Correct.
take that out of the equation, and all that's
left of mastering is
some parametric eq and (if you must) multiband compression.
And I wonder why these shouldn't be done when mixing instead.
In the 'old days' EQ and compression was required to adapt a
mix to the limits of the distribution medium (vinyl in most
cases). No such problem exists today. Why on earth should you
re-EQ a mix ? If the mixing engineer did a good job (by carefully
EQ-ing individual tracks), what chance do you have to improve this
by acting on the mixed signal ? If he didn't, the way to correct
for this is to redo the mix. Same for compression, it's much more
effective and less intrusive when done on single tracks.
Having said that, when a world class mix engineer does a mix, the
mastering engineer doesn't have to do much, as someone pointed out. But
unless someone like Dave Reitzas or Ed Cherney is mixing your tracks,
take it to a qualified mastering house. Even those guys take their
mixes to guys like Bob Ludwig. Running your mix through a Farichild 670
isn't going to hurt it. :-)
Hmm, this thing?
http://www.proharmonic.com/images/schema/Fairchild670.JPG
I know a guy who runs mixes through an old tube 2-track 30ips tape machine, to use the
tape saturation as a limiter. I guess there are all kinds of tricks people have, and
probably superstition and magick has a good deal to do with it too.
Currently, I just need to make louder mixes, using tools that don't introduce
artifacts into the signal, so I'll try NAMA and I expect it'll go well.
-ken
11:20 p.m.
On Mon, 17 Jan 2011 14:49:20 -0800
Ken Restivo <ken(a)restivo.org> wrote:
On Mon, Jan 17, 2011 at 05:20:15PM -0500, Ricardus
Vincente wrote:
curious: mix engineers suck but mastering engineers don't and they even
know how to mix better than mix engineers.
what's the reason? Maybe that mixing is being done by self taught
people while mastering no?
renato
On Mon, 2011-01-17 at 14:11 -0800, Ken Restivo
wrote:
Yep. I guess that's what mastering engineers spend most of their time
doing: fixing bad mixes.
On Mon, Jan 17, 2011 at 10:31:41PM +0100,
fons(a)kokkinizita.net
wrote:
Unfortunately most mix engineers suck. That's why you need a real
mastering engineer to fix your mixes. Taking the tracks back to a
guy with tin ears isn't going to help.
Most people making records today are inexperienced and doing it at
home. On Mon, Jan 17, 2011 at 03:38:48PM +0100, J?rn
Nettingsmeier
wrote:
> don't forget the most important aspect of mastering: a second
> pair of ears, in a very good listening room.
Correct.
> take that out of the equation, and all that's left of
> mastering is some parametric eq and (if you must) multiband
> compression.
And I wonder why these shouldn't be done when mixing instead.
In the 'old days' EQ and compression was required to adapt a
mix to the limits of the distribution medium (vinyl in most
cases). No such problem exists today. Why on earth should you
re-EQ a mix ? If the mixing engineer did a good job (by
carefully EQ-ing individual tracks), what chance do you have to
improve this by acting on the mixed signal ? If he didn't, the
way to correct for this is to redo the mix. Same for
compression, it's much more effective and less intrusive when
done on single tracks.
For the record, I hate mastering and compressed loudness-war
mixes. I enjoy making use of the dynamic range of 16-bit (or
more) audio. And, I also put the mastering (multiband
compression, really) stuff in the chain while mixing, one of the
wonderful things about JACK. It's just an insert on the master
bus in Ardour for me, and my exported mixes are mastered.
However, today's popular music must contend with limitations of
the listener's equipment, just as it did in the days of
turntables and six-peices-of-particle-board-and-an-8-inch-speaker
turntable/stereo combinations. The limitations are different and
so therefore are the solutions and workarounds.
Today, people listen to music on iPods and truly wretched laptop
speakers in noisy environments. And everything else they listen
to is compressed out the wazoo. So when my lightly-compressed
mixes come up on shuffle, they are inaudible, not just in
comparison to other professionally-mastered mixes, but against
the background noise they're competing with.
So, next time around, I'm putting my mixes thorugh NAMA and
squashing the holy hell out of them, until they sound like
whatever the major labels are pooting out these days.
11:46 p.m.
On Tue, Jan 18, 2011 at 12:26:25AM +0100, Renato wrote:
On Mon, 17 Jan 2011 14:49:20 -0800
Ken Restivo <ken(a)restivo.org> wrote:
That's the point that several people have made, and it seems plausible to me:
The mastering engineers are making their living fixing mixes that home-studio people
produce on Ableton or cracked ProTools LE.
It makes sense to just learn to (or get help to) produce better mixes instead.
-ken
On Mon, Jan 17, 2011 at 05:20:15PM -0500,
Ricardus Vincente wrote:
curious: mix engineers suck but mastering engineers don't and they even
know how to mix better than mix engineers.
what's the reason? Maybe that mixing is being done by self taught
people while mastering no?
On Mon, 2011-01-17 at 14:11 -0800, Ken Restivo
wrote:
Yep. I guess that's what mastering engineers spend most of their time
doing: fixing bad mixes.
On Mon, Jan 17, 2011 at 10:31:41PM +0100,
fons(a)kokkinizita.net
wrote:
> On Mon, Jan 17, 2011 at 03:38:48PM +0100, J?rn Nettingsmeier
> wrote:
>
> > don't forget the most important aspect of mastering: a second
> > pair of ears, in a very good listening room.
>
> Correct.
>
> > take that out of the equation, and all that's left of
> > mastering is some parametric eq and (if you must) multiband
> > compression.
>
> And I wonder why these shouldn't be done when mixing instead.
>
> In the 'old days' EQ and compression was required to adapt a
> mix to the limits of the distribution medium (vinyl in most
> cases). No such problem exists today. Why on earth should you
> re-EQ a mix ? If the mixing engineer did a good job (by
> carefully EQ-ing individual tracks), what chance do you have to
> improve this by acting on the mixed signal ? If he didn't, the
> way to correct for this is to redo the mix. Same for
> compression, it's much more effective and less intrusive when
> done on single tracks.
>
For the record, I hate mastering and compressed loudness-war
mixes. I enjoy making use of the dynamic range of 16-bit (or
more) audio. And, I also put the mastering (multiband
compression, really) stuff in the chain while mixing, one of the
wonderful things about JACK. It's just an insert on the master
bus in Ardour for me, and my exported mixes are mastered.
However, today's popular music must contend with limitations of
the listener's equipment, just as it did in the days of
turntables and six-peices-of-particle-board-and-an-8-inch-speaker
turntable/stereo combinations. The limitations are different and
so therefore are the solutions and workarounds.
Today, people listen to music on iPods and truly wretched laptop
speakers in noisy environments. And everything else they listen
to is compressed out the wazoo. So when my lightly-compressed
mixes come up on shuffle, they are inaudible, not just in
comparison to other professionally-mastered mixes, but against
the background noise they're competing with.
So, next time around, I'm putting my mixes thorugh NAMA and
squashing the holy hell out of them, until they sound like
whatever the major labels are pooting out these days.
Unfortunately most mix engineers suck. That's why you need a real
mastering engineer to fix your mixes. Taking the tracks back to a
guy with tin ears isn't going to help.
Most people making records today are inexperienced and doing it at
home.
18 Jan
18 Jan
1:42 a.m.
On 01/18/2011 12:26 AM, Renato wrote:
curious: mix engineers suck but mastering engineers
don't and they even
know how to mix better than mix engineers.
well, there are many self-taught mixers who might not be that good
(often band members who drew the shortest straw).
you don't become a mastering engineer unless you're really really good.
but also: mixing a session (and editing, for that matter) is terribly
hard. you keep fighting hasty overdubs, pronunciation gaffes,
intonation, timing blunders, sub-optimal arrangements, and misjudgements
during tracking, and toil for days selecting takes and editing. it's
very easy to get carried away, tweak minor flaws endlessly and lose the
big picture in the end.
when mixing, i often find myself retaining too many options until too
late, and then being overwhelmed by all the decisions i have to make.
a mastering engineer does not constantly think "hmm, maybe i should take
an insert from take 42 here", or "maybe i should change the mix balance
again here". the mix is done, only the big picture is left.
the mastering engineer can kick back and relax, safe in the knowledge
that the mixing engineer sucked and mastering has to pick up the pieces,
as always. and there's only so much you can do.
that is a very nice and comfortable starting point to work from :)
17 Jan
17 Jan
10:40 p.m.
On Mon, Jan 17, 2011 at 02:11:13PM -0800, Ken Restivo wrote:
So, next time around, I'm putting my mixes thorugh
NAMA and squashing the holy hell out of them, until they sound like whatever the major
labels are pooting out these days.
You mention good reasons for doing so, but you can get much better
results by EQ-ing and compressing individual tracks rather than
doing the same on the mix.
Ciao,
--
FA
There are three of them, and Alleline.
11:07 p.m.
On Mon, Jan 17, 2011 at 11:40:18PM +0100, fons(a)kokkinizita.net wrote:
On Mon, Jan 17, 2011 at 02:11:13PM -0800, Ken Restivo
wrote:
Thanks, that makes a lot of sense. I'll try that instead!
-ken
So, next time around, I'm putting my mixes
thorugh NAMA and squashing the holy hell out of them, until they sound like whatever the
major labels are pooting out these days.
You mention good reasons for doing so, but you can get much better
results by EQ-ing and compressing individual tracks rather than
doing the same on the mix.
15 Jan
15 Jan
12:01 a.m.
On Fri, Jan 14, 2011 at 10:08:29AM +0000, allcoms wrote:
Hi list,
I suppose I could've just addressed this to drobilla and got most of my
questions answered but it concerns us all really as even if A3 and qtractor
were to achieve feature parity with Cubase and buds tomorrow (obviously I'm
stretching things a bit there) we still wouldn't see vast droves switching
to Linux DAWs for a few reasons such as hardware support, people liking what
they know etc. but most importantly the dearth of quality native plugins
available for Linux seems to be a primary showstopper for most.
DSSI has a few things coded for it but not much and its still very early
days for LV2 so the open plugin format of the future is still anyones game
and it may not necessarily be either of those that succeeds and gets widely
used of course. I think a couple of VSTs have been ported over to LV2 but
I'm not aware of any that have been ported to DSSI and I think that the ease
in doing so is quite an important factor in the success of any such format,
if not the be-all and end-all. If anyone here has any experience with coding
and/or porting VSTis - what is currently lacking from LV2 or DSSI that could
potentially cause problems for someone wanting to port their big beefy synth
or snazzy FX from VSTi to LV2 or DSSI? I already know about the incomplete
persist LV2 extension but I'm pretty sure that won't be the only thing
needing work.
A very important factor for such a format would definitely be that the major
hosts (commercial, foss or otherwise) for all major platforms would be able
to easily implement support for it and that plugins would be easy to port
between the different platforms. I'm not aware of any DAWs for Windows that
support LV2 or DSSI yet but I could be wrong? There's nothing stopping a
closed source, commecial app vendor adding support for either format is
there? Another factor I see as increasingly important is that the plugin
format should be able to take advantage of OpenCL to take advantage of the
superior processing power of todays GPUs. Quite how we'd convince Steinberg
and co. we need a replacement for VSTi and get them to support an open
standard though is anyones guess :/
I'm kind of curious to see what Fons has got cooking up with his own new plugin
architecture.
-ken
4878
days inactive
4882
days old
linux-audio-user@lists.linuxaudio.org
72 comments
24 participants
participants (24)
-
Alex Stone -
Alexandre Prokoudine -
allcoms -
Dave Phillips -
fons＠kokkinizita.net -
Harry Van Haaren -
Hartmut Noack -
hermann -
Jeremy Jongepier -
Jeremy Salwen -
Jörn Nettingsmeier -
Ken Restivo -
linuxdsp -
Louigi Verona -
michael noble -
Paul Davis -
Philipp Überbacher -
Q -
Renato -
Ricardus Vincente -
rosea.grammostola -
Rui Nuno Capela -
S. Massy -
Tom Szilagyi