Csound Csound-dev Csound-tekno Search About

Q to Poles Comparison Statevar

Date2016-07-26 05:32
FromEmmett Palaima
SubjectQ to Poles Comparison Statevar
Hi, I am looking at using the statevar opcode in an app I am working on and was wondering how the q value of the filter corresponds to filter poles in terms of steepness of the cutoff.

What precisely does Q mean in the context of this opcode? The manual entry is a little vague on this point, it doesn't even give a range of values. 
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2016-07-26 07:00
FromPaul Batchelor
SubjectRe: Q to Poles Comparison Statevar
Q doesn't change the order (steepness) of the filter, but rather the amount of resonance a filter has:

https://ccrma.stanford.edu/~jos/fp/Quality_Factor_Q.html
https://en.wikipedia.org/wiki/Q_factor

-P

On Mon, Jul 25, 2016 at 9:32 PM, Emmett Palaima <epalaima@berklee.edu> wrote:
Hi, I am looking at using the statevar opcode in an app I am working on and was wondering how the q value of the filter corresponds to filter poles in terms of steepness of the cutoff.

What precisely does Q mean in the context of this opcode? The manual entry is a little vague on this point, it doesn't even give a range of values. 
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2016-07-26 17:55
FromSteven Yi
SubjectRe: Q to Poles Comparison Statevar
Paul's right on, but just to add about using Q, you could look at this
instrument:

instr 2
  icf = 1200
  ibandwidth = 75
  iq = icf / ibandwidth

  print iq
  ahp, alp, abp, abr  statevar rand:a(ampdbfs(-12)), icf, iq

  outc abp, abp
endin

event_i "i", 2, 0, 2.0

With  fd = f0 / Q, (where fd is the bandwidth and f0 is the center
frequency) you can work around it to experiment with different
bandwidths for a given center frequency. The example above gives a Q
of 16, and listening to it you should hear a lot of resonance and
narrow bandwidth.  16 is pretty high; going higher can cause the
resonance to feedback too much and have the filter explode.  A Q of 8
would give a bandwidth of 150, a Q of 4 would give a bandwidth of 300,
and so on.

If you worked with a fixed bandwidth, what would happen is that your Q
would become larger as the center frequency got higher.  I haven't
played around with that kind of thing, but it could make for an
interesting effect.

Working with a fixed Q, you'll get a wider bandwidth with higher
center frequencies, but it's proportional.  The resonant quality of
the sound should remain constant if you sweep through the range of
center frequencies.

So, if you want a more resonant, "sharper" sound, you might use Q
values [1,16], and if you want to have a more subtle effect, you would
use Q < 1.0.  At least, that's how I'd probably go about working with
it musically.

That's my interpretation at least.  Hope that's useful!
steven


On Tue, Jul 26, 2016 at 2:00 AM, Paul Batchelor  wrote:
> Q doesn't change the order (steepness) of the filter, but rather the amount
> of resonance a filter has:
>
> https://ccrma.stanford.edu/~jos/fp/Quality_Factor_Q.html
> https://en.wikipedia.org/wiki/Q_factor
>
> -P
>
> On Mon, Jul 25, 2016 at 9:32 PM, Emmett Palaima 
> wrote:
>>
>> Hi, I am looking at using the statevar opcode in an app I am working on
>> and was wondering how the q value of the filter corresponds to filter poles
>> in terms of steepness of the cutoff.
>>
>> What precisely does Q mean in the context of this opcode? The manual entry
>> is a little vague on this point, it doesn't even give a range of values.
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2016-07-26 20:47
FromOeyvind Brandtsegg
SubjectRe: Q to Poles Comparison Statevar
I've also found this resource helpful for the relation between bandwidth and Q.
http://www.rane.com/note170.html
Øyvind

