Separate all modules into abstractions

[balintlaczko]

This will make the app make use of multicore processing. Another huge benefit will be for the devs, since changes in one module do not cause git merge conflicts with changes in another module.

[aleksati]

Using [poly] would be really nice! Not quite sure what you mean by separate all modules though. Could you explain a bit further what you have in mind here? And by modules, do you mean only the [p patchers] or more of them together, like more of the signal paths for each poly?

[balintlaczko]

Roughly speaking: all the stuff which are in subpatchers right now (mostly) in the top-level patcher. Or more funcionally, all the routines which in the end achieve 1 task, like returning the input matrix with noise filtering applied, or the extracted motion image based on a stream of matrices, etc.

[balintlaczko]

I checked the performance of the current patch, and it already seems to use all 4 of my cores equally, so I guess there is no need for the [poly~], I just make abstractions.

[aleksati]

Yeah, would it help CPU if we made externals from the modules?

[balintlaczko]

"They" say abstractions are more and more efficient as you have more and more instances of one in the same patch. If you have to copy a couple (or a few) instances it can still be OK to have them in plane [p ]-s. I always say as a thumb rule from 3 or 4 upwards, you should create an abstraction and use it. (And if it has to be much more but in the same place, then go for [poly~].) In our case what is important is to have multicore support - typically audio really likes to be single-core by default in Max, and the general "trick" to add multicore support is to wrap the separate modules of the process into [poly~]-s (even with just 1 voice inside the wrapper) and occasionally enable @parallel 1. As for now it seems like we don't have to do this for video, I see clearly that the patch already makes use of my 4 cores here nicely. BUT! Since git was not designed in languages like Max in mind, teamwork on Max projects can get really complicated because git cannot so intelligently distinguish between relevant and irrelevant changes in files (ie. if I select all boxes in the patch and move them 1 pixel to the left - it will look like an enormous change on git, but it is effectively nothing). So what we have figured out in other teams is that separating the patch into blocks (abstractions) is good not only for CPU reasons, but also because it separates the whole thing into several files, which makes teamwork (with git) a whole lot easier, because changes on parts of the program have much smaller "scope", so they cause much less merge conflicts - for example when someone works on part A while someone else makes a change on part B (or C, D, etc) at the same time. Everyone can just push their changes in different parts, pull, and then everyone has the exact same patch, without having to have "merging sessions" in person.

[balintlaczko]

Will be easy to do this after we merge everything we have - so let's do this after that.