[LAU] Subject: Albums under a label recorded and/or mixed with Linux

[Jan Depner]

On Tue, 2010-09-28 at 18:22 -0700, Patrick Shirkey wrote:
> On Tue, September 28, 2010 7:33 am, Arnold Krille wrote:
> > On Tuesday 28 September 2010 16:21:48 Patrick Shirkey wrote:
> >> I'm pretty sure that this is the reasoning behind going with the filter
> >> option. The resources are available even on a eeepc as Ken has reported
> >> so
> >> it is not really a big deal as jamin is intended for use post pro.
> >
> > I don't actually remember Ken saying that he runs jamin on his eeepc.
> > True, he
> > is running an awful lot of software on there, but I doubt that he is
> > adding
> > 10ms artificial delay from jamin to his live-setup...
> >
> 
> Good point. Maybe Ken could clarify if he used his eeepc for the mastering
> stage on his album?
> 
> 
> >> If you want to have it running during production then you should
> >> probably
> >> just get a very powerful machine or invest the time to correct the
> >> issues
> >> as near as possible to source.
> >
> > Yes, a 1.8GHz turion64 running jack (3x1028 at 48kHz) and an ardour session
> > with
> > two stereo tracks, 4 plugins (SC4-compressor and an eq for each stereo) is
> > to
> > weak to also run jamin.
> >
> > Please get a grip! I am not using jamin on an under-spec machine. And I am
> > not
> > mis-using it during mixing/recording of a >48-channels session either. I
> > even
> > stopped dreaming about using jamin for live-foh usage (because of the
> > delay
> > introduced by the filter).
> 
> Well, it was never designed as a foh tool. It is and always has been a
> stereo channel post prod tool.
> 
> When it was developed I was running a 1 ghz celeron. It ran on there
> without issues. I don't see why it would have problems on any recent (past
> 8 years) notebook/netbook or PC.
> 
> 
> > All I am saying is that jamin takes up a good amount of resources for its
> > processing. [*]
> 
> This is by design. When the 2 very experienced DSP engineers Steve Harris
> and Jack O'Quin and the very experienced mastering engineer Ron Parker
> spec'd the backend they decided that this was the most appropriate method
> given the available resources at the time.
> 
> The idea was to provide as much smoothing of the bands as possible to
> create a very "clean" sound as per traditional mastering technique.
> 
> Now if you want to use a tool that is designed explicitly with that goal
> in mind then you should definitely be considering jamin as an option.
> 
> 
> 
> > And I combined Fons' argument that the filter used is not a good
> > implementation
> 
> Which has not been corroborated and in fact has been out right dismissed
> by my contact here.
> 
> > and probably not needed anyway with my idea of a simpler but equally
> > useful tool.
> 
> I think it would be worth your time to build a little mock up with pd or
> jack rack and listen to the difference in the audio quality.
> 
> I have very good reason to trust my sources that Fons is not correct when
> he says the current implementation is defective.
> 
> The point about using a stand alone parametric eq plugin as you suggested
> is that it would definitely add artifacts to the end result which is why
> the decision was made to use the linear filter.
> 
> 
> > [*] It would be uber-cool if one could switch off that analyzer-view to
> > save processing cycles.
> 
> That is a good point. I know you have the skills to make that happen. Do
> you have the time to craft a patch?
> 

    Since the analyzer view is only redrawn by default 10 times per
second there really isn't much overhead to save.  Take a look at
draw_EQ_spectrum_curve in hdeq.c.  You'll see that all it's really doing
is drawing a predefined pixmap, converting 1023 levels to dB, and then
drawing 1023 line segments.  This is hardly a drag on any system.  Be
that as it may, you can adjust the frequency of the update in
Edit->Preferences to be any value from 10 times per second to 0 times
per second.  In other words, the ability to switch off the analyzer view
is already there.

Jan