MischmeisterM

in a current patch i use a few jitter nodes and pwindows - everything runs fine in the max editor but whenever i close max and try to use the patch in ableton alone everything gets very sluggish. audio processing seems fine (no cutouts or clicks) but all the interface elements don't updated very often (even knobs and stuff from other non-max devices) and also the framerate in the pwindows drops out a lot.

cpu usage runs at about 20%
(ableton 9 with bundled max, win10)

m4l and jitter?
in a current patch i use a few jitter nodes and pwindows - everything runs fine in the max editor but whenever i close max a

live-interface-getting-really-slow-with-jitter

Without a patch, it is hard to answer something.

Max for Live runs patches with overdrive enabled, maybe it could help to test the patch in pure Max with overdrive enabled and see if some other clues appear.

Without a patch, it is hard to answer something.
Max for Live runs patches with overdrive enabled, maybe it could help to test the patch in pure Max with overdrive enabled and see if some other clues appear.

turning overdrive on or off in the max editor doesn't make a difference (everything runs fine in the editor)

the patch is more or less just a chain of jit.ops and submatrices, it's far from optimized but cpu is at 5% and gpu at 20% while running (inside editor as well as closed editor)

(i feed that into a pfft~ in the end for sound generation which i have ommited in the copied patch, the problem persists without it)

the patch is more or less just a chain of jit.ops and submatrices, it's far from optimized but cpu is at 5% and gpu at 20% while running (inside editor as well as closed editor)
(i feed that into a pfft~ in the end for sound generation which i have ommited in the copied patch, the problem persists without it)

I would try to optimize the jitter processing, I don't think it's about the audio here.

Quick things coming to mind, while keeping the bulk of your patch:

- don't use 2 [jit.brcosa] but just one, adjusting contrast and brightness!

- jit.op @op !- @val 255. You might get rid of that, using a negative contrast value upstream?

- when you use your [switch] objects, you are processing stuff twice, and using just one thing. Instead, try [gate 2] and process stuff either on the output 1 or the output 2.

- there might be a way to play clever with the parameters of your 'squelch / auto-squelch', thus using just one jit.op.

- phasor 1, snapshot 40? Why not refresh with your main qmetro?

- see if you can get rid of some of your jit.matrix objects that imply matrix copy and sometimes change of dim.

I would try to optimize the jitter processing, I don't think it's about the audio here.
Quick things coming to mind, while keeping the bulk of your patch:
- don't use 2 [jit.brcosa] but just one, adjusting contrast and brightness!
- jit.op @op !- @val 255. You might get rid of that, using a negative contrast value upstream?
- when you use your [switch] objects, you are processing stuff twice, and using just one thing. Instead, try [gate 2] and process stuff either on the output 1 or the output 2.
- there might be a way to play clever with the parameters of your 'squelch / auto-squelch', thus using just one jit.op.
- phasor 1, snapshot 40? Why not refresh with your main qmetro?
- see if you can get rid of some of your jit.matrix objects that imply matrix copy and sometimes change of dim.

thanks for the really helpful pointers, i'm not really experienced with jitter (yet)

it's a viable workaround for now, for the current project having max open while operating the patch also works - i still wonder though how i could get around ableton obviosly not allocating enough ressources for max patches

live interface getting really slow with jitter