Re: 0.97 metering

On Tue, 2008-11-25 at 10:48 +0000, John Rigg wrote:
> On Mon, Nov 24, 2008 at 06:46:21PM -0600, Jan Depner wrote:
> > On Mon, 2008-11-24 at 13:28 +0000, John Rigg wrote:
> > > Group delay is larger in LF speaker drivers than HF ones, so I'd
> > > expect to see zero delay on LF and longest delay on HF (or is it
> > > showing the amount of delay compensation?)
> > 
> >     Rane crossovers, Peavey crossovers (and others), and BBE Sonic
> > Maximizers give you the ability to set delays for low and mid
> > frequencies to compensate for speaker placement (both in the enclosures
> > and in space) and other issues.  The delays were added so you could play
> > around with those settings without buying a crossover or BBE.  Another
> > reason that I wanted to add them was to get a better handle on the
> > processing.  It forced me to actually run through the processing code
> > and see what was happening.
> 
> In big live sound rigs you sometimes want to delay the LF, but in a
> studio you might want to do the opposite. If you look at the impulse
> response plot for most multi-way monitor speakers,  you can see that 
> the HF reaches the listener before the LF. The difference can be
> several milliseconds, so if you're going to provide delays for speaker
> time alignment, a delay on the HF channel could also be useful.
>  

    Now that's interesting.  I hadn't heard that before.  Maybe
something else to play around with ;-)

> >     JAMin is still a dedicated mastering processor.  We're trying to
> > stay away from too many bells and whistles which is one of the reasons
> > there haven't been too many changes lately.  Almost everything that has
> > been added has been optional.  The RMS meters were requested by a fair
> > number of people so, IIRC, the concensus was that it was a good thing
> > (TM). 
> 
> RMS metering is important for many users. A peak/rms/both selector would
> be useful though :-).
> 

    It's doable.  We can use the GTK hide and show widget functions (I
think).


> > We keep getting requests to make it simpler and lighter so people
> > can use it as a plugin.  I think I can safely say that that ain't gonna
> > happen ;-)
> 
> Good to know.
> 
> >     I do have a question though, since you seem to be a serious user, is
> > there a need for five compressor bands or more parametric controls on
> > the HDEQ?  Both of those have come up before and it seems like overkill
> > to me but I'm not a mastering engineer so I really don't know.  What's
> > your take?
> 
> I'd say five compressor bands would be overkill. A lot of mastering
> engineers avoid multi-band compression altogether, unless there's a
> particularly bad problem that requires it. The existing three bands
> are already flexible enough for routine work, and another two
> would get in the way in many situations.
> 
> The same applies to the HDEQ. The existing features are more than 
> adequate for most mastering work. In an exceptional case requiring
> more, it's pretty easy to put it through an external EQ plugin.
> 

    That's good to know.  You and Ron both have the same opinion on that
and you both know more about the art of mastering than I do ;-)


> This is a dilemma of course. Do you provide all the bells and
> whistles that users ask for, given that anything you add could make
> routine work more difficult? It's more important to keep things simple
> enough to allow efficient work flow IMO.
> 

    Agreed.

-- 
Jan 'Evil Twin' Depner
http://www.thecfband.com


"Microsoft has a new version out, Windows XP, which according to
everybody is the 'most reliable Windows ever.' To me, this is like
saying that asparagus is 'the most articulate vegetable ever.'"

Dave Barry



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/