efficient use of a RAM-heavy patcher
I'm being thick-headed tonight, hoping someone can lift the fog I'm in.
I've made a patcher with an inlet and outlet, and which does some processing inside of it. Call it "foo". Within foo, there are many (almost 70) different coll objects (each of which holds about 20k of data).
In my main patch, I end up needing to use foo in many different places - probably somewhere between 50-100 (I haven't counted). I currently simply make a new instance of foo each time I need it, and connect its inlet and outlet to the part of the patch where it's needed.
The net result is that my main patch ends up using a LOT of memory because of all these foo instances (Activity Monitor on Mac shows around 350MB), and my patch is pretty slow to start up (much slower than other Max patches I've made).
My question - how do I strip my main patch down to use one instance of foo, with sends/receives rather than hard-wiring it to everything, and have it direct its output only to the part of the patch that's called it each time? I hope that makes sense.
if i am not missing something obvious ... there are only two possible scenarios.
1.) your 250 instances of foo contain 70 colls with the same 70 20k of data.
in this case i dont undertand why instances of foo from #2 and above would require memory at all - or do instances of foo use #0 type of names for the colls? - or no name at all? (!)
or 2.) you actually have 250*70 colls of different content. in this case 350 mb of data will requrie 350 mb of RAM no matter what you do :)
have oyu thought about using a matrix or a audio buffer? my favorite "big data -database" is jit.matrix. (yes, i know, it is only cool for the storage of numbers; as soon as you have characters and strings it is probably no longer helpful.)
-110
Dan, I too like to duplicate code.
In the case you mention, I think I would use named colls (shared memory). Did you try this?
It sounds like the thing to do if your content needs to be the same in all instances.
(I would not use send/receive.)
J-F
Thanks Roman and Jean-François.
@Roman - it's more like scenario #1, but no use of #0 naming.
@Jean-François - they *are* currently named, but if they do in fact share the same memory space, I'm wondering why I'm consuming so much RAM? I'll have to do some more formal testing I guess - perhaps all that memory is coming from something else in my patch...
Also wondering whether using 'refer' to point the colls in foo to one single place elsewhere in my patch where the actual data is stored in a named coll might work better?
Interesting. Indeed, having the coll in the main patch, and only empty colls in the patchers sounds like a good idea. When the patch is loaded, give the "refer" message to all colls.
from my understanding a named coll should not exist twice in RAM.
having the coll in the main patch, and only empty colls in the patchers sounds like a good idea.
dont forgt that the subpatcher initializes first. ;)
Thanks guys, will do some testing to see how it goes!
I requested long ago, that the „save with patcher“ attribute should be attached to the coll instance and not to the name of the coll. David rejected that for an unknown reason. That means usually, If you have a subpatcher with all the colls saved, you need another one with that attribute unchecked. Then there is only one instance loaded and the others access it through the reference...
You have to be very careful, because if the instance with the saved colls is loaded, it will switch all refering colls to „save with patcher“. (Or vice versa which could be a desaster if you don’t have a backup) You must not save any version you want to keep free of data!
For me that behaviour is a design bug, but at least back then David thought it is a feature...
Thanks Stefan, I will definitely bear that in mind!