@whale-av My issue is (was?) that there are things that affect the DSP sort order that you can't see from the graphics alone. As far as I understand, that's different from @ddw_music's question, which is "how much of the DSP graph does Pd have to resort when there's a change"? That said, I don't understand the reason that @spacechild1 gave on the mailing list--I'd love to see an example.

@ddw_music If Pd's topological sort algorithm were smart enough to know when a change inside an abstraction did not change the sort outside the abstraction, then it would be an easy lift for it to detect that feedback to some abstraction (e.g. one with an [inlet~], an [outlet~], and no connections) does not produce a cycle. But the last I checked, that was not the case, so I would bet that when anything changes, the whole directed graph is resorted. Compound that with the fact that two graphs can be exactly the same visually but result in different orderings depending on the order that the nodes and edges were created. Yikes!

@whale-av Let me rephrase your answers to test my understanding:

My test doesn't cause the slider to produce more intermediate values because I'm moving the slider really fast, and the logical time values are not meaningful because the slider is moved in real time, whereas the computer is free to process logical time faster than real time.

I've always suspected I was living in real time, but it's reassuring to have hard evidence

I combined your last test with mine, and got the same result. I'm concluding that metro intervals shorter than an audio tick preserve the order of processing, but the evaluation of the following graph may be bunched up in-between audio ticks, i.e. so fast that the slider is effectively not moving as it is being polled.

How did I do?

slider update rate 2.pd

Sorry to hijack this topic, but here's what I thought should be a simple control rate solution, but it looks like a slider only updates its own value every 8 mS. I was expecting to see 2.9 mS intervals.
slider update rate.pd

@CalBassist If [snapshot~] every 3 mS is too coarse-grained for you, the next and fastest thing you can get at control rate is 1.45 mS. Otherwise you're gonna have to switch to audio rate, which is what @oid suggested above when he mentioned [line~]. Another way would be to put [sig~] after the slider and then [slop~] or [lop~] its output. Edit: Note however that if you use [lop~] the output value may not reach its input value. I don't think [slop~] has that issue.

@Juicy-Jr Some additional thoughts:

• In case you thought otherwise, [block~ 1 1 1] does not oversample, it just makes the block size 1.
• You could apply the smaller block size to a subpatch or abstraction and isolate the feedback portion inside it. That way you only pay the CPU price for the stuff that needs it.
• MIDI 120 = ~8372 hz, and 44100/8372 = ~5, so [block~ 4 1 1] would suffice and be a bit cheaper. [block~ 8 1 1] would get you to MIDI 112.
• I know I'm in the minority, but I feel that my CPU works for me, not the other way around, so if something is computationally expensive, I don't worry about it until my machine can't keep up. Pd's load meter seems to exaggerate in Win10 because I routinely run at loads >100%. Finally, you can use [pd~] to distribute computation among several cores if necessary.

@Juicy-Jr Caveat: if you have feedback, then that ordering technique won't be possible. In that case, I think your best option would be to reduce the block size, e.g. [block~ 1 1 1].

@Juicy-Jr Are you making sure that delwrite~ is executed before delread4~? If not, I'm guessing that at sample rate 44100 and block size 64 your frequency can't go above 689 (44100/64). If I'm right, take a look at Pd vanilla help 3.audio.examples/G05.execution.order.pd.

@whale-av I'm guessing that when @KoaN writes about MIDI latency, what they are measuring is interval between when a MIDI note message is sent and the onset of sound from the plugin. That's why I'm curious about those audio settings, which I didn't see mentioned among their replies.

@KoaN In the File->Preferences->Edit Preferences... pop up, on the Audio tab, what have you selected for Delay (msec) and Block size?

@waffles If the patch is still popping because it's missing real time audio deadlines, try staggering the bangs from [metro 50] by substituting different length delays (e.g. 2, 4, 6, 8...) for the [bang] objects. That will distribute the control rate processing more evenly. Another thing to try is to delete any UI element you don't need. The patch stopped locking up my machine once I removed the vertical sliders near the AR oscillators. Finally, I noticed that sometimes it triggers a chime a couple of 50 ms intervals in a row, which is kind of a waste, so I added a 1 second lockout to ARosc~ to enforce a minimum interval between triggers. You can change the lockout time by changing the delay. ARosc~.pd

