@Josef [append $1( is a message, not an object

@whale-av Yes, your example is fine because [value me] is global. It's the $0- prefix that forces me to use var(), which in turn prevents me from assigning to it. fexpr~ interprets "$0-holdCount" as "$0 minus holdCount" and therefore complains that there is no value named "holdCount".

Edit: Oooo, just writing that last sentence suggested to me that I name the value "$0holdCount" (omit the dash so that fexpr~ doesn't interpret it as an operator) but alas, fexpr~ rejected that too.

Edit 2: Oooo, just writing that first edit suggested to me that I name the value "holdCount$0" and so far I haven't been rejected.

It appears that I have to jump through a small hoop to reference a local value object within fexpr~, e.g.

But then it appears to be impossible to assign to that value, e.g. var($s2) = var($s2) + 1

Really? I hope someone schools me because I want to be wrong!

@atux expanding on what @oid wrote, here are @yannseznec's video tutorials on [bonk~]:

I thought I'd watched one or two of them under tutorials, but I can't find them. Pro-tip: watch them on Youtube--there are six videos, but for some reason this site only shows the first one.

@mbbaker This is just my educated guess as someone who has written interrupt driven multitasking stuff in assembler during the Pleistocene era .

Anytime you have independent processes that have to communicate, they have to do it through some kind of buffer because the time slices that each process will receive are not under the programmer's control. Compare with cooperative multitasking using co-routines. So if 2 or more Pd processes have to stream audio between them and not miss a real-time deadline, there has to be a fifo buffer between them.

How big a buffer is required? That depends on each OS and differs from moment to moment depending on what other processes are competing for CPU time. Some processes may lurch forward in execution while others wait to be scheduled. So it can't be predetermined, and therefore it's a configurable option.

In my one project that used [Pd~}, -fifo 1 worked without issue. The lower the number, the lower the roundtrip latency between processes, so I guess that means the fifo size is a tradeoff between latency and reliability.

@polyplexmescalia Have you seen this explanation? https://puredata.info/
Scroll down to the section entitled "Main Pd Flavours"

@porres said:

I read the first messages and I couldn't understand at all what you people are discussing, or the idea about this complicated patch, sorry

OK, here's a restatement of the problem but presented as a patch. See if you can complete the two subpatches in such a way that it passes the exact copy test on the right. phasor snapshot problem statement.pd

I think you will discover that there's no snapshot or vsnapshot that is sufficient to make the right phasor output the exact same sequence as captured on the left. That said, there were other solutions proposed above that had a different structure, so it's not impossible, I'm just claiming it's impossible without going to 64 bit using this structure.

@whale-av Interesting idea, but I suppose another limitation is that you lose the slave's state when you exit Pd. But it suggests another way: count the number of blocks from when dsp gets turned on, and then run a fresh phasor in fast forward that same amount of time to get back to that state. It's more complicated than what I need, but it doesn't have the tiny timing disruption that my compromise solution has.

@FFW The idea of trading state-uncertainty for time-uncertainty sounds so cool that I desperately want it to be real ! But to "only allow the phasor to stop at specific states" suffers from the same issue as I had, no? How can you know what state the phasor is in? I'm arguing that knowing its inputs and output are not enough, even if you could capture them at audio rate timing, because phasors accumulate in double precision internally.

@lacuna said

And single precision is not enough for you?

I'm not sure what you're asking. I'm saying that doubles are required to capture [phasor~]'s state, so in that sense singles are not enough. But otherwise they are. And singles are OK for everything in my patch as long as I accept that I have to disrupt the double accumulation whenever I snapshot.

Do you know what is not working in Pd64?

In my real patch? No. But I should've said earlier that WRT state saving, things were working well enough last week to stop working on this problem (and finally switch back to making music). I started this topic just to report on the most interesting thing I learned during the 2 weeks I spent debugging my poor patch

Did you think about other ways, like rec/playback?

Yes, that's what this is for, to record snapshots of my chaotic patch to REAPER as sysex so that I can return to the exact same state and fiddle with things to make them sound better. I had to capture the values of 32 floats--20 were UI controls but 12 were the states of things like phasors, sampleholds, rzero-revs, and arrays used for feedback. I think we may be thinking slightly differently about recording, so let me tell you how I use it. My patch is kind of unpredictable, and I'm just randomizing its UI controls on a bang to see what I get. Each time I randomize them, I take one of these snapshots. When I'm listening back later, I might want one of the snapshots to be longer, so I just go to the sysex track and add time. Or I might go back and fiddle with the UI a little, then take another snapshot. The sound associated with each snapshot is not steady-state--it might do something surprising if you let it run long enough--so that's why recording the sound is not enough. But it's also true that you don't need any more data than those 32 floats to get back to where you were, no matter if you're only interested in the next second or the next 3 hours.

RE ppphasor-repeat, Pd is complaining about non-existent arrays. If you feel like fixing that, then you might also want to add something that tests whether the repeat is a sample-for-sample copy of the original. That's what I was starting to add before I noticed the error messages.