Aug 30, 2012 at 1:31pm
Hello everyone !
ive got strange feeling about the [coll] .
the strange thing about it is that :
i do have problem with it and cant find any useful alternative for such surprise .
im building “sampler with sample banks”
im using [coll]‘s to store huge amount of mixed data – its a sort of configuration file for my max patch . it also stores huge amount of paths to files on the disk (mainly WAVE AIFF files) to call them into a dynamically created buffers on the fly .This way im preparing some SAMPLE BANKS with dedicated settings (like individual tuning , start point loop etc) .
do u think is there a different solution for such scenario as mine ?
i cant use it :(
Aug 30, 2012 at 4:27pm
Yes, if you set coll to save its data in the with the patcher then that data is saved in the patcher file.
You can save the coll data as a separate text file. If that file is in your search path, then it will be read when the patch is started if you use the filename as an argument. [coll myFileName], for example.
You’ve been using the refer message? coll objects that are referring to the same name have the same memory pointer. They don’t copy any data.
Aug 30, 2012 at 5:31pm
Hi Mike !
thanks for your reply mate !
i wouldnt care about it all ,but its really getting BIG . im using [coll] to process that data in real time ,i need to have it in many places in the patcher, as u know it refers to the same file that keeps all the settings .
and cant see alternative
Aug 31, 2012 at 6:04am
you are right ; i never noticed that before… if you want to use “huge” database maybe SQL is a better choice ; i didn’t use it so i can not say nothing more ; have a look there :
Aug 31, 2012 at 8:37am
The source code for coll used to be distributed with the SDK. This is no longer the case, and it’s possible that coll might have been redisigned for Max5, although it is fairly likely that it’s using the same model. Which was:
Behind every coll there is an invisible xcoll object. Colls with the same name all use the same xcoll object, and the xcoll is where the data is stored. Still, each and every coll has its own data structure for maintaining stuff like the box position, color, patch cord connections, and anything else that is specific to the box.
However, my instinct doubts that this is really a lot of memory in RAM. How much memory are you seeing being used when you add multiple coll instances? Any at all?
Data storage is probably a bit different. When saving to disk, I’m not surprised if every coll instance writes the full complement of xcoll data into the file. You may have named colls in different patchers all referring to the same name, and the xcoll doesn’t “belong” to any of the patchers. So the coll objects can’t hope that “someone else” will write the xcoll data to the file. Each guy needs to look after it’s own needs.
Theoretically it might be possible to check if there is more than one coll of the same name, and suppress writing the content data to a file more than once. But that would require breaking the encapsulation principle that each object takes care of itself and the patcher doesn’t actually know what each object does internally. Plus, who cares if the file size is a couple of extra hundred kB? Sheez, why should anyone worry about a couple of hundred MB?. Data is cheap compared to the days when we thought a 50MB hard disk was large.
In short: what’s the problem? 10MB isn’t that big a patcher file.
Aug 31, 2012 at 11:45am
first of all . Even if i sounds like – im not complaining . This all is a sort of brainstorming i do everyday .
Hello Nicolas !!!
Hello Peter !
You are not surprised that the data storage acts different way ? .
ive been testing the situation where all the [coll]s where placed next to another . embeded into patcher .saved . multiplied the size .
But what do you mean by that xcoll doesnt belong to any of the other patchers ? do you mean other separate programs ? or patcher inside patcher ?
yeah SIZE . well ,i do care for many reasons .
much love guys !
You must be logged in to reply to this topic.