Tom;

Would it help to pipe stuff that might blow up through a Dyno?

That's a good question. I'm not sure about the exact functioning of Dyno but the issue involves a filter jumping to about 14 orders of magnitude(!!!) over its expected amplitude in a extremely brief time. We would need a limiter with a attack of absolutely 0 and a infinity to 1 compression beyond a certain level (not just a very high ratio). Most limiters I know don't have those extremes. Normally it's assumed that input levels will be more or less reasonably set and such extreme response times are undesirable because of the effect they will have on the spectrum. Dyno does have a "ratio" setting but considering the really quite extreme magnitude of the signal to be corrected I would have doubts about our ability to correct it completely. We can't trust the volume will stay below the maximum value of a double-float because Nyquist allows for reconstructed waves that exceed the maximum value of a sample. Dividing that by the maximum float we can express still won't do and may still leave a amplitude that would be painful. What is needed here, IMHO, would be a combination of a normal limiter (with a high ratio beyond .9 amplitude or so) and a hard clip at 1. That still won't sound pleasant once things blow, but at least Tomasz's ears will live for another day and his partner and cat won't have to be startled by thrown headphones. To do that we could use the tutorial that Stephen wrote for adding a hard-clip as a UGen to ChucK, either rushing that in as a patch or by Tomasz recompiling ChucK. That would buy us some time to look into verifying the filters are stable at the set coefficients, at least for non-modulated filters. This is quite possible, I believe, and the current issue indicates that this isn't -yet- done or not correctly. We would still need to keep a clip at hand because of Perry's notes on modulated filters and their stability. I agree with Tomasz that this issue deserves priority because of the very real chance of physically harming users when combining sensitive headphones with the output jacks of MacBooks running OSX. I know we make no warranties but it would still be good to try to keep everyone healthy. I believe it's a good thing that Tomasz keeps addressing this because of that. It may be a rare scenario but I don't want to imagine combining this issue with a big PA and a audience accustomed to subtle sounds listening attentively. Of course in a live situation a hardware limiter may be used. I'd have one for you to borrow for a while, Tomasz, if that would help. Yours, Kas.

Tom; I think

+/- 1 would be too low for a lot of people.

On OS's with a integer-based audio structure that would be the absolute max anyway. I think that on OSX you'd clip the dac when the master volume would be set to unity gain and ChucK would go beyond +/-1 anyway. Basically you'd just end up with two more multiplications, I think. It doesn't really matter what we call the reference level anyway; it's just a matter of perspective relative to the final soundsystem. Yours, Kas.

2010/2/16 Stefan Blixt

If you do SinOsc s=> dac and the 100.0 => s.gain, are you then able to blow a speaker on a Mac laptop even if it's main volume is turned down? That's the curious thing to me, how the filter messes up so badly it makes my MacBook's speaker scream even though the volume is almost down to zero.

100? Try something like this value for a output; 242210436022272.0 That's a actual recorded output of .last(). I'm not sure what would happen if something of that volume would be played back on real speakers; there is probably a UN convention against that kind of thing ;-).

From what I understand of the situation you wouldn't blow the speaker. If Apple was smart they put in a pre-amp that's slightly smaller than the maximum load of the speaker yet slightly over-speced for the output of the dac to keep repairs down. But yes; apparently you will can get a very high volume even though the (software) fader is down.

