davidestevens

I could really do with some help with [dict], which I’m trying to use for the first time, and failing to get my head around.

I’m trying to set up a way of storing the grid settings in a live.grid, in a particular format where cells in a column that are on are stored as the number of the cell. (I'm taking each column list from live.grid - e.g. [column 1 1 0 0 1 0 1 0 0 0...] and turning that using various LObjects into [1, 1 4 6] )

So an e.g. of the set of columns might be

(I’m storing them like this for a reason! The pattern above represents a sequence of 16 chords. Originally each pattern I stored like this was monophonic, which meant that I could store each pattern on a single line of a "master" coll. When I wanted to recall a pattern I would just select the line I wanted in the "master" and then iterate that line into a temp coll from which I could read out the note in the pattern one at a time. The problem now is that I want to store polyphonic patterns, which means groups of notes rather than single notes. Stored in a single line in the "master" coll, there's no way of knowing where to break the output line (though I suppose I could add in a differentiating symbol when I compile the polyphonic list to show where to break the groups of integers. My theory is that this should be easier to manage in dict. Maybe? )

So, I can get them into a dict by pulling from the named coll, but only that one set of settings. Which looks like this

But I want to store lots of sets of patterns. I guess like this..

As I said above, in the past (when there was only 1 item for each column) I did this in coll.

But as the number of items in each column (“1” etc) is variable, I won’t know where to split the lists when I dump them out into a temp coll.

So the basic question is - how do I format the messages for dict, so that I can store as many separate sets of column patterns as I want? (so I can recall them by e.g. sending a [get ptnset1::] message to the dict.)

I could really do with some help with [dict], which I’m trying to use for the first time, and failing to get my head around.
I’m trying to set up a way of storing the grid settings in a live.grid, in a particular format where cells in a column that are on are stored as the number of the cell. (I'm taking each column list from live.grid - e.g. [column 1 1 0 0 1 0 1 0 0 0...] and turning that using various LObjects into [1, 1 4 6] )
So an e.g. of the set of columns might be
1, 1 4 6;
2, 3;
3, 1;
4, 3;
5, 1 4;
etc…
15, 1 7;
16, 3 6;
(I’m storing them like this for a reason! The pattern above represents a sequence of 16 chords. Originally each pattern I stored like this was monophonic, which meant that I could store each pattern on a single line of a "master" coll. When I wanted to recall a pattern I would just select the line I wanted in the "master" and then iterate that line into a temp coll from which I could read out the note in the pattern one at a time. The problem now is that I want to store polyphonic patterns, which means groups of notes rather than single notes. Stored in a single line in the "master" coll, there's no way of knowing where to break the output line (though I suppose I could add in a differentiating symbol when I compile the polyphonic list to show where  to break the groups of integers. My theory is that this should be easier to manage in dict. Maybe?  )
So, I can get them into a dict by pulling from the named coll, but only that one set of settings. Which looks like  this
{
“1”, [1, 4, 6]
“2”, [3]
“3”, [1] …etc
}
But I want to store lots of sets of patterns. I guess like this..

{
ptnset1 {
                “1”, [1, 4, 6]
                “2”, [3]
                 “3”, [1] …etc
              }
ptnset2 {
                “1”, [2,7]
                “2”, [3, 6]
                 “3”, [1, 3, 5] …etc
              }
etc
}

As I said above, in the past (when there was only 1 item for each column) I did this in coll.
(ptn)1, 1 3 1 4 5 1 3 1;
(ptn) 2, 1 2 1 5 1 6;

But as the number of items in each column (“1” etc) is variable,  I won’t know where to split the lists when I dump them out into a temp coll.

need-help-with-dict

Plgrm Visuals came up with a solution (on the FB group). The important bit (for me) was discovering that one has to stack dict.packs to get the hierarchy set up. And needing an extra dict to get the data back out into a coll.

If you want to store and recall presets, why not use [preset] or [pattrstorage]?

Because it's not a simple store and recall situation. I'm using the live.grid as an input device only, then transforming the grid from that into diatonic scale numbers (in sets of 1 to maybe 5 or 6). And those numbers are what are stored and then recalled, on the fly, to transform the input from an IR sensor from a CC (0.-1.) into a series of notes (0-7/14). If I was going to use either preset or pattr I'd have to dump out each transformed column from live.grid into [number]s (I guess) and then store them. Messy, and probably a lot slower than using coll, where I can store the whole pattern in one go.

Also, I've been kind of looking for a situation where it would make sense for me to use dict, and after considerable thought as to how I might implement this just using [coll], this seemed to be ripe for a dict based solution. It's certainly working very well! (a slightly further modified version of the patch I posted above).

Because it's not a simple store and recall situation. I'm using the live.grid as an input device only, then transforming the grid from that into diatonic scale numbers (in sets of 1 to maybe 5 or 6). And those numbers are what are stored and then recalled, on the fly, to transform the input from an IR sensor from a CC (0.-1.) into a series of notes (0-7/14). If I was going to use either preset or pattr I'd have to dump out each transformed column from live.grid into [number]s (I guess) and then store them. Messy, and probably a lot slower than using coll, where I can store the whole pattern in one go.
Also, I've been kind of looking for a situation where it would make sense for me to use dict, and after considerable thought as to how I might implement this just using [coll], this seemed to be ripe for a dict based solution. It's certainly working very well! (a slightly further modified version of the patch I posted above).


I asked, because I'm also interested in [dict] usage, to the point I took your patch and messed with it a little (eg. I replaced Lobjects with native objects, also this dict.pack thing seemed to me clumsy, etc etc). But in the end I found that what it does is simply basic functionality of live.grid. Maybe I'm overlooking some important aspect of your idea, but here you get:

@AK Thanks for that. i didn't know about vexpr - well, i knew it existed but have no experience of it, or idea how to use it. So that's a useful way of dealing with lists I didn't know about before.

And as you say, I _could do what I want just by using the first outlet of live.grid; no idea why I didn't think of that (I hardly ever use live.grid either, so maybe it's not so surprising it didn't occur to me :) ).

Still, at least I also learnt something about using dict.

@AK Thanks for that. i didn't know about vexpr - well, i knew it existed but have no experience of it, or idea how to use it. So that's a useful way of dealing with lists I didn't know about before.
And as you say, I _could do what I want just by using the first outlet of live.grid; no idea why I didn't think of that (I hardly ever use live.grid either, so maybe it's not so surprising it didn't occur to me :) ).
Still, at least I also learnt something about using dict.


@AK woah, cool find for [dict]. I didn't know you could set a key's value as a dictionary reference, and it would fill it with the referenced dictionary's contents, instead of literally having "dictionary u####" as its entry.

@AK woah, cool find for [dict]. I didn't know you could set a key's value as a dictionary reference, and it would fill it with the  referenced dictionary's contents, instead of literally having "dictionary u####" as its entry.


Need help with dict.