Hi,
maybe someone can help me with this:
I read files with [readsf~]. It was working fine, but sometimes (unable to reproduce) for any reason I get this error and it refuses to read the file. Here is the log (I created)

11:47:59 PD_Bela : open ~/RECS/CE_23-50.wav 0 on player B
11:47:00 PD_Bela : player B PLAY
error: dsp: ~/RECS/CE_23-50.wav: No such file or directory
11:47:00 PD_Bela : Durée dernier fichier B 0:0:0
error: readsf: start requested with no prior 'open'

I don't think it is the patch itself, since sometimes it works. The files exists and seems ok (opened with Audacity to try).
I tried to open a file that doesn't exist, with [open nonexistent.wav 0( , and [start(. I get

[readsf~]: start requested with no prior 'open'

and no bang to the right outlet
The weird thing: the line in my log about "Durée du dernier fichier" (length last file read) mens it has read the file but it was 0:0:0 length, and send a bang to [readsf~] right outlet.

What can make think PD the file doesn't exist? Corrupted nevertheless? File rights issue?

afaik, a new Bela software should be released soon, I don't know embed PD version.

thank you,
Actually it is for a Bela board, it uses an ARM A8. I have rc5, and some objects seem not to work properly, but I've just read rc9 needs PD 0.54, and Bela uses 0.51...

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?