Benjamin Buch | 16 Jul 12:05 2011
Picon
Picon

Multiplying LocalIn -> Dangerous?

I'm currently trying to get a hang of supercollider by working through the supercollider 140 examples (http://ia700406.us.archive.org/16/items/sc140/sc140_sourcecode.txt)

I re-structured the first piece by Nathaniel like this so I can better understand what's going on:

(
{
	var bandpass, signal, bandpass_in, bandpass_freq;
	
	bandpass_in = (LocalIn.ar(2) * 7.5) + Saw.ar([32,33],0.2);
	
	bandpass_freq = 2**LFNoise0.kr(4/3,4)*300; 
	
	bandpass = BPF.ar(
					bandpass_in,
					bandpass_freq,
					0.1
				).distort;
		
	signal = CombN.ar(
		bandpass,
		2,
		2,
		40
	);
	
	LocalOut.ar(signal);
	
	signal;
	
}.play
(Continue reading)

David Niemi | 16 Jul 12:48 2011
Picon

Re: Multiplying LocalIn -> Dangerous?

Good Morning Benjamin,


I too am trying to get a hang of SC. The help file for LocalIn says:

"LocalIn defines buses that are local to the enclosing synth. These are like the global buses, but are more convenient if you want to implement a self contained effect that uses a feedback processing loop."

Is it possible *7.5 is creating a feedback loop? Maybe it causes a loop but does not affect the amplitude of the piece.

Hopefully we can figure this out!

Dave

On Sat, Jul 16, 2011 at 6:05 AM, Benjamin Buch <benni.buch-Mmb7MZpHnFY@public.gmane.org> wrote:
I'm currently trying to get a hang of supercollider by working through the supercollider 140 examples (http://ia700406.us.archive.org/16/items/sc140/sc140_sourcecode.txt)

I re-structured the first piece by Nathaniel like this so I can better understand what's going on:

(
{
       var bandpass, signal, bandpass_in, bandpass_freq;

       bandpass_in = (LocalIn.ar(2) * 7.5) + Saw.ar([32,33],0.2);

       bandpass_freq = 2**LFNoise0.kr(4/3,4)*300;

       bandpass = BPF.ar(
                                       bandpass_in,
                                       bandpass_freq,
                                       0.1
                               ).distort;

       signal = CombN.ar(
               bandpass,
               2,
               2,
               40
       );

       LocalOut.ar(signal);

       signal;

}.play
)

Here, LocalIn gets multiplied by 7.5!
How's that supposed to happen?
In my understanding, if you multiply any sound by 7.5 it should get pretty loud.
I tried to come up with a minimal example of what I mean.

DON'T EXECUTE THIS CODE! NEVER EVER! BAD CODE!
(
{
       var source, signal;

       source = Saw.ar([32,33],0.2);

       signal = LocalIn.ar(2)*2 + source;

       LocalOut.ar(signal);

       signal;

}.play
)
DON'T EXECUTE THIS CODE! NEVER EVER! BAD CODE!

Here, the LocalIn only gets multiplied by 2, but this results in an incredibly loud blip which crashes my mac's sound system.
The only thing that I can come up is that in Nathaniel's piece, the signal is filtered by BPF.

Could somebody explain what's going on?

Best,
Benjamin


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Wouter Snoei | 16 Jul 13:04 2011
Picon

Re: Multiplying LocalIn -> Dangerous?

Hi Benjamin,

I think you are already understanding what happens quite well. However Nathaniel's example is quite
clever and appears to be carefully tweaked by hand, so it is understandable that it is hard to grasp at first
look. Let me try to explain:

> (
> {
> 	var bandpass, signal, bandpass_in, bandpass_freq;
> 	
> 	bandpass_in = (LocalIn.ar(2) * 7.5) + Saw.ar([32,33],0.2);
> 	
> 	bandpass_freq = 2**LFNoise0.kr(4/3,4)*300; 
> 	
> 	bandpass = BPF.ar(
> 					bandpass_in,
> 					bandpass_freq,
> 					0.1
> 				).distort;
> 		
> 	signal = CombN.ar(
> 		bandpass,
> 		2,
> 		2,
> 		40
> 	);
> 	
> 	LocalOut.ar(signal);
> 	
> 	signal;
> 	
> }.play
> )
> 
> Here, LocalIn gets multiplied by 7.5!

Indeed, which means an increase in level of about 18 dB. Normally that will cause most signals to go out of the
-1.0 to 1.0 range. Here as well. That is no problem as long as you don't feed it directly to your outputs. SC
can handle out-of-range signals to an almost infinite range internally because it works with floating
point numbers.

In the bandpass line the magic happens. The signal is filtered with a bandwidth of 0.1, basically reducing
it's level again by apx 25db (depending on the cutoff frequency and the material in the loop). This is the
reason why there is no build up in the feedback loop; the level earlier multiplied is now lowered again, and
becomes apx -7dB. Sometimes a specific frequency gets amplified and the level increases, but because the
LFNoise0 changes the bandpass frequency every ~1.33s this never happens for too long.

But there's more: the loud clicks you hear are caused by the sudden jumps in frequency (bandpass_freq).
These are basically a side-effect of bpf, here used in a musical way. These clicks can stretch way beyond
the -1.0 to 1.0 range. To compensate for this Nathaniel added a .distort to the filter. Apart from adding a
nice distortion edge to the sound, this also makes sure the signal is clipped between -1.0 and 1.0. So
basically it works like a limiter too, making sure the signal never grows out of range.

The last step is the CombN which, very important, adds a 2 second delay to the sound. This makes the feeback
process evolve over time. It also has an internal feedback loop, which makes the total sound a blend
between the LocalIn/LocalOut pair and a normal feedback delay. This loop does add to the total volume
though, and results in the output signal being slightly out of range especially at the clicking moments.
So to make it really perfect we'd need to soften the output signal. Nathaneal chose not to, probably
because the hard clipping of the clicks creates a nice extra edge.

I hope this sheds some light on the situation.

You can experiment with widening the bpf q-factor and hear how it grows more and more out of control.
Feedback in digital situations is an interesting field, and requires usually a lot of tweaking..

cheers,
Wouter

> How's that supposed to happen?
> In my understanding, if you multiply any sound by 7.5 it should get pretty loud.

> I tried to come up with a minimal example of what I mean.
> 
> DON'T EXECUTE THIS CODE! NEVER EVER! BAD CODE!
> (
> {
> 	var source, signal;
> 	
> 	source = Saw.ar([32,33],0.2);
> 	
> 	signal = LocalIn.ar(2)*2 + source;
> 	
> 	LocalOut.ar(signal);
> 	
> 	signal;
> 
> }.play
> )
> DON'T EXECUTE THIS CODE! NEVER EVER! BAD CODE!
> 
> Here, the LocalIn only gets multiplied by 2, but this results in an incredibly loud blip which crashes my
mac's sound system.
> The only thing that I can come up is that in Nathaniel's piece, the signal is filtered by BPF.
> 
> Could somebody explain what's going on?
> 
> Best,
> Benjamin
> 
> 
> _______________________________________________
> sc-users mailing list
> 
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Benjamin Buch | 16 Jul 14:17 2011
Picon
Picon

Re: Multiplying LocalIn -> Dangerous?

Hi Wouter!

Thanks for explaining, things are a lot clearer now to me!

> Indeed, which means an increase in level of about 18 dB. Normally that will cause most signals to go out of
the -1.0 to 1.0 range. Here as well. That is no problem as long as you don't feed it directly to your outputs.
SC can handle out-of-range signals to an almost infinite range internally because it works with floating
point numbers.

Good to know!

> In the bandpass line the magic happens. The signal is filtered with a bandwidth of 0.1, basically reducing
it's level again by apx 25db (depending on the cutoff frequency and the material in the loop). This is the
reason why there is no build up in the feedback loop; the level earlier multiplied is now lowered again, and
becomes apx -7dB. Sometimes a specific frequency gets amplified and the level increases, but because the
LFNoise0 changes the bandpass frequency every ~1.33s this never happens for too long.

I wrote another example to see the effect of BPF:

(
{
	var source, signal;
	
	source = Saw.ar([32,33],0.2);
	
	signal = LocalIn.ar(2)*3 + source;
	signal = BPF.ar(signal, 1000, 0.1);
	
	LocalOut.ar(signal);
	
	signal;
}.scope
)

With a factor of 3 this works and demonstrates the effect of LocalIn/Out quite well; but with a factor of 7.5
this gets pretty loud too (very loud, so I wouldn't recommend trying).
I guess it's like you said, it's different if you do this on a steady or a changing signal.

> But there's more: the loud clicks you hear are caused by the sudden jumps in frequency (bandpass_freq).
These are basically a side-effect of bpf, here used in a musical way.

I figured out the clicks with this sample code:

	(
	{
		BPF.ar(
			Saw.ar([32,33],0.2),
			EnvGen.kr(
				Env(
					[0,20,480,20,960,20,1440,20,1920,20,2400,20,2880],
					[1,1,1,1,1,1,1,1,1,1,1,1],
					'step')
				),
			0.1
		).distort
	}.scope;
	)

Could you explain how the clicking/the bpf-side-effect works?
I mean how comes that this only occurs with sudden big jumps?

> These clicks can stretch way beyond the -1.0 to 1.0 range. To compensate for this Nathaniel added a
.distort to the filter. Apart from adding a nice distortion edge to the sound, this also makes sure the
signal is clipped between -1.0 and 1.0. So basically it works like a limiter too, making sure the signal
never grows out of range.

Nice explanation of distort! I wondered what this does, because it didn't seem to make too much of a
difference sound-wise.

> The last step is the CombN which, very important, adds a 2 second delay to the sound. This makes the feeback
process evolve over time. It also has an internal feedback loop, which makes the total sound a blend
between the LocalIn/LocalOut pair and a normal feedback delay. This loop does add to the total volume
though, and results in the output signal being slightly out of range especially at the clicking moments.
So to make it really perfect we'd need to soften the output signal. Nathaneal chose not to, probably
because the hard clipping of the clicks creates a nice extra edge.
> 
> I hope this sheds some light on the situation.

Absolutely did, thanks!

Best,
Benjamin

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Nathaniel Virgo | 16 Jul 18:02 2011
Picon

Re: Multiplying LocalIn -> Dangerous?

By the way, you might be interested in this analysis that Bruno
Ruviaro did of the same sctweet - it explains a little about how the
sound is produced:
https://ccrma.stanford.edu/wiki/SuperCollider_Tweets

(but really, I wrote it by adding, tweaking and removing things until
it sounded good and was short enough - all this analysis makes it
sound much cleverer than it really is...)

Nathaniel

On 16 July 2011 14:17, Benjamin Buch <benni.buch@...> wrote:
> Hi Wouter!
>
> Thanks for explaining, things are a lot clearer now to me!
>
>> Indeed, which means an increase in level of about 18 dB. Normally that will cause most signals to go out of
the -1.0 to 1.0 range. Here as well. That is no problem as long as you don't feed it directly to your outputs.
SC can handle out-of-range signals to an almost infinite range internally because it works with floating
point numbers.
>
> Good to know!
>
>> In the bandpass line the magic happens. The signal is filtered with a bandwidth of 0.1, basically
reducing it's level again by apx 25db (depending on the cutoff frequency and the material in the loop).
This is the reason why there is no build up in the feedback loop; the level earlier multiplied is now lowered
again, and becomes apx -7dB. Sometimes a specific frequency gets amplified and the level increases, but
because the LFNoise0 changes the bandpass frequency every ~1.33s this never happens for too long.
>
> I wrote another example to see the effect of BPF:
>
> (
> {
>        var source, signal;
>
>        source = Saw.ar([32,33],0.2);
>
>        signal = LocalIn.ar(2)*3 + source;
>        signal = BPF.ar(signal, 1000, 0.1);
>
>        LocalOut.ar(signal);
>
>        signal;
> }.scope
> )
>
> With a factor of 3 this works and demonstrates the effect of LocalIn/Out quite well; but with a factor of 7.5
this gets pretty loud too (very loud, so I wouldn't recommend trying).
> I guess it's like you said, it's different if you do this on a steady or a changing signal.
>
>> But there's more: the loud clicks you hear are caused by the sudden jumps in frequency (bandpass_freq).
These are basically a side-effect of bpf, here used in a musical way.
>
> I figured out the clicks with this sample code:
>
>        (
>        {
>                BPF.ar(
>                        Saw.ar([32,33],0.2),
>                        EnvGen.kr(
>                                Env(
>                                        [0,20,480,20,960,20,1440,20,1920,20,2400,20,2880],
>                                        [1,1,1,1,1,1,1,1,1,1,1,1],
>                                        'step')
>                                ),
>                        0.1
>                ).distort
>        }.scope;
>        )
>
> Could you explain how the clicking/the bpf-side-effect works?
> I mean how comes that this only occurs with sudden big jumps?
>
>> These clicks can stretch way beyond the -1.0 to 1.0 range. To compensate for this Nathaniel added a
.distort to the filter. Apart from adding a nice distortion edge to the sound, this also makes sure the
signal is clipped between -1.0 and 1.0. So basically it works like a limiter too, making sure the signal
never grows out of range.
>
> Nice explanation of distort! I wondered what this does, because it didn't seem to make too much of a
difference sound-wise.
>
>> The last step is the CombN which, very important, adds a 2 second delay to the sound. This makes the feeback
process evolve over time. It also has an internal feedback loop, which makes the total sound a blend
between the LocalIn/LocalOut pair and a normal feedback delay. This loop does add to the total volume
though, and results in the output signal being slightly out of range especially at the clicking moments.
So to make it really perfect we'd need to soften the output signal. Nathaneal chose not to, probably
because the hard clipping of the clicks creates a nice extra edge.
>>
>> I hope this sheds some light on the situation.
>
> Absolutely did, thanks!
>
> Best,
> Benjamin
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Nathaniel Virgo | 16 Jul 13:12 2011
Picon

Re: Multiplying LocalIn -> Dangerous?

Hi Benjamin

It's a long time since I wrote that code, so I can't remember the
reason for every decision - but note that in my tweet code there is a
.distort in there as well.  The distortion prevents the amplitude from
becoming greater than 1.  If we add the distortion into your code then
it doesn't sound amazing, but it doesn't mess up the sound system
either.  Generally combining distortion effects with filters in
feedback loops tends to make unpredictable but cool sounds.

(
{
       var source, signal;

       source = Saw.ar([32,33],0.2);

       signal = LocalIn.ar(2)*2 + source;

       signal = signal.distort;

       LocalOut.ar(signal);

       signal;

}.play
)

By the way, in case you don't know - if you ever accidentally stop
your sound from working by running this kind of code, you can fix it
by running the 'Audio MIDI Setup' app (found in
/Applications/Utilities) and changing the output sample rate from
44100 to 48000 and back again.  You should hear a loud click as the
output level goes back to 0.  There might be a better way, but that
works for me.

HTH,
Nathaniel

On 16 July 2011 12:05, Benjamin Buch <benni.buch@...> wrote:
> I'm currently trying to get a hang of supercollider by working through the supercollider 140 examples (http://ia700406.us.archive.org/16/items/sc140/sc140_sourcecode.txt)
>
> I re-structured the first piece by Nathaniel like this so I can better understand what's going on:
>
> (
> {
>        var bandpass, signal, bandpass_in, bandpass_freq;
>
>        bandpass_in = (LocalIn.ar(2) * 7.5) + Saw.ar([32,33],0.2);
>
>        bandpass_freq = 2**LFNoise0.kr(4/3,4)*300;
>
>        bandpass = BPF.ar(
>                                        bandpass_in,
>                                        bandpass_freq,
>                                        0.1
>                                ).distort;
>
>        signal = CombN.ar(
>                bandpass,
>                2,
>                2,
>                40
>        );
>
>        LocalOut.ar(signal);
>
>        signal;
>
> }.play
> )
>
> Here, LocalIn gets multiplied by 7.5!
> How's that supposed to happen?
> In my understanding, if you multiply any sound by 7.5 it should get pretty loud.
> I tried to come up with a minimal example of what I mean.
>
> DON'T EXECUTE THIS CODE! NEVER EVER! BAD CODE!
> (
> {
>        var source, signal;
>
>        source = Saw.ar([32,33],0.2);
>
>        signal = LocalIn.ar(2)*2 + source;
>
>        LocalOut.ar(signal);
>
>        signal;
>
> }.play
> )
> DON'T EXECUTE THIS CODE! NEVER EVER! BAD CODE!
>
> Here, the LocalIn only gets multiplied by 2, but this results in an incredibly loud blip which crashes my
mac's sound system.
> The only thing that I can come up is that in Nathaniel's piece, the signal is filtered by BPF.
>
> Could somebody explain what's going on?
>
> Best,
> Benjamin
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Benjamin Buch | 16 Jul 14:04 2011
Picon
Picon

Re: Multiplying LocalIn -> Dangerous?

Hi Nathaniel!

Am 16.07.2011 um 13:12 schrieb Nathaniel Virgo:

> Hi Benjamin
> 
> It's a long time since I wrote that code, so I can't remember the
> reason for every decision - but note that in my tweet code there is a
> .distort in there as well.  The distortion prevents the amplitude from
> becoming greater than 1.  If we add the distortion into your code then
> it doesn't sound amazing, but it doesn't mess up the sound system
> either.  Generally combining distortion effects with filters in
> feedback loops tends to make unpredictable but cool sounds.
> 
> (
> {
>        var source, signal;
> 
>        source = Saw.ar([32,33],0.2);
> 
>        signal = LocalIn.ar(2)*2 + source;
> 
>        signal = signal.distort;
> 
>        LocalOut.ar(signal);
> 
>        signal;
> 
> }.play
> )

Thanks for explaining what .distort does.
(Thanks to Wouter as well, who explained it in a previous email...)

It's a good thing to have sort of an out-of-the-box-limiter when experimenting.

As often I'm surprised/impressed how important the underlaying details of supercollider
functions/methods/ugens are.
There's often knowledge hidden which is not obvious from reading the documentation.

Now when I think of it .distortion seems to do what a guitar effect stomp box does:
Clipping off the upper and lower parts of the signal, which makes it 'edgy'.

> By the way, in case you don't know - if you ever accidentally stop
> your sound from working by running this kind of code, you can fix it
> by running the 'Audio MIDI Setup' app (found in
> /Applications/Utilities) and changing the output sample rate from
> 44100 to 48000 and back again.  You should hear a loud click as the
> output level goes back to 0.  There might be a better way, but that
> works for me.

Thanks, I'll try it next time.
Seems more reasonable than switching the computer off and on again...

> HTH,
> Nathaniel

It did!

Benjamin

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

thor | 16 Jul 22:48 2011
Picon

Re: Multiplying LocalIn -> Dangerous?


Another and perhaps quicker way is to plug and unplug a minijack into your sound output on your laptop.
(this has been discussed on the list in the past)

On 16 Jul 2011, at 13:04, Benjamin Buch wrote:

>> By the way, in case you don't know - if you ever accidentally stop
>> your sound from working by running this kind of code, you can fix it
>> by running the 'Audio MIDI Setup' app (found in
>> /Applications/Utilities) and changing the output sample rate from
>> 44100 to 48000 and back again.  You should hear a loud click as the
>> output level goes back to 0.  There might be a better way, but that
>> works for me.
> 
> Thanks, I'll try it next time.
> Seems more reasonable than switching the computer off and on again...

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Tim Blechmann | 16 Jul 23:05 2011

Re: Multiplying LocalIn -> Dangerous?

> By the way, in case you don't know - if you ever accidentally stop
> your sound from working by running this kind of code, you can fix it
> by running the 'Audio MIDI Setup' app (found in
> /Applications/Utilities) and changing the output sample rate from
> 44100 to 48000 and back again.  You should hear a loud click as the
> output level goes back to 0.  There might be a better way, but that
> works for me.

btw, it would probably make sense to clip the signal to -1 to 1 and to fixup 
denormals in the core-audio backend of scsynth, if a user can break the driver 
by sending it an invalid signal.

otherwise someone could file a bug report at apple

tim

Gmane