28 Sep
2010
28 Sep
'10
4:34 p.m.
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...
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).
All I am saying is that jamin takes up a good amount of resources for its
processing. [*]
And I combined Fons' argument that the filter used is not a good implementation
and probably not needed anyway with my idea of a simpler but equally useful
tool.
Have fun,
Arnold
[*] It would be uber-cool if one could switch off that analyzer-view to save
processing cycles.