Hello list, Not sure this issue is still of any interest, but just for the record I got up to 836 sine oscillators without crackles. At 836 I got 1 crackle and got the second crackle around 900 sines. Above 960 sine oscillators the crackles appear more often. This is on a Mac Intel Core Duo 1.83GHz, 1GB DDR2 SDRAM, OS 10.4.6 . It make no difference to have my settings under System Preferences > Energy saving as Normal or Best Performance. The code I have used is: 1024 => int max; sinosc @ a[max]; 0 => int counter; sinosc s1; 440 => s1.freq; 1./max => s1.gain; while( true ) { s1 @=> a[counter] => dac; .25::second => now; <<<"oscillator ", counter++>>>; } cheers, Eduard
Could you try this code and let us know when you get clicks?: 1024 => int max; sinosc a[max]; 0 => int counter; sinosc s1; 1./30.0 => s1.gain; int i; while( true ) { for (0=>i; i<=counter; i++) { 1./(counter+1) => a[i].gain; } 440.0 + std.rand2f(-100.0,100.0) => a[counter].freq; a[counter] => dac; .25::second => now; <<<"oscillator ", counter++>>>; }
Yep, I just showed the original code to Ge, and he verified that you are only using one sineosc (s1), but connecting it multiple times to the dac, through the array. So the clicking begins when the multiple connections to the dac finally take up enough time. Mine clicks at about 450 on my PowerBook. The true test is in my code, where there are truly multiple sineoscs, and multiple connections. That clicks at about 40. Be interested in seeing where it clicks on IntelMac. PRC On Tue, 2 May 2006, Perry R Cook wrote:
Could you try this code and let us know when you get clicks?:
1024 => int max; sinosc a[max]; 0 => int counter; sinosc s1; 1./30.0 => s1.gain; int i;
while( true ) { for (0=>i; i<=counter; i++) { 1./(counter+1) => a[i].gain; } 440.0 + std.rand2f(-100.0,100.0) => a[counter].freq; a[counter] => dac; .25::second => now; <<<"oscillator ", counter++>>>; }
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On 5/2/06, Perry R Cook
Yep, I just showed the original code to Ge, and he verified that you are only using one sineosc (s1), but connecting it multiple times to the dac, through the array. So the clicking begins when the multiple connections to the dac finally take up enough time. Mine clicks at about 450 on my PowerBook.
Is that realy what's going on? I was wondering about that. I never realised arrays can hold audio signals. Can they? Does this make them work like a sort of multiplexer or more like a mixer? I'm quite baffled by that line in the original example. Aparently the VM is fine with it; if I were the VM I probably would have complained but now I'm wondering exactly what it is that the VM thinks we are trying to do here and what the use of it would be. Do I gather from your reply that when we send a array to a ugen the ugen will get a sort of sum of all that's conatained by the array to it's input? As far as mistakes go I think Eduard made a very interesting one and I'd love to hear what we could do with this when not making mistakes. Kas.
The multiple connections to the dac mix (add) by default. All inputs to any unitgenerators (that have inputs) add by default, with optional flags you can set to cause them to multiply (maybe other too). I'm not sure why chucking the single sineosc to the elements of the array works. Ge will explain... PRC On Wed, 3 May 2006, Kassen wrote:
Is that realy what's going on? I was wondering about that. I never realised arrays can hold audio signals. Can they? Does this make them work like a sort of multiplexer or more like a mixer? I'm quite baffled by that line in the original example. Aparently the VM is fine with it; if I were the VM I probably would have complained but now I'm wondering exactly what it is that the VM thinks we are trying to do here and what the use of it would be. Do I gather from your reply that when we send a array to a ugen the ugen will get a sort of sum of all that's conatained by the array to it's input?
As far as mistakes go I think Eduard made a very interesting one and I'd love to hear what we could do with this when not making mistakes.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
OK, here's the deal with that original code. s1 @=> a[counter] => dac; The first Chuck does assignment (replaces that member of the array with s1. The 2nd Chuck connects it to the dac. The @ part of the operator signifies assignment. So it's all legal, but maybe confusing. PRC
On May 3, 2006, at 12:58 AM, Perry R Cook wrote:
OK, here's the deal with that original code.
s1 @=> a[counter] => dac;
The first Chuck does assignment (replaces that member of the array with s1. The 2nd Chuck connects it to the dac. The @ part of the operator signifies assignment. So it's all legal, but maybe confusing.
I understand @ as "reference to". Same as & in C. Is this the correct way of understanding it?
On 5/3/06, Perry R Cook
The first Chuck does assignment (replaces that member of the array with s1. The 2nd Chuck connects it to the dac. The @ part of the operator signifies assignment. So it's all legal, but maybe confusing.
Thanks, I was just about to try using a array as a multiplexer/ signal router myself. This is actually quite useful for reconnecting signals in that case. I hope Ge will still explain exactly what type the array would be in this case. it seems to me that with this sort of thing you could have arrays that contain some floats and some links to ugens and while that need not be a problem it would probably lead to crashes if those accidentally got mixed up. Another thing I don't get is how this relates to the need for a DAC or blackhole to "tickle" Ugens. In Eduard's code they all end up at the DAC anyway but what if they don't due to the array getting called in some different way? Would they stop running until reconnected? it's all becoming more clear now but there are some areas left where I have my doubts or at least uncertainties. Kas.
Yep, I just showed the original code to Ge, and he verified that you are only using one sineosc (s1), but connecting it multiple times to the dac, through the array. So the clicking begins when the multiple connections to the dac finally take up enough time. Mine clicks at about 450 on my PowerBook.
oops, yes that's right. Sorry, I got confused.
The true test is in my code, where there are truly multiple sineoscs, and multiple connections. That clicks at about 40. Be interested in seeing where it clicks on IntelMac.
With your test, I got 95 sines. quoting an old email from Ge: "On our linux box (2.8 ghz Intel, mucho RAM, RH9), I got up to 130 without crackles." Ge, what test did you use ?
Perry R Cook wrote:
The true test is in my code, where there are truly multiple sineoscs, and multiple connections. That clicks at about 40. Be interested in seeing where it clicks on IntelMac.
PC winXP SP2 Pentium M 1400MHz clicks at 143 PC winXP SP2 Athlon 64x2 Dual Core 3800 clicks at 190 if "cool & quiet" is enabled it starts clicking at 100. processor utilisation is in both cases at 50% but with c&q the processor frequency stays first at 1000MHz and then speeds up to 1800MHz which stops the clicking for a while. joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/
participants (4)
-
eduard aylon -
joerg piringer -
Kassen -
Perry R Cook