I was also originally thinking more of a [dict] object which you could access via io and symbol name, like a text or array. Also possible to pass as a reference via some sort of pointer mechanism, however using a name would suffice and matches existing behavior for object-as-datastore.
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? It so, the it feels like we are reinventing JSON 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. enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com
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 < [email protected]> 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 <[email protected]> wrote:
>
> Am 10. Februar 2026 17:21:58 MEZ schrieb Alexandre Torres Porres <[email protected]>:
>> 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
> ---
> [email protected] - the Pure Data mailinglist
> https://lists.iem.at/hyperkitty/list/[email protected]/message/QRGLHRQDTYORJPNFFTMASFFPWDFOEYW5/
>
> To unsubscribe send an email to [email protected] mailing list
> UNSUBSCRIBE and account-management -> https://lists.iem.at/
>
---
[email protected] - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/WALVCVGZFLKWQW4OMWK662Y2T4OM5US7/
To unsubscribe send an email to [email protected] mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/
|