This is what we know. Then from that I speculated (and unless something more credible comes by I think it's a good theory) that Apple is doing everything in float (with virtually unlimited headroom for practical applications), setting the master volume with a floating point multiplication, and handing the resultant value to the dac where inevitably it will be turned into a plain integer. In this case that integer will be the highest volume the poor little dac can take. If that's not it I can't imagine why +/- some 15 digit number would have a higher amplitude than +/-1, as a final output, post master fader. This is cheap compared to tweaking the voltage on the final hardware amp (which would always preserve the full bit-range) and probably sounds a lot better than going integer and throwing away a lot of bits at low volume, but it fails to take into account that we may not just turn the volume down for a more pleasant listen but also to protect our ears. Combine that with with potentially very sensitive studio or DJ headphones and you have a situation that may lead to hearing damage. I know that my own pro DJ headphones will output a lot more volume than my mid-range earbuds at the same volume setting for a headphone jack. IMHO this would be a oversight by Apple and I'm a bit surprised there hasn't been a storm of practical joke mails aimed at OSX users featuring videoclips embedding floating-point audio. I'd offer at least a optional output limiter like what has been proposed for mp3 players. I don't believe in those for protecting children's ears through mandatory regulation because of the differences in headphone output volume, but for user-set protection it might be a good idea. Of course ChucK is a bit more likely to cause this sort of issue than the average off-the-shelf audio player. Here is the original topic if you'd like to try to reproduce the findings so far; http://electro-music.com/forum/viewtopic.php?t=37921 Yours, Kas.

2010/2/16 Andrew C. Smith

Yes, you don't blow the speaker. I've done it many times, and actually use that filter blowing up sound as a musical tool (routed through an external mixer). It's so unpredictable that it's really fun. In fact, this awesome sound was one of the reasons I got into ChucK and the primary reason I keep my old PowerBook around.

We wouldn't lose that though. The "Filter" class is perfectly capable of letting you enjoy endless amounts of unstable or "mostly stable" filters. LPF (etc) on the other hand is supposed to be stable, dependable and convenient. The convenience filters merely extend Filter. I do agree that it can sound good. Some of the reverbs can under some conditions go quite out of control as well. I've a audience applaud that. I was a bit ambiguous about that as I was trying to livecode a more sensitive atmospheric piece but yes, it can sound good.

Seems that ChucK can crash brains, not just computers!

I suspect so but I do believe that there are indications that some of us were a bit loony before we started ChucKing. more research will be needed. At the very least a control group. kas.

About the filter problem: does it mean that currently no one is using chuck for classic sutractive synthesis patches like: Oscillators -> Filters (cuttof driven by an ADSR) -> Amplifier (Level driven by an ADSR) ? Are people just not doing this kind of routing in ChucK yet, or are there workarounds that avoid the filters going unstable when modulated in this way? (Sorry to keep on about this, but I'm really keen to keep using ChucK if at all possible) 2010/2/17 mike clemow

OT:

2010/2/16 Andrew C. Smith

...

Seems that ChucK can crash brains, not just computers!

Chuck's filter code is actually written in Sumerian. The Goddess Asherah created Chuck to erase peoples' minds and make them worship her. The sound is actually a nam-shub and if you hear it, you will lose your wits and start mumbling Sumerian syllables...

(sorry, i couldn't help this outburst. i finished the book just a few short weeks ago. ;)

-Mike

...

Actually, my other solution was to run the audio through Jack and into Logic, where I can do a much better job of controlling the volume. This actually doesn't distort (since the distortion comes at the dac level), and changes the sound entirely. Anyway, just an option.

-Andrew

On Feb 16, 2010, at 5:03 PM, Kassen wrote:

2010/2/16 Stefan Blixt

...

If you do SinOsc s=> dac and the 100.0 => s.gain, are you then able to blow a speaker on a Mac laptop even if it's main volume is turned down? That's the curious thing to me, how the filter messes up so badly it makes my MacBook's speaker scream even though the volume is almost down to zero.

100? Try something like this value for a output; 242210436022272.0 That's a actual recorded output of .last(). I'm not sure what would happen if something of that volume would be played back on real speakers; there is probably a UN convention against that kind of thing ;-).

From what I understand of the situation you wouldn't blow the speaker. If Apple was smart they put in a pre-amp that's slightly smaller than the maximum load of the speaker yet slightly over-speced for the output of the dac to keep repairs down. But yes; apparently you will can get a very high volume even though the (software) fader is down.

This is what we know.

Then from that I speculated (and unless something more credible comes by I think it's a good theory) that Apple is doing everything in float (with virtually unlimited headroom for practical applications), setting the master volume with a floating point multiplication, and handing the resultant value to the dac where inevitably it will be turned into a plain integer. In this case that integer will be the highest volume the poor little dac can take. If that's not it I can't imagine why +/- some 15 digit number would have a higher amplitude than +/-1, as a final output, post master fader.

This is cheap compared to tweaking the voltage on the final hardware amp (which would always preserve the full bit-range) and probably sounds a lot better than going integer and throwing away a lot of bits at low volume, but it fails to take into account that we may not just turn the volume down for a more pleasant listen but also to protect our ears. Combine that with with potentially very sensitive studio or DJ headphones and you have a situation that may lead to hearing damage. I know that my own pro DJ headphones will output a lot more volume than my mid-range earbuds at the same volume setting for a headphone jack.

IMHO this would be a oversight by Apple and I'm a bit surprised there hasn't been a storm of practical joke mails aimed at OSX users featuring videoclips embedding floating-point audio. I'd offer at least a optional output limiter like what has been proposed for mp3 players. I don't believe in those for protecting children's ears through mandatory regulation because of the differences in headphone output volume, but for user-set protection it might be a good idea. Of course ChucK is a bit more likely to cause this sort of issue than the average off-the-shelf audio player.

Here is the original topic if you'd like to try to reproduce the findings so far; http://electro-music.com/forum/viewtopic.php?t=37921

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

@mike I'm not sure about Supercollider, but in max, i generally use the svf~ object: a state variable filter with separate outputs for LPF HPF BPF and band stop. It doesn't blow up when you modulate its cutoff or resonance inputs, so it's very straightforward to plug into subtractive synthesis patches. I'm looking for a similarly 'tolerant' filter ugen (or collection of ugens) in ChucK. 2010/3/1 mike clemow

Curious...

Is there a difference between the way that filters blow up in, say, Supercollider than there is in Chuck? Because my understanding is that those algorithms just... blow up, if you push on them too much. Am I wrong here? It wouldn't be the first time...

;)

Mike

2010/3/1 Tomasz Kaye's brain

About the filter problem: does it mean that currently no one is using chuck

...

for classic sutractive synthesis patches like:

Oscillators -> Filters (cuttof driven by an ADSR) -> Amplifier (Level driven by an ADSR) ?

Are people just not doing this kind of routing in ChucK yet, or are there workarounds that avoid the filters going unstable when modulated in this way?

(Sorry to keep on about this, but I'm really keen to keep using ChucK if at all possible)

2010/2/17 mike clemow

OT:

...

2010/2/16 Andrew C. Smith

...

Seems that ChucK can crash brains, not just computers!

Chuck's filter code is actually written in Sumerian. The Goddess Asherah created Chuck to erase peoples' minds and make them worship her. The sound is actually a nam-shub and if you hear it, you will lose your wits and start mumbling Sumerian syllables...

(sorry, i couldn't help this outburst. i finished the book just a few short weeks ago. ;)

-Mike

...

Actually, my other solution was to run the audio through Jack and into Logic, where I can do a much better job of controlling the volume. This actually doesn't distort (since the distortion comes at the dac level), and changes the sound entirely. Anyway, just an option.

-Andrew

On Feb 16, 2010, at 5:03 PM, Kassen wrote:

2010/2/16 Stefan Blixt

...

If you do SinOsc s=> dac and the 100.0 => s.gain, are you then able to blow a speaker on a Mac laptop even if it's main volume is turned down? That's the curious thing to me, how the filter messes up so badly it makes my MacBook's speaker scream even though the volume is almost down to zero.

100? Try something like this value for a output; 242210436022272.0 That's a actual recorded output of .last(). I'm not sure what would happen if something of that volume would be played back on real speakers; there is probably a UN convention against that kind of thing ;-).

From what I understand of the situation you wouldn't blow the speaker. If Apple was smart they put in a pre-amp that's slightly smaller than the maximum load of the speaker yet slightly over-speced for the output of the dac to keep repairs down. But yes; apparently you will can get a very high volume even though the (software) fader is down.

This is what we know.

Then from that I speculated (and unless something more credible comes by I think it's a good theory) that Apple is doing everything in float (with virtually unlimited headroom for practical applications), setting the master volume with a floating point multiplication, and handing the resultant value to the dac where inevitably it will be turned into a plain integer. In this case that integer will be the highest volume the poor little dac can take. If that's not it I can't imagine why +/- some 15 digit number would have a higher amplitude than +/-1, as a final output, post master fader.

This is cheap compared to tweaking the voltage on the final hardware amp (which would always preserve the full bit-range) and probably sounds a lot better than going integer and throwing away a lot of bits at low volume, but it fails to take into account that we may not just turn the volume down for a more pleasant listen but also to protect our ears. Combine that with with potentially very sensitive studio or DJ headphones and you have a situation that may lead to hearing damage. I know that my own pro DJ headphones will output a lot more volume than my mid-range earbuds at the same volume setting for a headphone jack.

IMHO this would be a oversight by Apple and I'm a bit surprised there hasn't been a storm of practical joke mails aimed at OSX users featuring videoclips embedding floating-point audio. I'd offer at least a optional output limiter like what has been proposed for mp3 players. I don't believe in those for protecting children's ears through mandatory regulation because of the differences in headphone output volume, but for user-set protection it might be a good idea. Of course ChucK is a bit more likely to cause this sort of issue than the average off-the-shelf audio player.

Here is the original topic if you'd like to try to reproduce the findings so far; http://electro-music.com/forum/viewtopic.php?t=37921

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Tomasz: I use SndBuf => ResonZ => Envelope => DAC frequently in live performances. Even though the center frequency and Q of the ResonZ are controlled by pitch bend and modulation wheel (respectively), I've never had any problems with stability. Am I missing something? :) - Rob 2010/3/1 Tomasz Kaye's brain :

About the filter problem: does it mean that currently no one is using chuck for classic sutractive synthesis patches like:

Oscillators -> Filters (cuttof driven by an ADSR) -> Amplifier (Level driven by an ADSR) ?

Are people just not doing this kind of routing in ChucK yet, or are there workarounds that avoid the filters going unstable when modulated in this way?

(Sorry to keep on about this, but I'm really keen to keep using ChucK if at all possible)

2010/2/17 mike clemow

...

OT:

2010/2/16 Andrew C. Smith

...

Seems that ChucK can crash brains, not just computers!

Chuck's filter code is actually written in Sumerian.  The Goddess Asherah created Chuck to erase peoples' minds and make them worship her.  The sound is actually a nam-shub and if you hear it, you will lose your wits and start mumbling Sumerian syllables...

(sorry, i couldn't help this outburst.  i finished the book just a few short weeks ago.  ;)

-Mike

...

Actually, my other solution was to run the audio through Jack and into Logic, where I can do a much better job of controlling the volume. This actually doesn't distort (since the distortion comes at the dac level), and changes the sound entirely. Anyway, just an option. -Andrew On Feb 16, 2010, at 5:03 PM, Kassen wrote:

2010/2/16 Stefan Blixt

...

If you do SinOsc s=> dac and the 100.0 => s.gain, are you then able to blow a speaker on a Mac laptop even if it's main volume is turned down? That's the curious thing to me, how the filter messes up so badly it makes my MacBook's speaker scream even though the volume is almost down to zero.

100? Try something like this value for a output; 242210436022272.0 That's a actual recorded output of .last(). I'm not sure what would happen if something of that volume would be played back on real speakers; there is probably a UN convention against that kind of thing ;-).

From what I understand of the situation you wouldn't blow the speaker. If Apple was smart they put in a pre-amp that's slightly smaller than the maximum load of the speaker yet slightly over-speced for the output of the dac to keep repairs down. But yes; apparently you will can get a very high volume even though the (software) fader is down. This is what we know. Then from that I speculated (and unless something more credible comes by I think it's a good theory) that Apple is doing everything in float (with virtually unlimited headroom for practical applications), setting the master volume with a floating point multiplication, and handing the resultant value to the dac where inevitably it will be turned into a plain integer. In this case that integer will be the highest volume the poor little dac can take. If that's not it I can't imagine why +/- some 15 digit number would have a higher amplitude than +/-1, as a final output, post master fader. This is cheap compared to tweaking the voltage on the final hardware amp (which would always preserve the full bit-range) and probably sounds a lot better than going integer and throwing away a lot of bits at low volume, but it fails to take into account that we may not just turn the volume down for a more pleasant listen but also to protect our ears. Combine that with with potentially very sensitive studio or DJ headphones and you have a situation that may lead to hearing damage. I know that my own pro DJ headphones will output a lot more volume than my mid-range earbuds at the same volume setting for a headphone jack.

IMHO this would be a oversight by Apple and I'm a bit surprised there hasn't been a storm of practical joke mails aimed at OSX users featuring videoclips embedding floating-point audio. I'd offer at least a optional output limiter like what has been proposed for mp3 players. I don't believe in those for protecting children's ears through mandatory regulation because of the differences in headphone output volume, but for user-set protection it might be a good idea. Of course ChucK is a bit more likely to cause this sort of issue than the average off-the-shelf audio player. Here is the original topic if you'd like to try to reproduce the findings so far; http://electro-music.com/forum/viewtopic.php?t=37921 Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

i have no idea if this will help, but i've been meaning to bring the old gQ filter stuff to ChucK for sometime. gQ is a really nice filter: http://www.music.princeton.edu/~dan/gQpage/gQ.html it might be more stable. maybe not. it usually sounds real nice. in any case, here it is, and it seems to work ok. probably should make a class out of it... //==================================== //gQ lives! //dan trueman 2010 Noise n => BiQuad gq => dac; 0.1 => gq.gain; //need these: 0 => int PEAKNOTCH; 1 => int LOWSHELF; 2 => int HIGHSHELF; 2. * pi => float twopi; 1::second/1::samp => float thisSR; //set everything setFreqBoostBandwidth(440., 10., 0.1, LOWSHELF); //yay, hang out 1::day => now; //main function for setting biquad params fun void setFreqBoostBandwidth(float freq, float boost, float thisBandwidth, int type) { float d, a_boost, a_cut, Vzero, true_bw; freq * thisBandwidth => true_bw; boost - 1. => Vzero; //a's are pole coeffs, b's are zero coeffs //PEAK/NOTCH CASE if (type == PEAKNOTCH) { (Math.tan(true_bw*twopi/(2.*thisSR)) - 1.) / (Math.tan(true_bw*twopi/(2.*thisSR)) + 1.) => a_boost; (Math.tan(true_bw*twopi/(2.*thisSR)) - boost) / (Math.tan(true_bw*twopi/(2.*thisSR)) + boost) => a_cut; -Math.cos(freq*twopi/thisSR) => d; /* cut */ if(boost <= 1.0) { 1.0 + (1.0 + a_cut)*Vzero/2.0 => gq.b0; d*(1 - a_cut) => gq.b1; (-a_cut - (1 + a_cut)*Vzero/2.0) => gq.b2; d*(1.0 - a_cut) => gq.a1; -a_cut => gq.a2; } /* boost */ if(boost > 1.0) { 1.0 + (1.0 + a_boost)*Vzero/2.0 => gq.b0; d*(1 - a_boost) => gq.b1; (-a_boost - (1 + a_boost)*Vzero/2.0) => gq.b2; d*(1.0 - a_boost) => gq.a1; -a_boost => gq.a2; } } //LOW SHELF CASE else if (type == LOWSHELF) { (Math.tan(freq*twopi/(2.*thisSR)) - 1.) / (Math.tan(freq*twopi/(2.*thisSR)) + 1.) => a_boost; (Math.tan(freq*twopi/(2.*thisSR)) - boost) / (Math.tan(freq*twopi/(2.*thisSR)) + boost) => a_cut; /* cut */ if(boost <= 1.0) { 1.0 + (1.0 + a_cut)*Vzero/2.0 => gq.b0; a_cut + (1 + a_cut)*Vzero/2.0 => gq.b1; 0. => gq.b2; a_cut => gq.a1; 0. => gq.a2; } /* boost */ if(boost > 1.0) { 1.0 + (1.0 + a_boost)*Vzero/2.0 => gq.b0; a_boost + (1 + a_boost)*Vzero/2.0 => gq.b1; 0. => gq.b2; a_boost => gq.a1; 0. => gq.a2; } } //HIGH SHELF CASE else if (type == HIGHSHELF) { (Math.tan(freq*twopi/(2.*thisSR)) - 1.) / (Math.tan(freq*twopi/(2.*thisSR)) + 1.) => a_boost; (boost*Math.tan(freq*twopi/(2.*thisSR)) - 1.) / (boost*Math.tan(freq*twopi/(2.*thisSR)) + 1.) => a_cut; /* cut */ if(boost <= 1.0) { 1.0 + (1.0 - a_cut)*Vzero/2.0 => gq.b0; a_cut + (a_cut - 1.)*Vzero/2.0 => gq.b1; 0. => gq.b2; a_cut => gq.a1; 0. => gq.a2; } /* boost */ if(boost > 1.0) { 1.0 + (1.0 - a_boost)*Vzero/2.0 => gq.b0; a_boost + (a_boost - 1.)*Vzero/2.0 => gq.b1; 0. => gq.b2; a_boost => gq.a1; 0. => gq.a2; } } } //==================================== On Mar 1, 2010, at 4:48 PM, Tomasz Kaye's brain wrote:

Hi Robert. Thanks for the pointer, that's very useful.

I'd stayed away from RezonZ until now because I thought it would be wisest to begin by using filter types I already knew (or thought i knew) from other environments: LPF BPF and HPF.

I saw that RezonZ doesn't have the runaway tendency of the other three when plugged into the test patch (and now I think I understand the significance of the line in the RezonZ ugen documentation: "keeps gain under control independent of frequency").

I'll have a try at getting RezonZ act as a rough approximation of the other three filter types (any further pointers anyone can offer in this direction would be great), and try again to do some reading around musical applications of biquad filters, though filter-related writing tends to make my head hurt :)

On Mon, Mar 1, 2010 at 9:00 PM, Robert Poor wrote: Tomasz:

I use SndBuf => ResonZ => Envelope => DAC frequently in live performances. Even though the center frequency and Q of the ResonZ are controlled by pitch bend and modulation wheel (respectively), I've never had any problems with stability. Am I missing something? :)

- Rob

2010/3/1 Tomasz Kaye's brain :

...

About the filter problem: does it mean that currently no one is using chuck for classic sutractive synthesis patches like:

Oscillators -> Filters (cuttof driven by an ADSR) -> Amplifier (Level driven by an ADSR) ?

Are people just not doing this kind of routing in ChucK yet, or are there workarounds that avoid the filters going unstable when modulated in this way?

(Sorry to keep on about this, but I'm really keen to keep using ChucK if at all possible)

2010/2/17 mike clemow

...

OT:

2010/2/16 Andrew C. Smith

...

Seems that ChucK can crash brains, not just computers!

Chuck's filter code is actually written in Sumerian. The Goddess Asherah created Chuck to erase peoples' minds and make them worship her. The sound is actually a nam-shub and if you hear it, you will lose your wits and start mumbling Sumerian syllables...

(sorry, i couldn't help this outburst. i finished the book just a few short weeks ago. ;)

-Mike

...

Actually, my other solution was to run the audio through Jack and into Logic, where I can do a much better job of controlling the volume. This actually doesn't distort (since the distortion comes at the dac level), and changes the sound entirely. Anyway, just an option. -Andrew On Feb 16, 2010, at 5:03 PM, Kassen wrote:

2010/2/16 Stefan Blixt

...

If you do SinOsc s=> dac and the 100.0 => s.gain, are you then able to blow a speaker on a Mac laptop even if it's main volume is turned down? That's the curious thing to me, how the filter messes up so badly it makes my MacBook's speaker scream even though the volume is almost down to zero.

100? Try something like this value for a output; 242210436022272.0 That's a actual recorded output of .last(). I'm not sure what would happen if something of that volume would be played back on real speakers; there is probably a UN convention against that kind of thing ;-).

From what I understand of the situation you wouldn't blow the speaker. If Apple was smart they put in a pre-amp that's slightly smaller than the maximum load of the speaker yet slightly over-speced for the output of the dac to keep repairs down. But yes; apparently you will can get a very high volume even though the (software) fader is down. This is what we know. Then from that I speculated (and unless something more credible comes by I think it's a good theory) that Apple is doing everything in float (with virtually unlimited headroom for practical applications), setting the master volume with a floating point multiplication, and handing the resultant value to the dac where inevitably it will be turned into a plain integer. In this case that integer will be the highest volume the poor little dac can take. If that's not it I can't imagine why +/- some 15 digit number would have a higher amplitude than +/-1, as a final output, post master fader. This is cheap compared to tweaking the voltage on the final hardware amp (which would always preserve the full bit-range) and probably sounds a lot better than going integer and throwing away a lot of bits at low volume, but it fails to take into account that we may not just turn the volume down for a more pleasant listen but also to protect our ears. Combine that with with potentially very sensitive studio or DJ headphones and you have a situation that may lead to hearing damage. I know that my own pro DJ headphones will output a lot more volume than my mid-range earbuds at the same volume setting for a headphone jack.

IMHO this would be a oversight by Apple and I'm a bit surprised there hasn't been a storm of practical joke mails aimed at OSX users featuring videoclips embedding floating-point audio. I'd offer at least a optional output limiter like what has been proposed for mp3 players. I don't believe in those for protecting children's ears through mandatory regulation because of the differences in headphone output volume, but for user-set protection it might be a good idea. Of course ChucK is a bit more likely to cause this sort of issue than the average off-the-shelf audio player. Here is the original topic if you'd like to try to reproduce the findings so far; http://electro-music.com/forum/viewtopic.php?t=37921 Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

@kassen These, IMHO, need to be fixed, as something is plainly buggy there. How much

time would this take from somebody who is fluent in C/C++ (needed to evaluate the rounding possibility) and not too scared of the Z-plane stuff? I'd look into it myself but I'd be out of my league in both fields.

I've asked a friend who's knowledgeable about DSP. He had a look at the ChucK source and seems optimistic that he (or one of his peers) may be able to find a solution for achieving stable, sweepable filter(s). Hard to say whether it will work out at this early stage though.

Kurt: Has nobody told you that a synthesis system that won't produce occasional bleeding eardrums is a BORING synthesis system? :) Best, - r On 2010Apr01, at 17:07, Kurt Kotheimer wrote:

I found a great way to blow up RezonZ today. Give it a freq value beyond the sample rate. Noise n => Resonz z => dac; 1.0 => z.Q; Std.mtof(440) => z.freq;//whoops!!! -- gave mtof a cps value instead of a midi value. This gets REALLY loud on a Mac. Hope this gets looked at. In the meantime watch your ears. Later. Kurt ........................................................ http://www.kurtKotheimer.com .......................................................

On Mar 1, 2010, at 4:48 PM, Tomasz Kaye's brain wrote:

...

Hi Robert. Thanks for the pointer, that's very useful.

I'd stayed away from RezonZ until now because I thought it would be wisest to begin by using filter types I already knew (or thought i knew) from other environments: LPF BPF and HPF.

I saw that RezonZ doesn't have the runaway tendency of the other three when plugged into the test patch (and now I think I understand the significance of the line in the RezonZ ugen documentation: "keeps gain under control independent of frequency").

I'll have a try at getting RezonZ act as a rough approximation of the other three filter types (any further pointers anyone can offer in this direction would be great), and try again to do some reading around musical applications of biquad filters, though filter- related writing tends to make my head hurt :)

On Mon, Mar 1, 2010 at 9:00 PM, Robert Poor wrote: Tomasz:

I use SndBuf => ResonZ => Envelope => DAC frequently in live performances. Even though the center frequency and Q of the ResonZ are controlled by pitch bend and modulation wheel (respectively), I've never had any problems with stability. Am I missing something? :)

- Rob

...

About the filter problem: does it mean that currently no one is using chuck for classic sutractive synthesis patches like:

Oscillators -> Filters (cuttof driven by an ADSR) -> Amplifier (Level driven by an ADSR) ?

Are people just not doing this kind of routing in ChucK yet, or are there workarounds that avoid the filters going unstable when modulated in this way?

(Sorry to keep on about this, but I'm really keen to keep using ChucK if at all possible)

2010/2/17 mike clemow

...

OT:

2010/2/16 Andrew C. Smith

...

Seems that ChucK can crash brains, not just computers!

Chuck's filter code is actually written in Sumerian. The

Goddess Asherah

...

created Chuck to erase peoples' minds and make them worship her. The sound is actually a nam-shub and if you hear it, you will lose your wits and start mumbling Sumerian syllables...

(sorry, i couldn't help this outburst. i finished the book just a few short weeks ago. ;)

-Mike

...

Actually, my other solution was to run the audio through Jack

and into

...

Logic, where I can do a much better job of controlling the volume. This actually doesn't distort (since the distortion comes at the dac level), and changes the sound entirely. Anyway, just an option. -Andrew On Feb 16, 2010, at 5:03 PM, Kassen wrote:

2010/2/16 Stefan Blixt

...

If you do SinOsc s=> dac and the 100.0 => s.gain, are you then

able to

...

blow a speaker on a Mac laptop even if it's main volume is turned down? That's the curious thing to me, how the filter messes up so badly it makes my MacBook's speaker scream even though the volume is almost down to zero.

100? Try something like this value for a output; 242210436022272.0 That's a actual recorded output of .last(). I'm not sure what would happen if something of that volume would be played back on real speakers; there is probably a UN convention against that kind of thing ;-).

From what I understand of the situation you wouldn't blow the speaker. If Apple was smart they put in a pre-amp that's slightly smaller

...

...

...

maximum load of the speaker yet slightly over-speced for the output of the dac to keep repairs down. But yes; apparently you will can get a very high volume even though the (software) fader is down. This is what we know. Then from that I speculated (and unless something more credible comes by I think it's a good theory) that Apple is doing everything in float (with virtually unlimited headroom for practical applications), setting the master volume with a floating point multiplication, and handing the resultant value to the dac where inevitably it will be turned into a plain integer. In this case that integer will be the highest volume the poor little dac can take. If that's not it I can't imagine why +/- some 15 digit number would have a higher amplitude than +/-1, as a final output, post master fader. This is cheap compared to tweaking the voltage on the final hardware amp (which would always preserve the full bit-range) and probably sounds a lot better than going integer and throwing away a lot of bits at low volume, but it fails to take into account that we may not just turn the volume down for a more pleasant listen but also to protect our ears. Combine

...

...

...

potentially very sensitive studio or DJ headphones and you have a situation that may lead to hearing damage. I know that my own pro DJ

...

...

...

output a lot more volume than my mid-range earbuds at the same volume setting for a headphone jack.

IMHO this would be a oversight by Apple and I'm a bit surprised

...

...

...

hasn't been a storm of practical joke mails aimed at OSX users featuring videoclips embedding floating-point audio. I'd offer at least a

...

...

...

output limiter like what has been proposed for mp3 players. I don't believe in those for protecting children's ears through mandatory regulation because of the differences in headphone output volume, but for user-set

...

...

...

it might be a good idea. Of course ChucK is a bit more likely to cause this sort of issue than the average off-the-shelf audio player. Here is the original topic if you'd like to try to reproduce

2010/3/1 Tomasz Kaye's brain : than the that with with headphones will there optional protection the findings

...

...

...

so far; http://electro-music.com/forum/viewtopic.php?t=37921 Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

2010/4/1 Robert Poor :

Has nobody told you that a synthesis system that won't produce occasional bleeding eardrums is a BORING synthesis system? :)

My favorite recent blow-up happens when you tweak StifKarp's sustain too much. I use speakers not powerful enough to kill me, and I have to say, StifKarp sounds way cooler when it's broken than when it's working. -- Tom Lieber http://AllTom.com/ http://ckvlang.org/