7 Jul
2010
7 Jul
'10
1:21 p.m.
Hi Fons and LAD's,
I'm a very happy user of the decent FIL-equalizer and so far, it serves all my
needs for mixing down mono channels in mixing situations. The problem is that
a Stereo EQ is also needed from time to time, for example with drums; I'm
thinking about overhead channels. I use to make on bus for the drums and an
additional bus for the OH channels (so left and right OH channels can use
common hipass, compressor and EQs, and deesser (and so on)), then every drum
item is feed into the drum bus and OH's is feed it's stereo bus and from there
into the drum bus; this is probably the most common way to do it.
So my humble (I hope) request is: Is it possible to make a stereo version of
FIL-equalizer and can someone implement it? That would make the mixing
situation very much better.
And while I'm at it: Is it possible to add a Hi Pass filter (12(/18)/24 db) on
them too? ;-)
I know that's it's other EQ's out there, but the FIL-equalizer seems to cover
up my needs while still being simple to use and not overloading the computer -
2 or 3 bands are normally everything one need.
Thank you.
Jostein
7 Jul
7 Jul
1:51 p.m.
On Wed, Jul 07, 2010 at 01:18:40PM +0200, Jostein Chr. Andersen wrote:
I'm a very happy user of the decent FIL-equalizer
and so far, it serves all my
needs for mixing down mono channels in mixing situations. The problem is that
a Stereo EQ is also needed from time to time, for example with drums; I'm
thinking about overhead channels. I use to make on bus for the drums and an
additional bus for the OH channels (so left and right OH channels can use
common hipass, compressor and EQs, and deesser (and so on)), then every drum
item is feed into the drum bus and OH's is feed it's stereo bus and from there
into the drum bus; this is probably the most common way to do it.
So my humble (I hope) request is: Is it possible to make a stereo version of
FIL-equalizer and can someone implement it? That would make the mixing
situation very much better.
If you mean the LADSPA plugin, I don't see the problem: Ardour
will automatically duplicate it if you use it in a stereo track
or bus.
And while I'm at it: Is it possible to add a Hi
Pass filter (12(/18)/24 db) on
them too? ;-)
The plugin is frozen as far as I'm concerned, as there
are some new ones in preparation - see for example
<http://www.kokkinizita.net/linuxaudio/eq1.png>.
This one has improved parametric sections, second
order shelf filters (with variable slope) and an
18 dB/oct higpass.
This will be released some day as a series of plugins
(using their own standard) together with host/plugin
libraries and a reference host.
ATM it is available as a Jack app to selected users,
write to me off-list if you want to try it.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
3:36 p.m.
onsdag 07 juli 2010 13.50.58 skrev fons(a)kokkinizita.net:
Shit, I didn't know that! :-)
On Wed, Jul 07, 2010 at 01:18:40PM +0200, Jostein Chr.
Andersen wrote:
...
So my humble
(I hope) request is: Is it possible to make a stereo version
of FIL-equalizer and can someone implement it? That would make the
mixing situation very much better.
If you mean the LADSPA plugin, I don't see the problem: Ardour
will automatically duplicate it if you use it in a stereo track
or bus. ATM it is available as a Jack app to selected users,
write to me off-list if you want to try it.
Yes please, I'm glad to try it. It looks like something useful and productive.
Thank you very much for doing all this wonderful Linux Audio Stuff!
Jostein
4:01 p.m.
Sorry folks, this posting was ment to be sendet offlist to Fons. :-(
I do only have place for mixing in my mind just now, sorry.
Jostein
onsdag 07 juli 2010 15.36.03 skrev Jostein Chr. Andersen:
onsdag 07 juli 2010 13.50.58 skrev
fons(a)kokkinizita.net:
Shit, I didn't know that! :-)
On Wed, Jul 07, 2010 at 01:18:40PM +0200, Jostein
Chr. Andersen wrote:
...
So my
humble (I hope) request is: Is it possible to make a stereo
version of FIL-equalizer and can someone implement it? That would make
the mixing situation very much better.
If you mean the LADSPA plugin, I don't see the problem: Ardour
will automatically duplicate it if you use it in a stereo track
or bus. ATM it is available as a Jack app to selected
users,
write to me off-list if you want to try it.
Yes please, I'm glad to try it. It looks like something useful and
productive.
Thank you very much for doing all this wonderful Linux Audio Stuff!
Jostein
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
3:36 p.m.
onsdag 07 juli 2010 13.50.58 skrev fons(a)kokkinizita.net:
Shit, I didn't know that, now, I'm exited! :-)
It looks like something useful and productive.
Thank you very much for doing all this wonderful Linux Audio Stuff!
Jostein
On Wed, Jul 07, 2010 at 01:18:40PM +0200, Jostein Chr.
Andersen wrote:
...
So my humble
(I hope) request is: Is it possible to make a stereo version
of FIL-equalizer and can someone implement it? That would make the
mixing situation very much better.
If you mean the LADSPA plugin, I don't see the problem: Ardour
will automatically duplicate it if you use it in a stereo track
or bus. And while I'm at it: Is it possible to add a
Hi Pass filter (12(/18)/24
db) on them too? ;-)
The plugin is frozen as far as I'm concerned, as there
are some new ones in preparation - see for example
<http://www.kokkinizita.net/linuxaudio/eq1.png>.
This one has improved parametric sections, second
order shelf filters (with variable slope) and an
18 dB/oct higpass. 
3:47 p.m.
Excerpts from fons's message of 2010-07-07 13:50:58 +0200:
On Wed, Jul 07, 2010 at 01:18:40PM +0200, Jostein Chr.
Andersen wrote:
Previously I was unsure whether it will be a set of lv2 extension or
another plugin API, I guessed the former but apparently was wrong.
Does it really need another plugin API in addition to the 5 free and
native (read: non-VST) APIs I can think of off the top of my head?
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
I'm a very happy user of the decent
FIL-equalizer and so far, it serves all my
needs for mixing down mono channels in mixing situations. The problem is that
a Stereo EQ is also needed from time to time, for example with drums; I'm
thinking about overhead channels. I use to make on bus for the drums and an
additional bus for the OH channels (so left and right OH channels can use
common hipass, compressor and EQs, and deesser (and so on)), then every drum
item is feed into the drum bus and OH's is feed it's stereo bus and from there
into the drum bus; this is probably the most common way to do it.
So my humble (I hope) request is: Is it possible to make a stereo version of
FIL-equalizer and can someone implement it? That would make the mixing
situation very much better.
If you mean the LADSPA plugin, I don't see the problem: Ardour
will automatically duplicate it if you use it in a stereo track
or bus.
And while I'm at it: Is it possible to add a
Hi Pass filter (12(/18)/24 db) on
them too? ;-)
The plugin is frozen as far as I'm concerned, as there
are some new ones in preparation - see for example
<http://www.kokkinizita.net/linuxaudio/eq1.png>.
This one has improved parametric sections, second
order shelf filters (with variable slope) and an
18 dB/oct higpass.
This will be released some day as a series of plugins
(using their own standard) together with host/plugin
libraries and a reference host.
ATM it is available as a Jack app to selected users,
write to me off-list if you want to try it.
Ciao,
4:46 p.m.
On Wed, Jul 07, 2010 at 03:47:20PM +0200, Philipp Überbacher wrote:
Previously I was unsure whether it will be a set of
lv2 extension or
another plugin API, I guessed the former but apparently was wrong.
Does it really need another plugin API in addition to the 5 free and
native (read: non-VST) APIs I can think of off the top of my head?
I now of LADSPA, DSSI and LV2. None of them comes close to
what is required. Which are the others (apart from Csound
opcodes etc.) ?
It could be done as an LV2 extension (LV2, like the Borg,
could assimilate anything), but nothing is gained by doing
that - it just complicates things. Only the discovery
mechanism would remain, and it is widely known that I don't
much like anything that even looks like XML.
There are number of fundamental differences between existing
Linux plugin systems and the one I'm working on, so as far as
I can see the answer to your question is positive.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
5:13 p.m.
Excerpts from fons's message of 2010-07-07 16:46:26 +0200:
On Wed, Jul 07, 2010 at 03:47:20PM +0200, Philipp
Überbacher wrote:
There's also MESS (some muse related thing, also only read recently
about it) and RHSP
(http://sites.google.com/site/rockhardbuns/rhsp).
Previously I was unsure whether it will be a set
of lv2 extension or
another plugin API, I guessed the former but apparently was wrong.
Does it really need another plugin API in addition to the 5 free and
native (read: non-VST) APIs I can think of off the top of my head?
I now of LADSPA, DSSI and LV2. None of them comes close to
what is required. Which are the others (apart from Csound
opcodes etc.) ? It could be done as an LV2 extension (LV2, like the
Borg,
could assimilate anything), but nothing is gained by doing
that - it just complicates things. Only the discovery
mechanism would remain, and it is widely known that I don't
much like anything that even looks like XML.
There are number of fundamental differences between existing
Linux plugin systems and the one I'm working on, so as far as
I can see the answer to your question is positive.
Ciao,
I'm just afraid that it might end up as a pretty much app specific
thing, similar to MESS and RHSP. What's the point of a plugin API
'standard' when there's a single host supporting the thing? It doesn't
help plugin developers either if they have to chose between 5-7 plugin
APIs, knowing that, whatever they chose, only a, often tiny, subset of
programs will be able to load the plugin.
I'm not sure the lv2 way would be better either, hosts would need to
adapt your extensions and that may or may not take a long time.
I guess there's no easy answer until there's a plugin standard everyone is
happy with.
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
7:51 p.m.
On Wed, Jul 07, 2010 at 05:12:56PM +0200, Philipp Überbacher wrote:
I'm just afraid that it might end up as a pretty
much app specific
thing, similar to MESS and RHSP.
That would be perfectly OK for me. I'm not after popularity,
and I'm writing these things in the first place for myself.
What's the point of a plugin API
'standard' when there's a single host supporting the thing?
Apart from the host(s) I'll provide (one of which is an app on
its own, the other a pure plugin host) that would probably be
the case anyway.
Actually, for a host author implementing this standard directly
would be easier than trying to squeeze it into an existing LV2
framework - some things are quite different.
It doesn't help plugin developers either if they
have to
chose between 5-7 plugin APIs, knowing that, whatever they
chose, only a, often tiny, subset of programs will be able
to load the plugin.
That again is not something that keeps me awake at night.
In fact it would provide a form of natural selection. The
main point of this series of plugins will be *quality*.
I'm not really waiting to see the N-th 'I-dont-understand-it-
but-copied-it-from-some-textbook' algorithm being added to it.
There are already enough of those, and that in itself is a
good reason for not wanting to be associated with existing
standards.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
8:23 p.m.
On Wed, 2010-07-07 at 19:51 +0200, fons(a)kokkinizita.net wrote:
On Wed, Jul 07, 2010 at 05:12:56PM +0200, Philipp
Überbacher wrote:
Natural selection.
I bet as soon as Qtractor will have some additional features or as soon
as Ardour3 is released, the Linux people who now wish to have 1000 apps,
will switch to the one in all solution too. The people who still wish to
use 1000 apps could run 10 hosts, so this shouldn't be an issue.
Natural selection will be done by the first all in one solutions for
Linux, another for the future might be Rosegarden.
I guess a developer just needs to take a look at what is supported by
(in lexically order) Ardour, Qtractor and Rosegarden as host.
- Ralf
It doesn't help plugin developers either if
they have to
chose between 5-7 plugin APIs, knowing that, whatever they
chose, only a, often tiny, subset of programs will be able
to load the plugin.
That again is not something that keeps me awake at night.
In fact it would provide a form of natural selection.
10:53 p.m.
On Wed, Jul 07, 2010 at 08:23:50PM +0200, Ralf Mardorf wrote:
I guess a developer just needs to take a look at what
is supported by
(in lexically order) Ardour, Qtractor and Rosegarden as host.
Depends on the developer's own interests and target audience.
For production tools I keep an eye on Ardour, and that's it
more or less.
If people think that Autotalent is really great then they
should just use it. Even if its resampling code distorts as
hell. If they believe that the Calf Compressor really has
an RMS mode as it claims it has, let them be happy believing
that. I don't care.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
11:09 p.m.
On Wed, 2010-07-07 at 22:53 +0200, fons(a)kokkinizita.net wrote:
On Wed, Jul 07, 2010 at 08:23:50PM +0200, Ralf Mardorf
wrote:
That explains why you're happy with PCs to produce music, you don't use
MIDI ;). Anyway, some developer might care about at least the most
common hosts. Until now those are Ardour + Rosegarden and Qtractor gets
more and more fans too.
Now, autotalent might become better and might be important for the more
up to date pop music orientated crowed while people might use Calf
compressor without RMS mode.
I don't need autotalent. I do need a compressor, but if possible I avoid
using a compressor and try to do a good mix by using EQs instead of a
compressor.
Anyway, we do have different needs and I would welcome if you coders
take care of Ardour, Rosegarden and Qtractor. IMO anything else is less
important. Note, it's not unimportant!
0,02 €
I guess a developer just needs to take a look at
what is supported by
(in lexically order) Ardour, Qtractor and Rosegarden as host.
Depends on the developer's own interests and target audience.
For production tools I keep an eye on Ardour, and that's it
more or less.
If people think that Autotalent is really great then they
should just use it. Even if its resampling code distorts as
hell. If they believe that the Calf Compressor really has
an RMS mode as it claims it has, let them be happy believing
that. I don't care.
Ciao, 
8 Jul
8 Jul
12:43 a.m.
On 7 July 2010 22:08, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Anyway, we do have different needs and I would welcome
if you coders
take care of Ardour, Rosegarden and Qtractor. IMO anything else is less
important. Note, it's not unimportant!
0,02 €
It'll take more than 0,02 € for developers to do as you say ;-)
7 Jul
7 Jul
10:56 p.m.
Excerpts from fons's message of 2010-07-07 19:51:29 +0200:
On Wed, Jul 07, 2010 at 05:12:56PM +0200, Philipp
Überbacher wrote:
But I'm sure that you see the benefit of a single plugin standard as VST
pretty much is on windows. Anyway, there's no easy way to solve the
multiple-standards thing in Linux land apparently.
One thing that I'm wondering about though, what about NASPRO? Do you
think it might be able to wrap around your plugins and bridge to lv2?
http://naspro.atheme.org/about
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
I'm just afraid that it might end up as a
pretty much app specific
thing, similar to MESS and RHSP.
That would be perfectly OK for me. I'm not after popularity,
and I'm writing these things in the first place for myself.
What's the point of a plugin API
'standard' when there's a single host supporting the thing?
Apart from the host(s) I'll provide (one of which is an app on
its own, the other a pure plugin host) that would probably be
the case anyway.
Actually, for a host author implementing this standard directly
would be easier than trying to squeeze it into an existing LV2
framework - some things are quite different.
It doesn't help plugin developers either if
they have to
chose between 5-7 plugin APIs, knowing that, whatever they
chose, only a, often tiny, subset of programs will be able
to load the plugin.
That again is not something that keeps me awake at night.
In fact it would provide a form of natural selection. The
main point of this series of plugins will be *quality*.
I'm not really waiting to see the N-th 'I-dont-understand-it-
but-copied-it-from-some-textbook' algorithm being added to it.
There are already enough of those, and that in itself is a
good reason for not wanting to be associated with existing
standards.
Ciao,
8 Jul
8 Jul
12:08 a.m.
On Wed, Jul 07, 2010 at 10:56:24PM +0200, Philipp Überbacher wrote:
But I'm sure that you see the benefit of a single
plugin standard as VST
pretty much is on windows. Anyway, there's no easy way to solve the
multiple-standards thing in Linux land apparently.
A single standard would be a good thing. But in the field of
audio plugin standards all Linux efforts have had the same
approach: to make things as simple as possible in order to
avoid scaring away even the most unprepared would-be authors.
With the result of ignoring any form of real analysis, or
pushing it into the future.
This is *not* the case for most of Linux. For the system level
the UNIX heritage, POSIX, existing networking standards, etc.
have dominated its design. None of these were defined in the
way Linux audio standards typically are.
The only exception is Jack which has hit its target right
in the center, even if IMHO it will sooner or later benefit
from a rather invasive and incompatible cleanup to remove
the scars and deformations it incurred while climbing the
learning curve.
One thing that I'm wondering about though, what
about NASPRO? Do you
think it might be able to wrap around your plugins and bridge to lv2?
http://naspro.atheme.org/about
If there's one thing I do detest down to the center of my bones
it is such wrapping of layer upon layer to transform A into B.
And if NASPRO would be able to 'bridge' my system, it would still
require extensions to LV2 which is its base, the same that would
be required without NASPRO. Nothing at all is gained by doing this.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
12:40 a.m.
Excerpts from fons's message of 2010-07-08 00:08:11 +0200:
Ah, didn't know detest is an English word as well..
I understand why you hate this, it rarely works as well as it should.
On the other hand, software today is nothing but layer upon layer upon
layer...
NASPROs goal is a noble and pragmatic one however, it tries to make any
plugin available in any lv2 host. Afaik, I still haven't tested it, it
doesn't provide any GUI.
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
On Wed, Jul 07, 2010 at 10:56:24PM +0200, Philipp
Überbacher wrote:
The 'simple' part seems to have worked out well for LV2...
But I'm sure that you see the benefit of a
single plugin standard as VST
pretty much is on windows. Anyway, there's no easy way to solve the
multiple-standards thing in Linux land apparently.
A single standard would be a good thing. But in the field of
audio plugin standards all Linux efforts have had the same
approach: to make things as simple as possible in order to
avoid scaring away even the most unprepared would-be authors.
With the result of ignoring any form of real analysis, or
pushing it into the future. One thing that
I'm wondering about though, what about NASPRO? Do you
think it might be able to wrap around your plugins and bridge to lv2?
http://naspro.atheme.org/about
If there's one thing I do detest down to the center of my bones
it is such wrapping of layer upon layer to transform A into B.
And if NASPRO would be able to 'bridge' my system, it would still
require extensions to LV2 which is its base, the same that would
be required without NASPRO. Nothing at all is gained by doing this.
Ciao,
5203
days inactive
5203
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
5 participants
participants (5)
-
fons＠kokkinizita.net -
James Morris -
Jostein Chr. Andersen -
Philipp Überbacher -
Ralf Mardorf