dhjdhjdhj

I'm trying again to switch from Max 5 to Max 7 now that I have no more need for [vst~] support in it. It's working pretty well except for the [coll] object which intermittently causes Max 7 to crash. Unfortunately I don't have a reproducible example but it happens sufficiently often that I just can't rely on it. Before I go write my own external, I'm wondering if anyone knows of a decent replacement that has similar capability.

I'm trying again to switch from Max 5 to Max 7 now that I have no more need for [vst~] support in it. It's working pretty well except for the [coll] object which intermittently causes Max 7  to crash. Unfortunately I don't have a reproducible example but it happens sufficiently often that I just can't rely on it. Before I go write my own external, I'm wondering if anyone knows of a decent replacement that has similar capability.
Thanks,
D


anyone-know-of-a-replacement-for-the-coll-object

I believe the dict system is intended as a replacement for coll

Ah, I knew of its existence but had never used it --- I see it has a pull_from_coll message, that's a good sign. I'll play with it.

Ah, I knew of its existence but had never used it --- I see it has a pull_from_coll message, that's a good sign.   I'll play with it.

OK --- from a quick review of dict related objects, it looks like it implements a basic hash table system. That's fine except hash tables generally don't have any concept of order (like you get with an array, for example). So there's no concept of "next". I guess that means that one has to wrap the dict in a new abstraction along with a counter and route to convert messages that [coll] accepts like 'next' or 'prev' into counter manipulation.

Not quite as seamless as I would have liked but hopefully it will be rock solid.

It would be very nice if you could specify a "txt" file as used by [coll] as an argument to a [dict] so that the [dict] could just pull the text file in directly and convert to the appropriate JSON representation. Bit of a nuisance to need to have a [coll] object already instantiated to use the pull_from_coll message, particularly if you have a lot of existing coll objects around.

as a person of habit, I normally use coll, and only use dict if I need to use a data structure more sophisticated than coll's, (rather than adapt existing coll functionality to a dict system) so I've never really been in your situation, but the lack of prev/next is a good point. I think the way to save/read with dict is to use the dict.serialize and deserialize objects-- maybe use the pull from coll technique once to reformat your data, then abandon coll completely and rely only on serialize/deserialize method-- hth

as a person of habit, I normally use coll, and only use dict if I need to use a data structure more sophisticated than coll's, (rather than adapt existing coll functionality to a dict system) so I've never really been in your situation, but the lack of prev/next is a good point.  I think the way to save/read with dict is to use the dict.serialize and deserialize objects-- maybe use the pull from coll technique once to reformat your data, then abandon coll completely and rely only on serialize/deserialize method-- hth


Uhm, well I would choose to just use the 'coll' is well but since its use is intermittently crashing Max 7 on me, I haven't much choice!

So, for anyone else who tries to do this, another caveat to be aware of. According to the documentation, when you request a value from a dictionary using the 'get someKey' message, you're supposed to just get the value back. However, in my experiments, I found that the key is produced as well. You have to use a [zl slice 1] to get rid of it.

So, for anyone else who tries to do this, another caveat to be aware of.  According to the documentation, when you request a value from a dictionary using the  'get someKey' message, you're supposed to just get the value back. However, in my experiments, I found that the key is produced as well. You have to use a [zl slice 1] to get rid of it.


And to get the values of several keys like 'get key1' and 'get key2' just use 'route key1 key2' on output.

Using [route] is impractical unless (a) you know ahead of time which keys you will want and (b) you only ever need a few keys and always the same ones. Hardly useful if you will be querying thousands of keys.

Anyone know of a replacement for the 'coll' object?