- chuck-users - lists.cs.princeton.edu

linux build failure, qt5 support?
by Colleen Josephson 13 Oct '17

13 Oct '17

I'm trying to run 'make linux-jack' in miniAudicle1.3.5.2's source directory, and the build fails nearly immediately with: which: no qmake-qt4 in (/home/cjoseph/anaconda2/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/usr/x86_64-pc-linux-gnu/avr/gcc-bin/4.8.2:/usr/x86_64-pc-linux-gnu/gnat-gcc-bin/4.3:/usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.3:/usr/games/bin:/usr/local/ec2/ec2-api-tools-1.6.13.0/bin:/home/cjoseph/piran/platform_util) .... In file included from qt/mAMainWindow.cpp:25:0: qt/mAMainWindow.h:28:23: fatal error: QMainWindow: No such file or directory #include <QMainWindow> The website just specifies qt4.8+, I currently have Qt 5.6.2. Is there any QT5 support? QT5 has been out for 5 years now and it's nearly impossible to downgrade, so I am really hoping the answer is yes! Thanks, -Colleen

2 1

what exactly is tuned feedback?
by Michael Heuer 12 Oct '17

12 Oct '17

All, The Dave Smith DSM03 Feedback module has what is described as tuned feedback https://www.davesmithinstruments.com/product/dsm03-feedback-module/ I have the same question as was posted here "I'm trying to understand what 'tuned feedback' means -- does this mean the signal enters a delay line that lasts one cycle of a certain pitch? (So, say, a 50Hz sound is a 20ms delay line.) Does this end up reinforcing that pitch when you hear the sound? (I guess it would reinforce multiples of the pitch too, but less so.)" https://www.kvraudio.com/forum/viewtopic.php?p=1673572&sid=ae6a060ebaffea26… Thanks! michael

2 2

Wrap/Modulo UGen
by mario buoninfante 02 Aug '17

02 Aug '17

Hi All, do you guys know if there's a Modulo/Wrap Ugen? I'd like to use the same Phasor to read 2 or more different arrays (Wavetable UGen), but I must read them from a different starting point. cheers, Mario

1 0

Re: [chuck-users] phase modulation and hard sync?
by mario.buoninfante 05 Jun '17

05 Jun '17

