@avenir Look! I know Italian!

Here's what I mean. All the connections in the shaded area are 2 channel snakes, so you only have to multiply, throw~, and catch~ once. But the other way works too.

@crttrkix I think you're still a little off WRT subpatches, and I'm enjoying the crazy c++ metaphors, so I'll continue as if you asked a question . In Pd, an abstraction is like function, and since it's in a separate file, it's like a function in a separate compilation unit that has to be linked in (or in Pd's case, loaded). But a subpatch is more like bracketed code--not that it introduces a new scope (it doesn't, e.g. $0 is the same value inside and outside of a subpatch) but that it's really just a graph that's been hidden except for its inputs and outputs. That's why [pd mySubpatch-$1] is just a renaming of the subpatch--it's just a labelled section of code.

@avenir FYI, you know how you are applying the grain envelope to the output of snake~, 1 for each channel? You could also just apply it to the snake once and it affects both channels. That's the point of snake~--to help reduce uninteresting duplication.

@avenir No, you can duplicate the tabread4~ objects each with its own table, or you can use one tabread4~ object and specify 2 tables to read from, in which case the output of tabread4~ is a snake. Look at tabread4~ help and click on the multichannel support subpatch.

@avenir said:

My idea is to duplicate the existing array and the corresponding tabread4~ object

Yep, that's the right approach. [soundfiler] can fill the left and right channel tables in one call, and if you want, you could also specify left and right tables for a single tabread4~ object, and then the output would be a 2 channel snake (see [snake~]).

@avenir I think you might have uploaded the wrong patches. I only see one array called "source-array" and only one mono tabread4~ object.

@crttrkix
I don't 100% understand what @whale-av wrote, so this response may just repeat an idea @whale-av already gave you. But maybe not. I agree that

all you have done is change the name of the sub-patch.

So why not instead change the name of an object within your subpatch using the argument to the enclosing abstraction? The analogy isn't perfect, but it's sort of like passing a function pointer, and the weird object inside the abstraction is like an abstract superclass but for a single function. OMG that was too complicated to be helpful

@dreamer I'm not so much scared of the concept of a chat room as I am incredulous that that would be the preferred format for technical discussions. Over here, people apologize for digressing and sometimes have a hard time following along! OK, let's see if anyone over there lectures me about cross-posting

Edit: I immediately got my answer from that scary chaotic place known as Discord . Use [plugin_latency].

Edit 2: But that object doesn't exist in v0.8.3, and I can't get v0.9.2 to work in REAPER. MIDI doesn't seem to be passed out of the plugdata to the next VST properly.

Thanks @jyg, I've been looking! So I'm thinking of posting in either #plugdata-questions or #plugdata-issues, except that it looks like my question will just get tacked on to the end of a flat, unstructured list of questions, comments, and replies, is that correct? It looks like there are very few "threads" so I'm assuming you don't need to create one in order to not interrupt an ongoing discussion, correct? It's like a room where everyone is having a different conversation but you hear them all. And that one line text box at the bottom of the page is all you get to enter your question, even if there are tons of technical details?

@jyg I haven't. I have never been able to understand discord, it. It looks like one big stream of consciousness babble to me. I'll give another look.

(I asked my friend who is a decade or two younger to explain discord, and he said it was like talking to a TV )

@jameslo OK, well...I decided to fall back to Camomile in order to regain the ability to set the latency programmatically. I had to replace a few facilities that didn't work under Pd 0.51 (the latest version that the latest version of Camomile supports), but I don't miss them, and nor do I miss having to recalculate and set the latency by hand. If anyone is making plugins with variable latency using plugdata I would be grateful to hear how you achieved it.

@impression You can use [s~] and [r~] to feedback audio to an earlier point in the patch, but there is a one block delay. To minimize that delay, you reduce the blocksize using [block~], but that's incompatible with [adc~] and [dac~], so you have to isolate the feedback portion in a subpatch or abstraction, like this:
audio feedback.pd

Play with different powers of 2 block sizes (e.g. 16, 32, 64) to hear what the delay is contributing.

In plugdata v0.9.2 hosted on REAPER v7.48 running on both Windows 10 and 11, I can't set the plugin's latency under Settings...->Latency (samples). When I enter the number of samples and close the dialog box, it immediately reverts to 0 and REAPER reports a plugin delay compensation amount of 64 samples which is what it reports when plugdata is first loaded. I fell back to plugdata v0.8.3 on my Win10 machine and was again able to set the latency, so there's my workaround.

Surprisingly, if I copy that same REAPER project hosting plugdata v0.8.3 over to the Win11 machine that has plugdata v0.9.2, it retains the latency I set on the Win10 machine, but as soon as I try to edit it, it reverts to 0.

Anyone else seeing this issue?

I'd also love to know if there is a way of setting the plugdata latency setting within Pd. My patch has a look-ahead detector, and when I change the look-ahead amount, the latency has to change accordingly.

@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