arne

This surprised me a bit when I tried to create a nested loop through a coll with non-successive indices.

- Create a named coll, give it some indexed data (1, one; 2, two; 3, three;)

- pass to the first coll the message [start, next]. It will send out the contents of its first index ("one").

- pass it another message, [next]. It will send out the contents of the second index ("two").

- pass to the SECOND coll a [start] message.

- pass to the FIRST coll a [next] message. It will send out the contents of the first index ("one"), rather than the third ("three").

Try this:
- Create a named coll, give it some indexed data (1, one; 2, two; 3, three;)
- Make a copy of it.
- pass to the first coll the message [start, next]. It will send out the contents of its first index ("one").
- pass it another message, [next]. It will send out the contents of the second index ("two").
- pass to the SECOND coll a [start] message.
- pass to the FIRST coll a [next] message. It will send out the contents of the first index ("one"), rather than the third ("three").

coll-bug-or-feature

In this case you are giving an instruction to the contents of that particular coll. I agree that this could be interpreted as a bug, but I'm not sure what c74 would say w/r/t colls sharing data and state.

If you want the behavior you've described, here's one way to do it:

Coll can be tricky.
In this case you are giving an instruction to the contents of that particular coll.  I agree that this could be interpreted as a bug, but I'm not sure what c74 would say w/r/t colls sharing data and state.

Even though I use colls a lot, I never ever use the refer or named coll feature. Like jml, if i'd really need it i'd create a copy. But most of the time I just use grab to get data from a coll, which also allows me to store all the data in one subpatcher.

Also, do note that the next/previous messages, for some unknown reason, do not run through a coll at the speed you would expect them to run through a LinkedList, but search for the correct index instead. Dump really is the only fast way to read a number of elements from a coll, so if you need more than a couple, do use that and filter them.

Coll had a major rewrite for Max 5, and is no longer the precarious beast it once was. I happily use it throughout my patchers, which can contain dozens, if not hundreds, of subpatchers.

But this is the sort of limitation to Max that makes me sigh. The lack of adequate data structures - ones in which you do not need to dump the contents of an array in order to access its (non-sequential) data in different places- needs to be addressed.

Coll had a major rewrite for Max 5, and is no longer the precarious beast it once was. I happily use it throughout my patchers, which can contain dozens, if not hundreds, of subpatchers. 

I think its neither bug nor feature, its a design flaw...

It bugs me since ages, that the messages to coll, like start/next/prev are not linked to the object, what I would expect (and the only way I believe makes sense), but to the data, which is the case (and mostly useless...). 

Its a bad design flaw we probably have to live with, unless we get an extra attribute (maybe "non dumb mode"?)...

In the end, the rewrite of the object for Max 5 didn't help, we still have to patch our own next commands...:-(

I think its neither bug nor feature, its a design flaw...
It bugs me since ages, that the messages to coll, like start/next/prev are not linked to the object, what I would expect (and the only way I believe makes sense), but to the data, which is the case (and mostly useless...). 
Its a bad design flaw we probably have to live with, unless we get an extra attribute (maybe "non dumb mode"?)...
In the end, the rewrite of the object for Max 5 didn't help, we still have to patch our own next commands...:-(

coll bug or feature?