Quick question about [coll] data...

Brian H.'s icon

Is there a way or technique to account for blank items in a [coll]? For example, if a line of data is banged out into [unpack] and then each outlet to it's own processing, it needs to see the same number of items in every line, right? Or is there a way around that, other than using a random 'placeholder' character and trying to weed it out correctly?

Thanks,
Brian

pdelges's icon

[pack ] will unpack lists longer or shorter than the number of its outputs. Just try.

But if the length of the list coming from [coll] is important, you could get it with [zl len] and route your datas to different processing.

Holland Hopson's icon

Another trick is to store data in pairs with its label. Something like:
0, data1 12 important_stuff 15 rarely_used_stuff 22;
Then you can split the list into pairs and use [route] to parse the data appropriately.

I've also been known to use send/receive names in conjunction with data in colls. That way you can split the list into pairs and send the data directly to its destination via [forward].

These attribute-like techniques make the order of data in the coll unimportant. But they don't necessarily help if you want to detect null data.

Luke Hall's icon

If you want to output something for an empty index in a [coll] then you can do something like the example below. Remove the [zl rot] if you make it into an abstraction as a [patcheragrs] in a [patcher] will always report the patcher name as the first argument. I hope it helps.

lh

Max Patch
Copy patch and select New From Clipboard in Max.

Brian H.'s icon

This is a great help, thanks!