@whale-av Thanks! While searching for [coords( documentation I stumbled across [goprect( buried in the dynamic patching help. It looks like it's relatively new and doesn't set the dirty flag.

And unless there's a difference in how canvases are messaged, then it seems like the answer to my original question is that the [namecanvas] way let's you send to any accessible named canvas in the patch, whereas pdcontrol is just for the containing canvas and saves you the trouble of having to name it. Other than that they seem equivalent.

I'm sending a [donecanvasdialog....( message to a canvas to resize its GOP. It appears that I can either use [namecanvas] to create a receive on a particular canvas, or I can use the [sendcanvas...( message with [pdcontrol]. Which one should I use?

@ben.wes I like your mouse click logic + clipping better because you can drag outside the control to make things maximum or minimum.

For anyone else is trying to understand your patch, I want to correct my faulty explanation. Firstly, there are 2 canvases in the GOP area, one is the grey background that fills it, and one is a smaller white foreground. This latter one receives messages sent to $0-cnv, not the silly thing I wrote before, and its configured size has to be 1 so that vis_size can go to 1.

@ben.wes Woah! Look how similar my patch is and how little is missing:

I'm really more amazed by the missing part because it really drives home what I don't know! Wait, that didn't come out right. I mean it's like I'm standing next to the Empire State Building asking people "hey, where's is the Empire State Building?"

I can't find (in 10 minutes of happy hour searching) where either the pos or vis_size messages are documented, so here are my guesses from looking at your code:

• sending to $0-cnv sends messages to the containing canvas
• the visibility window just happens to have the exact same color scheme as Reaktor?!!! Unbelievable coincidence.
• the visibility window is anchored relative to its upper left corner, so that's why you did the pos message that way
• and the size of the window extends down and to the right of the visibility window anchor

How did I do, professor? All kidding aside, thanks so much.

This array of squares is allegedly from Reaktor 6, and they're xy controls. The lower left-justified white rectangle denotes where in the grey square the control point is.

How would you recommend I approach making something like this? I'd like the enclosing square to be GOP from an abstraction. I made something that gets the xy coordinates using else/canvas.mouse, but it doesn't display what the current xy value is. Do I have to try to learn data structures (again)?

PS: the actual sq/rectangle colors don't matter to me. I don't see an easy way to paint the GOP window some other color than white.

@whale-av HannahGen has got to be a bot, right?

@willblackhurst A million years ago I tried to interface a Wacom tablet to Pd and remember trying to find a version of [hid] that would work for my machine without success. I've never heard of a nanopad2 until now, but if I needed an x/y interface for a show that was breathing down my neck, I'd jump on it for $79 and its simple MIDI interface, Everything has a cost; it's either your money, or your time. Or both. That said, I'd be happy to be schooled on how to use [hid].

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

Edit 3: plugdata v0.9.2 on REAPER is identifying note on messages on channel 1 as being on channel 17 using [notein]. When using [midiin] it says it's on channel 2! Not an issue in v0.8.3 or Camomile.

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.