@jameslo I just combined all your patches into one and they all behave like yours! I don't know what was going on earlier, perhaps a typo in [expr]? But I guess it wouldn't have been created. Now the numbers are toggling between 255 and 256 and 0 and 1.5258e-05, like your screenshots.

@jameslo The patch you provided indeed shows the bug. When clicking 44.1 the number on the bottom is 0. When clicking on 1 or 48, it's 1. But @ddw_music gave a very good explanation of why this is happening.

@jameslo for ceil. I only tried the patch of the screenshot in the first post.

On my machine, no matter how many times I switch between 1 and 44.1, I always get 0 after [expr].

I can't see anything wrong with it. The result before [expr] is 255 when using both 1 and 44.1 for the first division and the multiplication. Isn't this what should be expected?

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?