Performance (Scheduler?) Spike in large sequencer style patch
Hi all,
I'm in the midst of designing a large scale multiple instrument based sequencer (that is mapped to an original musical controller), but I seem to be having a serious problem with a performance spike that occurs at the same point at every "loop" of the sequencer.
At the end of the current 'bar', the next bar's worth of information is loaded into the relevant grids/matrices (This includes: parameter automation grids, matrixctrls, itables). However at this specific point there is a 300-500ms hang while all of the relevant information is loaded. This is a serious issue as the hang/spike causes performance/recording/play back problems.
What is the most appropriate way to identify what is specifically causing the performance spike? I've never attempted de-bugging on my Max patches, could de-bugging help?
I've been looking through the forums, and I'm led to believe this could be a scheduler based problem, and could potentially be resolved by using a timer system based on a [phaser~] -> [Edge~] concept, however my scheduler doesn't appear to be going out of time, so I'm not sure whether this'll resolve my problem.
I'd post the patch but its close to 7mb now, and I get the impressive it'd be difficult for people to 'understand' what is happening where and why. I'd appreciate some general guidance or tips on improving performance, or debugging a large patch to resolve performance based issues.
Thanks in advance,
Ben K
More info:
Most of the individual systems within the patch are in seperate patches loaded into bpatchers.
LOTS of Sends and Receives are used.
Each instrument is a "VSTi"
Win 7 , Max 6.05
It may not be much, but seeing as I haven't included a code, here is a sample screenshot of the presentation view.
a 500 ms hang should not be a too many messages issue but some audio problem.
otherwise check your patch for what happens after the last beat (or before
the first), there must be some coding which is suboptimal.
i bet you do something like updating the states of all toggles after each loop or
something like that. (can you say "bug"?)
the functionality of this patch (except plug-ins but with audio on and overdrive on)
should run tight on any 100 MHz computer.
-110
The 'hang' makes everything within the patch come to a halt, and the problems the 'hang' cause are as follows:
Notes input on the first beat are often delayed, and placed into the wrong beat grid of the matrix.
Notes being played back from the matrix grid have to "catch up" with what was missed, causing a very 'non-musical' output.
Automation is stopped, then has to also "catch up" when the hang stops, once again causes a very unoptimal output.
I'm aware of what happens, and when, within the patch, but my question is what is the best way of approaching identifying what specifically is causing the problem? Is it a CPU hang? A GPU hang? A scheduler based hang? I've tried changing the priority of messages sent on that beat using defer and deferlow objects, but it doesn't seem to make a difference.
Overdrive and Interrupt is on, using ASIO drivers, my computer's power settings are at ultra high, but I'm still at a loss!
Thanks for your reply!
defer should normally not be required, except at points where you want to
come from the sequencer and go to some other place, which doesnt need
to be in time.
some strategies how to find out what it causes:
- try to remember what you changed before it occured the first time.
- upload the whole patch for others to see
- connect 16 bang buttons instead of the metro, then debug the patch by enabling the message tracing mode.
It seems unlikely that simple data loading would take 500 ms.
Are you perhaps reloading the VST instruments/presets?