[linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
3 Jan
2005
3 Jan
'05
7:12 p.m.
Tom Szilagyi wrote:
At first I agreed that the splitter was the solution, and I wrote one,
only to find one already exists in the SWH package. The argument is
that this is clumsy and not an optimal solution. After hearing this
argument, it does seem like a cleaner, faster solution to have available
plugins in various connection formats instead of building the
connections from lego's. I am in no way an authority on this though, so
I am going to forward this to LAD, as I think it pertains to all the
plugin projects. There was recently a thread on ardour-dev regarding
connections and plugin counts that is probably going to start all over
again, but discussions are fun anyway, arent they? :)
Doug
--
http://nostar.net/
Hey Tom,
Attatched is a patch that creates a 1in / 2out version of TAP Stereo Echo. It would need
a
new ladspa ID and better name possibly. Ardour now has a strict policy regarding plugin
connections, requiring a mono to stereo splitter to preceed TAP S.E. on a mono track.
The
popular opinion with the ardour guys is that plugins be made available in various forms
instead of trying to make the host too complex or having to use combinations to acheive
the desired results.
I can do the others as well, like reverberator, etc too if you would like.
Hi,
What if I released a stand-alone mono->stereo splitter plugin ASAP?
That would solve this issue completely, no?
Of course, users will have to explicitly use it, but if I agree to make split versions
of
all my stereo plugins, then 1) users still have to decide which one to use and 2)
duplicated
code to maintain arises (and many Ladspa ID-s get wasted) etc etc.
OK, I see you wrote "having to use combinations to achieve the desired results"
is ungood,
but I still think this is a cleaner solution from an engineering p.o.v.
So, what's your opinion? Splitter-plugin vs plugin-splitting? :) 
4 Jan
4 Jan
4:22 p.m.
New subject: [linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
On Mon, 2005-03-01 at 18:18 -0500, Doug McLain wrote:
Tom Szilagyi wrote:
At first I agreed that the splitter was the solution, and I wrote one,
only to find one already exists in the SWH package. The argument is
that this is clumsy and not an optimal solution. After hearing this
argument, it does seem like a cleaner, faster solution to have available
plugins in various connection formats instead of building the
connections from lego's. I am in no way an authority on this though, so
I am going to forward this to LAD, as I think it pertains to all the
plugin projects. There was recently a thread on ardour-dev regarding
connections and plugin counts that is probably going to start all over
again, but discussions are fun anyway, arent they? :)
Doug
Personally, I think it's a disgusting waste of time and effort to make
every stereo plugin have to have a mono->stereo sibling. It
just /screams/ bad solution. (Duplication of effort, wasted IDs,
significantly increased compile time for LADSPA plugin libraries, more
plugins to wade through.. etc. etc)
If user intervention is the problem, ardour should ask the user if they
want to automatically insert a mono->stereo plugin before the plugin
when this situation arises. Problem (easily) solved, none of the nasty
problems above.
-DR-
Hey Tom,
Attatched is a patch that creates a 1in / 2out version of TAP Stereo Echo. It would need
a
new ladspa ID and better name possibly. Ardour now has a strict policy regarding plugin
connections, requiring a mono to stereo splitter to preceed TAP S.E. on a mono track.
The
popular opinion with the ardour guys is that plugins be made available in various forms
instead of trying to make the host too complex or having to use combinations to acheive
the desired results.
I can do the others as well, like reverberator, etc too if you would like.
Hi,
What if I released a stand-alone mono->stereo splitter plugin ASAP?
That would solve this issue completely, no?
Of course, users will have to explicitly use it, but if I agree to make split versions
of
all my stereo plugins, then 1) users still have to decide which one to use and 2)
duplicated
code to maintain arises (and many Ladspa ID-s get wasted) etc etc.
OK, I see you wrote "having to use combinations to achieve the desired results"
is ungood,
but I still think this is a cleaner solution from an engineering p.o.v.
So, what's your opinion? Splitter-plugin vs plugin-splitting? :) 
4:45 p.m.
New subject: [linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
On Tuesday 04 Jan 2005 20:20, Dave Robillard wrote:
Personally, I think it's a disgusting waste of
time and effort to
make every stereo plugin have to have a mono->stereo sibling. It
just /screams/ bad solution.
I agree, it sounds ridiculous -- on first hearing at least. I'm going
to have to go and read some of this ardour-dev discussion (it's not a
list I subscribe to) and see if it makes any more sense to me then.
I realise it's not easy (or even always possible) to do the Right Thing
in the host -- my own host has some way to go too -- but I don't
understand why it should be better to create dozens of spurious plugins
than to give the user the information they need and let them decide how
a plugin should be handled.
Chris
5 p.m.
New subject: [linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
I agree, it sounds ridiculous -- on first hearing at
least. I'm going
to have to go and read some of this ardour-dev discussion (it's not a
list I subscribe to) and see if it makes any more sense to me then.
ardour-dev has nothing. we do almost all discussion on IRC these days.
I realise it's not easy (or even always possible)
to do the Right Thing
in the host -- my own host has some way to go too -- but I don't
understand why it should be better to create dozens of spurious plugins
than to give the user the information they need and let them decide how
a plugin should be handled.
definitely. for the record, i intend to have ardour do the right thing
post-2.0, but right now when i am putting out fires that prevent us
from turning the corner to 1.0, a solution is required, or maybe i
should say "decision" :)
right now, ardour just requires the user to set this up manually. the
only argument i can see in favor of at least some 2in/2out plugins
having a 1in/2out cousin is that their DSP algorithms are actually
different in each case. whether thats true for the typical cases under
discussion, i don't know.
--p
5 Jan
5 Jan
4:31 a.m.
New subject: [linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
On Tuesday 04 Jan 2005 21:00, Paul Davis wrote:
ardour-dev has nothing. we do almost all discussion on
IRC these
days.
Ah. Does that get logged anywhere?
the only argument i can see in favor of at least some
2in/2out plugins
having a 1in/2out cousin is that their DSP algorithms are actually
different in each case.
Can't argue with that.
Chris
4 Jan
4 Jan
5:01 p.m.
New subject: [linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
tisdagen den 4 januari 2005 21.57 skrev Chris Cannam:
On Tuesday 04 Jan 2005 20:20, Dave Robillard wrote:
In ardour, which allows for any channel configuration I guess this might be
harder. In MusE only 1 and 2 channels are supported at the moment, in which
case it is simpler, atleast that's how I interpret it.
1. Insert a mono plug on a stereo track and both channels will be mixed into
the plugin.
2. Insert a stereo plugin into a mono track and it will be split to both
inputs.
/Robert
Personally, I think it's a disgusting waste
of time and effort to
make every stereo plugin have to have a mono->stereo sibling. It
just /screams/ bad solution.
I agree, it sounds ridiculous -- on first hearing at least. I'm going
to have to go and read some of this ardour-dev discussion (it's not a
list I subscribe to) and see if it makes any more sense to me then.
I realise it's not easy (or even always possible) to do the Right Thing
in the host -- my own host has some way to go too -- but I don't
understand why it should be better to create dozens of spurious plugins
than to give the user the information they need and let them decide how
a plugin should be handled.
Chris
--
http://spamatica.se/music/
7:57 p.m.
New subject: [linux-audio-dev] Audio CD verification/error detection
Hi everyone,
I'm looking for a way to verify an audio CD -- to make sure
there are no flaws (scratches, mfg errors) that would cause skips or
other playback problems on your typical consumer CD player.
Are there any tools that are specifically written to do this?
Or any tools that could be easily modified for this?
It seems that most of the tools I've found that are close to
this are designed to rip a CD and only deal with any problems only in
so far as they cause the ripping process to fail. What I want to have
is something that actually reports on the errors that it encounters
so I can reject any disks that would fail (or be likely to fail).
Thanks,
---Lawrence
--
+------------------------------------------------------------------------+
| Lawrence Coffin Watertown, MA |
| http://www.PointInfinity.com/lcoffin/ lcoffin(a)PointInfinity.com |
| http://www.whosmytwin.org Find your long lost twin! |
+------------------------------------------------------------------------+
Garbage In -- Gospel Out.
-
8:36 p.m.
New subject: [linux-audio-dev] Audio CD verification/error detection
On Tue, 2005-01-04 at 18:56 -0500, Lawrence Coffin wrote:
Hi everyone,
I'm looking for a way to verify an audio CD -- to make sure
there are no flaws (scratches, mfg errors) that would cause skips or
other playback problems on your typical consumer CD player.
Are there any tools that are specifically written to do this?
Or any tools that could be easily modified for this?
It seems that most of the tools I've found that are close to
this are designed to rip a CD and only deal with any problems only in
so far as they cause the ripping process to fail. What I want to have
is something that actually reports on the errors that it encounters
so I can reject any disks that would fail (or be likely to fail).
Can't cdparanoia do that?
Lee
8:42 p.m.
New subject: [linux-audio-dev] Audio CD verification/error detection
Indeed, the (old-old) cdparanoia is the best, I think.
Andrew
======= On Wednesday 05 January 2005 03:36, Lee Revell wrote: =======
...
It seems that most of the tools I've found that
are close to
this are designed to rip a CD and only deal with any problems only in
so far as they cause the ripping process to fail. What I want to have
is something that actually reports on the errors that it encounters
so I can reject any disks that would fail (or be likely to fail).
Can't cdparanoia do that?
Lee
9:45 p.m.
New subject: [linux-audio-dev] Audio CD verification/error detection
Thanks Lee and Andrew. I'll take a look at it.
Indeed, the (old-old) cdparanoia is the best, I think.
Which version would that be?
---Lawrence
--
+------------------------------------------------------------------------+
| Lawrence Coffin Watertown, MA |
| http://www.PointInfinity.com/lcoffin/ lcoffin(a)PointInfinity.com |
| http://www.whosmytwin.org Find your long lost twin! |
+------------------------------------------------------------------------+
A Los Angeles judge ruled that "a citizen may snore with immunity in
his own home, even though he may be in possession of unusual and
exceptional ability in that particular field."
-
10:06 p.m.
New subject: [linux-audio-dev] Audio CD verification/error detection
I think, it is "cdparanoia III 9.8" (or 3.9.8) - it depends on
your distribution, the last may have specific patches.
Andrew
======= On Wednesday 05 January 2005 04:28, Lawrence Coffin wrote: =======
Thanks Lee and Andrew. I'll take a look at it.
Indeed, the (old-old) cdparanoia is the best, I think.
Which version would that be?
10:16 p.m.
New subject: [linux-audio-dev] Audio CD verification/error detection
On Wed, 2005-01-05 at 05:07 +0300, Andrew Gaydenko wrote:
I think, it is "cdparanoia III 9.8" (or
3.9.8) - it depends on
your distribution, the last may have specific patches.
Andrew
======= On Wednesday 05 January 2005 04:28, Lawrence Coffin wrote: =======
Thanks Lee and Andrew. I'll take a look at it.
Just to clarify, did you mean that an old version of cdparanoia is
preferred, or just that it's an old program?
Anyway, your results will vary from drive to drive. The best are
Plextor, you can rip very fast and reliably with them.
Lee
Indeed, the (old-old) cdparanoia is the best, I
think.
Which version would that be?
10:30 p.m.
New subject: [linux-audio-dev] Audio CD verification/error detection
I mean, the last offical release is rather old, but is still
the best app of such kind (I think :-).
I and my friend have used it with many different CD drives (all with
IDE interfaces) without any problems (Teac, Mitsumi, NEC, ...).
Sometimes the app eats many CPU with kernel 2.4 (when a drive is configured
via SCSI emulation), but eats nothing with 2.6 (when a drive is
configured as IDE device).
Andrew
======= On Wednesday 05 January 2005 05:16, Lee Revell wrote: =======
>Indeed, the (old-old) cdparanoia is the best, I
think.
Just to clarify, did you mean that an old version of cdparanoia is
preferred, or just that it's an old program?
Anyway, your results will vary from drive to drive. The best are
Plextor, you can rip very fast and reliably with them.
Lee
7257
days inactive
7259
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
8 participants
participants (8)
-
Andrew Gaydenko -
Chris Cannam -
Dave Robillard -
Doug McLain -
Lawrence Coffin -
Lee Revell -
Paul Davis -
Robert Jonsson