Hi!
I've just learned subpatches doesn't work with arguments.
Although I've been trying that in the meanwhile and I noticed a strange behavior:
I copied various version of an eq subpatch, which I numbered like [pd eq 1] [pd eq 2] etc. (don't tell me to use abstraction, I have a lot of parameters and [savestate] seems too heavy).
I don't know why it is working, but it is: within the subpatches I have for example [s $1-freq] and [r $1-freq] and all the other eqs aren't affected.
That's not all: for any reason I can't reproduce all the subpatches copies after a while turned like [pd eq N 1] (notice the space between N and 1), N 2, N 3, N 4, and again N 1 in the next column of object (!?!). The interesting thing is that all my $1 inside the subpatches have been replaced by the corresponding number I gave as argument (1 - 16).

I want to reproduce the last point so I don't have to change some names within all the subpatches. I have send and receives, but also [route $1-freq $1-slope] etc., coming from a remote computer by [netsend]

doe's anybody know about that?

@rph-r If your subpatches don't need a [savestate] to hold their data between sessions then the subpatch as an abstraction shouldn't need [savestate], just use the abstraction exactly like you want to use the subpatch. But [savestate] can load a good amount of data before it bogs things down, I think you have some issue in your patch/abstraction which is causing [savestate] to seem heavy and also making it seem like subpatch arguments are working. Can you upload your patch?

this is the style I think theyre describing - so youd maybe have to make an object?
or maybe you can make a abstraction hold numbers like that?

I got this to work! you can save an abstraction and then add the arguements after placing the abstraction object in the file. ive never done this before its $ in an F box. you can get $0 from a f box as well.

@willblackhurst Yes, it works for all objects in abstractions (not messages).
But the OP doesn't want to use them, and has had some very strange things happening in their patch
As @oid says, without the patch we cannot see what is going on.
David.

ive never seen savestate work. has it ever worked? youd have to have spy stuff hooked to your computer doing everything for you. and thats why things dont work the way they look. thats why things work when they shouldnt.

You're right: here is the critical part of my patch. All the eqs have been automatically changed to N 3, N 4 etc as I said, I fixed the first and the second so they are now like I wrote them first. Maybe you can understand when and why it is automatically changing.
subpatches_wargs.pd

@rph-r It works exactly as expected, watch the symbol boxes when you switch either of the first two channels, they switch on both channels when you change either and so does the internal state of both [pd filters] but not the vradio since it is not connected to [r $1-type] and its own send/receive symbols are $0-from_type and $0-to_type. There is no reason these would bog down [savestate], can't say why it was causing problems for you without seeing how you implemented it, I regularly store far greater amounts of data in [savestate] without issue.

@oid said:

There is no reason these would bog down [savestate], can't say why it was causing problems for you without seeing how you implemented it, I regularly store far greater amounts of data in [savestate] without issue.

I didn't even tried [savestate]. Pd version on the board the patch will run is 0.51, and I read somewhere [savestate] is present only since 0.52 (I'm using a Bela).. And anyway it seemed difficult to use for 10-20 parameters.

About the patch as it is, you're right about the type thing, it moves both 1 and 2. But how did the other changed?

@rph-r I am not sure what other change you are talking about, everything works exactly as I would expect it, the only wrong behavior I see is the stuff associated with [r $1-type] that I mentioned. [savestate] came with 0.49 and you just use the send and receives of the the UI elements to make your list for it, use a [pack] and [unpack] with an extra element which is only used for [savestate] to bang.

You can also use [list store] instead of [pack] with a [set n $1( between each receive and [list store] with n replaced by the appropriate index value, this can be a good way to go when the number of parameters you need to save gets high.

ok, I'll give a try. Indeed [savestate]-help says since 0.49. Never trust chatgpt.

@willblackhurst ok I got savestate to work. I hadnt looked at it in a while.
it puts lists into the parent file from an abstraction . and then the abstraction number slot gets the lists returned back when you open the saved parent file.

I had exactly the same feeling @willblackhurst, a good idea nobody use because it is not really functional. I'm happy I was wrong. It would have been so useful in a lot of my past project, especially the one with 60 instances of an abstraction with 15 parameters some years ago...

ok, I did it with list. On my computer it is working nicely, but on the Bela I get:

error: list store: no mehod for 'set'

I use:

|
[set n $1(
|
[list store 0 0 0 0 0]

one [set( for each item, n is the index

Doesn't 0.51-4 [list] version provides set method?

@rph-r Forgot that [list store] was a much simpler object in 0.51, https://forum.pdpatchrepo.info/topic/14432/equivalent-of-list-store-insert-delete-pre-pd-0-52/2 is an abstraction that implements the methods added to [list store] in 0.52. Always forget about this.

Edit: You could also use [text] or [array] instead of [list store]

thank you @oid, that is exactly what I needed!
I'll try this afternoon on the Bela, but it does work on my computer.
However, I noticed right inlet doesn't store list like the original.

@rph-r You sure it doesn't store like the original? Just redownloaded it and it seems to work for me. The right inlet is just a [send] which sends to all the internal [list store]s right inlets, while that send is also used for the internal logic that internal logic is quite simple and I can not think of a situation where it would fail. Check again and if it still fails redownload to make sure nothing corrupted, if it still fails upload a patch demonstrating the failure so I can fix it.