Question RE Simplicity vs Processing
Hi all, and sorry for the way I’m diving straight in with a question, I’ve been away from MaxMSP for 3 years and I’ve just bought Max 6 with a view to improving a project I did back at university, maybe to release.
I’m looking at the way I used abstractions before. Basically, I had 170 abstractions of an object, all having the same function but interacting with eachother. This meant that each abstraction needed its own ID (patcher argument), and this ID would then be used within the abstraction to calculate the names of 16 different wireless inputs and outputs. It got a bit complicated, and there were a lot of expr, if, sprintf etc objects and set messages being triggered by a loadbang. It took a long time to make this one object, but then when I came to reproduce that object 170 times it was very neat and I was not bogged down with a mass of interconnecting patch cords.
HOWEVER…
the patch runs slow. It takes around 50 seconds to open on my new i5 laptop, and there are often glitches in the audio. I suppose there’s two questions.
1) Do the initial calculations carried out on loadbang have any effect on performance once the patch is running?
2) Do wireless inputs/outputs cause extra CPU load compared to wired ones?
I know that my patch needs a lot of work. But I need to know how to start to improve the performance of my patch. I suppose the answer to the above questions will help. At the moment I can think of a few options:
1) Still use abstractions but with wired inputs and outputs, doing away with the send/receives and removing all calculations from the patch.
2) Still use abstractions, and send/receives, but instead of each patcher calculating the send/receive names, have 16 extra arguments for each of the 170 patches to reduce CPU usage.
3) Don’t use abstractions at all, try to combine everything into one patcher (baring in mind there will be 6,000+ objects in one patcher…)
4) Something I’m overlooking…
I’m more inclined towards option 1 at the moment. Anybody any thoughts?
Just been looking at this in more detail. The more I look, the more I realise how badly I designed this thing. There are a bunch of 170 png slider buttons being packed and stored in a table, then in each of the 170 patches mentioned above the values are extracted from the tables. If I just put the slider in with the patch in the first place there would be no need to pack it into a table. I must have been very blinkered at the time not to see that… blurgh… only reason I can think is for ease of preset manager. I do seem to remember having some issues with button overlay as the buttons were hexagonal, but hopefully Max 6 might have solved this isue, will find out soon I guess :)
Definitely get rid of the tables if you can, free up some memory. [pattr] is your friend. image files for the slider button might also slow things down, best to use native objects if you can. You might want some nicer-looking image files in the interface, just compare whether they have an effect on performance. I recall [jsui] would bog things down considerably when there were a lot of them, don’t know about your setup.
170 is a lot! :) but is totally doable, except if there are elements which are wasteful. It can be difficult to determine what these are though.
Without seeing the patch, it’s hard to give concrete advice, but other than load time, having a bunch of abstractions does not sound like inherently bad design. That said, with patter as a preset mechanism, presentation mode and the judicious use of bpatchers, you can probably clean up the code a fair amount.
Connections made with send/receive/forward are a _little_ more expensive than wired connections, but I wouldn’t look there first for optimizations.