Q: about Harrison/other DAWS and graphics in MMultianalyser

[Batty]

I have seen a big ressource use of my DSP in Harrison (and possibly in other daws but I only need it in Harrison32c surrently as it is my main output mixer), using one instance of MMultianalyser per Track. That means about 50 Tracks. I had to step down on my RME sample buffer. From 1024 to 4096 or else playing a song wouldn't be possible without extreme slowmotion and crackling.

And I do wonder now: does MMultianalyser use the graphics card or is this still calculated on cpu and/or breaking down speed in the system? In my cubase time...a year ago...I never had that much of an impact by MMultianalyser. Or is this a daw problem? Is the graphics card used for most of the graphical stuff (outsourcing of work cycles)? Is analysing that much ressource intensive?

It's not that big of a problem...more a curiosity thing and maybe something for thoughts, in case there could be space for optimisations. Maybe I have to check on something I haven't known/considered as well. Or maybe it is like it is?
But you'll never know until you ask, isn't it?

[Batty]

I should rephrase my question:
to use lots of MMultianalysers what would be best to upgrade, if it hangs:
Graphics card, Ram, Mainboard, cpu - or is the only thing that can make this physically faster a better soundcard?
Or does one need a slave computer? What could be done, if reaching for low sample buffers doesn't help anymore especially with this plugin?

[moonmadness]

50 MMultiAnalyzer plugins loaded???
do you disable them when not in use?
if not, that's a lot of wasted CPU power.

i usually load them only on the tracks i need and disable them when done.
when i think i don't intend to use them anymore i just delete them from the chain.

no sense cluttering up the DAW which stuff i don't use...

[steve2KVR]

...I devote a single "bus/aux" across all channels with nothing but analyzers/etc on it, and that analyzer channel is parked way off to the right side next to the 2bus...when I need to "check something," I can simply arm the aux-send on the channel/s that I am interested in...it's the graphics of the meters that eats up the cpu...hth.../s~

[Batty]

there's no other way than to load'em all, if you wanna find out visually where frequencies are colliding.
Later, when I allocate the most problematic ones I disable them. But I have to go through it all first.

[Batty]

corretion: ....I dosable the 'ok' ones than need no further manipulation.

[Batty]

*sigh*....disable...I shouldn't write in darkness :p

[Batty]

and a "that" instead of "than" ...oh well.

[pone]

The rendering by default is done on the GPU, since you're looking at a lot of instances at the same time, I'd guess it's on for you as well.
The actual analysis of the signal is done entirely by the cpu. I haven't used mixbus, but it looks like you can drag and drop effects between tracks. Why not toss instances around when you need them?

[Batty]

I am using those copied instances in interlocked mode all over the tracks.
That way one instance shows all tracks in the same plugin - showing me the frequencies of all tracks and if they are colliding
in one view.

[MeldaProduction]

Holy crap 50 instances? Well, there probably is some latency due to interthread locking and it's quite possible that with so many instances they are waiting too much on each other. I'll check, but I doubt we can get much better. We'll see.

[Batty]

Thanks Vojtech
Just in case...what would you suggest I should upgrade to help with the flow?

[Batty]

I mean hardware wise.
Nah it's not 50, hehe. 53 :p

[MeldaProduction]

I could avoid the synchronization, but next version will optimize by processing only those measurements that are actually visible at some instance at each moment. Seems helping a lot.

[DarkStar]

^^^^
Is that similar to / the same as 'Process hidden graphs' for the Timegraphs?