@jamshark70 I was describing this:
for what I can see, its passing the signal from the phasor to the div function, I don’t know how it actually makes the division, but the phasor is running at a “rate”, not a frequency (it may sound the same but one is sampled based and the other is cycles per seconds), so the only way to divide the signal of a phasor is to know at which rate is running, or maybe there is a way to measure the rate of a signal that Im not aware of.
My main problem is that I see computer music as a stream of numbers, and the timing should always be sample based to ensure synchronicity. But Collider’s architecture makes it impossible cause sending a message and retrieving, delays the information. Or in your example, you will have to trigger the SendReply each sample to be sure the information you are getting is the one you wanted. And of course this is not possible cause you will saturate the server with thousands of requests.
Im kind of starting to see that maybe supercollider is not adequate for what I want to do, I really want to go sample based synthesis and in supercollider is really difficult to do this.
For example:
(
p = ProxySpace(
clock: t = TempoClock(90/60).permanent_(true)
).push;
)
p.quant_(4);
~clock1 = { Impulse.ar(2, 0) };
~clock2 = { Impulse.ar(4, 0) };
~clock1.quant_(4);
~clock2.quant_(4);
~clock1.play;
~clock2.play;
~clock2 = { Impulse.ar(2, 0) };
As far as I know, this would make the changes in clock2 and clock1 stay in sync when I change the NodeProxy, but it doesn’t happen, they get out of sync when I change ~clock2 at the last line. You can execute the last line several times to see what I mean, even if it waits to the quantization.
I want to create phase distortion synthesis, or hard sync with custom oscillators but really is super difficult. I like that supercollider has the biggest community, and that it has a huge library of objects, but it really lacks in sample precision. It’s just my opinion, maybe it’s because I don’t know certain tricks or Im thinking everything wrong.
Thanks for the reply btw.