2016-07-26 18:55 GMT+02:00 Steven Yi :
> Paul's right on, but just to add about using Q, you could look at this
> instrument:
>
> instr 2
>   icf = 1200
>   ibandwidth = 75
>   iq = icf / ibandwidth
>
>   print iq
>   ahp, alp, abp, abr  statevar rand:a(ampdbfs(-12)), icf, iq
>
>   outc abp, abp
> endin
>
> event_i "i", 2, 0, 2.0
>
> With  fd = f0 / Q, (where fd is the bandwidth and f0 is the center
> frequency) you can work around it to experiment with different
> bandwidths for a given center frequency. The example above gives a Q
> of 16, and listening to it you should hear a lot of resonance and
> narrow bandwidth.  16 is pretty high; going higher can cause the
> resonance to feedback too much and have the filter explode.  A Q of 8
> would give a bandwidth of 150, a Q of 4 would give a bandwidth of 300,
> and so on.
>
> If you worked with a fixed bandwidth, what would happen is that your Q
> would become larger as the center frequency got higher.  I haven't
> played around with that kind of thing, but it could make for an
> interesting effect.
>
> Working with a fixed Q, you'll get a wider bandwidth with higher
> center frequencies, but it's proportional.  The resonant quality of
> the sound should remain constant if you sweep through the range of
> center frequencies.
>
> So, if you want a more resonant, "sharper" sound, you might use Q
> values [1,16], and if you want to have a more subtle effect, you would
> use Q < 1.0.  At least, that's how I'd probably go about working with
> it musically.
>
> That's my interpretation at least.  Hope that's useful!
> steven
>
>
> On Tue, Jul 26, 2016 at 2:00 AM, Paul Batchelor  wrote:
>> Q doesn't change the order (steepness) of the filter, but rather the amount
>> of resonance a filter has:
>>
>> https://ccrma.stanford.edu/~jos/fp/Quality_Factor_Q.html
>> https://en.wikipedia.org/wiki/Q_factor
>>
>> -P
>>
>> On Mon, Jul 25, 2016 at 9:32 PM, Emmett Palaima 
>> wrote:
>>>
>>> Hi, I am looking at using the statevar opcode in an app I am working on
>>> and was wondering how the q value of the filter corresponds to filter poles
>>> in terms of steepness of the cutoff.
>>>
>>> What precisely does Q mean in the context of this opcode? The manual entry
>>> is a little vague on this point, it doesn't even give a range of values.
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>> be posted here
>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://flyndresang.no/
http://soundcloud.com/t-emp

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2016-07-26 21:25
FromEmmett Palaima
SubjectRe: Q to Poles Comparison Statevar
Okay, so Q defines resonance, that makes sense. 

In that case, what is the bandwidth / cutoff steepness of the filters in the opcode? The manual entry doesn't make a mention of it. Since there is no input on the opcode for setting bandwidth is that set internally?

On Tue, Jul 26, 2016 at 2:47 PM, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:
I've also found this resource helpful for the relation between bandwidth and Q.
http://www.rane.com/note170.html
Øyvind

2016-07-26 18:55 GMT+02:00 Steven Yi <stevenyi@gmail.com>:
> Paul's right on, but just to add about using Q, you could look at this
> instrument:
>
> instr 2
>   icf = 1200
>   ibandwidth = 75
>   iq = icf / ibandwidth
>
>   print iq
>   ahp, alp, abp, abr  statevar rand:a(ampdbfs(-12)), icf, iq
>
>   outc abp, abp
> endin
>
> event_i "i", 2, 0, 2.0
>
> With  fd = f0 / Q, (where fd is the bandwidth and f0 is the center
> frequency) you can work around it to experiment with different
> bandwidths for a given center frequency. The example above gives a Q
> of 16, and listening to it you should hear a lot of resonance and
> narrow bandwidth.  16 is pretty high; going higher can cause the
> resonance to feedback too much and have the filter explode.  A Q of 8
> would give a bandwidth of 150, a Q of 4 would give a bandwidth of 300,
> and so on.
>
> If you worked with a fixed bandwidth, what would happen is that your Q
> would become larger as the center frequency got higher.  I haven't
> played around with that kind of thing, but it could make for an
> interesting effect.
>
> Working with a fixed Q, you'll get a wider bandwidth with higher
> center frequencies, but it's proportional.  The resonant quality of
> the sound should remain constant if you sweep through the range of
> center frequencies.
>
> So, if you want a more resonant, "sharper" sound, you might use Q
> values [1,16], and if you want to have a more subtle effect, you would
> use Q < 1.0.  At least, that's how I'd probably go about working with
> it musically.
>
> That's my interpretation at least.  Hope that's useful!
> steven
>
>
> On Tue, Jul 26, 2016 at 2:00 AM, Paul Batchelor <ralphbluecoat@gmail.com> wrote:
>> Q doesn't change the order (steepness) of the filter, but rather the amount
>> of resonance a filter has:
>>
>> https://ccrma.stanford.edu/~jos/fp/Quality_Factor_Q.html
>> https://en.wikipedia.org/wiki/Q_factor
>>
>> -P
>>
>> On Mon, Jul 25, 2016 at 9:32 PM, Emmett Palaima <epalaima@berklee.edu>
>> wrote:
>>>
>>> Hi, I am looking at using the statevar opcode in an app I am working on
>>> and was wondering how the q value of the filter corresponds to filter poles
>>> in terms of steepness of the cutoff.
>>>
>>> What precisely does Q mean in the context of this opcode? The manual entry
>>> is a little vague on this point, it doesn't even give a range of values.
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>> be posted here
>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here



