I don't know any C++, so I'll just speak to what its doing in gen, as I understand it. You can use a counter, or accumulator to simulate a phasor in gen, by taking into account sample rate, and wrapping the count at the appropriate value basd on the frequency value.

Here's a very crude gen~ phasor with nothing but arithmetic in codebox:

History count(0); frequency = in1; length = samplerate/frequency; count = count + 1; out1 = (count % length)/length;

That's all good, but what I don't get is how you can have more than one call to phasor in the same gen code box.

does each phasor magically have a unique set of all of those variables? frequency,length,count?

so if I did this: my_frequency_1 = 40; my_frequency_2 = 1000;

phasor_val_1 = phasor(my_frequency_1); // this is a phasor phasor_val_2 = phasor(my_frequency_2); // this is another instance of phasor phasor_val_1 != phasor_val_2 // resolves to true?

so each call to phasor is magically a unique instance?

Yeah it won't resolve to true unless th phasors start at the same time and have identical frequencies. I'm no expert, but I don't think its magic.

phasor(x){ History count(0); length = samplerate/x; count = count + 1; return (count % length)/length; } out1 = phasor(in1); out2 = phasor(in2);

That will give you two different phasors. I don't know enough about the low level memory allocation stuff going on, to comment on exactly how or why this works.

Ok, so I am overthinking this. Phasor is just a function, not an object, not an instance of some oscillator class.

it is like a counter object. and, as you know, is aware of the current samplingrate, so there are the two variables you need. :) (the count is always the same...)

I am not overthinking this. After implementing the suggested code by Evan, I got results that differ from Max/MSP/Gen.

In Max/MSP/Gen, each call to phasor is indeed a unique oscillator. With Evan's code, changing frequency also changes phase, because there is no memory of phase in Evan's code. In Max/MSP/Gen, increasing frequency simply makes the phasor run faster rather than jerk around like Evan's code (jerking is result of changing phase).

I guess you'd need to keep track of phase separate to freq, with a phase variable expressed as a float between 0 and 1, so if freq is changed, you reset the count according to the current phase fraction

I created this C++ class:

looks eloquent, when frequency changes you alter the increment (phase_inc), while keeping the current accumulation (phase), and your phase is between zero and 2pi which is perhaps more useful than between 0 and 1

Was away for the weekend - sorry I missed the developments. I didn't include any phase handling, because I didn't want to take all the fun ;).

Although it seems you've already got it sorted rather well. my two ideas for handling phase would be to (1)only update at the end of a cycle ( less flexible, but more syncable), or (2) sample the phase when the frequency changes, and then reset the count with the new frequency, while adding an offset equal to the previous phase.

I didn't even think of altering the increment....

Wait... WTF... my phasor is not 0 to 1?!?! I didn't think about that!.. that could explain why none of my gen-to-C++ has been working.