Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
Hi, I have recently included into ELSE (though it is not part of any release yet) a [dictionary] object that is a very simple external based on vanilla's [text] (hence, it's an abstraction). It works more like a simplified Max [coll]: address/key lookup returning stored data. It’s not a hierarchical JSON-style structure, but it might cover part of the associative key–value use case. Curious what specific features you need on the C side and I am also interested in this whole topic.
I am still using some objects from ELSE into this abstraction, so it can't be fully Vanilla. I am using some dynamic patching hacks that need "initbang", which is a functionality I have included into my [loadbanger] object.
One thing that I am struggling with in [text] is being able to set commas into a line via external messages, see https://github.com/pure-data/pure-data/issues/1262 - I am now doing a very dirty hack to overcome this issue. And also, getting a whole line with things separated by commas is not quite easy with [text], but I've managed to do so with my [dictionary] abstraction.
By the way, I was trying to use Pd's Data Structures to deal with some Lisp-like Linked Lists, hoping to be able to work with arrays of arrays, but it was just too limited and impossible. This is for another project, which is like the BACH library for Pd. The way around was to use LUA, and I also have LUA in ELSE.
Maybe dealing with LUA can help and we have also already discussed about natively supporting LUA in PD, see https://github.com/pure-data/pure-data/issues/687
As far as parsing JSON files goes into Pd vanilla, I think that besides importing it into a [text], you can think about maybe using [file]? Maybe that's overkill, I don't know.
cheers
Em dom., 8 de fev. de 2026 às 11:47, Pierre Alexandre Tremblay < tremblap@gmail.com> escreveu:
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
did you have a look at the purest_json library, does it help?
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email topd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.i
did you have a look at the purest_json library, does it help?
I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it)
hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way…
BACH library for Pd.
now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job
p
On 8 Feb 2026, at 17:38, João Pais jmmmpais@gmail.com wrote:
did you have a look at the purest_json library, does it help?
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.i https://lists.i/---
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Em dom., 8 de fev. de 2026 às 13:48, Pierre Alexandre Tremblay < tremblap@gmail.com> escreveu:
hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick.
Please let me know, and if it doesn't, let me know exactly what you need so I can maybe help and provide a solution - it's here by the way https://github.com/porres/pd-else/blob/master/Abstractions/Control/dictionar... and hopefully you can get the binaries from Actions ( https://github.com/porres/pd-else/actions ) or compile it yourself.
The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way…
BACH library for Pd.
now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job
It's not an actual port of BACH, we're just doing it our own way. It is inspired by it of course, and it's called "BHACK", see https://github.com/EL-LOCUS-SOLUS/pd-bhack it's kinda almost ready to be included into ELSE ;) - Charles Neimog is doing all the heavy weight lifting by the way...
Cheers
p
On 8 Feb 2026, at 17:38, João Pais jmmmpais@gmail.com wrote:
did you have a look at the purest_json library, does it help?
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p ---pd-list@lists.iem.at - the Pure Data mailinglisthttps://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.i
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Em dom., 8 de fev. de 2026 às 14:49, Alexandre Torres Porres < porres@gmail.com> escreveu:
It's here by the way https://github.com/porres/pd-else/blob/master/Abstractions/Control/dictionar...
Heads up, I just renamed this object to [messcoll], seems like a better fit as it's not a proper dictionary and relates to [coll]
hello pierre alexandre,
a while ago i made a parser for .kml files (xml files recorded by bycicle route trackers) for a friend to sonify her tours. its plain vanilla and was a pita to make :-) if thats interesting for you, i can send you a copy of the patch.
cheers
hans
Am 08.02.2026 um 17:48 schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
did you have a look at the purest_json library, does it help?
I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it)
hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way…
BACH library for Pd.
now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job
p
On 8 Feb 2026, at 17:38, João Pais jmmmpais@gmail.com wrote:
did you have a look at the purest_json library, does it help?
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.i
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY...
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/FDMWVTTF62...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Unless the usage is very basic, I think plain vanilla as a requirement does not make sense for this. There are numerous C and C++ libraries which handle the basics and should be leveraged instead of reading bytes with [file] or something similar. Best of all, many of these libraries are only 1-2 files, so making a light wrapper external with minimal requirements for compilation should not be huge issue IMO.
On Feb 8, 2026, at 8:04 PM, hans w. koch hansw.koch@gmail.com wrote:
hello pierre alexandre,
a while ago i made a parser for .kml files (xml files recorded by bycicle route trackers) for a friend to sonify her tours. its plain vanilla and was a pita to make :-) if thats interesting for you, i can send you a copy of the patch.
cheers
hans
Am 08.02.2026 um 17:48 schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
did you have a look at the purest_json library, does it help?
I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it)
hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way…
BACH library for Pd.
now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job
p
On 8 Feb 2026, at 17:38, João Pais jmmmpais@gmail.com wrote:
did you have a look at the purest_json library, does it help?
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.i
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY...
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/FDMWVTTF62...
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/V5ZSSTMQSA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
we do tap on one of these in flucoma, so if I do a fluid.dictionary it’ll be this that I use indeed. I just try to keep maintenance of codebase to minimum, and dependencies to null.
p
On 8 Feb 2026, at 20:53, Dan Wilcox danomatika@gmail.com wrote:
Unless the usage is very basic, I think plain vanilla as a requirement does not make sense for this. There are numerous C and C++ libraries which handle the basics and should be leveraged instead of reading bytes with [file] or something similar. Best of all, many of these libraries are only 1-2 files, so making a light wrapper external with minimal requirements for compilation should not be huge issue IMO.
On Feb 8, 2026, at 8:04 PM, hans w. koch hansw.koch@gmail.com wrote:
hello pierre alexandre,
a while ago i made a parser for .kml files (xml files recorded by bycicle route trackers) for a friend to sonify her tours. its plain vanilla and was a pita to make :-) if thats interesting for you, i can send you a copy of the patch.
cheers
hans
Am 08.02.2026 um 17:48 schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
did you have a look at the purest_json library, does it help?
I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it)
hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way…
BACH library for Pd.
now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job
p
On 8 Feb 2026, at 17:38, João Pais jmmmpais@gmail.com wrote:
did you have a look at the purest_json library, does it help?
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.i
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY...
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/FDMWVTTF62...
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/V5ZSSTMQSA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Maybe this is a good time to propose a *native* dictionary or dict-style functionality. Maybe it comes down to a special mode for [text] etc? There is a symbol name map in the rjlib but I'd also like something more flexible.
On Feb 9, 2026, at 9:15 AM, Pierre Alexandre Tremblay tremblap@gmail.com wrote:
we do tap on one of these in flucoma, so if I do a fluid.dictionary it’ll be this that I use indeed. I just try to keep maintenance of codebase to minimum, and dependencies to null.
p
On 8 Feb 2026, at 20:53, Dan Wilcox danomatika@gmail.com wrote:
Unless the usage is very basic, I think plain vanilla as a requirement does not make sense for this. There are numerous C and C++ libraries which handle the basics and should be leveraged instead of reading bytes with [file] or something similar. Best of all, many of these libraries are only 1-2 files, so making a light wrapper external with minimal requirements for compilation should not be huge issue IMO.
On Feb 8, 2026, at 8:04 PM, hans w. koch hansw.koch@gmail.com wrote:
hello pierre alexandre,
a while ago i made a parser for .kml files (xml files recorded by bycicle route trackers) for a friend to sonify her tours. its plain vanilla and was a pita to make :-) if thats interesting for you, i can send you a copy of the patch.
cheers
hans
Am 08.02.2026 um 17:48 schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
did you have a look at the purest_json library, does it help?
I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it)
hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way…
BACH library for Pd.
now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job
p
On 8 Feb 2026, at 17:38, João Pais jmmmpais@gmail.com wrote:
did you have a look at the purest_json library, does it help?
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.i
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY...
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/FDMWVTTF62...
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/V5ZSSTMQSA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
hello,
[text] object is quite a powerfull tool for building data structures, meanwhile it often need some safe recursive search.
I'm working on a lua script for experimenting json on pd world if anyone wants to try:
https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson%EF%BF...
It's still experimental, but maybe it could give some clues about sharing json and pd structures.
Le 9 févr. 2026 à 09:56, Dan Wilcox danomatika@gmail.com a écrit :
Maybe this is a good time to propose a *native* dictionary or dict-style functionality. Maybe it comes down to a special mode for [text] etc? There is a symbol name map in the rjlib but I'd also like something more flexible.
On Feb 9, 2026, at 9:15 AM, Pierre Alexandre Tremblay tremblap@gmail.com wrote:
we do tap on one of these in flucoma, so if I do a fluid.dictionary it’ll be this that I use indeed. I just try to keep maintenance of codebase to minimum, and dependencies to null.
p
On 8 Feb 2026, at 20:53, Dan Wilcox danomatika@gmail.com wrote:
Unless the usage is very basic, I think plain vanilla as a requirement does not make sense for this. There are numerous C and C++ libraries which handle the basics and should be leveraged instead of reading bytes with [file] or something similar. Best of all, many of these libraries are only 1-2 files, so making a light wrapper external with minimal requirements for compilation should not be huge issue IMO.
On Feb 8, 2026, at 8:04 PM, hans w. koch hansw.koch@gmail.com wrote:
hello pierre alexandre,
a while ago i made a parser for .kml files (xml files recorded by bycicle route trackers) for a friend to sonify her tours. its plain vanilla and was a pita to make :-) if thats interesting for you, i can send you a copy of the patch.
cheers
hans
Am 08.02.2026 um 17:48 schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
> did you have a look at the purest_json library, does it help?
I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it)
hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way…
BACH library for Pd.
now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job
p
On 8 Feb 2026, at 17:38, João Pais jmmmpais@gmail.com wrote:
did you have a look at the purest_json library, does it help? > Dear all > > Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider) > > here is an example of one of our user’s clever use of the text object despite its limits > > https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-... > > now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values? > > Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway. > > any pointers (pun intended) welcome > > p > --- > pd-list@lists.iem.at - the Pure Data mailinglist > https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK... > > To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.i
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY...
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/FDMWVTTF62...
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/V5ZSSTMQSA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/WKWXXMDY5C...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Like I said, pd has data structures for arrays whose elements can be symbols or other arrays nested in any depth, but this is impractical to work with. If anyone ever made discriminators with nested dictionaries on it or nested lists, I’d like to know, but where I’m getting at is that maybe we already have the structure in pd to work with such things and perhaps we can just improve it a bit?
If not, we’d need formally a new data type so we can do all of this. Lua has something that allows us to deal with nested lists and dictionaries, so maybe something like that. Of course, like I also said, we can natively support lua, but if this is the sole reason, a better actual solution would be this new data type.
An object like dict from max would be cool and I don’t think it’s possible to build it with a text object. We need to be able to set and visualize nested data and text is only capable of setting and viewing lines
Cheers
On Mon, 9 Feb 2026 at 06:20 Patrice Colet colet.patrice@gmail.com wrote:
hello,
[text] object is quite a powerfull tool for building data structures, meanwhile it often need some safe recursive search.
I'm working on a lua script for experimenting json on pd world if anyone wants to try:
critapec-pd-externals/pdjson at main · patricecolet/critapec-pd-externals https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson github.com https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson [image: apple-touch-icon-180x180-a80b8e11abe2.png] https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson
It's still experimental, but maybe it could give some clues about sharing json and pd structures.
Le 9 févr. 2026 à 09:56, Dan Wilcox danomatika@gmail.com a écrit :
Maybe this is a good time to propose a *native* dictionary or dict-style functionality. Maybe it comes down to a special mode for [text] etc? There is a symbol name map in the rjlib but I'd also like something more flexible.
On Feb 9, 2026, at 9:15 AM, Pierre Alexandre Tremblay tremblap@gmail.com wrote:
we do tap on one of these in flucoma, so if I do a fluid.dictionary it’ll be this that I use indeed. I just try to keep maintenance of codebase to minimum, and dependencies to null.
p
On 8 Feb 2026, at 20:53, Dan Wilcox danomatika@gmail.com wrote:
Unless the usage is very basic, I think plain vanilla as a requirement does not make sense for this. There are numerous C and C++ libraries which handle the basics and should be leveraged instead of reading bytes with [file] or something similar. Best of all, many of these libraries are only 1-2 files, so making a light wrapper external with minimal requirements for compilation should not be huge issue IMO.
On Feb 8, 2026, at 8:04 PM, hans w. koch hansw.koch@gmail.com wrote:
hello pierre alexandre,
a while ago i made a parser for .kml files (xml files recorded by bycicle route trackers) for a friend to sonify her tours. its plain vanilla and was a pita to make :-) if thats interesting for you, i can send you a copy of the patch.
cheers
hans
Am 08.02.2026 um 17:48 schrieb Pierre Alexandre Tremblay < tremblap@gmail.com>:
did you have a look at the purest_json library, does it help?
I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it)
hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way…
BACH library for Pd.
now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job
p
On 8 Feb 2026, at 17:38, João Pais jmmmpais@gmail.com wrote:
did you have a look at the purest_json library, does it help?
Dear all
Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider)
here is an example of one of our user’s clever use of the text object despite its limits
https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-...
now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values?
Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway.
any pointers (pun intended) welcome
p
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.i
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY...
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/FDMWVTTF62...
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/V5ZSSTMQSA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com robotcowboy.com
Dan Wilcox danomatika.com robotcowboy.com
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/WKWXXMDY5C...
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/D3DGTVM2RB...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
A but out of left field, but I have used a simple Python server to host a database lookup over OSC. The Pd patch then sent queries and the answer came over OSC. This of course is a "system" and not all "within Pd" however would be a relatively futureproof approach as long as you use stable Python APIs.
As for [text], if it's too focused/complicated, maybe we should make a [dict] proposal?
On Feb 9, 2026, at 3:09 PM, Alexandre Torres Porres porres@gmail.com wrote:
Like I said, pd has data structures for arrays whose elements can be symbols or other arrays nested in any depth, but this is impractical to work with. If anyone ever made discriminators with nested dictionaries on it or nested lists, I’d like to know, but where I’m getting at is that maybe we already have the structure in pd to work with such things and perhaps we can just improve it a bit?
If not, we’d need formally a new data type so we can do all of this. Lua has something that allows us to deal with nested lists and dictionaries, so maybe something like that. Of course, like I also said, we can natively support lua, but if this is the sole reason, a better actual solution would be this new data type.
An object like dict from max would be cool and I don’t think it’s possible to build it with a text object. We need to be able to set and visualize nested data and text is only capable of setting and viewing lines
Cheers
On Mon, 9 Feb 2026 at 06:20 Patrice Colet <colet.patrice@gmail.com mailto:colet.patrice@gmail.com> wrote:
hello,
[text] object is quite a powerfull tool for building data structures, meanwhile it often need some safe recursive search.
I'm working on a lua script for experimenting json on pd world if anyone wants to try:
critapec-pd-externals/pdjson at main · patricecolet/critapec-pd-externals github.com <apple-touch-icon-180x180-a80b8e11abe2.png> https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjsoncritapec-pd-externals/pdjson at main · patricecolet/critapec-pd-externals https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson github.com https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson <apple-touch-icon-180x180-a80b8e11abe2.png> https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson
It's still experimental, but maybe it could give some clues about sharing json and pd structures.
Le 9 févr. 2026 à 09:56, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> a écrit :
Maybe this is a good time to propose a *native* dictionary or dict-style functionality. Maybe it comes down to a special mode for [text] etc? There is a symbol name map in the rjlib but I'd also like something more flexible.
On Feb 9, 2026, at 9:15 AM, Pierre Alexandre Tremblay <tremblap@gmail.com mailto:tremblap@gmail.com> wrote:
we do tap on one of these in flucoma, so if I do a fluid.dictionary it’ll be this that I use indeed. I just try to keep maintenance of codebase to minimum, and dependencies to null.
p
On 8 Feb 2026, at 20:53, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Unless the usage is very basic, I think plain vanilla as a requirement does not make sense for this. There are numerous C and C++ libraries which handle the basics and should be leveraged instead of reading bytes with [file] or something similar. Best of all, many of these libraries are only 1-2 files, so making a light wrapper external with minimal requirements for compilation should not be huge issue IMO.
On Feb 8, 2026, at 8:04 PM, hans w. koch <hansw.koch@gmail.com mailto:hansw.koch@gmail.com> wrote:
hello pierre alexandre,
a while ago i made a parser for .kml files (xml files recorded by bycicle route trackers) for a friend to sonify her tours. its plain vanilla and was a pita to make :-) if thats interesting for you, i can send you a copy of the patch.
cheers
hans
> Am 08.02.2026 um 17:48 schrieb Pierre Alexandre Tremblay <tremblap@gmail.com mailto:tremblap@gmail.com>: > >>> did you have a look at the purest_json library, does it help? > I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it) > > hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way… > >> BACH library for Pd. > > now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job > > p > > >> On 8 Feb 2026, at 17:38, João Pais <jmmmpais@gmail.com mailto:jmmmpais@gmail.com> wrote: >> >> did you have a look at the purest_json library, does it help? >>> Dear all >>> >>> Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider) >>> >>> here is an example of one of our user’s clever use of the text object despite its limits >>> >>> https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-... >>> >>> now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values? >>> >>> Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway. >>> >>> any pointers (pun intended) welcome >>> >>> p >>> --- >>> pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist >>> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK... >>> >>> To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> https://lists.i https://lists.i/ >> --- >> pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist >> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY... >> >> To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.iem.at/ > > > --- > pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist > https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/FDMWVTTF62... > > To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/V5ZSSTMQSA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/WKWXXMDY5C...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/D3DGTVM2RB...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto: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/R3G4OAUQLN...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Em seg., 9 de fev. de 2026 às 12:14, Dan Wilcox danomatika@gmail.com escreveu:
As for [text], if it's too focused/complicated, maybe we should make a [dict] proposal?
yup :)
On 09/02/2026 23:14, Dan Wilcox wrote:
[dict] proposal?
I've often thought it would be interesting to have JSON-like data that flows through Pd's graphs, rather than being "at rest" like the [text] object. For example, let's say you had a message box containing: {"hello": 42}
You send it into [json-get-in "hello"] and out comes 42. The right inlet takes the "coordinates" to look up within the datastructure.
A more complicated example is {"things": [1, 2, 3]}.
You send it into [json-get-in "things" 1] and out comes "2".
To compose these things you can also have json-update which you can use like this:
[json-update "things" 1]
The right inlet takes the value to replace and the left inlet takes the datastructure. So if you send that same example in again and on the right inlet you send in 67 then the output is: {"things": [1, 67, 3]}.
Of course it's JSON so these documents would not have a specific shape and you could just as easily insert {"foo": "bar"} and you'd end up with {"things: [1, {"foo": "bar"}, 3]}.
You could also have a "map" type of operation similar to Frank Barknecht's list updating utilies where you send the old value out of the right inlet and take the updated value into a rightmost inlet, and the old value is replaced at those coordinates within the datastructure.
With these operations the JSON is not something that sits at rest in a [text] like object but rather it is data that is flowing through the graph just like audio does.
I guess it's similar to the 'list' family of objects, but for nested datastructures rather than just flat lists of atoms.
To me this has always felt like something that would be useful in Pd.
Cheers,
Chris.
I don't know if I would be in favor of something built-in that is specifically JSON, but maybe more allow for nesting lists.
Also, I feel like this use case is also something for an embedded scripting system ala including a minimal "vanilla lua" where these kinds of problems are IMO just easier to solve in that kind of environment. I tend to separate my mapping and audio into pure Pd and do the rest in other environments. It would be nice to bing some of that back into Pd without having to patch it *and* having remaining vanilla.
On Feb 10, 2026, at 12:05 AM, Chris McCormick chris@mccormick.cx wrote:
On 09/02/2026 23:14, Dan Wilcox wrote:
[dict] proposal?
I've often thought it would be interesting to have JSON-like data that flows through Pd's graphs, rather than being "at rest" like the [text] object. For example, let's say you had a message box containing: {"hello": 42}
You send it into [json-get-in "hello"] and out comes 42. The right inlet takes the "coordinates" to look up within the datastructure.
A more complicated example is {"things": [1, 2, 3]}.
You send it into [json-get-in "things" 1] and out comes "2".
To compose these things you can also have json-update which you can use like this:
[json-update "things" 1]
The right inlet takes the value to replace and the left inlet takes the datastructure. So if you send that same example in again and on the right inlet you send in 67 then the output is: {"things": [1, 67, 3]}.
Of course it's JSON so these documents would not have a specific shape and you could just as easily insert {"foo": "bar"} and you'd end up with {"things: [1, {"foo": "bar"}, 3]}.
You could also have a "map" type of operation similar to Frank Barknecht's list updating utilies where you send the old value out of the right inlet and take the updated value into a rightmost inlet, and the old value is replaced at those coordinates within the datastructure.
With these operations the JSON is not something that sits at rest in a [text] like object but rather it is data that is flowing through the graph just like audio does.
I guess it's similar to the 'list' family of objects, but for nested datastructures rather than just flat lists of atoms.
To me this has always felt like something that would be useful in Pd.
Cheers,
Chris.
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 10/02/2026 07:40, Dan Wilcox wrote:
Also, I feel like this use case is also something for an embedded scripting system ala including a minimal "vanilla lua" where these kinds of problems are IMO just easier to solve in that kind of environment. I tend to separate my mapping and audio into pure Pd and do the rest in other environments.
It's true, using a "proper" language for that kind of thing is ergonomic, and that's what I have done in the past too. In 2024 I used pdjs like that on a couple of albums. My suggestion is really just a weird idea that I keep coming back to for some reason. 😅
Chris.
Am 10. Februar 2026 00:40:27 MEZ schrieb Dan Wilcox danomatika@gmail.com:
I don't know if I would be in favor of something built-in that is specifically JSON, but maybe more allow for nesting lists.
this.
and while this was shot down when I proposed it back then, I still think that using curlies for nested lists would be the simplest solution.
mfg.sfg.jfd IOhannes
retrieving by key is what is also quite important for me. I can always translate to/from json, but the ability to nest that structure in itself is also quite important feature of dicts power usage.
p
On 10 Feb 2026, at 08:40, IOhannes m zmölnig via Pd-list pd-list@lists.iem.at wrote:
Am 10. Februar 2026 00:40:27 MEZ schrieb Dan Wilcox danomatika@gmail.com:
I don't know if I would be in favor of something built-in that is specifically JSON, but maybe more allow for nesting lists.
this.
and while this was shot down when I proposed it back then, I still think that using curlies for nested lists would be the simplest solution.
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/7G2RRQ6TJE...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Nested lists would be awesome!
There has already been a discussion on GitHub: https://github.com/pure-data/pure-data/issues/505.
I've tried to argue that we shouldn't suddenly reclaim existing valid characters. Instead we could extend the semantics of $ to allow for more control sequences.
In that sense, I have suggested to use ${ and $} instead of plain { and } as nested list delimiters.
Similarly, we could finally support $@ as a placeholder for all arguments or even introduce argument slices like $[1:4].
Christof
On 2/10/2026 8:40 AM, IOhannes m zmölnig via Pd-list wrote:
Am 10. Februar 2026 00:40:27 MEZ schrieb Dan Wilcox danomatika@gmail.com:
I don't know if I would be in favor of something built-in that is specifically JSON, but maybe more allow for nesting lists.
this.
and while this was shot down when I proposed it back then, I still think that using curlies for nested lists would be the simplest solution.
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/7G2RRQ6TJE...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
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 carries extra data types. For reference, see https://periodicos.unespar.edu.br/vortex/article/view/6783/4805
They have a data type for nested lists (with the same syntax as Lisp using parenthesis) and dictionaries (whose syntax is a little bit python-like, using brackets and the ability to load/save JSON files).
There are yet other data types and I think that adding that many more is kinda overkill (like a data type just for envelopes), but anyway, it's interesting and I'm getting inspired to add both (nested lists and dicts) into ELSE, I just don't really think I'd need to create a new data type into Pd for this and add complexity to Pd's syntax. I guess that maybe I can only deal with special syntax for nesting lists and dictionaries...
And now that we're also talking about adding these to Vanilla, I wonder and would like to know if the idea is to expand the data types and complexity of the syntax, or if it's also just a matter of syntax.
Cheers
Em ter., 10 de fev. de 2026 às 11:13, Christof Ressi info@christofressi.com escreveu:
Nested lists would be awesome!
There has already been a discussion on GitHub: https://github.com/pure-data/pure-data/issues/505.
I've tried to argue that we shouldn't suddenly reclaim existing valid characters. Instead we could extend the semantics of $ to allow for more control sequences.
In that sense, I have suggested to use ${ and $} instead of plain { and } as nested list delimiters.
Similarly, we could finally support $@ as a placeholder for all arguments or even introduce argument slices like $[1:4].
Christof
On 2/10/2026 8:40 AM, IOhannes m zmölnig via Pd-list wrote:
Am 10. Februar 2026 00:40:27 MEZ schrieb Dan Wilcox <
danomatika@gmail.com>:
I don't know if I would be in favor of something built-in that is
specifically JSON, but maybe more allow for nesting lists.
this.
and while this was shot down when I proposed it back then, I still think
that using curlies for nested lists would be the simplest solution.
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/7G2RRQ6TJE...
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/YGHN4Y5PCD...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
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
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.
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/
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/
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/
wow this is all getting very exciting!
To add to the wish list: we need API support to, to have access via externals to that data structure, or at least a json parsing to file. nested dictionaries are very powerful indeed…
On 9 Feb 2026, at 15:09, Alexandre Torres Porres porres@gmail.com wrote:
Like I said, pd has data structures for arrays whose elements can be symbols or other arrays nested in any depth, but this is impractical to work with. If anyone ever made discriminators with nested dictionaries on it or nested lists, I’d like to know, but where I’m getting at is that maybe we already have the structure in pd to work with such things and perhaps we can just improve it a bit?
If not, we’d need formally a new data type so we can do all of this. Lua has something that allows us to deal with nested lists and dictionaries, so maybe something like that. Of course, like I also said, we can natively support lua, but if this is the sole reason, a better actual solution would be this new data type.
An object like dict from max would be cool and I don’t think it’s possible to build it with a text object. We need to be able to set and visualize nested data and text is only capable of setting and viewing lines
Cheers
On Mon, 9 Feb 2026 at 06:20 Patrice Colet <colet.patrice@gmail.com mailto:colet.patrice@gmail.com> wrote:
hello,
[text] object is quite a powerfull tool for building data structures, meanwhile it often need some safe recursive search.
I'm working on a lua script for experimenting json on pd world if anyone wants to try:
critapec-pd-externals/pdjson at main · patricecolet/critapec-pd-externals github.com <apple-touch-icon-180x180-a80b8e11abe2.png> https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjsoncritapec-pd-externals/pdjson at main · patricecolet/critapec-pd-externals https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson github.com https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson <apple-touch-icon-180x180-a80b8e11abe2.png> https://github.com/patricecolet/critapec-pd-externals/tree/main/pdjson
It's still experimental, but maybe it could give some clues about sharing json and pd structures.
Le 9 févr. 2026 à 09:56, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> a écrit :
Maybe this is a good time to propose a *native* dictionary or dict-style functionality. Maybe it comes down to a special mode for [text] etc? There is a symbol name map in the rjlib but I'd also like something more flexible.
On Feb 9, 2026, at 9:15 AM, Pierre Alexandre Tremblay <tremblap@gmail.com mailto:tremblap@gmail.com> wrote:
we do tap on one of these in flucoma, so if I do a fluid.dictionary it’ll be this that I use indeed. I just try to keep maintenance of codebase to minimum, and dependencies to null.
p
On 8 Feb 2026, at 20:53, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Unless the usage is very basic, I think plain vanilla as a requirement does not make sense for this. There are numerous C and C++ libraries which handle the basics and should be leveraged instead of reading bytes with [file] or something similar. Best of all, many of these libraries are only 1-2 files, so making a light wrapper external with minimal requirements for compilation should not be huge issue IMO.
On Feb 8, 2026, at 8:04 PM, hans w. koch <hansw.koch@gmail.com mailto:hansw.koch@gmail.com> wrote:
hello pierre alexandre,
a while ago i made a parser for .kml files (xml files recorded by bycicle route trackers) for a friend to sonify her tours. its plain vanilla and was a pita to make :-) if thats interesting for you, i can send you a copy of the patch.
cheers
hans
> Am 08.02.2026 um 17:48 schrieb Pierre Alexandre Tremblay <tremblap@gmail.com mailto:tremblap@gmail.com>: > >>> did you have a look at the purest_json library, does it help? > I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it) > > hence asking if there was a native version/hack. I’ll look at Alexandre’s abstraction, that might do the trick. The idea would be to be able to dump fluid* status (mlp for instance) in text, edit, then load them back. This has been seen as useful on other platforms, so I’m trying to find a way… > >> BACH library for Pd. > > now, that is a fun challenge ;) I was talking to both Daniele and Andrea about this in the last year… it would be a fantastic addition obviously but I don’t envy the person who will do that job > > p > > >> On 8 Feb 2026, at 17:38, João Pais <jmmmpais@gmail.com mailto:jmmmpais@gmail.com> wrote: >> >> did you have a look at the purest_json library, does it help? >>> Dear all >>> >>> Apart the fact that flucoma releases (and nightles soon) are on deken (hurray!), I am slowly getting back in trying to add the last bit missing to our interface… but the lack of native dictionary style file/data structure is not helping us to keep the structured (json style) states of objects simply yet programmatically editable (like in max and supercollider) >>> >>> here is an example of one of our user’s clever use of the text object despite its limits >>> >>> https://discourse.flucoma.org/t/way-of-modifying-state-of-fluid-robustscale-... >>> >>> now I know there are “pd structure” magicians on here, and maybe someone has had the idea to create a sort of hack to parse json files, or even general dictionaries of associative key-values? >>> >>> Ideally, I’d be able to access those in the C api… but a temp json file is also possible on the way, we do that with SuperCollider anyway. >>> >>> any pointers (pun intended) welcome >>> >>> p >>> --- >>> pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist >>> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YWXEUDCIFK... >>> >>> To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> https://lists.i https://lists.i/ >> --- >> pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist >> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/QI3VZVQVMY... >> >> To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.iem.at/ > > > --- > pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist > https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/FDMWVTTF62... > > To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/V5ZSSTMQSA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/WKWXXMDY5C...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/D3DGTVM2RB...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto: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/R3G4OAUQLN...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Am 08.02.26 um 17:48 schrieb Pierre Alexandre Tremblay:
did you have a look at the purest_json library, does it help?
I didn’t but I saw it was neither vanilla nor available for all CPUs, so that won’t be helpful in my case (except if I decide to tackle a fluid.dictionary external which i don’t want to if I can avoid it)
The main reason for it not being available for all CPUs is the problem with cross-compiling for Mac.
Best Thomas