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

@whale-av said:

@rph-r Looking at the warning it seems alsa will not run at 44100..... so Pd is probably running at 48K.

The message appears with portaudio, not alsa. But you're right, I suspect Pd to follow something @ 48k (Pulseaudio? Alsa?), although [samplerate~] indicates 44100.

I can't use most of externals on Bela, and since the patch will be running for a veeeery long time, I have to keep it light.
I don't really understand why a simple and so common object doesn't work...

Hi,
ok, a lot in the title.
I have trouble with a patch playing wav 44100 files. The files are exactly 10', verified mounting them on some DAWs.
But:
-if I use alsa @ 44100, [readsf] plays the files in 9'13'', too quickly
-with portaudio:

warning: requested samplerate 44100 not supported, using 48000.

but anyway I played the files: 10'3''

The patch will then run on a Bela board, who knows what will happen there...

The [timer] issue:
I used it to measure playing time, but this object seems to be related to the samplerate, since I always measure 10'00''+/-some milliseconds.
This is not fair, I spend two days figuring out what causes issue.
Now I measure with [realtime].

How can I fix the play speed?

no clicks! The junction is perfect. As said, I open next file some time before, and start next file on current file end bang.

thank you, I didn't know about [command].
I get exactly the same result. I wonder if it is not a format issue. I tried to escape spaces, but it returns an error
test_command-object.pd
concat.pd

hi!
I cannot get this to work:

[echo "bla" >> textfile.txt(
|
[shell]
|
[print]

In textfile.txt, I get nothing, and in the console I get:

"bla" >> textfile.txt

as if all the command is a string.