Gen~ Data object storage
I'm trying to figure out how the data object handles its storage, and I wasn't able to find answers to my questions in the forums or documentation. You don't seem to be able to save a copy of what's in it to disk and recall it later. The second you stop sending it an index and a value, it clears its contents of all other values, correct? This would be unfortunate if this was true, because one thing I want to use it for is to free up computing resources by saving results of computations, and just looking those up, instead of having to compute them every time. But if I have to do the computation just to keep the data in there, that kind of defeats the purpose.. This is at least what I observed. Is this the intended functionality, or am I doing something wrong?
Clarification: As I was working on an example patch, I realized the problem has to do with altering the INSIDE of the gen patcher. If this is done, the data object is completely cleared. You can alter anything in the signal path OUTSIDE of the gen patcher, and it recalls its values just fine. You can even delete the gen patcher itself and undo the deletion it and it will still recall the values. This is more workable, although I am still curious as to why the data object must be cleared upon editing the gen patch. Is this a bug?
On a somewhat related note, in my example patch, the number~ box will only represent fractional numbers up to 6 decimal places, even when I change the "Number of Decimal Places" field in the inspector to 9. What is going on with this world?
I would assume it has to do with the fact that the Gen patch is recompiled whenever you edit it.
A logical assumption. Still, what would be the danger in NOT clearing the data object on recompilation?
yeah, this is a recompilation thing i guess. with 'auto-compile' switched off, it does not happen of course. the gen~ patch is an object, and changes mean recompilation, so after a change, it is effectively a new object. the data exists in the object and is 64-bit if using the [data] object. however, if reading an external msp buffer into a gen~ [data] or [buffer] object, this is correctly replaced inside gen~ after a recompile (this used to be a bug that it did not, but now it all works). most probably a pointer to it is held in memory and then reinstantiated. i guess it is because your data exists only inside the specific gen~ namespace that it resets (clears) itself on recompile.
regarding decimal places in max/msp land - max is a 32-bit application and thus can only display up to 6 points of accuracy. i agree that it is funny that this means that it cannot display correctly from the 64-bit gen~ world. i guess global 64-bit max is around the corner at some point...
p.s. - these are all opinions, not knowledge. i could be wrong and hope that someone more knowledgable jumps in
Hi there,
Yes, gen~ currently does all processing all the time, so there's no real way to cache computations as such. However, there's a pretty nice feature coming soon that will allow conditional processing, which will help a lot in these situations.
And yes, since data is local to the gen~ patcher, unlike buffer~ which is global to the containing Max patcher, it gets cleared each time the patcher is recompiled (i.e. at each edit, if auto-compile is on). I admit it would be nice if this could be preserved between edits. It has been logged as a feature request (#2963), however at such a point that buffer~ stores its data in 64 bits of depth, this won't be as much of an issue I guess...
Graham
Well, this was 4 years ago, and somewhat surprise no one has said thank you codebox fixed it :)
Data local(10);
History flag;
if(flag==0){
local.poke(2,9);
flag=1;
}
out1 = in1 + local.peek(9);
Doesn't need conditional compilation. It runs once at initializing. When recompiling, history loses its value, so the data is poked once again. Thanks Graham.