29 Mar
2005
29 Mar
'05
4:29 p.m.
On Tue, 2005-03-29 at 12:32, R Parker wrote:
and
I see no use for meterbridge in JAMin. We've already
got good metering.
Agreed. Plus, you can always put meterbridge in the chain (Steve's
suggestion). The other problem is just screen real estate. We're
trying to keep it as small as possible. As it is I'm probably going
dual screen in the near future.
I am not the originator of the request. Joern relayed
his experience and suggested a solution for detecting
problems. Because it doesn't affect audio processing
it is an easier feature to be in favor of. In
comparison your proposals for low, mid and high delays
are much more complicated. And I imagine you're tired
of arguing about it.
It's certainly not as easy to implement as the delays. Also, there
is no reason for a delay on the high band.
> Wait now, you're the one that thought it
would
be a good
idea to add
meterbridge to JAMin.
Really? I have no recollection of suggesting that if I did am clueless as to the context within
which I
would have cast that vote.
Someone said that they were using meterbridge and
another app to
monitor inputs to JAMin and they thought it would be
a good thing if
they were included in JAMin. You replied that you
agreed. I don't
remember what list it was on but I'm sure I could
find it. I think it
might have been Joern's first post on the DC offset
problem. Besides all that, what does meterbridge have to do
with my reply?
You were complaining about too many things being
included in JAMin.
I was just pointing out that you also want more
things in JAMin. I'm curious about the results you're getting
by
routing through the BBE. Can you adjust the delay
amount realtime and if yes could you create an example
where you slowly sweep from no delay to the right
amount of delay and then beyound where there's to much
delay? If that's reasonable sweep slowly enough and
hold in each setting long enough to adust our hearing
and try to analyze what's happening.
Unfortunately, no. You can't adjust the delay times. They are
static at ~2.5 ms for 20-150Hz and about .5 ms for 150-1200Hz. What
you're suggesting is exactly what I'd like to try, I just don't have
anything that will do it.
How many milliseconds of delay do you suspect are
inherent in our processing chain?
I believe there is a minimum of 10ms (the lowest limiter setting),
beyond that I'm not sure. It shouldn't be much.
Are you suggesting the latency is inherent in
software
or not until it hits audio card hardware?
It's in the lookahead limiter I think.
I am accutely aware of the negative affect that
timing
and sync have and how phasing undermines amplitude
response.
If "delay" is a real problem in mastering do you have
any thoughts on how it's affects Ardour? It seems to
me that there can't be any difference between it and
JAMin. In fact phasing should be more apparent in
Ardour simply because of the track counts. Right or
wrong?
The delay only happens when you go to the speakers. Some systems
now take that into account. Heck, even my television uses a BBE
processor now ;-)
Jan