hey! where can I find the RC9 version for RPi? (or the latest)

Right inlet works actually,
the issue is [savestate] sends the list too early I guess, maybe before [list-store51] loads everything. I tried with:

[loadbang]
|
[delay 1000]
|
[list 1 2 3 4 5(
|____________
             |
[list-store51]
|
[print]

and a more-delayed bang on list-store51 left inlet to print, the list 1 2 3 4 5 is printed.

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.

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?

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'll give a try. Indeed [savestate]-help says since 0.49. Never trust chatgpt.

@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?

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

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?

I've tried with [textfile] some times ago, I don't remember why it wasn't working.
Anyway, I found a way

This is working well, and doesn't escape the backslashes (therefore they don't appear in the textfile)