Hi Alexandre, If you look at the complete formula here (under "spectral analysis" - for sure it is better then my explanation): https://en.wikipedia.org/wiki/Frequency_modulation_synthesis?wprov=sfla1 You can see that alongside the Carrier Frequency there's the phase. This one is a sine wave (that goes from -1 to 1). Now we can consider SinOsc on ChucK, the same that the first sin in the formula above. Everything is feeding SinOsc in ChucK can be considered the same that all the stuff into parenthesis. Thus the argument you pass to SinOsc ( oscil.freq(certainFreq) ) is the Carrier Frequency (a fixed argument) and the the signal coming out from the Fm oscillator (scaled with a given value Am/Fm or ModInd, it is the same) is modulation factor that makes the Carrier Freq oscillate. Now 2pi is needed only if you deal with a ramp, with a phasor. Cause Phasor*2pi gives you a sine. If you already have a sine there is no need to use 2pi. Cheers, Mario Sent from my Wiko ROBBYOn Jun 4, 2017 17:20, Alexandre Torres Porres <porres(a)gmail.com> wrote: > > 2pi is already there if you are using a phase input, cause it seems the phase is normalized (0 to 1 instead of 0 - 2pi) in Chuck. > > What I mean is how to implement the same result with both frequency and phase modulation in a Chuck code, using SinOsc. > > All these things have to be adjusted > > But if the phase input wasn't normalized to 0-1, like is the case with SuperCollider, you don't need it. > > cheers > > 2017-06-04 13:09 GMT-03:00 mario.buoninfante <mario.buoninfante(a)gmail.com>: >> >> Hi Alexandre, >> >> In my implementation there's no need to use 2pi. That is required if you're using a phasor (in math terms). In that case you need 2pi to have the angular frequency. But if you're using instead a Sine wave there's no need, cause 2pi is already there. >> Looking at the formula I posted before, the Fm oscillator is the phase parameter, while the Cm is the frequency. You can consider them as an offset (Cm) and an deviation from it (Fm). >> The index mod is equal to Am/Fm, but of course the parameter that you can use with an oscillator is the amplitude (Am), thus from the previous one you have Am = Fm*modInd >> >> Cheers, >> Mario >> >> Sent from my Wiko ROBBY >> >> On Jun 4, 2017 16:39, Alexandre Torres Porres <porres(a)gmail.com> wrote: >>> >>> btw, for adjusting the index, you're just multiplying the frequency to the index, you should also multiply it by 2pi (like Jean found out by accident). >>> >>> >>> 2017-06-04 12:29 GMT-03:00 Alexandre Torres Porres <porres(a)gmail.com>: >>>> >>>> >>>> >>>> 2017-06-04 4:24 GMT-03:00 mario buoninfante <mario.buoninfante(a)gmail.com>: >>>>> >>>>> this is the simplest modulation, that usually is considered as FM, but in the end is a PM. >>>> >>>> Well, as I see it, it should be either FM or PM, it can't be one but in the end is something else. And your code is can only (not usually) be considered FM. >>>> >>>> But it seems you're saying both are related, without getting into details - which is something we've already discussed here, and I've also pointed out (with no details either). But the bottom line is that they're different, and the same input parameters generate different results. Though I've said before the parameters can be "converted"/"adjusted" to sound the same. >>>> >>>> Namely, the same modulation index does not generate the same result (Jean noticed that), and I can add the detail that the same modulating signal/waveform generate different results too. For example, a triangular wave modulating the phase is the same as a square wave modulating the frequency. So, they're quite different. >>>> >>>> In terms of sine waves, what we've been doing so far, if you modulate the phase with a sine wave, you need to modulate the frequency with a cosine wave. >>>> >>>> Like I pointed before, if you're going for a phase modulation implementation, you should just modulate the phase instead of trying to replicate it via frequency modulation, cause it's just more convenient to do directly via phase modulation if you want it to behave like that. >>>> >>>> And that not

3 3

Re: [chuck-users] phase modulation and hard sync?
by mario.buoninfante 05 Jun '17

05 Jun '17

Hi Alexandre, No worries, I know it's not a challange ;) . Btw for sure, what I tried to say wasn't clear. The implementation I sent you is a Phase Modulation, not a Frequency Modulation. You can have a PM also if you don't use SinOsc with sync(2), you're still changing the phase and not the frequency using my ChucK program. The last thing, the example you sent before, with a Phasor controlling the phase, also in that case ModInd doesn't need any 2pi, cause when you said the phase in SinOsc is normalized (from 0 to 1), it means there is a 2pi in there. But it's ok, if I get it right, you simply wanna have PM with that specific configuration, Phasor and SinOsc with sync(2). Cheers, Mario Sent from my Wiko ROBBYOn Jun 4, 2017 22:44, Alexandre Torres Porres <porres(a)gmail.com> wrote: > > 2017-06-04 13:59 GMT-03:00 mario.buoninfante <mario.buoninfante(a)gmail.com>: >> >> Now 2pi is needed only if you deal with a ramp, with a phasor. Cause Phasor*2pi gives you a sine. If you already have a sine there is no need to use 2pi. > > Hi, let me try to be clearer. Phasor * 2pi going through a sine function gives you a sine wave. SinOsc can also be drive by a Phasor. Such as this. > > Phasor p => SinOsc osc => dac; > > 440 => p.freq; > > 1 => osc.sync; > > 4::second => now; > > > In this case, you get a sine wave and you don't need to multiply the phasor by 2pi, because the input is normalized, from 0-1 > > > What I was trying to say is that if you have a modulating index in phase modulation, and you want to replicate it in frequency modulation, you alsop need to multiply it by 2pi. > > I'm not challenging the math or equations, just adding an implementation detail in Chuck code. I know I wasn't clear about it, sorry. Hope it's clear now. > > But my main point was something else. It is true that if you multiply the index value by the modulation frequency value, such as in your code, you sort of get a similar behaviour than you'd get with phase modulation. But there's another detail missing if you're to really convert it. > > One thing about this conversion is that the waveform/function of the modulation signal needs to also be adjusted. In terms of sine waves, if you have the phase signal being modulated by a sine wave, you need to modulate the frequency with a cosine wave. > > With other waveforms it gets more complicated. By the way, the rule of thumb (multiply the index by the frequency) also changes, that is important to note as well. > > My main point is just that it's just best to implement via phase modulation, if that's the behaviour you want. > > cheers

