Martin Eisenberg wrote:
> robert bristow-johnson wrote:
> > Martin Eisenberg wrote:
>
> >> DF2 transposed halves the number of states.
> >
> > not for multiple cascaded biquad sections.  the two output
> > states of "section n-1" are the same as the input states of
> > "section n".
>
> OK -- numerical properties aside you presume one way of constructing
> programs there, and so did I when I catered to David's immediate
> question but no more. Fusing the states of adjacent DF1 sections is
> of course easy if you write the thing from scratch every time.  If you
> just want to chain modules from a library and still do it, either you
> end up connecting filter objects to state buffers explicitly which
> sort of defies the premise; or you abstract the fusing into another
> library entity which is unconventional enough to add a fair bit of
> complexity however its code actually looks, and also possibly incurs
> runtime overhead.

well, i'm trying to compare apples to apples here.  there are little
optimized subroutines to do the DF2 with N sections, why don't TI and
ADI write them as DF1 (with that state "fusing")?

> > although the DF2 won't suffer saturation if floating point is
> > used, i have noted a numerical problem for DF2 if single
> > precision is used (having to do with loss of precision when
> > scaled states are subtracted).  we've discussed this before on
> > comp,dsp  you might unwrap this URL and read about it:
>
> Are you referring to DF2 or DF2-transposed here? You didn't respond
> to Nigel's pointing out in that thread that the latter is more benign
> (even though it has three summing nodes, alas). Also, when the code
> mostly keeps states in the extended-precision registers of the x86
> (David's target, as I learned on music-dsp) the difference between
> DF1 and DF2-t might be inconsequential after all, what do you say?

i didn't try the DF2-t, so what you and Nigel say might very well be
correct.  but, unless you put in a couple of quantizers, the states in
the DF2 transpose must be double precision.  if they are not, then the
DF2-t has 3 quantization noise sources instead of 1.

the DF1 needs only a double precision accumulator and has only one
quantization per section.

r b-j

robert bristow-johnson wrote:
> Martin Eisenberg wrote:

>> DF2 transposed halves the number of states.
> 
> not for multiple cascaded biquad sections.  the two output
> states of "section n-1" are the same as the input states of
> "section n".

OK -- numerical properties aside you presume one way of constructing 
programs there, and so did I when I catered to David's immediate 
question but no more. Fusing the states of adjacent DF1 sections is 
of course easy if you write the thing from scratch every time. If you 
just want to chain modules from a library and still do it, either you 
end up connecting filter objects to state buffers explicitly which 
sort of defies the premise; or you abstract the fusing into another 
library entity which is unconventional enough to add a fair bit of 
complexity however its code actually looks, and also possibly incurs 
runtime overhead. 

> although the DF2 won't suffer saturation if floating point is
> used, i have noted a numerical problem for DF2 if single
> precision is used (having to do with loss of precision when
> scaled states are subtracted).  we've discussed this before on
> comp,dsp  you might unwrap this URL and read about it:

Are you referring to DF2 or DF2-transposed here? You didn't respond 
to Nigel's pointing out in that thread that the latter is more benign 
(even though it has three summing nodes, alas). Also, when the code 
mostly keeps states in the extended-precision registers of the x86 
(David's target, as I learned on music-dsp) the difference between 
DF1 and DF2-t might be inconsequential after all, what do you say?


Martin

-- 
There are two kinds of people -- those who do the
work and those who take the credit. Try to be in
the first group; there is less competition there.
--Indira Gandhi

we'll see how long it takes Google to post this.  last time i used
Google to post, IT TOOK TWO DAYS to get out there.  (totally
inexcusable).  just for everyone's info, it's midnight EST (GMT-5hours)
Sunday night/Monday morn.

Martin Eisenberg wrote:
> davidross wrote:
> > rbj wrote:
>
> >>> Two sections cascaded, Direct Form I
> >>
> >>not bad.
> >
> > ta. If you know of anything better, i.e. less internal buffers,
> > then feel free to suggest.
>
> DF2 transposed halves the number of states.

not for multiple cascaded biquad sections.  the two output states of
"section n-1" are the same as the input states of "section n".  so, for
cascaded biquad DF1, the number of states are 2N+2 and for DF2, it's 2N
(if "N" is the number of biquad sections).

although the DF2 won't suffer saturation if floating point is used, i
have noted a numerical problem for DF2 if single precision is used
(having to do with loss of precision when scaled states are
subtracted).  we've discussed this before on comp,dsp  you might unwrap
this URL and read about it:

http://groups.google.com/group/comp.dsp/browse_thread/thread/39672b521039867c/72b222fd8b2bad41?hl=en#72b222fd8b2bad41

DF1 with a double-wide accumulator (so there is precisely one
quantization operation per biquad, DF2 has two quantization points in
each biquad unless your states are double precision), is still the best
way to go for either fixed or floating point, unless there are other
strange requirements (like decoupling the filter frequency from Q in
the filter coefficients).

r b-j

davidross wrote:

> Hey, your from the VST Developers list. Do you make plugins?

Yes, but none are public so far. Some are custom for a friend's use, 
in other cases I'm just too perfectionist for my own good.

> Your in the credits doco for providing some testing, and RBJ is
> in there too for helping with my post here. 

Ooh, how glamorous! ;)


Martin

-- 
Quidquid latine scriptum sit, altum viditur.

>davidross wrote:
>> rbj wrote:
>
>>>> Two sections cascaded, Direct Form I
>>>
>>>not bad.
>> 
>> ta. If you know of anything better, i.e. less internal buffers,
>> then feel free to suggest.
>
>DF2 transposed halves the number of states.
>
>
>Martin

Thanks Martin, I'll look into that. Hey, your from the VST Developers
list. Do you make plugins?

Cheers,
David

PS
EQ18 is now finished for the time being. I have to leave it to the side
for the minute although I would of really liked a 'reset' button in there
I couldnt get it work, should be simple'ish though which is strange. Your
in the credits doco for providing some testing, and RBJ is in there too
for helping with my post here.

You can check out EQ18 here, I would still like to do more with it such as
make the gui a bit more professional and add a reset button, but theres
only so much time you can spare for the old hobbies...

http://www.davideross.net/EQ18.htm

davidross wrote:
> rbj wrote:

>>> Two sections cascaded, Direct Form I
>>
>>not bad.
> 
> ta. If you know of anything better, i.e. less internal buffers,
> then feel free to suggest.

DF2 transposed halves the number of states.


Martin

-- 
I am an Indian and looked upon by the whites as a foolish man;
but it must be because I follow the advice of the white man.
--Shunka Witko

>in article iKSdnZf4u7DOMVLenZ2dnUVZ_tidnZ2d@giganews.com, davidross at
>david_ross@hotmail.co.uk wrote on 01/19/2006 10:12:
>
>>> 
>>> not that it's your fault or your newsserver's or news client's fault,
>but
>>> for some reason the ASCII LF characters "
>>> " weren't getting properly
>>> translated for me to read in my client program (OE).
>>> 
>> 
>> mmh, thats strange, not sure why that happened?? Sorry!
>> 
>
>the funny thing is that the LF i put in quotes above became a real LF
(note
>the line breaks between quotes) and below your quoting of my text has
>inserted more of these "little rectangles" are are ASCII LF (0x0A).  and
the
>strangest thing is that, as far as i know, when the messages are out
there
>in the USENET ether, the line breaks are *supposed* to be LF and then
our
>client programs are supposed to fix it (convert to CR, 0x0D, for Mac and
to
>CR/LF, 0x0D0A, for the PC).  so i do not understand this at all.  is it
>possible that you're spitting out something other than 0x0A for line
breaks
>and then somehow they fail to break the lines and then get converted to
0x0A
>to display?
>

rbj - to be honest, i'm not sure why this happens. I post from either my
computer at work or from home. I use Internet Explorer on both machines. I
dont know in any way why little squares would be displayed. Judging b what
you say it seems that this behaviour is rare, so I'm not sure why i seem
to generate it? I just want to post like everyone else.


>>> in article IPmdncNyZ8dHr1PeRVn-vA@giganews.com, davidross at
>>> david_ross@hotmail.co.uk wrote on 01/18/2006 07:21:
>>> 
>>>> I was wondering if anyone could offer some advice on what i can do
to
>>> maximize
>>>> the quality of my filters. I have developed a Parametric
>>> Equalizer with 10
>>>> bands (for audio). I would like the EQ to sound as good
>>> as possible.
>>> 
>>> well, that's commendable.  some of us don't like our EQs do sould as
good
>as
>>> possible.  we sorta like it if it sounds like dog excrement. :-)
>>> 
>> 
>> haha! Those filters must smell bad too then!
>> 
>>>> I am currently implementing the structure as a second order Direct
>Form.
>>> 
>>> there is more than one kind of Direct Form.  also are your second
order
>>> section in parallel or in cascade (series)?
>>> 
>> 
>> Two sections cascaded, Direct Form I
>
>not bad.

