[max5] jit.cellblock read message disappeared?
It seems like jit.cellblock doesn't understand the "read" message anymore in Max 5. Is that right or am I doing something wrong? It isn't mentioned in the object specific changes in the documentation.
Does that mean that you have to refer jit.cellblock to a coll for writing and reading data from and to disk?
Jens
That is correct - the read and write messages are no longer supported
in jit.cellblock. Your solution (referring to a coll) is what I was
expecting people to use as an alternative.
[ddg]
Darwin Grosse
Hi Darwin,
thank you for your answer. Maybe this should be mentioned in the documentation.
BTW, all messages for "thispatcher" are missing in the reference manual. Also, "wclose" message isn't in the help patcher, so there is no clue that "wclose" exists. "dispose", which should also close the patcher window, deletes the subpatcher completely from the parent patcher. Is this what "dispose" should do? If not, "wclose" should be mentioned in the docs, I think.
Jens
An additional question on this change for saving/loading things thru the coll.
I have a jit.cellblock which adds/removes colls and rows on the fly. Most of the data in the jit.cellblock is not changed by hand, but by messages send to the object. The information stored is a mix of digits, strings and symbols.
My experience is that handling these kind of a things with a coll is very hard, and is very easily done by a jit.cellblock.
What should be the correct way to save the contents of this jit.cellblock with the help of a coll? Rows/colls added to the jit.cellblock aren't updated in the coll.
One other addon to this new jit.cellblock/coll relation, it is no longer possible to edit the first column of the jit.cellblock when it is refering to a coll: "set 0 0 33" will result in an error "cellblock: can't edit the index of a coll entry."
I can see why it is not possible and know there are workarounds for all these kind of things, but why was the behaviour changed in the first place?
First off, I've done a fallback on the read/write messages, so those work again. As for the unavailability to change the first column of a coll's data - if that ever worked, it shouldn't have (and was therefore a bug).
Thanks for putting back in the read/write messages. This also solves the problem of not being able to edit the first column of a jit.cellblock.