If you want to feed your signal back to the same object, you must use a [s~]/[r~] pair, otherwise Pd will correctly complain about a DSP loop. Also, I don't see any real reason for using [fexpr~], as you only reference the current sample of the input with x1[0]. If you did something like x1[-1] to reference the last sample. it would make sense, but the way you wrote this, [expr~] with $v1 should suffice.

If I'm not mistaken, iemguts is a collection of objects and doesn't come as a signle binary, which means that you only need to set its path to Pd's search paths. If you have it in your externals directory, which in turn is in Pd's search paths, then you can load an object with the library name prepended, like this: [iemguts/oreceive].

The image you posted is a bit too small to really figure out what's going on. Both for the clickiness and reading backwards, you can check this very old but still valid tutorial http://pd-tutorial.com/english/ch03s04.html
Actually, I would suggest going through the entire tutorial and not only this section. It covers a lot of ground.

You can find information on abstractions and the dollar arguments here http://pd-tutorial.com/english/ch05.html. Go to 5.1.1.2 which is focused on abstractions.

You'll might find the cyclone library useful. It clones a bunch of Max objects in Pd. Go to Tools->Find externals and type "cyclone" to get it.

The heavy compiler will behave the same way, whatever hardware you use. Using a Pi though, you can use Pd as is, without heavy. That being said, you can use any objects you like, whether native or externals.

PureVST-0.8 is out. This is Miller's message on the mailing list:

PureVST version 0.8 is out on the usual site:

msp.ucsd.edu/tools/purevst/

This might fix some of the bugs in previous versions. It's available as source, or compiled for "M" series processors in MACOS and for fedora linux (Intel processors), or you can compile your own binaries from the source tarball.

"pdnam" returns no results in deken (I'm not hidding foreign architectures, so it's not only the Linux binaries that don't show up).

gain is just a multiplication of a signal with some constant value in digital audio.

First of all, what you're sending to the oscilloscope is a sinewave oscillator, not your granular sampler. Second, we cannot know what is inside the oscilloscope subpatch (you can tell it's a subpatch because its name starts with "pd"). You can right-click on it and select "open" to see what's inside and why it doesn't show anything.
Wild guess, the "samples 1" is probably the number of samples to display. Only one sample is a single value, while you want a bunch of values to display. Try raising the number to something like 512. Otherwise, post a screenshot of the inside of this subpatch.

I just downloaded the Linux amd64 version and it loaded and played fine. Thanks for sharing this!
As for packaging, I think it's best if you create a different package for each architecture. I think that if you just upload each different architecture package with the same library name and version, deken should pack them under the same directory, so when you search for pdnam~ in deken, you'll get one directory with a drop-down menu including all different versions and architectures.

[canvasname] from iemguts. Aparenlty, if you give it an argument 1, it will spit the name of the parent patch out its right outlet.

Check vanillaUrn from here https://github.com/alexdrymonitis/miscellaneous_abstractions.

@willblackhurst how are recent vanilla versions a mess? What issues do they introduce?

I think Pof, which embeds openFrameworks (much like Ofelia did), runs on a different thread (I think). But I have tried closing its window and that crashes Pd. But I could be wrong, as I could be doing this the wrong way.
Switching back to another external that embeds OF, since you have switched from Ofelia to Gem, can be discouraging. I just thought of mentioning that Pof runs on a different thread (I think).

Did you try installing the externals on the second machine through deken, instead of transferring them?

What do you mean by "recompile"? When you install an external object through deken, there's no compilation going on, you're just downloading a pre-compiled binary file (the external object, not its source code) for your architecture (that would be macOS in your case). Are you sure the computer where you transfer your patches and externals has the same architecture as yours? What are the error messages you get?
I don't have a mac and it might be some issue with apple doing all this quarantine stuff, but I could be wrong in this.
Can you post the error messages you get?

Have you tried enabling "Init" in the toggle's parameters? Right-click on it and select properties. In the window that opens, under "Parameters", click the menu and select "Init". Probably you're aware of that and it might not work with abstractions though.

Can't you send 248 to [midiout]? That's the MIDI clock byte. Just setup a [metro] to the desired tempo and connect its outlet to a "248" message. Then use a MIDI interface to send that to your other devices.