[chuck-users] phase modulation and hard sync?

Sat Jun 3 23:47:38 EDT 2017

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 at 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 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
>
-- 
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/7241dbd5/attachment.html>