Em ter., 10 de fev. de 2026 às 20:53, Dan Wilcox <[email protected]> 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 <[email protected]> > 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 < > [email protected]> escreveu: > >> Em ter., 10 de fev. de 2026 às 15:13, Dan Wilcox <[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/ >> >>
--- [email protected] - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/[email protected]/message/WEB42WYQFAA23DY3I3JFGB2QLWUYHMDG/ To unsubscribe send an email to [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
