Em ter., 10 de fev. de 2026 às 20:53, Dan Wilcox danomatika@gmail.com escreveu:
however using a name would suffice and matches existing behavior for object-as-datastore.
I think I agree
The complexity comes if you want to support nested data, ie. if we have "key" : "value" is value just an atom or list internally or can it also be an array or another dict?
I'm still getting acquainted with all this. Until the other day I never really had the need to use something like [coll]. But anyway, isn't the idea nesting a key feature for dictionaries?
A plain and flat key => value thing is already achievable with [text]. That's how I built my [messcoll] abstraction.
It so, the it feels like we are reinventing JSON
Yeah, and it's the idea in MAX, where dictionaries are claimed to be what JSON objects are, and the objects can read and write JSON files. So I guess it would come down to this particular feature, and with nesting of course.
and is this not applicable to extending data structures in some way?
For these kinds of things, I'd personally rather just wish for a core lua external as I feel things start to get away from the patching metaphor. In this case, I could script the objects behavior and the data store is contained within it.
Well, I did mention that in the beginning of this discussion. So yeah, supporting lua as a native scripting language would do the trick and also allow more things. Actually, our bhack project uses lua tables as dictionaries to do what BACH in MAX does with nested lists.
Not sure about loading and exporting JSON files, how easy that'd be. I never needed any of those. An object like did would, of course, be a nice high level option for less savvy users.
cheers
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Feb 10, 2026, at 11:02 PM, Alexandre Torres Porres porres@gmail.com wrote:
Now that I am thinking about it, I see that [text] is kinda like that. We don't have a "text" message type, and it is not exposed in the Pd ecosystem, right? In a sense, same for "arrays". MAX, in the same way, doesn't expose the data type and can use named objects to share data. It can output a pointer, but that is coded as regular symbol.
The ceammc approach adds complexity with new data types for nothing as I see it now. There are other ways to manage it. Now that I am going for an external that handles it, I'm totally not doing the same and will try to make something like MAX.
It now boils down to how we could add this to Vanilla and what it means in practice. It could also be just like in MAX and we could pass pointers as symbols... or is it a not too crazy idea do add a new data structure type and have pointers for it too? This is where I'm frying my brain now. It'd be an odd case out that we'd have a data type without having them exposed as data structures.
One way or another, this can be exposed in the API for externals, it has nothing to do with Pd data types on the patch level, right?
cheers
Em ter., 10 de fev. de 2026 às 16:48, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em ter., 10 de fev. de 2026 às 15:13, Dan Wilcox danomatika@gmail.com escreveu:
If we prefer to stick to simple, C-inspired syntax, I'd recommend looking at Lua's approach with its table data structure. There is beauty in the minimalism IMO. I am not really of the opinion that Pd should expand to naturally include every data type to solve every problem in everyone's own way. For specific problems, that's where an external or scripting interface comes in.
yeah, so, you think that if we could add these to Vanilla we'd need not to add more data types, huh? I also wonder what is the advantage for an external to create and deal with an extra data type. The might be some I guess but I have no idea and my intuition is that it's best to just treat these as Pd lists with some special syntax.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Feb 10, 2026, at 5:55 PM, IOhannes m zmölnig via Pd-list <
pd-list@lists.iem.at> wrote:
Am 10. Februar 2026 17:21:58 MEZ schrieb Alexandre Torres Porres <
porres@gmail.com>:
While we're at it, I'd like to mention the ceammc library, that can be installed in Vanilla (or you can use it as part of the Pd-Ceammc
fork) and
well yeah.
there's also "pdcontainer" (from about 2004) by Georg Holzmann, that
maps c++ std::containers (including dicts) to pd.
mfg.sfg.jfd IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QRGLHRQDTY...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing
list
UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/WALVCVGZFL...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
errata: An object like **dict *would, of course, be a nice high level option for less savvy users.
Em ter., 10 de fev. de 2026 às 21:45, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em ter., 10 de fev. de 2026 às 20:53, Dan Wilcox danomatika@gmail.com escreveu:
however using a name would suffice and matches existing behavior for object-as-datastore.
I think I agree
The complexity comes if you want to support nested data, ie. if we have "key" : "value" is value just an atom or list internally or can it also be an array or another dict?
I'm still getting acquainted with all this. Until the other day I never really had the need to use something like [coll]. But anyway, isn't the idea nesting a key feature for dictionaries?
A plain and flat key => value thing is already achievable with [text]. That's how I built my [messcoll] abstraction.
It so, the it feels like we are reinventing JSON
Yeah, and it's the idea in MAX, where dictionaries are claimed to be what JSON objects are, and the objects can read and write JSON files. So I guess it would come down to this particular feature, and with nesting of course.
and is this not applicable to extending data structures in some way?
For these kinds of things, I'd personally rather just wish for a core lua external as I feel things start to get away from the patching metaphor. In this case, I could script the objects behavior and the data store is contained within it.
Well, I did mention that in the beginning of this discussion. So yeah, supporting lua as a native scripting language would do the trick and also allow more things. Actually, our bhack project uses lua tables as dictionaries to do what BACH in MAX does with nested lists.
Not sure about loading and exporting JSON files, how easy that'd be. I never needed any of those. An object like did would, of course, be a nice high level option for less savvy users.
cheers
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Feb 10, 2026, at 11:02 PM, Alexandre Torres Porres porres@gmail.com wrote:
Now that I am thinking about it, I see that [text] is kinda like that. We don't have a "text" message type, and it is not exposed in the Pd ecosystem, right? In a sense, same for "arrays". MAX, in the same way, doesn't expose the data type and can use named objects to share data. It can output a pointer, but that is coded as regular symbol.
The ceammc approach adds complexity with new data types for nothing as I see it now. There are other ways to manage it. Now that I am going for an external that handles it, I'm totally not doing the same and will try to make something like MAX.
It now boils down to how we could add this to Vanilla and what it means in practice. It could also be just like in MAX and we could pass pointers as symbols... or is it a not too crazy idea do add a new data structure type and have pointers for it too? This is where I'm frying my brain now. It'd be an odd case out that we'd have a data type without having them exposed as data structures.
One way or another, this can be exposed in the API for externals, it has nothing to do with Pd data types on the patch level, right?
cheers
Em ter., 10 de fev. de 2026 às 16:48, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em ter., 10 de fev. de 2026 às 15:13, Dan Wilcox danomatika@gmail.com escreveu:
If we prefer to stick to simple, C-inspired syntax, I'd recommend looking at Lua's approach with its table data structure. There is beauty in the minimalism IMO. I am not really of the opinion that Pd should expand to naturally include every data type to solve every problem in everyone's own way. For specific problems, that's where an external or scripting interface comes in.
yeah, so, you think that if we could add these to Vanilla we'd need not to add more data types, huh? I also wonder what is the advantage for an external to create and deal with an extra data type. The might be some I guess but I have no idea and my intuition is that it's best to just treat these as Pd lists with some special syntax.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Feb 10, 2026, at 5:55 PM, IOhannes m zmölnig via Pd-list <
pd-list@lists.iem.at> wrote:
Am 10. Februar 2026 17:21:58 MEZ schrieb Alexandre Torres Porres <
porres@gmail.com>:
While we're at it, I'd like to mention the ceammc library, that can
be
installed in Vanilla (or you can use it as part of the Pd-Ceammc
fork) and
well yeah.
there's also "pdcontainer" (from about 2004) by Georg Holzmann, that
maps c++ std::containers (including dicts) to pd.
mfg.sfg.jfd IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QRGLHRQDTY...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing
list
UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/WALVCVGZFL...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Tl:dr: I’m not married to the idea of dictionaries, I just want to be able to deal with complex data structures dynamically, simply, and to/from the api. Hence the OP: if there is a way that [text] can do that (I know it is API supported although no example nor documentation) then I can try to get it to work. I’ll try Alexandre’s [messdict].
== 2c: I used to hate dicts, in Max, then in SC. Then I started to nest them. and that became incredibly powerful.
A few UX vignettes, if anyone is curious:
Example: you start a patch with states, you can make presets. Suddenly you can make preset of subpatches in their own dicts and recall them from a top dict. and the data is human readable. for growing projects, it is powerful.
another example: in flucoma, the neural nets are trained. you dump them as dict. Then in a workshop, people started to make presets of trainings, by nesting these complex dicts in dicts. I was flabbergasted. At the moment, there is no way to do that inside Pd… except saving the states on files (because flucoma supports that) and then reloading. a bit messy.
the last example: I wanted to do a leaky integrator of a multidimensional statful object. In Max and SC, I dump the state as a dict, mess programmatically with the dict, then load the new state in the object. A Pd user wanted to do that, and contacted me. they managed via [text] and temporary files, the hack works, but they are sad they cannot dump/load states like other users.
Em qua., 11 de fev. de 2026 às 07:56, Pierre Alexandre Tremblay < tremblap@gmail.com> escreveu:
I’ll try Alexandre’s [messdict].
it's called [messcoll] now, more related to [coll] as a dictionary, so no nesting. And no JSON parsing at all. If you think something like [coll] can help you, good, but I believe this is not what you need.
cheers