ta. If you know of anything better, i.e. less internal buffers, then feel
free to suggest. Of course i'll find all this out in due course, but if
you want to hasten my passage then feel free...

>>> just, to confirm, is the processing done for your EQ being done in
>>> fixed-point arithmetic?  it sounds like it but you never mention it.
>>> nowadays, i, for the most part, assume they're doing it in floating
>point
>>> until i read differently.
>> 
>> good old-fashioned floating point.
>
>then there simply is no scaling issue.  it's not that there is any
internal
>saturation.  one might argue that if your internal states are
>single-precision floats, your quality might suffer noticeably in
comparison
>to having double-precision internal states.

cool, so i dont really need to scale. One less thing to think about...

>> 
>>>> Just for fun I chosed an arbitrary scale factor of
>>> 50
>>>> i.e.  x = input / 50; and for the output y = output * 50; . But
there
>>> must be
>>>> a way in which scale factors are chosen?
>>> 
>>> it depends on the architecture.  assuming fixed-point, given a filter
>>> architecture, you try to compute the gain vs. frequency for each node
>w.r.t.
>>> the input.  then try to scaling the input so that the maximum gain at
>any
>>> frequency is unity.
>> 
>> cool, i liked that answer :-)
>
>yeah, but it's not an issue for you since you're good old-fashioned
floating
>point.
>

