Comments in [coll]

is there a way to put comments in a text file that is used by a [coll]? I’m having a patch where performance parameters are stored in huge colls (a quite frequent scenario, I guess) and it would be very, very helpful if I could add some small comments here and there that would be ignored by the [coll] operations and outlets.

Thanks for the reply. However, I’m looking for a solution where I don’t get the comments out of the [coll] outlets at all, for two reasons:

1) Independently of my actual problem, I’d like to know whether this feature exists, as I would find it a quite useful feature for anyone that has to deal with [coll]s.

2) In my particular case, since my [coll]s don’t have a fixed number of columns, and some of my algorithms processing the outputs will act depending the number of items contained in a row, it would take much more time to re-write the whole patch in a "comment-aware" way than to take notes in a separate text file (which I’m currently doing).

Wow! This tool, although in my current case I can’t benefit much of it, is really cool! I’ll keep the link for future reference :-)

I don’t know if there is an ‘official feature-suggesting’ forum (I guess there isn’t), but regarding comments in [coll]s, it shouldn’t be hard to implement. Since the data in the [coll] must be ended by a semicolon, and the identifier of each row is a single atom (either a symbol, a long or a float — so, no lists allowed anyway), I don’t see why the content after a semicolon but before the next identifier why couldn’t be treated as comment/whitespace… (Now the editor simply gives an error if I try to do that, so the internal code does even recognize that something’s at the wrong place — if instead of giving an error it would simply be ignored, then we could use that place to put comments…)

Wow! This tool, although in my current case I can’t benefit much of it, is really cool! I’ll keep the link for future reference :-)

I don’t know if there is an ‘official feature-suggesting’ forum (I guess there isn’t), but regarding comments in [coll]s, it shouldn’t be hard to implement. Since the data in the [coll] must be ended by a semicolon, and the identifier of each row is a single atom (either a symbol, a long or a float — so, no lists allowed anyway), I don’t see why the content after a semicolon but before the next identifier why couldn’t be treated as comment/whitespace… (Now the editor simply gives an error if I try to do that, so the internal code does even recognize that something’s at the wrong place — if instead of giving an error it would simply be ignored, then we could use that place to put comments…)

Could you not code something around [zl ecils 1] to always remove the last item at each [coll] index? It might take a bit of work for a few of the commands but for normal store and recall it should be fairly easy to implement.

Could you not code something around [zl ecils 1] to always remove the last item at each [coll] index? It might take a bit of work for a few of the commands but for normal store and recall it should be fairly easy to implement.

Here’s I think what you’re asking for. You can just add comments to any coll file after the end of line semicolon, or in its own line. The patch parses out the comments and then loads into a coll. A nice clean and reusable abstraction can be made from this with a little time…

Here’s I think what you’re asking for. You can just add comments to any coll file after the end of line semicolon, or in its own line. The patch parses out the comments and then loads into a coll. A nice clean and reusable abstraction can be made from this with a little time…

best,
Zachary

Attachments:

I’m wondering if the Cycling ’74 developers could add this simple behaviour to [coll] itself in a later release (maybe Max 6?), though. Theoretically I don’t see why this couldn’t be implemented, as it’s quite easy and it doesn’t cause any backwards-compatibility problem…

I’m wondering if the Cycling ’74 developers could add this simple behaviour to [coll] itself in a later release (maybe Max 6?), though. Theoretically I don’t see why this couldn’t be implemented, as it’s quite easy and it doesn’t cause any backwards-compatibility problem…