Gen~ Oopsy Looper Logic/Overdub Question

Will this need to happen into the inlet of a poke object? That’s the only way input into a data object, correct?

poke ops can be coded within codebox as within a gen~ patcher as visual versions...
if i recall correctly, everything in the visual object form within gen~ can actually be translated to an 'op' within codebox, including your 'data loop1' object.

a simple codebox to clear your 'data loop1' buffer would be this, but keep in mind, since i'm declaring the 'loop1' data/buffer within codebox here, you might want to delete the visual object version from the main gen~ patcher, and only have it within the codebox:Data loop1(768000);
if(in1>0)
{
    for(i = 0; i < dim(loop1); i += 1)
    {
        poke(loop1, i, 0);
    }
}
(i can't remember since i've not worked with these details in awhile but it's best to only have buffer/data/history ops declared once within a gen~ patcher, otherwise, since it's referring to a physical hardware memory-space, it might get confused, or rename things internally to create separate data spaces... other ops like 'poke' and 'peek' can have multiple copies of the same name, so long as you remember where everything is and delineate what they're doing separate from each other, should be fine...

many things like History, Data, Buffer, etc. will need to be capitalized in codebox, as this is more like a declaration of an instance from a class within code as with many other programming languages, whereas the visual version of ops in gen~ will be left lower case as that's in keeping with the visual-object style of Max proper)

we can test this out further by using buffer instead(just for a Max-patcher-only demonstration), and by having a buffer refer to a buffer~ in the outer max patch, will allow you to double-click on buffer/buffer~(you can double-click on the gen~ op, or on the outer max object to see[edit: oh but i use the buffer op in codebox, so i guess you can't double-click on this one within gen~ below, have to use the outer max-patch buffer~... i commented as such in the patch to make it clear :)]), and check it's empty after writing something in it, here i've created a quick patch that can help you understand just that:

{Edit: that test patch pasted above is not an efficient one at all, while leaving the toggle on, it's constantly writing the entire buffer~ with 0s, basically cycling through 256 samples at a time, clearing them to 0, within the timing of one-sample at sample-rate... but in your oopsy patch, you'll have a different triggering mechanism that hopefully only triggers it once(during one single sample, not constantly) whenever you need it... like [Param sw1] -> [delta] -> [< 0] -> [codebox]}

and finally, while the docs are extensive and can help a great deal, much of this i learned by clicking the 'C' icon in the right-hand toolbar, and looking at the code posted there after creating visual versions of what i wanted first, here's a pic that shows what i mean where i just highlight the one 'poke' object in your patch i wanted to research within the code(to remember what all the inputs are), and you'll see it highlights the equivalent line of code:

for your patch, i don't recommend just copying and pasting all that code shown within the 'C' icon's display into one codebox(gen~ will rename things with its own naming scheme that's very confusing for human-readability, and there's often redundant lines you don't need to write as much into codebox, even if it will translate into something more verbose for itself after you create something in codebox... and also, as it does this, it doesn't necessarily mean when it finally runs or exports to C++, that it will be less efficient(this is just the way it translates at first, then under-the-hood, will streamline for you)).
hope that all makes sense and helps 🍻

Thanks for sharing the Snoopsy (also my wife’s name) I’ll ... learn what I can...

cool name! (yes, one's wife is always the best to learn from, about all things in life) 😄