@oid Nah, I'm actually fine with what I've got, thanks. My issue is mostly with help.

@oid Yeah, I don't like having to keep those two texts sync'd either. It would've been even worse (but not uninteresting) if they had to change during the course of a run--I mostly use them for table-driven logic where they never change. OK, so you're saying you arrange for each line in the source [text] to only contain one message (with special sub-message separators that you've devised) and then copy to [list] to access the contents of each line? If I've understood you correctly, then may I assume you agree with me that [text] help is misleading?

(Actually, I think insert only inserts messages assuming they will be the last message on the line, which seems inconsistent with the way text is inserted in [text define])

The top-level help for [text] suggests that you can access and manipulate its contents by line, but is that really true? [text] seems to be message oriented and the line structure is just a side-effect of what terminators (comma or semicolon) are bound with each message. One has to add extra plumbing to make [text get] behave as though it were line oriented, e.g. "please return the 2nd message on the 5th line".

Follow up: OK well, as far as I can tell, here's what I have to go through to make [text get] line oriented. I happened to notice that if each line only contains one message and all messages contain the same number of atoms, then the contents start to resemble a 2D table. So I made such a table that contains the message indexes of the irregular table that I'm really interested in, i.e. the former table helps me translate line indexing to the kind of message indexing that [text] prefers. See what I'm sayin'?
text by line.pd

@Moothart If your values really are just small integers, then you could use an array to indicate whether a value is in or out of the set. In this case, n is in the set if the nth element of the array is non-zero.
set inclusion.pd

@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.