On Wed Sep 29 16:11 , "Patrick Shirkey" sent: > >On Tue, September 28, 2010 5:47 pm, Jan Depner wrote: >> >> 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@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. >> > > >Good point, thanks for the reminder. > >Yet another reason why nothing has been done on jamin for a while now ;-) > I've used Jamin a number of times for self-mastering releases, including a vinyl release in 2009. While I would prefer to go to a professional mastering agency my return from music currently doesn't justify it (it doesn't even pay my ardour subscription :) ).. . The labels I've submitted too were more happy with the mastering quality (probably happier than I was .. although the problem is my skill level not the software quality). Jamin does a very good job, I can't see any reason to change it. As for resources, I have got in the habit of not rendering my final mix-down to stereo and then mastering, but simply inserting Jamin into the main output of Ardour.. this allows for any adjustments to be made at the mix level (e.g. a channel being too loud)... without going through the process of rendering again.. On a AMD Phenom II X3 720 OC'd to ~3.5 GHZ.. I have not exceeded resource limits on 24 channel (48KHz 32 bit broadcast wav)... with numerous plugins, including some of the more complex ones then going through JACK while retaining a 128 period and 3 buffer setting on jackd - remembering that everything inside Jack is in on one processor core... (with the other cores simply providing smooth X11 rendering e.t.c..) .. It's not a eeepc but it is just an average spec PC.. (with some high quality parts). _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