cool

>> Actually, I just found an article on music-dsp.org which has an
article
>> by
>some guy called rbg or something. It has some nice
>> lattice-ladder
>structures in there. You kept that one quiet guvnor!
>
>if i thought it was "sequitur", i'd a brought it up.  are you talking
about
>the "equivalence" paper?  it's more than a decade old.
>
>> Soo, what do you think about my idea, go for the lattice? Or do you
think
>its
>> overkill?
>
>i think it's not necessary for the purpose of controlling the magnitude
of
>internal states.
>
>if double precision is not used for the internal states, one thing that
some
>people do is dithering and noise shaping at the point of quantization,
but
>it's sorta hard and unnatural to do that for floating point because the
>magnitude of quantization error varies unpredictably.  pretty hard to
dither
>that.
>

well, i'll probably just leave as is for the time being. its sounding ok
and theres lots of pretty girls out there to soak up my attention at the
minute..

Best Regards,
David E Ross

in article iKSdnZf4u7DOMVLenZ2dnUVZ_tidnZ2d@giganews.com, davidross at
david_ross@hotmail.co.uk wrote on 01/19/2006 10:12:

>> 
>> not that it's your fault or your newsserver's or news client's fault,
but
>> for some reason the ASCII LF characters "
>> " weren't getting properly
>> translated for me to read in my client program (OE).
>> 
> 
> mmh, thats strange, not sure why that happened?? Sorry!
> 

the funny thing is that the LF i put in quotes above became a real LF (note
the line breaks between quotes) and below your quoting of my text has
inserted more of these "little rectangles" are are ASCII LF (0x0A).  and the
strangest thing is that, as far as i know, when the messages are out there
in the USENET ether, the line breaks are *supposed* to be LF and then our
client programs are supposed to fix it (convert to CR, 0x0D, for Mac and to
CR/LF, 0x0D0A, for the PC).  so i do not understand this at all.  is it
possible that you're spitting out something other than 0x0A for line breaks
and then somehow they fail to break the lines and then get converted to 0x0A
to display?

>> in article IPmdncNyZ8dHr1PeRVn-vA@giganews.com, davidross at
>> david_ross@hotmail.co.uk wrote on 01/18/2006 07:21:
>> 
>>> I was wondering if anyone could offer some advice on what i can do to
>> maximize
>>> the quality of my filters. I have developed a Parametric
>> Equalizer with 10
>>> bands (for audio). I would like the EQ to sound as good
>> as possible.
>> 
>> well, that's commendable.  some of us don't like our EQs do sould as good
as
>> possible.  we sorta like it if it sounds like dog excrement. :-)
>> 
> 
> haha! Those filters must smell bad too then!
> 
>>> I am currently implementing the structure as a second order Direct
Form.
>> 
>> there is more than one kind of Direct Form.  also are your second order
>> section in parallel or in cascade (series)?
>> 
> 
> Two sections cascaded, Direct Form I

not bad.

>> just, to confirm, is the processing done for your EQ being done in
>> fixed-point arithmetic?  it sounds like it but you never mention it.
>> nowadays, i, for the most part, assume they're doing it in floating
point
>> until i read differently.
> 
> good old-fashioned floating point.

then there simply is no scaling issue.  it's not that there is any internal
saturation.  one might argue that if your internal states are
single-precision floats, your quality might suffer noticeably in comparison
to having double-precision internal states.

> 
>>> Just for fun I chosed an arbitrary scale factor of
>> 50
>>> i.e.  x = input / 50; and for the output y = output * 50; . But there
>> must be
>>> a way in which scale factors are chosen?
>> 
>> it depends on the architecture.  assuming fixed-point, given a filter
>> architecture, you try to compute the gain vs. frequency for each node
w.r.t.
>> the input.  then try to scaling the input so that the maximum gain at
any
>> frequency is unity.
> 
> cool, i liked that answer :-)

