{"id":490,"date":"2015-05-18T09:48:14","date_gmt":"2015-05-17T23:48:14","guid":{"rendered":"http:\/\/x37v.com\/x37v\/?p=490"},"modified":"2022-02-02T20:04:07","modified_gmt":"2022-02-02T09:04:07","slug":"dict-object","status":"publish","type":"post","link":"https:\/\/x37v.com\/x37v\/max\/dict-object\/","title":{"rendered":"Structuring JSON data with the [dict] object in Max"},"content":{"rendered":"\n
\n
{\n\t\"perceivedComplexity\": \"beastly\",\n\t\"actualComplexity\": \"manageable\",\n}<\/code><\/pre>\n\n\n\n
Working with setting and getting content from dictionaries<\/em> in Max seems straightforward enough, but trying to group data into well-structured form can be a little tricky.<\/p>\n<\/div><\/div>\n\n\n\n
Structured Data<\/h4>\n\n\n\n
Recently I had a need to create a way to store some fairly complex data in Max. I wanted to map out and find similarities in a bunch of audio files. I’m not a computer scientist or a real programmer, so I had no idea how I should do this or how I should store this information in a manageable way. [As it turns out, I needed to create a hash table<\/a><\/em>.]<\/p>\n\n\n\n
Traditionally, the coll<\/code> object was the go-to<\/em> object to do this kind of stuff (and still is to an extent). It’s a simple way to store a list of values at a numerical (or symbolic) index<\/em>.<\/p>\n\n\n\n
\n
1, 100 72 64 forward 7.43 delay 85 0;\n2, 60 160 62 forward 5.0 bypass 51 1;\n3, 82 10 114 backward 0.2 delay 15 1;\n4, 155 97 98 backward 8.2 delay 99 0;<\/code><\/pre>\n\n\n\n
Send the coll<\/code> object a 2<\/code>, and the corresponding data (60 160 62 forward 5.0 bypass 51 1<\/code>) will come out the first outlet.<\/p>\n<\/div><\/div>\n\n\n\n
When trying to encode lots of data though, a more descriptive index<\/em> would be more helpful.<\/p>\n\n\n\n
While coll<\/code> supports indexes that are symbols, I was keen to use something that allowed me to look up or retrieve particular ‘atoms’ of the information I was storing. With coll<\/code>, if you request the data stored at an index, you retrieve all<\/em> the data stored at that index. As coll<\/code> data is stored as a list of values, the order of the data stored at that index is important, and it can be a little difficult to see what each value represents. Furthermore, as I was interested in storing and retrieving data based on some kind of shared similarity (ie. separate arrays of data that should be grouped under the same ‘index’) I wanted to store it in a more descriptive and extensible way. What I needed was something like an associative array<\/a>.<\/p>\n\n\n\n
Associative arrays store every piece of information as key<\/em> and value<\/em> pairs. This data structure goes by many differing names (dictionaries, hashes, maps, symbol tables, hash tables, collections). In the JavaScript world these kinds data storage structures are referred to as objects<\/a>. I’ll refer to them as objects<\/em> for the time being. (Just to confuse things more, key-value<\/em> pairs are also sometimes termed name-value<\/em> pairs, index-value<\/em> pairs, and attribute-value pairs<\/a><\/em>.)<\/p>\n\n\n\n
The key<\/em> would describe the bit of information I was interested in storing, and the value<\/em> would be the number\/setting\/value representing that information.<\/p>\n\n\n\n
Essentially, objects<\/em> represent structured data like this:<\/p>\n\n\n\n
\n
\n
\n
\n
{\n\t\"name\": \"Alex\",\n\t\"sex\": \"male\",\n\t\"age\": 35,\n\t\"coffee\": \"espresso\",\n\t\"coffeeTimes\": [7, 9, 11, 16]\n}<\/code><\/pre>\n\n\n\n
An example of object notation<\/em>.<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div><\/div>\n\n\n\n
key<\/em>s sit on the left, value<\/em>s on the right. There’s a colon after each key<\/em>, and a comma after the first to the penultimate key-value<\/em> pair. key<\/em>s are strings, and all strings are surrounded by quotes (eg. \"coffee\"<\/code> or \"espresso\"<\/code>), and arrays are a list of comma separated values in square brackets (eg. [7, 8, 11, 16]<\/code>).<\/p>\n\n\n\n
The cool thing about object notation<\/em> is that values can be strings, numbers, lists\/arrays, or even objects themselves<\/em>. Even better is that you can insert a new key-value<\/em> pair at any point within your object and it won’t break anything, because you retrieve value<\/em>s by their key<\/em> (in contrast to coll<\/code> where you’d have to keep track of where the data value you were storing was in the array of values stored at that index).<\/p>\n\n\n\n
Combined with arrays, objects are very flexible ways to store and format data. Scott Murray’s D3 Tutorial chapter on Data Types<\/a> illustrates the power of objects and arrays really well: “You can combine these two structures to create arrays of objects, or objects of arrays, or objects of objects or, well, basically whatever structure makes sense for your data set.”<\/q><\/p>\n\n\n\n
What do ‘arrays of objects’, ‘objects of arrays’, and ‘objects of objects’ mean?<\/h4>\n\n\n\n
Well, many things. If an array<\/em> is a list of items, and an object<\/em> is a collection of named properties grouped together. You could combine them in ways to:<\/p>\n\n\n\n