I'm working on a subtractive synthesis program written in ChucK, and I'm not sure, I may have sporked one too many threads, it may be that I'm just not resetting some parameter, but I'm getting some clicking noises in my latest program... I guess my first question is in general, what would cause a clicking or popping noise first of all... The synth is three square waves, slightly detuned and out of phase with each other, and there's a high-to-low LPF and HPF filter acting on the note as it attacks and decays, but it seems to only click *sometimes* and specifically when I hit a low note and then go up to a high note. If I disable filter sweeping entirely, it seems to get rid of some of the clicks, but not all of them. The program is based on the example "polyfony.ck" but it's quite a bit larger now (approx 700+ lines)... Some other notes of concern, each note handler thread (of which there are 20) sporks it's own threads to modulate some parameters, so being 20 note handlers + three threads per note handler + a few other threads (such as the midi watcher), I've got almost 90 threads running at one time, could that be part of the issue? - Johnathan
Jonathan; I guess my first question is in general, what would cause a clicking or
popping noise first of all...
Either discontinuities in the wave-form that you synthesise or CPU load issues. Both are potentially fairly involved subjects.
Some other notes of concern, each note handler thread (of which there are 20) sporks it's own threads to modulate some parameters, so being 20 note handlers + three threads per note handler + a few other threads (such as the midi watcher), I've got almost 90 threads running at one time, could that be part of the issue?
That sounds like suspect #1 right now, yes. Check your cpu load; on Windows you can use "TaskManager" (found under the ctrl+alt+del menu unless they changed it), on Linux and OSX you can run "top" at your terminal. There are likely other ways too, but I use those. If that's it we'll have to talk about the structure of the program; that might get complicated but it might be fun too, Then again; in the case of discontinuities (a fancy words for your wave making a "vertical jump") it might get tricky too. See how far you can get on your own. If you get stuck you may need to send the most simple version of your code that still has these clicks to the list and we can have a look. Could be that it's something simple, but it could also be that you are asking too much; there is always a limit to the cpu power, it might be at two sines, it might be at two modelled full orchestras but there is some limit where it will click.... Yours, Kas.
On Jun 11, 2011, at 5:57 PM, Kassen wrote:
Jonathan;
I guess my first question is in general, what would cause a clicking or popping noise first of all...
Either discontinuities in the wave-form that you synthesise or CPU load issues. Both are potentially fairly involved subjects.
That makes sense, both discontinuities and that they're fairly involved subjects...
Some other notes of concern, each note handler thread (of which there are 20) sporks it's own threads to modulate some parameters, so being 20 note handlers + three threads per note handler + a few other threads (such as the midi watcher), I've got almost 90 threads running at one time, could that be part of the issue?
That sounds like suspect #1 right now, yes. Check your cpu load; on Windows you can use "TaskManager" (found under the ctrl+alt+del menu unless they changed it), on Linux and OSX you can run "top" at your terminal. There are likely other ways too, but I use those.
Top (on my mac) doesn't show an excessive load, the highest loading process is MIDIServer (which I'm assuming is OSX, not ChucK?), and even while playing several notes on and off with pedal and without, the idle% never went below 50% (as in, less than 50% cpu used)... I don't think it's a CPU issue unless the ChucK VM is having troubles on its own apart from the rest of the system
If that's it we'll have to talk about the structure of the program; that might get complicated but it might be fun too, Then again; in the case of discontinuities (a fancy words for your wave making a "vertical jump") it might get tricky too.
See how far you can get on your own. If you get stuck you may need to send the most simple version of your code that still has these clicks to the list and we can have a look. Could be that it's something simple, but it could also be that you are asking too much; there is always a limit to the cpu power, it might be at two sines, it might be at two modelled full orchestras but there is some limit where it will click....
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hmm thanks for the input and feedback. I don't think it's CPU issues, but I'm not ruling it out. I did manage to make it happen reliably now, or at least I figured out why it was *sometimes* ... I'm not to the point of paring down the program to something appropriate for a mailing list, that's going to be a huge job. Anyway, some more info (and more questions) Info: it only happens when a handler which had previously sounded a low frequency is then called to play a significantly higher frequency. If you've got a midi controller, the easiest way to do this is play 20 (the number of handlers I have) notes on the C below middle C, and then jump up to the C above middle C... Until every handler has played at least one note in the new range, it'll pop. It also started when I added the modulation functionality I discussed in a previous thread, "Modulation of parameters 'by hand'"... none of my previous patches before this addition do this, so I want to blame some fault in this section of the program... Questions: How does chuck handle concurrancy with time and threads? If any one thread advances time, it advances time for the whole VM right? My loop for the modulators advances time by 1::ms or else the program just spins forever - the rest of the program isn't ever reached. Is there a better way to do this? The loop is just a while(true) loop with a 1::ms => now at the end (after setting the parameters) ... but this thread doesn't actually own the osc's, it's a child of that thread. Maybe I'm getting into a bugger here? Anyway, thanks again!
Jonathan: Would it be possible to run your setup out of real time, writing the samples to disk? If so, that would eliminate the running out of CPU question. - r
Robert Poor
Jonathan:
Would it be possible to run your setup out of real time, writing the samples to disk? If so, that would eliminate the running out of CPU question.
- r _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Actually, I think I may have found part of the problem... If I have my high pass filter set as high as I did (4x the sounded freq) then I get the click. Anything 1x or lower and there's no click... Could the filter be bringing out the click more or actually causing it, our would that be evidence of an error relating to it or something else?
Actually, I think I may have found part of the problem... If I have my high pass filter set as high as I did (4x the sounded freq) then I get the click. Anything 1x or lower and there's no click... Could the filter be bringing out the click more or actually causing it, our would that be evidence of an error relating to it or something else?
Interesting! That sounds like something you might be able to re-create in a few lines and send to the list. It does sounds like you found the issue, congratulations. Kas.
On Jun 12, 2011, at 4:57 AM, Kassen wrote:
Actually, I think I may have found part of the problem... If I have my high pass filter set as high as I did (4x the sounded freq) then I get the click. Anything 1x or lower and there's no click... Could the filter be bringing out the click more or actually causing it, our would that be evidence of an error relating to it or something else?
Interesting! That sounds like something you might be able to re-create in a few lines and send to the list. It does sounds like you found the issue, congratulations.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
I have an example for you (and everyone else)... It's here: http://pastebin.com/vc2W0UNW ... There's only 41 lines of code, but with my comments explaining it, it's more like 80 lines. You can take out the Attack/Decay code and replace that with a chuck to now (like noteLen => now) if you want to just peel that bit out, I mostly included it to prove (or disprove) that adding a fadein/fadeout didn't have any effect. You can mask the click by adding a really slow decay (>100::ms or so). Line #54 causes the click. Lines 37 or 38 can be used to set up a static filter combined with commenting out #54, and that conclusively gets rid of the click. There is still a small pop if the filter is set real high, but considering it's a "high pass" filter, I'm ready to write that bit off as the nature of the beast. That pop is nothing like the one I get from changing the filter around... FWIW this doesn't happen with an LPF IME. It also seems that it's not actually affected by how the HPF is related to the output freq, if you change the *4 to *1 on line 54, it actually gets louder, at least to my ears. Anyway, I'm going to keep poking at it (as always), but here's the proof of concept. Let me know what you think. Thanks, Johnathan
On Jun 13, 2011, at 9:59 AM, Johnathan Bell wrote:
On Jun 12, 2011, at 4:57 AM, Kassen wrote:
Actually, I think I may have found part of the problem... If I have my high pass filter set as high as I did (4x the sounded freq) then I get the click. Anything 1x or lower and there's no click... Could the filter be bringing out the click more or actually causing it, our would that be evidence of an error relating to it or something else?
Interesting! That sounds like something you might be able to re-create in a few lines and send to the list. It does sounds like you found the issue, congratulations.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
I have an example for you (and everyone else)... It's here: http://pastebin.com/vc2W0UNW ... There's only 41 lines of code, but with my comments explaining it, it's more like 80 lines. You can take out the Attack/Decay code and replace that with a chuck to now (like noteLen => now) if you want to just peel that bit out, I mostly included it to prove (or disprove) that adding a fadein/fadeout didn't have any effect. You can mask the click by adding a really slow decay (>100::ms or so). Line #54 causes the click. Lines 37 or 38 can be used to set up a static filter combined with commenting out #54, and that conclusively gets rid of the click. There is still a small pop if the filter is set real high, but considering it's a "high pass" filter, I'm ready to write that bit off as the nature of the beast. That pop is nothing like the one I get from changing the filter around... FWIW this doesn't happen with an LPF IME.
It also seems that it's not actually affected by how the HPF is related to the output freq, if you change the *4 to *1 on line 54, it actually gets louder, at least to my ears.
Anyway, I'm going to keep poking at it (as always), but here's the proof of concept. Let me know what you think.
Thanks, Johnathan
FWIW I've also cross-posted this on the electro-music.com forums, here: http://electro-music.com/forum/viewtopic.php?p=332902#332902 - Johnathan
Questions: How does chuck handle concurrancy with time and threads? If any one thread advances time, it advances time for the whole VM right? My loop for the modulators advances time by 1::ms or else the program just spins forever - the rest of the program isn't ever reached. Is there a better way to do this? The loop is just a while(true) loop with a 1::ms => now at the end (after setting the parameters) ... but this thread doesn't actually own the osc's, it's a child of that thread. Maybe I'm getting into a bugger here?
Essentially "second => now;" can be translated as "I (as a shred) am done using the cpu for now and want it back in a second", handing on the service of the cpu to other processes that might need it. When no shred uses the cpu right "now" the cpu can be busy calculating UGens, if that too is done then the cpu can take a rest or tend to stuff like your incoming mail. If you'd like to know more about the why and how of it all then I recommend you look at Ge's thesis; https://ccrma.stanford.edu/~ge/thesis.html That's probably the best source of info on the reasoning behind it all (really, there is some! :-p ). I recommend that one to anyone looking to understand more about ChucK's internal workings. Shreds, BTW, don't "own" UGens. They may be in the same name-space though, so a shred can address a UGen. A UGen may *only* be addressable by a given shred (due to being defined in it) in which case the death of the shred will mean the end of the UGen's life too (as the UGen will lack references). As long as they are in the same name-space the UGen will be addressable and beyond that it shouldn't make a difference. I hope that clarifies, Kas.
participants (3)
-
Johnathan Bell -
Kassen -
Robert Poor