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?

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)

and Bela, written with xenomai wrappers, otherwise it generates errors also.
ahora.pd_linux

@whale-av This point is solved, I actually wrote an object. I was using [shell] with date command but it was generating errors in the sound stream, like xruns. You can already try it (linux and Bela versions), but I will rewrite it soon to be easier portable.
And yes, the Bela is connected to internet and automatically sync the time. Syncing is not a big deal, but syncing without glitch is another story...
x86 Linux version here
ahora.pd_linux

thank you for all your infos and suggestions.

The thing is: I play back field recordings recorded twelve hours before. I divided the recording into 10m slices. The playbacks have to be on time +/-1 or 2 seconds. For example the church bells ringing at midnight have to be played back on time at noon. The installation is permanent, so I need to resync if the offset - the junction between the files - moves.

I finally use the simple [sfplay~]. I made 12 hours tests and it is not so bad: it moves +/- 1sec, but finally keep sync with tenths minutes +/-2sec.

I noticed a strange behavior: sometimes I start the patch and it reads the files too quickly (they finishes after 9' and some seconds). But after restarting the patch it is ok again...
I'll provide more tests soon

by Tcl you mean netsend? I'm using it locally with pdreceive, I receive the messages but only with the backslashes escape characters.

but anyway I'll figure out how I could use [sf-varispeed2~] since I need to fine tune and resync. I have to guarantee the installation for 5 years (!!).

I seems to work on Bela too... ouf

@alexandros said:

The Bela runs on 44100 only.

that is why I use 44100. So there is definitely something wrong with pulseaudio.

Ok, pulseaudio or something in between is probably guilty:
I made this patch to test and it unsync on my regular linux system. It could be the 44100/48000, but the weird thing is it doesn't unsync the same manner with alsa or portaudio.
On my sound production system (lowlatency, and with Jackd), it remains perfectly synchronized.
I'll try tomorrow on the Bela, hopefully it will be ok...
TEST_timerVSrealtime.pd