Max/MSP DSP Settings--Help or Advice?

  • I read the Cycling '74 help files on DSP settings, and I think I get the gist (sort of), but I was wondering if there were any basic guidelines to follow when adjusting the Max/MSP DSP settings for monome apps or is it just a question of fiddling with them until you hit the sweet spot for your particular setup?

    I/O Vector Size, Signal Vector Size, Overdrive, Interrupt Signal--this is a foreign language.

    Any advice on how to approach these settings for optimization or is it more of a feel-your-way-though kind of thing?

    EDIT: language

  • A bit of a 'feel-your-way-through' kind of thing only because everyone's computer is differently capable(CPU specs, RAM, etc.).

    Can't explain it any better than the doc page you read, but i'll try:
    I/O Vector Size - this is like the buffer size on a hardware/soundcard I/O setting. It's how many samples are calculated at a time when taken from soundcard input or sent to output.
    Bigger size decreases CPU hit because it doesn't have to crunch as frequently but will also increase latency.
    You mostly worry about I/O vector size when trying to decrease latency of live-input.

    Signal Vector Size - this is Max's internal vector size... in order to understand this fully, it helps to code externals in C or C++. In any MSP external, the main function which performs DSP(is called the 'perform routine'), grabs and delivers this many samples for processing at one time. Increasing this size again will reduce CPU hit(the perform routine will not have to grab/deliver samples as frequently). In addition, for some extremely heavy processing or high-sync situations, like FFT, you'll start to notice accumulated latency with a bigger size.
    You can read even more specifics about how these samples are processed by going to the SDK:
    click in the left panel on the heading labelled, "Anatomy of an MSP object" and go to the bottom of the page and read the last paragraph in the section "The DSP Method and Perform Routine".
    You mostly worry about signal-vector sizes when trying to streamline your CPU(sometimes to decrease latency of extensive processing like FFTs and such).

    I generally use I/O&Signal-Vector sizes anywhere between 32 and 256. Less and you're taxing your CPU... more and i really notice a huge amount of latency. Calculate latency like so:
    [Vector-Size divided by [Sample-Rate divided by 1000]]
    ....if you have a sample-rate of 48k, and vector size of 256, that's 48000samps-per-sec/1000ms-per-sec = 48 samples-per-ms; 256samps/48samps-per-ms = 5.333333333... milliseconds of latency.

    Overdrive - this is basically switching the scheduler into a higher-priority thread. The audio DSP thread which uses 'vector size' and 'perform routines' is always running in a high-priority thread, so this setting is like telling Max to run the scheduler at the same priority... i don't know much about threads, it might even be telling it to run in the same high-priority thread but i'm not sure of that... essentially, though, it's enough to understand this switches scheduler to be in a high-priority thread which simply increases the reliability of its timing(without this, certain functions, especially graphics, etc. can interrupt the scheduler and bog the timing down...).

    In Audio Interrupt - ('Overdrive' must be turned on for this to work because the Scheduler needs to be in high-priority for something requiring such a sample-accurate setting...)
    Setting this 'on' will cause Max to run the scheduler immediately before it calculates a vector-size worth of samples. You can imagine this increases tightness of timing because it hard-syncs the scheduler to the audio-thread allowing you to get reliable, almost audio-rate sync with the scheduler(this again is limited by vector size).

    Difference between 'Overdrive' and 'Audio Interrupt': Overdrive sets priority, AudioInterrupt sets scheduler-to-audio sync(and requires Overdrive to be on). If you only use 'overdrive', an object like metro(relies on scheduler), will bang with reliable timing, but it might not sync up perfectly to a specific sample without 'audio interrupt' also on(sidenote: and to achieve perfect sync even with AudioInterrupt on, you might want a vector size of 1, but that's too heavy on CPU for the entire Max environment, so instead you can run a specific part of your patch requiring hard sync within a poly~ object set to a vector size of 1, in other words, the poly~ object can help you streamline your patch so that different parts of it use different vector-sizes without taxing CPU unnecessarily throughout the entire app... there are many other great streamlining secrets which the poly~ object helps with ;).

    I generally leave 'Overdrive', 'Audio Interrupt' both on, and keep my vector size around 64(eventually, with faster computers, i'll probably move down to 32...)

    There is another place(MaxMSP->Preferences->Scheduler) which I never mess with nor mention to anyone else where you can customize the scheduler's behavior. I am only linking to this page so that you're aware of its existence but DO NOT change these settings unless you absolutely have to and absolutely know what you're doing(the wrong settings here can really slow down Max entirely):

    I'm just linking to it so that you're aware of it(it might help further understand what the scheduler does when it runs/polls each time).

  • @Str8: very helpful, thanks! There was more of a layman's (layperson's) explanation in what you wrote. Reading the official literature got me a bit bleary eyed. Part of the problem is I am running all my monome apps on a seven year old PC motherboard and processor (AMD Athlon 2700+) and have been looking for ways to optimize my system as best I can to keep it going longer. Running Max/MSP + monome apps is the most I ask of my processor these days so I don't feel like buying a new machine just for that. (In fact I just had all of the capacitors on my motherboard replaced so I hope it goes for another few years.)

    It only recently occurred to me to look up the DSP explanations. After fifteen months of monoming I had never peeked under the hood one bit. I'll keep fiddling with it until it all works better. I rarely use live audio input so latency is not much of an issue--yet!