Robin Parmar

The help files are particularly opaque when it comes to nested dictionaries. The "hierarchy" tab shows only how to use sub-dicts if you explicitly know all the values to put in a simple message. But in any real application, this data is going to be compiled from different sources. For arrays of [dict] the help file only shows retrieval, not how to intelligently get data into the structure in the first place.

You can use [dict] in two ways: with or without field names. Without a name for each data field, you have a simple array with a top level key. Working with these is easy, but it's the same as using [coll], near as I can tell.

With named fields you have a structured JSON hierarchy. You also have a headache, since the docs abandon you to the elements.

So, how can I create nested dictionaries with named fields from arbitrary data? (Oh, and without Javascript.)

The following patcher should clarify the issue. It's likely only one or two objects away from working. 

The help files are particularly opaque when it comes to nested dictionaries. The "hierarchy" tab shows only how to use sub-dicts if you explicitly know all the values to put in a simple message. But in any real application, this data is going to be compiled from different sources. For arrays of [dict] the help file only shows retrieval, not  how to intelligently get data into the structure in the first place. 

You can use [dict] in two ways: with or without field names. Without a name for each data field, you have a simple array with a top level key. Working with these is easy, but it's the same  as using [coll], near as I can tell.

The following patcher should clarify the issue. It's likely only one or two objects away from working. 


dict-stored-as-a-field-of-another-dict

Here is a suboptimal solution that ignores [dict.pack]. Instead, each element of the sub-dict is created individually, using a rather brute force technique. This may be difficult to generalise, since [join] / [unjoin] need an explicit size.

I would prefer to be able to create one dictionary and then assign it to the other. That must be more elegant.

Here is a suboptimal solution that ignores [dict.pack]. Instead, each element of the sub-dict is created individually, using a rather brute force technique. This may be difficult to generalise, since [join] / [unjoin] need an explicit size. 

I would prefer to be able to create one dictionary and then assign it to the other. That must be more elegant.


This is strange. There is no way to set the name of a [dict] programmatically? It must be specified explicitly in the patch.

A message (name fruit) sent to the second [dict] sets the dictionary name. Sort of. It responds to messages as though it's [dict fruit].

But when I double-click on [dict] it's empty.

A message (name fruit) sent to the second [dict] sets the dictionary name. Sort of. It responds to messages as though it's [dict fruit]. 

But when I double-click on [dict] it's empty. 

I extended the "brute force method", as I called it above, and have my solution. Now that I can properly address an arbitrary named [dict], I was able to put the whole mess out of sight in an abstraction. If there was any interest, I might do a tutorial.

I was struggling with the exact same issue a few weeks ago. This is the best resource I've found.

But I think I ended up doing all the dict logic in javascript. :(

I was struggling with the exact same issue a few weeks ago. This is the best resource I've found.
http://x37v.com/x37v/max/dict-object/

But I think I ended up doing all the dict logic in javascript. :(


Robin Parmar - I would definetly like to see this tutorial or some kind of simple patch. Thanks

dict stored as a field of another dict