yeah, but it's not an issue for you since you're good old-fashioned floating
point.

> Actually, I just found an article on music-dsp.org which has an article
> by
some guy called rbg or something. It has some nice
> lattice-ladder
structures in there. You kept that one quiet guvnor!

if i thought it was "sequitur", i'd a brought it up.  are you talking about
the "equivalence" paper?  it's more than a decade old.

> Soo, what do you think about my idea, go for the lattice? Or do you think
its
> overkill?

i think it's not necessary for the purpose of controlling the magnitude of
internal states.

if double precision is not used for the internal states, one thing that some
people do is dithering and noise shaping at the point of quantization, but
it's sorta hard and unnatural to do that for floating point because the
magnitude of quantization error varies unpredictably.  pretty hard to dither
that.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

>
>not that it's your fault or your newsserver's or news client's fault,
but
>for some reason the ASCII LF characters "
>" weren't getting properly
>translated for me to read in my client program (OE).
>

mmh, thats strange, not sure why that happened?? Sorry!


>in article IPmdncNyZ8dHr1PeRVn-vA@giganews.com, davidross at
>david_ross@hotmail.co.uk wrote on 01/18/2006 07:21:
>
>> I was wondering if anyone could offer some advice on what i can do to
>maximize
>> the quality of my filters. I have developed a Parametric
>Equalizer with 10
>> bands (for audio). I would like the EQ to sound as good
>as possible.
>
>well, that's commendable.  some of us don't like our EQs do sould as good
as
>possible.  we sorta like it if it sounds like dog excrement. :-)
>

haha! Those filters must smell bad too then!

>> I am currently implementing the structure as a second order Direct
Form.
>
>there is more than one kind of Direct Form.  also are your second order
>section in parallel or in cascade (series)?
>

Two sections cascaded, Direct Form I

>just, to confirm, is the processing done for your EQ being done in
>fixed-point arithmetic?  it sounds like it but you never mention it.
>nowadays, i, for the most part, assume they're doing it in floating
point
>until i read differently.

good old-fashioned floating point.


>> Just for fun I chosed an arbitrary scale factor of
>50
>> i.e.  x = input / 50; and for the output y = output * 50; . But there
>must be
>> a way in which scale factors are chosen?
>
>it depends on the architecture.  assuming fixed-point, given a filter
>architecture, you try to compute the gain vs. frequency for each node
w.r.t.
>the input.  then try to scaling the input so that the maximum gain at
any
>frequency is unity.

cool, i liked that answer :-)

Actually, I just found an article on music-dsp.org which has an article by
some guy called rbg or something. It has some nice lattice-ladder
structures in there. You kept that one quiet guvnor!

Soo, what do you think about my idea, go for the lattice? Or do you think
its overkill?

Best,
David

not that it's your fault or your newsserver's or news client's fault, but
for some reason the ASCII LF characters "
" weren't getting properly
translated for me to read in my client program (OE).

in article IPmdncNyZ8dHr1PeRVn-vA@giganews.com, davidross at
david_ross@hotmail.co.uk wrote on 01/18/2006 07:21:

> I was wondering if anyone could offer some advice on what i can do to
maximize
> the quality of my filters. I have developed a Parametric
Equalizer with 10
> bands (for audio). I would like the EQ to sound as good
as possible.

well, that's commendable.  some of us don't like our EQs do sould as good as
possible.  we sorta like it if it sounds like dog excrement. :-)

> I am currently implementing the structure as a second order Direct Form.

there is more than one kind of Direct Form.  also are your second order
section in parallel or in cascade (series)?

>
Would 
> it be worthwhile converting this structure over to a lattice ladder
structure
> - I have read here that the lattice ladder structure gives the
least
> quantization noise error. Would I notice an improvement?
> 
> I also have considered scaling my input signal to reduce the chance
> of
overflow error or roundoff error within the filter structure. But I'm
> not
sure what to choose as suitable scale factor? If I scale to much i
> may
throw away precious audio data, is this right? So how do we choose
> a
suitable scale factor?

just, to confirm, is the processing done for your EQ being done in
fixed-point arithmetic?  it sounds like it but you never mention it.
nowadays, i, for the most part, assume they're doing it in floating point
until i read differently.

> Just for fun I chosed an arbitrary scale factor of
50
> i.e.  x = input / 50; and for the output y = output * 50; . But there
must be
> a way in which scale factors are chosen?

it depends on the architecture.  assuming fixed-point, given a filter
architecture, you try to compute the gain vs. frequency for each node w.r.t.
the input.  then try to scaling the input so that the maximum gain at any
frequency is unity.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."