[chuck-users] phase modulation and hard sync?

[Jean Menezes da Rocha]

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 at gmail.com>
escreveu:

> 2017-06-03 15:01 GMT-03:00 Jean Menezes da Rocha <jean at 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 at gmail.com>:
>
>>
>>
>> 2017-06-03 15:01 GMT-03:00 Jean Menezes da Rocha <
>> jean at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20170604/f6f3ccc9/attachment-0001.html>