@waffles On Windows 10/Pd 0.55.2, this patch somehow prevents me from switching between windows or accessing the taskbar, except when task manager is open. I'm guessing it's related to the fact that all the bangs hanging off of the [sel 0]s are solidly on, suggesting that the patch is falling behind in the control domain and perhaps missing realtime audio deadlines in the audio processing. That would definitely cause clicks.

I also notice that the connections coming from each of those same bangs are not explicitly sequenced with a trigger object. I'm assuming the author intended [line] to jump to 1 first, which could also be a source of noise due to the discontinuity. Even if you took @seb-harmonik.ar's suggestion to replace it with [line~], that discontinuity would still be there.

If I could somehow get this patch to let me edit it, my first experiment would be to cut out most of the repetition to see how various subsets behave. I think that would give me a lot of information about why the patch is making so much noise.

Edit: just learned about the -noloadbang flag. <other silly BS deleted >

Another edit: Let me know if this works better for you--this version doesn't freeze my computer. calm-generative 4.zip I replaced the loadbang with a toggle so it wouldn't start immediately. I added abstractions for each LFO and each AR oscillator to help me see what was going on. The latter lengthens the attack to 20 ms (from 0) and also controls the final volume using the LFO signal itself, rather than the one sampled every 50 ms, in case that was the cause of the zipper noise you were hearing. I deleted the oscillators that weren't connected to the dac in case they were eating CPU. It should be easy to add them back in now that you have the abstractions. I combined all the metros into one in case it helps reduce the control rate processing, and in an earlier version I staggered the bangs by 2 ms, but that didn't seem to make a difference. Finally, I noticed some light, occasional clipping, mostly in the left channel, so I halved the signal.

FYI, an algorithm I was taught in school uses a heap-based priority queue for that B array. Makes it a bit faster in big-Oh terms.

@freq63 If you want to follow my suggestion, the issue is here in your Arduino code:

As @FFW was explaining, you are putting a single value on each line, but your Pd patch is looking for 4 values on one line. Try this instead:

for (int i = 0; i < 4; i++) {
  Serial.print(myArray[i]);
  Serial.print(" ");
}
Serial.println();

Serial.println() comes after the loop where it only outputs a line terminator once for all 4 values.

@freq63 +1 to @FFW, but your patch as is suggests you are sending the data incorrectly. On the Arduino side, try printing 4 floats on a single line separated by spaces, then terminate the line with /n (i.e. use Serial.println to terminate the line). You can see an example for 2 floats here: https://forum.pdpatchrepo.info/topic/13086/arduino-to-pd-vanilla/8

@H.H.-Alejandro In case you weren't aware, direct OSC messaging to/from Arduino is possible. This is the library I used https://forum.pdpatchrepo.info/topic/15621/iannix-open-sound-control-arduino. I've tested using an Uno with an ethernet shield but built my final version using a MKR1000, communicating with TouchOSC running on my phone over the phone's WiFi hotspot.

@ddw_music Just for fun, while I'm waiting on marching orders from a choreographer:
ULFNoise~ shift register version.pd

@ddw_music I didn't stare holes at your patch, but it looks to me like you are trying to generate ultra-low frequency noise. If I've guessed right, here's my solution: ULFNoise~.pd ULFNoise~-help.pd

Instead of a shift register, I just maintain a 64 sample array of noise and refill it when I'm nearing the end, taking care to copy the samples relevant to the last read point to the beginning of the array so it can pick up where it left off.

@ddw_music +1 to @alexandros' suggestion, but also--do you remember having this exchange? https://forum.pdpatchrepo.info/topic/14762/fidelity-of-tabread4/2
tabread4c~ doesn't have those non-differentiable points if that matters to you.

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