bias

hi to all, i'm quite a max newby, so i'm really sorry if mine is a rtfm question, but i'm not able to find an univocal answer.

i'm creating a patch that converts amplitude levels to dmx values (after some manipulations such eq, interpolation time, scaling, etc...) to control a lighting structure. there are 16 "channel strips" wich analyze audio input and gives back 16 dmx values per 16 dmx channels.

for what concernes cpu load (not audio dsp, for general cpu usage), is it better to copy the same channel strip 16 times or to use 16 bpatchers containing the channel strip?

hi to all, i'm quite a max newby, so i'm really sorry if mine is a rtfm question, but i'm not able to find an univocal answer.
i'm creating a patch that converts amplitude levels to dmx values (after some manipulations such eq, interpolation time, scaling, etc...) to control a lighting structure. there are 16 "channel strips" wich analyze audio input and gives back 16 dmx values per 16 dmx channels.
for what concernes cpu load (not audio dsp, for general cpu usage), is it better to copy the same channel strip 16 times or to use 16 bpatchers containing the channel strip?
thanx for the patience.


bpatcher-and-cpu-load

it's months later, but i am under the strong impression that any bpatcher will significantly decrease your performances. So i'd advice avoiding them if you're concerned about cpu load, especially since there is little reason (or not at all) that they may increase performance.

The poor performance that multiple bpatchers gives is why I instead make a single UI bpatcher with multiple "backends". The user can switch out which back end instance the UI is mapped to using the pattr system (lots of "bindto" messages).

I suspect that the poor performance of using many bpatchers is that, even while hidden, the UI objects within them are performing "draw" calls. This has been a puzzle for me for a long time and it's really difficult to test. I've played around with the settings in the Preferences panel such as "Redraw Queue Throttle" and such, but never really had any tangible results.

If I get time I'll do try to devise some kind of performance tests for it, as this has been a big unknown for me too.

If one of the folks at Cycling could give an insight as to how the bpatcher drawing works it would be a big help ;)

I use bpatchers all the time, lots of them and have never noticed any performance problems apart from the time taken to load them. once loaded, there is no difference at all, and as with any other ui element, things are only drawn if visible on screen.

if you have any concrete examples of this not being the case then I'd send them off to c74 a this would not be expected behaviour

This could be completely true. I'd like to be able to quantify the responsiveness of the UI to user interaction in a repeatable test in Max. I can't think of a way to do this. Any ideas?

I just did a test to see if there was a difference in bpatcher performance vs non-bpatcher performance. It's safe to say there is definitely something to this. Note that I did two tests for each type, locked and unlocked, as Max performs differently in these states.

I duplicated the attached patch 64 times in a single patcher making an 8x8 grid, with all elements in view. It ran very stable, with about .6% of variance and no spikes.

I put the same patch into a bpatcher which I then duplicated to make 64 instances and arranged in an 8x8 formation, the same as before. This test ran with periods of far higher CPU usage.

- locked @ ~9.5% CPU for ~50% of the time, and 15-18% CPU for the rest

- unlocked @ ~10.5% CPU for ~10% of the time, and up to 15-18% CPU for the rest

I used Task Manager (Windows 8.1) to display the CPU usage of the Max environment (if someone can think of a better way to quantify this test it would be appreciated).

It would be great to see if others got a similar result.

Test 1 (non-bpatchers):
I duplicated the attached patch 64 times in a single patcher making an 8x8 grid, with all elements in view. It ran very stable, with about .6% of variance and no spikes.

 - Locked @ ~9.2% CPU all of the time
 - unlocked @ ~10% CPU all of the time

Test 2 (bpatchers):
I put the same patch into a bpatcher which I then duplicated to make 64 instances and arranged in an 8x8 formation, the same as before. This test ran with periods of far higher CPU usage.

 - locked @ ~9.5% CPU for ~50% of the time, and 15-18% CPU for the rest
 - unlocked @ ~10.5% CPU for ~10% of the time, and up to 15-18% CPU for the rest

But you're on max 6 as i see, i'm pretty sure there would be differences with the 7

i shall give the test a go a little later today

The Serial Tester :>
But you're on max 6 as i see, i'm pretty sure there would be differences with the 7
i shall give the test a go a little later today


in this months i decided to use the bpatcher solution, since the tests i made didn't show a very big difference between the two, so i preferred the most tidy in terms of workflow.

anyway i made the same test chris did, in this system (previously i forgot to specify):

result: quite the same (between 48% and 49%, stable, no spikes) using or not using bpatcher, with locked or unlocked patch.

maybe the cpu load is slightly bigger with the bpatchers (more often it goes over 49%, but is really impercettible...) and the "visual" response of the ui is slower.

hope we could answer definitely to this question.

mac book pro 13"
mac os x 10.9.5
max 7.0.1

hope we could answer definitely to this question.
bye


Keep in mind that this test is pretty loose. I'll work out something that can actually record the results inside Max for some real data.

so as it appears i might have less of a war machine than you guys.

mbp osx 10.10.2 - 2,66 GHz Intel Core i7 - 4 Go 1067 MHz DDR3

It also appears that... the results of that test are quite completely opposite to what i had expected !

Results vary little from one method to the other... plus apparently here embedded bpatchers are better. However i closed some apps between non-embedded and embedded series so yeah... not the scientific-est method you could say...

for now, i'm gonna conclude that my strong impression was just an impression, and that the slowing down i had observed came from somewhere else. But it is odd indeed, since when i removed bpatchers in a slow patch i had, everything did accelerate afterwards. So either there are some supplementary circumstances to take into account - bpatcher in presentation mode, for example ? or dsp on ? - or the slowing down occurs after a certain time the patch is open (i didn't run the tests for very long), or it was something else entirely. Who knows.

so as it appears i might have less of a war machine than you guys.
mbp osx 10.10.2 - 2,66 GHz Intel Core i7 - 4 Go 1067 MHz DDR3
max 7.0.2

* copy/paste *unlocked - overdrive on
187 - 194%locked - overdrive on
187 - 194%unlocked - overdrive off
89 - 91%locked - overdrive off
85 - 91%

* bpatchers *unlocked - overdrive on
186 - 190%locked - overdrive on
185 - 190%unlocked - overdrive off
83 - 86%locked - overdrive off
83 - 87%

* bpatchers embedded *unlocked - overdrive on
183 - 189%locked - overdrive on
184 - 188%unlocked - overdrive off
85 - 89%locked - overdrive off
82 - 87%

It also appears that... the results of that test are quite completely opposite to what i had expected !
Results vary little from one method to the other... plus apparently here embedded bpatchers are better. However i closed some apps between non-embedded and embedded series so yeah... not the scientific-est method you could say...
for now, i'm gonna conclude that my strong impression was just an impression, and that the slowing down i had observed came from somewhere else. But it is odd indeed, since when i removed bpatchers in a slow patch i had, everything did accelerate afterwards. So either there are some supplementary circumstances to take into account - bpatcher in presentation mode, for example ? or dsp on ? - or the slowing down occurs after a certain time the patch is open (i didn't run the tests for very long), or it was something else entirely. Who knows.


Great work on the tests Vichug. You're right it's not scientific, but it's also not really suggestive of bpatcher performing slower than non-bpatcher either.

Unfortunately there are so many possibilities and factors it's hard to tell what the issue is. But this is why I'm endeavoring to run repeatable tests for each aspect of Max that I'm curious about performance-wise.

Hopefully, bit by bit we can weed out the culprits :)

bpatcher and cpu load