1 0

Re: [chuck-users] phase modulation and hard sync?
by mario.buoninfante 04 Jun '17

04 Jun '17

Btw this seems to be the best explanation I found around: http://msp.ucsd.edu/techniques/v0.11/book-html/node79.html As you can see, the phase modulation deals with a phasor when this is controlling a wavetable. That means the phasor reads all the points in it. But in our case the table is not visible,cause it can be considered as embedded into SinOsc. Cheers, Mario Sent from my Wiko ROBBYOn Jun 4, 2017 17:20, Alexandre Torres Porres <porres(a)gmail.com> wrote: > > 2pi is already there if you are using a phase input, cause it seems the phase is normalized (0 to 1 instead of 0 - 2pi) in Chuck. > > What I mean is how to implement the same result with both frequency and phase modulation in a Chuck code, using SinOsc. > > All these things have to be adjusted > > But if the phase input wasn't normalized to 0-1, like is the case with SuperCollider, you don't need it. > > cheers > > 2017-06-04 13:09 GMT-03:00 mario.buoninfante <mario.buoninfante(a)gmail.com>: >> >> Hi Alexandre, >> >> In my implementation there's no need to use 2pi. That is required if you're using a phasor (in math terms). In that case you need 2pi to have the angular frequency. But if you're using instead a Sine wave there's no need, cause 2pi is already there. >> Looking at the formula I posted before, the Fm oscillator is the phase parameter, while the Cm is the frequency. You can consider them as an offset (Cm) and an deviation from it (Fm). >> The index mod is equal to Am/Fm, but of course the parameter that you can use with an oscillator is the amplitude (Am), thus from the previous one you have Am = Fm*modInd >> >> Cheers, >> Mario >> >> Sent from my Wiko ROBBY >> >> On Jun 4, 2017 16:39, Alexandre Torres Porres <porres(a)gmail.com> wrote: >>> >>> btw, for adjusting the index, you're just multiplying the frequency to the index, you should also multiply it by 2pi (like Jean found out by accident). >>> >>> >>> 2017-06-04 12:29 GMT-03:00 Alexandre Torres Porres <porres(a)gmail.com>: >>>> >>>> >>>> >>>> 2017-06-04 4:24 GMT-03:00 mario buoninfante <mario.buoninfante(a)gmail.com>: >>>>> >>>>> this is the simplest modulation, that usually is considered as FM, but in the end is a PM. >>>> >>>> Well, as I see it, it should be either FM or PM, it can't be one but in the end is something else. And your code is can only (not usually) be considered FM. >>>> >>>> But it seems you're saying both are related, without getting into details - which is something we've already discussed here, and I've also pointed out (with no details either). But the bottom line is that they're different, and the same input parameters generate different results. Though I've said before the parameters can be "converted"/"adjusted" to sound the same. >>>> >>>> Namely, the same modulation index does not generate the same result (Jean noticed that), and I can add the detail that the same modulating signal/waveform generate different results too. For example, a triangular wave modulating the phase is the same as a square wave modulating the frequency. So, they're quite different. >>>> >>>> In terms of sine waves, what we've been doing so far, if you modulate the phase with a sine wave, you need to modulate the frequency with a cosine wave. >>>> >>>> Like I pointed before, if you're going for a phase modulation implementation, you should just modulate the phase instead of trying to replicate it via frequency modulation, cause it's just more convenient to do directly via phase modulation if you want it to behave like that. >>>> >>>> And that not

1 0

Re: [chuck-users] phase modulation and hard sync?
by mario.buoninfante 04 Jun '17

04 Jun '17