--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://flyndresang.no/
http://soundcloud.com/t-emp

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2016-07-26 23:06
FromSteven Yi
SubjectRe: Q to Poles Comparison Statevar
Please read the articles posted and the email I sent earlier.
Bandwidth is dependent upon the Q and center frequency.

If you want use the opcode by setting a specific bandwidth instead of
Q, you have to calculate for Q according to the center frequency,
which I gave in the code:

  icf = 1200
  ibandwidth = 75
  iq = icf / ibandwidth

If you set a constant bandwidth, the Q will change as the center
frequency changes, and your resonance then will depend upon the center
frequency.

On Tue, Jul 26, 2016 at 4:25 PM, Emmett Palaima  wrote:
> Okay, so Q defines resonance, that makes sense.
>
> In that case, what is the bandwidth / cutoff steepness of the filters in the
> opcode? The manual entry doesn't make a mention of it. Since there is no
> input on the opcode for setting bandwidth is that set internally?
>
> On Tue, Jul 26, 2016 at 2:47 PM, Oeyvind Brandtsegg
>  wrote:
>>
>> I've also found this resource helpful for the relation between bandwidth
>> and Q.
>> http://www.rane.com/note170.html
>> Øyvind
>>
>> 2016-07-26 18:55 GMT+02:00 Steven Yi :
>> > Paul's right on, but just to add about using Q, you could look at this
>> > instrument:
>> >
>> > instr 2
>> >   icf = 1200
>> >   ibandwidth = 75
>> >   iq = icf / ibandwidth
>> >
>> >   print iq
>> >   ahp, alp, abp, abr  statevar rand:a(ampdbfs(-12)), icf, iq
>> >
>> >   outc abp, abp
>> > endin
>> >
>> > event_i "i", 2, 0, 2.0
>> >
>> > With  fd = f0 / Q, (where fd is the bandwidth and f0 is the center
>> > frequency) you can work around it to experiment with different
>> > bandwidths for a given center frequency. The example above gives a Q
>> > of 16, and listening to it you should hear a lot of resonance and
>> > narrow bandwidth.  16 is pretty high; going higher can cause the
>> > resonance to feedback too much and have the filter explode.  A Q of 8
>> > would give a bandwidth of 150, a Q of 4 would give a bandwidth of 300,
>> > and so on.
>> >
>> > If you worked with a fixed bandwidth, what would happen is that your Q
>> > would become larger as the center frequency got higher.  I haven't
>> > played around with that kind of thing, but it could make for an
>> > interesting effect.
>> >
>> > Working with a fixed Q, you'll get a wider bandwidth with higher
>> > center frequencies, but it's proportional.  The resonant quality of
>> > the sound should remain constant if you sweep through the range of
>> > center frequencies.
>> >
>> > So, if you want a more resonant, "sharper" sound, you might use Q
>> > values [1,16], and if you want to have a more subtle effect, you would
>> > use Q < 1.0.  At least, that's how I'd probably go about working with
>> > it musically.
>> >
>> > That's my interpretation at least.  Hope that's useful!
>> > steven
>> >
>> >
>> > On Tue, Jul 26, 2016 at 2:00 AM, Paul Batchelor
>> >  wrote:
>> >> Q doesn't change the order (steepness) of the filter, but rather the
>> >> amount
>> >> of resonance a filter has:
>> >>
>> >> https://ccrma.stanford.edu/~jos/fp/Quality_Factor_Q.html
>> >> https://en.wikipedia.org/wiki/Q_factor
>> >>
>> >> -P
>> >>
>> >> On Mon, Jul 25, 2016 at 9:32 PM, Emmett Palaima 
>> >> wrote:
>> >>>
>> >>> Hi, I am looking at using the statevar opcode in an app I am working
>> >>> on
>> >>> and was wondering how the q value of the filter corresponds to filter
>> >>> poles
>> >>> in terms of steepness of the cutoff.
>> >>>
>> >>> What precisely does Q mean in the context of this opcode? The manual
>> >>> entry
>> >>> is a little vague on this point, it doesn't even give a range of
>> >>> values.
>> >>> Csound mailing list Csound@listserv.heanet.ie
>> >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> >>> https://github.com/csound/csound/issues Discussions of bugs and
>> >>> features can
>> >>> be posted here
>> >>
>> >>
>> >> Csound mailing list Csound@listserv.heanet.ie
>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> >> https://github.com/csound/csound/issues Discussions of bugs and
>> >> features can
>> >> be posted here
>> >
>> > Csound mailing list
>> > Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> > Send bugs reports to
>> >         https://github.com/csound/csound/issues
>> > Discussions of bugs and features can be posted here
>>
>>
>>
>> --
>>
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>>
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://flyndresang.no/
>> http://soundcloud.com/t-emp
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here