I managed to install SuperCollider and run your example of Phase Modulation. I could achieve the exact same sound with the following ChucK code:

SinOsc mod => SinOsc car => dac;

400 => car.freq;
201 => mod.freq;
mod.freq() * Math.PI => float ind => mod.gain; // this bugger works with much greater values as standard gain...
2 => car.sync; // FM instead of syncing to phase. don't know why...

while ( true ) {
    1::second => now;
}

The weird thing is that I had to use 2 (FM) as a value for .sync, contrary to my intuition of syncing to phase. Another oddity is the way to calculate the modulation index, which I admit was a wild guess that turned out to be correct. I am also curious if anyone can explain this.

Anyways, the example above sounded exactly like your SC code, and now it responds to changes in the carrier signal, which was what you wanted at first place.

However, I am now the one struggling to figure out the difference between this phase modulation and FM, since the method used had to be the same as used for Frequency Modulation... syncing to phase, as was my first intuition, yields a rather different sound (much harsher) and does not respond to changes to the carrier's frequency.

Hope it can get you going, anyways!

Em sáb, 3 de jun de 2017 às 23:36, Jean Menezes da Rocha <jean@menezesdarocha.info> escreveu:
Alexandre,

the thing is that SuperCollider does the iteration stuff automatically for you. In ChucK you have to iterate manually to achieve the same effect. I think your SuperCollider example could adapt as follows:

SinOsc car;
SinOsc mod;

400 => car.freq;
201 => mod.freq;
2 * Math.PI => float ind => mod.gain; // I don't know if using PI is relevant here, or linear values between -1 and 1 would suffice!

car => dac;
mod => blackhole;

while ( true ) {
    ind * mod.last() => car.phase;
    1::samp => now;
}

I think advancing time at sample level is the key, as we are using .last() to get accurate values from the modulator. Anyways it indeed does not respond to changes in the carrier's frequency, which is not what you expect. Changing the modulator's frequency, however, does effectively change the resulting sound. I honestly don't know if this is just a plain difference to each language's approach, or if ChucK has another method to hard sync stuff that we are missing here.
Please observe that in this example we are not using the .sync parameter; instead we are mapping values for every sample directly to the carrier's .phase parameter.
Unfortunately I don't have SC installed here so I cannot compare results. Please let me know.

Good luck!

Em sáb, 3 de jun de 2017 às 19:04, Alexandre Torres Porres <porres@gmail.com> escreveu:
2017-06-03 15:01 GMT-03:00 Jean Menezes da Rocha <jean@menezesdarocha.info>:
Unfortunately, my knowledge of SuperCollider is very limited and I don't feel like I'm able to translate your code.

Here's an attempt to make SC code clearer.

Here's the fm example I found in chuck, using sync = 2

////////////////////////////////////////////////////

SinOsc m => SinOsc c => dac; // modulator to carrier

400 => c.freq; // carrier frequency

201 => m.freq; // modulator frequency

1500 => m.gain; // modulation index

2 => c.sync; // FM synthesis (sync is 2)

while( true ) 1::second => now; // time-loop

////////////////////////////////////////////////////


And now for the SC equivalent


////////////////////////////////////////////////////

{var carrier = 400; // carrier frequency

var modulator = 201; // modulator frequency

var index = 1500; // modulation index

var m = SinOsc.ar(modulator) * index; // modulating signal

var c = SinOsc.ar(carrier + m); // frequency modulation (carrier + modulating signal)

Out.ar (0, c ! 2)}.play

////////////////////////////////////////////////////


and now a phase modulation example in SC


////////////////////////////////////////////////////

{var carrier = 400; // carrier frequency

var modulator = 201; // modulator frequency

var index = 2pi; // modulation index

var m = SinOsc.ar(modulator) * index; // modulating signal

var c = SinOsc.ar(carrier, m); // frequency modulation (carrier + modulating signal)

Out.ar (0, c ! 2)}.play

////////////////////////////////////////////////////


note, the SinOsc in SuperCollider takes frequency input as the first variable in parenthesis, and phase (in radians) in the second.


cheers


2017-06-03 15:31 GMT-03:00 Alexandre Torres Porres <porres@gmail.com>:


2017-06-03 15:01 GMT-03:00 Jean Menezes da Rocha <jean@menezesdarocha.info>:
Alexandre,

As far as I understand it, the .sync attribute is more like an identifier, rather than a true numeric value (that is, 0 says you are syncing frequency with frequency; 1 says that you are syncing phase with frequency; 2 says you are doing true Frequency Modulation). As you are telling that no value means no sound, one can infer that there is no default value for that, and if you are feeding UGen => UGen, telling which is your sync method is mandatory (but I can be mistaken, as usual).
 
there may be a default parameter, right? And that seems to be 0. If I have sync at "0", I hear no sound.

Anyway, it doesn't seem like the sync parameter is able to do hard sync. It seemed that the "0" value would do that, but, as I said, I hear nothing.

If phase input is linear in chuck, then the code from SuperCollider would be equivalent, but it is not. And even if it wasn't linear, I tried it with radian values and did not get the same results.

I suspect it is not really doing phase modulation because it doesn't matter if I change the carrier frequency, and that is weird.

well, I guess I'm repeating myself, sorry, just anxious in the hope of clarification.

thanks

--
Jean Menezes da Rocha
Compositor
Professor
Doutorando em Música pela Universidade Federal da Bahia
--
Jean Menezes da Rocha
Compositor
Professor
Doutorando em Música pela Universidade Federal da Bahia