Hi all,

I'm porting a max patch to pd and one problem is that [value] object in pd doesn't store symbols and/or lists. Is there any external object can do that? Thanks

Hi, and welcome to the forum,

I believe the object [any] should do what you are looking for, give it a try.

Cheers!
Gilberto

Hi Gilberto,

Thanks for your warm welcome and help.

Unfortunately [any] works more like [list] and [symbol], while [value] can have multiple instance with the same name sharing one single stored value.

I tried making an abstraction to do this, and it's really a pain. Pd's API resists at nearly every turn:

• There's no way to make a singleton. This is necessary if you want all the abstractions to share a single [list], rather than sending a bunch of messages around to copy the state of the variable
• If you try to use the hidden pd-_float subpatch to store shared state, you can only create internal objects. If you try to create an abstraction it will fail because pd-_float doesn't have the correct path for that abstraction (unless of course you add the path globally, which is a pain)
• The common case of using the empty symbol as the shared variable name (e.g., like [v]) is extremely difficult because of the discrepancy between dollarsign expansion with a single dollar arg vs string concatenation with a dollar symbol.

The best I could do is have the first instance of the abstraction store the shared state. But that doesn't suffice for general purpose patching, as the user can easily delete the first instance (or even forget which one it is).

Here's the abstraction attempt...list-value.zip

if you don't mind having multiple copies or sending to multiple copies when changing the message, here is a very simple solution.
vlist.zip

perhaps someone should make an external to do this... It would also be nice to be able to change the name. of the send symbol.

It might be possible to control singletons through the use of closebang and loadbang though, right? When the patch that contains the singleton closes, get it to broadcast to all of the member objects to make a singleton. The first object that receives the message sets a flag (value object) that tells the other members not to create singletons.

@seb-harmonik.ar said:

if you don't mind having multiple copies or sending to multiple copies when changing the message, here is a very simple solution.
vlist.zip

That can get expensive rather quickly, especially with a high rate of messages arriving at the input. I wanted to try having a single storage location so that the performance would compete with an external written in C.

perhaps someone should make an external to do this... It would also be nice to be able to change the name. of the send symbol.

It might be possible to control singletons through the use of closebang and loadbang though, right? When the patch that contains the singleton closes, get it to broadcast to all of the member objects to make a singleton. The first object that receives the message sets a flag (value object) that tells the other members not to create singletons.

That's certainly possible, and I have to admit polymorphic code that responds to user edits is intriguing.

But if we're forced to use the most complicated and brittle programming strategies just to leverage the platform-independence of abstractions it's not worth the benefit. What it shows is that basic tools are missing from the language itself. (Though I still don't have a great solution in mind, aside from just loading a hidden version of each library's *-meta.pd patch when the library loads for the first time.)

@jancsika just rambling on a bit OT.. I've actually done this singleton trick with closebang before for abstractions that use arrays (not wanting to have multiple copies of the same array array). In the end, duplicating an array everytime it was necessary to do so along with all the hackishness motivated me to move those arrays into a dynamic lib now anyways, but I've managed to find the hackishness in an old commit

globeline.zip
edit: forgot to include cycle count for the help file

Don't forget about the [text] objects. They are not a replacement for [value], but can be used to replicate its behavior if need be.

@seb-harmonik What do you mean by a "dynamic lib"? I've also been looking for ways to share arrays between abstractions.

So I made an attempt by using cyclone's coll. You must provide a name for this [vany] object.

vany.zip

@LiamG wow I always forget about [text], I just switched to vanilla after staying on extended 43.4 so I need to get used to having all the awesome new objects.

I mean, I found myself wanting to use a function stored in an array in my abstractions, but not wanting to copy the array for each abstraction. Rather than use the dynamic patching hacks, I made signal and message versions of externals that read arrays from memory. When those classes are loaded they create the arrays in memory if they need them. This way there only needs to be one copy of each array.

Yeah, [text] and [array] are both really powerful. It took me a while to get used to them because they depart from the data-flow paradigm that I'm so accustomed to. But they really change things when you start using them.