coll bug or feature?
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;)
- 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").
----------begin_max5_patcher---------- 517.3oc6VssSiCCD84juBq7bnxNMAZ3CgWPnJ2jAvPhcUrSorH92WeKgTHkF gZWVI3gZ4LiG6yblwm5WBChVI1BxHzknqQAAuDFDXMYLD3+NHpltsnhJsKKp FjR5cPTryGuslwq.k0YxaFEspNqDu00TUw8L9cKafBk6HIo3Y3XTdlYLyNmr XFFciODVo8LEqd3rj4cG4sBthSqAqqqflRJm14ycrpmWCtCHJpeuLgIY+w5f PlgMVeMLzLD+cj6YSO0S9uK0UvVaZDIUzF0QpYXtkKla4h4m+YLBI+6mQ3vS Zn7ABoPTUgTfbbRgLJojdPR4bWaR9rrXTBdOsI3uFoDO32dIHuYc1IZ7HyfH WeqenOXCGrrjpnd5yyeFGsbahkE6szspqsqqekZOOBOOfwLV1PqZ6Psfqmci 2kqnMZ3IiGt5IwjBOc7vuUz1Lo3uX73kvFfOoMff2SBra79o5MxUAjzMP4Rc WgtQZIUoZXqZUNg9g0CndEXafH9vOhJCbyjihvvhg5BYeptvheDJkoSVnLG+ SQnLcx5j4je0I+Um7noSZqlQUL96eGssI0Xe26FRMmTzWd7+uM5slhR8UBFm pXB9vEoe9Khzun6Ykkf0eWGWMqbsfwUdP3RzObScpXxbG4vXJ4eJlLO56vXZ Wx7jioES.SuiLO40N7oFS5OdM7u.3U7DOA -----------end_max5_patcher-----------
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:
----------begin_max5_patcher---------- 872.3oc6Y9zTiBCFF+L8SQFNWcHoPA1a6Wh8hiSm.Dq3BILPpZ0wu6a9CfnR qzTJKG7fosgDxC+xadxavWWXYGwdlTYC9E3Ffk0qKrrTUIqvp92V143miyvU plYSIOwhdvdo9RbxybU0krcbBnZedDKq4h2wn7pzWHxF.ct1ot5BLO99T51M kjXtdngqVKtLHvUVtNPVBEkfaq6BcWdJMivUR.9dkhAsoVTcsoIJ8Hz3UPTW kPw4JkX+6xTbqF02A99BhVI11KE+AtUd02VrPVr77HCGDApLFIPn5Cufq8FG l.MfIQX5Vy4RNopBuk7EvnCV.LJoW5.OJcVqBUPdHUbC73QLndoCrG53zKc9 CoLASwGNlocXKJIUDJGySYztxUqPjuJz1otXboIGWxOcPhbUpAtRAx5XtyGj gWFNhb0yzqbtXbjJ+xoiw.MF0wiq7FIL5ZJFGO6qWx.OvRolaf4oMvBMAI8X fELG7zEPojr0bln+vrvjdXh+bfIhkrEDZBnhyJIliFe0G9HSxAnmUPqMAMiI VhYYYfXVwdNohCtBd5jA4n2qCpXhuQYG49Ux3YZPyx1fm5lUgejjrQbOERdC lyKSiDICVUypZXYYSxiHpg2QUgBumJjE2XNq0LpGX0r.SwJjSS4YFEgNdpQW hzhpHORZePyRojX1NJuqAvv2cRCk5.HcpHqfm8lSHzDt6zgnUI4NRIPt1ZIH YWdgAoRpsg0oT.cFsTIC++u2sz6wDmXEPV6UeXLuQwtA4LZ9MxGqMIXN9yNL sKQ7VVWSSqtQ0t1VJtxeI66neYMOhy10LvxCknmIrZlG5s6n96N+I1f5ta+c +N1txA0e+96u16XH2.nyAd.9X+q+p3FYliOzbG+wMO8fNq0GsrzgAy.iPSO+ mdKxfw8zeNyCuO09BmtAnaG+Ow4VFG+uP3O9e+3+8d3sZ1TkX2md8qp.RY8e LluRvj31oG8Ia.uGTlHhzSop2WRm138g1beZRBQc4lf+7zjBwg640R3.q+Fp hbmcJJb1oHuAnH4agD.mLIIekvcFt90TvzKouCS9S5Dm7elv2OyAmdMAmWZR lm+2yIzjpofAHo0Sph7GfhBl94M3.VxMgt.Cw99SwaW7cTFhyDBMsbZHw2gS qMPnyLTSCZt6Ljj3Gus3eT3N.bM -----------end_max5_patcher-----------
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.
Time to look at FTM, again…
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…:-(
Forums > MaxMSP