Hi Alexandre, In my implementation there's no need to use 2pi. That is required if you're using a phasor (in math terms). In that case you need 2pi to have the angular frequency. But if you're using instead a Sine wave there's no need, cause 2pi is already there. Looking at the formula I posted before, the Fm oscillator is the phase parameter, while the Cm is the frequency. You can consider them as an offset (Cm) and an deviation from it (Fm). The index mod is equal to Am/Fm, but of course the parameter that you can use with an oscillator is the amplitude (Am), thus from the previous one you have Am = Fm*modInd Cheers, Mario Sent from my Wiko ROBBYOn Jun 4, 2017 16:39, Alexandre Torres Porres <porres(a)gmail.com> wrote: > > btw, for adjusting the index, you're just multiplying the frequency to the index, you should also multiply it by 2pi (like Jean found out by accident). > > > 2017-06-04 12:29 GMT-03:00 Alexandre Torres Porres <porres(a)gmail.com>: >> >> >> >> 2017-06-04 4:24 GMT-03:00 mario buoninfante <mario.buoninfante(a)gmail.com>: >>> >>> this is the simplest modulation, that usually is considered as FM, but in the end is a PM. >> >> Well, as I see it, it should be either FM or PM, it can't be one but in the end is something else. And your code is can only (not usually) be considered FM. >> >> But it seems you're saying both are related, without getting into details - which is something we've already discussed here, and I've also pointed out (with no details either). But the bottom line is that they're different, and the same input parameters generate different results. Though I've said before the parameters can be "converted"/"adjusted" to sound the same. >> >> Namely, the same modulation index does not generate the same result (Jean noticed that), and I can add the detail that the same modulating signal/waveform generate different results too. For example, a triangular wave modulating the phase is the same as a square wave modulating the frequency. So, they're quite different. >> >> In terms of sine waves, what we've been doing so far, if you modulate the phase with a sine wave, you need to modulate the frequency with a cosine wave. >> >> Like I pointed before, if you're going for a phase modulation implementation, you should just modulate the phase instead of trying to replicate it via frequency modulation, cause it's just more convenient to do directly via phase modulation if you want it to behave like that. >> >> And that noted, several FM modules are not actually implemented via frequency modulation, but phase modulation (i.e DX7 and native's instruments FM8). >> >> Anyway, performing FM in Chuck is easy and straightforward, it was never a question. The relationship between FM and PM was known and does not really mean they're both the same thing. >> >> Hence, there's still a need to quest for an easy implementation of phase modulation. >> >> cheers > >

2 1

phase modulation and hard sync?
by Alexandre Torres Porres 04 Jun '17

04 Jun '17

Hi, new to chuck here. Can SinOsc be hard synced by an impulse or something? And how would you do phase modulation with SinOsc? If you cannot do one or both with SinOsc, how would you do it? thanks

4 20

Chuck support for visual components sliders etc
by Ian Dickinson 18 May '17

18 May '17

Hi i qm a complete newbie to chuck and was looking for a way of impkementing a graphical interface for chuck i.e to allow the addition of visual controls say sliders for controlling adsr values etc Thanks Ian Sent from Samsung tablet.

3 2

OscOut string encoding
by Stuart McDonald 18 Apr '17

18 Apr '17

I have a Heath Robinson/Rube Goldberg contraption which has a ChucK program sending an OSC message to a nodejs app which is broadcasting data to a web browser client via web sockets. My problem is that by the time the OSC messages get to nodejs the string "Höckerschwäne" is converted into "HC6ckerschwC$ne". ChucK itself can print non-ascii characters ok so I'm guessing the problem is with OSC itself. The OSC 1.0 spec (http://opensoundcontrol.org/spec-1_0, link to 1.1 spec is dead) suggests ASCII only is supported for strings, although punycode is mentioned on other OSC pages (I tried punycode decoding the strings and they display gibberish). I'm wondering if the artefacts are just 16 bit characters being naively encoded as two separate ascii characters, or something similar. Anyway, I'm asking here in the (perhaps unlikely) event anyone else had been down this road before. I'm getting around the problem by doing some string replacing at the nodejs end: not ideal, but there's I've only got 3 non-ASCII characters in the mix so good enough for now. Cheers Stuart

2 1