CarpentersKeys

I've been trolling these forums pretty hard the last few days trying to implement any possible solutions to my problems but I think I've got to the point where I need to state my case directly.

I've made a 4track sampler with 2d.wave~ and some gen~/vb effects  in each instance.

90% of the time the little clicks and pops etc max produces don't bother me in the least but recently now that I'm pushing my DSP more and more I'm finding breaks in my track dedicated to percussion. This really kills the track if the kick transient isn't clean.

I've encapsulated all 4 tracks in to a poly~ and am running with threadcount 0 and parallel processing and I've made my patch as efficient as is probably possible with my current knowledge but I'm still getting these clicks.

I know it's possible to prioritize messages but I can't tell if there's any way to prioritize DSP, if I could do that I think the percs would be safe from harm.

Any other advice would be helpful as well.

patching-effiecency-and-clipping-reduction

I’ve been trolling these forums pretty hard the last few days

I'm not sure that's the term you're looking for... :D

I can’t tell if there’s any way to prioritize DSP

Just in case you don't already know... Options -> Overdrive prioritizes audio. You can also modify the signal vector length to improve performance. Options -> Audio Status...

I’ve been trolling these forums pretty hard the last few days 

 I can’t tell if there’s any way to prioritize DSP

Just in case you don't already know...  Options -> Overdrive prioritizes audio.   You can also modify the signal vector length to improve performance.  Options -> Audio Status...


And besides general DSP settings advice (does increasing latency help? what sample rate are you running?) we can't say very much without seeing your patch. What hardware are you running it on?

I was under the impression that ocverdrive mode prioritized the message thread involved with executing timing and midi.

Poll Throttle sets the number of events processed per servicing of the scheduler's high priority event queue (High priority events include MIDI, events generated by metro, tempo, line, delay, pipe, snapshot~, and other scheduler based objects). A lower setting (e.g. 1) means less event clumping, while a higher value (e.g. 100) will result in less of an event backlog. The default value is 20 events.

https://cycling74.com/docs/max5/vignettes/core/scheduler_pane.html

You can also modify the signal vector length to improve performance.

Can you explain or point me to a resource that thoroughly explains how signal vector length impacts things, I've heard some advice here and there about increasing the length in some circumstances or decreasing elsewhere but until I can comprehend it fundamentally I'm not going to be able to know which advice to apply.

does increasing latency help? what sample rate are you running?

I haven't played with latency, I'm at 44100, will probably change to 48000 as my patch gets tighter.

we can’t say very much without seeing your patch. What hardware are you running it on?

I'm afraid my patch will seem somewhat idiosynchratic and there's a lot of stuff going on from start to finish (max is my only app for my liveset) but I'll post it for you to look over.

it's getting slugish, admittedly but I was hoping to ignore that fact and just get the patch to be so efficient it won't matter.

This is my track patch so there are 4 instances of this running. I couldn't post the whole project for some reason so let me know if there's any obvious spots where this is eating processing power.

Aside from this there's a bank of midi in/processing things for my three controllers as well as a data sequencing patch (after the midi is processed) for each track that is under construction, it'll work relative to the global transport. Also I load all my samples (4xhowever many tracks I'm playing, in a 45 minute set something like 7, the loops are usually around 60000 ms) along with cycles of phasor at the loadup and these sit in a polybuffer~ somewhere just waiting to be referenced so I don't have to load mid set.

I was under the impression that ocverdrive mode prioritized the message thread involved with executing timing and  midi.

 Poll Throttle sets the number of events processed per servicing of the scheduler's high priority event queue (High priority events include MIDI, events generated by metro, tempo, line, delay, pipe, snapshot~, and other scheduler based objects). A lower setting (e.g. 1) means less event clumping, while a higher value (e.g. 100) will result in less of an event backlog. The default value is 20 events. 

- https://cycling74.com/docs/max5/vignettes/core/scheduler_pane.html

 You can also modify the signal vector length to improve performance. 

 does increasing latency help? what sample rate are you running? 

 we can’t say very much without seeing your patch. What hardware are you running it on? 

  Processor Name:	Intel Core 2 Duo
  Processor Speed:	2.4 GHz
  Number Of Processors:	1
  Total Number Of Cores:	2
  L2 Cache:	3 MB
  Memory:	4 GB
  Bus Speed:	1.07 GHz

I feel you're optimization pains. My MBP's an oldy core2duo 2.33GHz. Got the fast desktop but that 's not always handy...

I had a look there. First off I don't know the stretch externals so perhaps they're too heavy on your CPU.

You definitely should set overdrive to on. Audio and midi timing will get priority over GUI drawing. Do not activate 'in audio interrupt'.

There's a couple of places where you cross from the signal to the message domain (peakamp~, number~). Check their output rates. The shorter their update interval the heavier on your system.

Increase I/O and signal vector size. Those set the sample size of audio chunks that Max will process at a time.

You definitely should set overdrive to on. Audio and midi timing will get priority over GUI drawing. Do not activate 'in audio interrupt'. 

Increase I/O and signal vector size. Those set the sample size of audio chunks that Max will process at a time.


How fast are you polling the LED colls? Too fast might be clogging things.

I think that might be an old one, I recently encapsulated the peakamps and [poly~ down 8]'d them to help with that.

As it stands the LED situation could be part of it, I'm working on that, I want to poll every quarter or 16th note, is that reasonable? the LEDs display sample position so it's kind of important to be current. I don't have any GUI on my computer so the LEDs are my only feedback.

PS @DTR will the vector size and I/O have any effect on the gen~ environment? It shouldn't right? Gen whole thing is handling everything sample by sample.

Colls on 1/4-16th should be fine. Not sure about gen~ and vector size. My hunch is that it's still interlinked somehow. They're part of the same audio chain, right?

Btw, you might see big improvements from running it in Max Runtime or exporting to an app/exe. Can 't edit though but that's likely fine for performance situations. I do this a lot too.

That's brilliant! I hadn't thought about using runtime or making it in to a standalone.

Thanks for the feedback, very helpful ^_ ^

Patching effiecency and clipping reduction