[bug?] coll & jit.cellblock

Jul 15, 2010 at 1:01pm

[bug?] coll & jit.cellblock

Hi,

as nobody replied to my old post about this topic (http://cycling74.com/forums/topic.php?id=23305), let’s try again but this time with Max5.1.4 under X.6.4

The following patch explains the procedure… Can somebody confirm this bug?

– Pasted Max Patch, click to expand. –
#51369
Jul 16, 2010 at 12:42am

yes I can reproduce
mac os 10.4.11
max 5.1.4

#184180
Feb 15, 2011 at 5:38am

First of all, I’m sorry for the delay in responding. I’ve been focused on other things, and have not been keeping up with the forum as much as I’d like.

The two issues that you are showing in this example patch are part of a fundamental problem with a jit.cellblock that is tied to a coll: the difficulty in maintaining structural integrity of a coll when the user interface isn’t an exact match.

So, for example, in the first instance (typing 666 into cell 0/3), you are adding content to the colls row content. This changes the cellblock’s understanding of the “structure” of the coll, and it reacts by removing the row (similar to the “remove” message to a coll) then adds it again, which places it at the end.

Secondly, the reason that the 666 moves into the second position is that cellblock (correctly) identified there to be an empty cell – but there is no such thing as an empty value in a coll. So cellblock gets rid of the empty cell and provides coll with a row that it can deal with.

The connection between jit.cellblock and coll is imperfect – especially when using inline edit mode. If you need to have a more robust data storage/management solution, you either need to use something other than jit.cellblock, or something other than coll.

[ddg]

#184181
Feb 15, 2011 at 10:18am

To address the first problem, you could use the message (sort -1 1 ) to the coll after step 2.
To address the second problem you could fill empty spaces with a placeholder, (like •, option-8 on the mac), so your coll looks like this:

1, 1 • 666;
2, 2 3 4;
3, 3 4 5;
This could be automated somehow…
boring and inelegant, but possibly a workaround

T

#184182
Feb 15, 2011 at 11:17am

The connection between jit.cellblock and coll is imperfect – especially when using inline edit mode. If you need to have a more robust data storage/management solution, you either need to use something other than jit.cellblock, or something other than coll.

Darwin, thanks for your honesty. As you proposed, I stopped using jit.cellblock with coll the very same day I discovered this bug (or let’s call it imperfection).

@Terry: sort does work for the example I gave, but is not a viable abstract workaround. And the • idea (I used a more discrete char when I tried – btw, on my kb • is option-. :-) is, as you said, boring and inelegant.

p

#184183

You must be logged in to reply to this topic.