Let's say that I have made a pd abstraction called "abstraction.pd" which has a graph on parent window. I now create this abstraction object in a new canvas, with some creation arguments, [abstraction 1 2 3], and the graph on parent window pops up.

1. Is it possible to now rename the object, or otherwise change the creation arguments? Ie, if I wanted to change it to [abstraction 4 5 6], is there any way of doing this, or would I have to delete the original object and then create a new one?

2. Is it possible to modify the creation arguments automatically from within the graph on parent window? Ie., lets say that the graph on parent window has a number box in it. Is it possible to use that number box to modify the creation argument in the object name, so that [abstraction 1] becomes [abstraction 2]?

I feel like this should be possible with internal messages, but I don't know how to go about it...

when you use creation arguments in abstractions you receive the values by means of $1, $2 etc. right? So the [$1 ] object can receive the output of the number atom in its inlet and therefore change the value of the argument. Is this clear?

This would work, however, I'm looking to change the value in the actual creation argument itself. The reason is that the creation argument will be saved in the main canvas, whereas the number atom will be cleared every time.

I figured out number 1--you just have to deselect the "hide object name and arguments" option. Number 2 is still perplexing me, though. You can send a [rename( message to the canvas, but I don't think that it updates the actual text in the creation argument...

for saving with the patch you could use constructions like this:

this way the current numer set with the number box in parent is saved with parent, on top you can also recall the initial argument with the bang.

Thanks, Johnny--this actually works. However, I still want to know if it is possible to modify the original creation argument, so that the [abstraction 1] box becomes [abstraction 2]. If it's possible, this would allow for a more elegant state saving solution, without the external message box in the parent.pd window.

For example, I know that you can create a new object using internal messages by doing something like this:

[obj 10 40 metro 500(
|
|
[send pd-my_patch]

Is it possible to later modify that object automatically, so that it becomes, say, [metro 1000]?

If this is possible, then my abstraction's settings can be saved as creation arguments, making state saving very easy.

I think I've figured out how to do it. The [textfile] object can read and write pd files. It should be possible to create an abstraction that picks apart a patch file, alters it (say by changing the creation arguments of a particular object) and then recompiles it. It's going to take a lot of work to make such a patch, but it should work.

Has anyone explored using [textfile] to modify patches before? It seems like it would have a lot of implications for dynamic patching.

Here's an example of what I mean:

abtract_saving.zip

1. open parent.pd. The abstraction's creation argument is set to 15
2. Choose a new creation argument using the number box
3. Click save
4. Close parent.pd and open it again. The new creation argument is now in effect.

The abstraction works by editing the parent.pd file using [textfile]. At the moment, it will only edit for one variable, but there is no limit to how many things can be edited, in principle. Unfortunately, the newly edited file doesn't come into effect unless it is reloaded, and there might be no way around this. Still, it seems like this technique should open up new avenues for state saving and dynamic patching.