coll bug or feature?

    Oct 13 2009 | 6:15 am
    This surprised me a bit when I tried to create a nested loop through a coll with non-successive indices.
    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").
    No surprise?

    • Oct 13 2009 | 8:38 pm
      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.
      If you want the behavior you've described, here's one way to do it:
    • Oct 14 2009 | 10:28 am
      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.
    • Oct 14 2009 | 11:25 pm
      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.
      Time to look at FTM, again...
    • Oct 27 2009 | 9:25 am
      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...:-(