not that I know of, can you translate them into a 'note number' with some kind of lookup? (not that pd vanilla is great for maps..)
I guess you could use a big [select] or something to do that

zexy try using [declare -lib zexy]

@lacuna [tabplay~] can just accumulate an integer internally for the sample index as it doesn't need resampling/fractional indices
looks like [tabosc4~] does the essentially same thing as [osc~]
[loop~] uses doubles internally, but also outputs to a 32-bit float in the range 0-1, so similar issue to [phasor~]

maybe pd takes over some [command] process and blocks on it? dunno why it would be different on macos and linux though.. just a shot in the dark

internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.

Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.. https://github.com/supercollider/supercollider/blob/137cb4cd56f5bdf4484c9ad6761d4724dc8d7818/server/plugins/TriggerUGens.cpp#L134

I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit whereas when using phasor~ it is output as 32-bit and also scaled from range 0-1 as a 32-bit by multiplying by buffer size

If there were a Phasor equivalent in pd it might be comparable..
(and that also seems to be the case if [rpole~] gives similar results)
[vline~] should work as well

If your question is "why does the 1st command work when the 2nd one doesn't" you have to add the directory that contains pdreceive to your shell's PATH variable

@icarordp you need to install the mac command line tools and change the gcc command (might be able to replace w/ clang? plain 'gcc might work too). Right now it looks like it's trying to compile for iphone.
anyways the makefile seems quite outdated, barely anyone uses pd-extended (you also need some pd directory to link against and find m_pd.h)
You might have luck with a newer version of the makefile? Is it from your professor?
You can try transitioning the build system to use pd-lib-builder, which is standard these days https://github.com/pure-data/pd-lib-builder

Imo it's better design to supply it as an argument. I'd be curious what your use-case is, since the only reason you'd need it is sending, receiving, arrays, and texts. (and in those cases you would supply the full names as arguments bc it would make the abstraction reusable in other contexts)

Another reason is that it's better to make dependencies explicit in arguments because it's self-documenting behavior: if you or someone else opens your patch later they can tell which things depend on others just by looking instead of having to dig into the internals of the abstractions.

[text sequence] would be pretty much identical I think.
I've never tried it but you might have more luck using [binfile] (external) if you're worried about extra size & conversion

no I think you have to get the incoming frequency seperately because freqshifting uses a complex oscillator.
Once you have the incoming frequency you could scale it with multiplication.
btw frequency shifting is different from pitch shifting. In pitch shifting all the harmonics/frequencies are scaled by a certain amount whereas in frequency shifting they are just shifted, keeping the distance between frequencies/harmonics the same.
pitch shifting: f2 = f1*c where c is a multiplier and f1 and f2 are frequencies (e.g c is. 2 for an octave up) vs
frequency shifting: f2 = f1+c where c is a frequency