It seems to me that buzz~ isn't working according to it's description.
I'm using a zip file with source files dated in January 2002, and am running Linux, using the external freshly compiled using the supplied makefile.
The problem I am having can be seen using the buzz~-help.pd patch. When I set the frequency to some non-zero value, set "a" to result in a "rich" spectrum (ie > 0), and set "H" to 1, I would expect to see a sinusoid at the fundamental frequency (since H==1). But there are already strong overtones with H==1. The problem is quite obvious audibly to the extent that I can clearly hear overtones with H==1; it's not just some subtle floating point approximation error.
I haven't gone through the code to work through the math yet, but I suspect there might be a problem either in the code or the documentation, or that there is a more recent version available.
Anyway, I just thought I'd post this in case you (Frank), or anyone has a quick answer. If not I'll certainly investigate the code if I get the time to do it, and report back.
Larry
Hallo,
Larry Troxler hat gesagt: // Larry Troxler wrote:
It seems to me that buzz~ isn't working according to it's description.
I'm using a zip file with source files dated in January 2002, and am running Linux, using the external freshly compiled using the supplied makefile.
The problem I am having can be seen using the buzz~-help.pd patch. When I set the frequency to some non-zero value, set "a" to result in a "rich" spectrum (ie > 0), and set "H" to 1, I would expect to see a sinusoid at the fundamental frequency (since H==1). But there are already strong overtones with H==1. The problem is quite obvious audibly to the extent that I can clearly hear overtones with H==1; it's not just some subtle floating point approximation error.
Yes, you're right, it behaves that way. It might very well be that there indeed is a bug hidden (although it still makes interesting sounds... ;)
I haven't gone through the code to work through the math yet, but I suspect there might be a problem either in the code or the documentation, or that there is a more recent version available.
There also is a flext/SndObj version on my disk that I worked on some months ago but didn't finish. It has the same problem. I've put it on http://footils.org/pkg/fbuzz-test.tgz (really unfinished, but should compile on Linux)
I'd love it if you have a look at buzz, whichever version.
Frank Barknecht _ ______footils.org__
On Friday 24 October 2003 15:12, Frank Barknecht wrote:
Hallo,
Larry Troxler hat gesagt: // Larry Troxler wrote:
It seems to me that buzz~ isn't working according to it's description.
...
Yes, you're right, it behaves that way. It might very well be that there indeed is a bug hidden (although it still makes interesting sounds... ;)
Well I compared your code against the formula in the paper, and I couldn't find any differences - it looks like it matches to me.
The only minor error is that H is the number of harmonics minus one, so that H=0 should give a single frequency, not H=1. I guess you could say that it's the number of overtones.
I tried to convince myself using trig identities that with H=0 and a=1/2, that big mess simplifies to a sinusoid. But so far I haven't been able to do that yet. But I'm not a mathematician, so this doesn't in itself mean a problem.
Still, I suspect that there's an error somewhere in the paper as published.
Well we should look at the csound buzz opcode I guess...
Larry
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
Still, I suspect that there's an error somewhere in the paper as published.
Well we should look at the csound buzz opcode I guess...
Or ask John Lazzaro lazzaro@CS.Berkeley.EDU?
Frank Barknecht _ ______footils.org__
On Friday 24 October 2003 15:12, Frank Barknecht wrote:
Yes, you're right, it behaves that way. It might very well be that there indeed is a bug hidden (although it still makes interesting sounds... ;)
Frank, I replaced the formula with the one in this paper:
www.ccrma.www/~stilti/papers/blit.pdf
and it sounds correct now.
L0arry
On Sunday 26 October 2003 09:13, Larry Troxler wrote:
On Friday 24 October 2003 15:12, Frank Barknecht wrote:
Yes, you're right, it behaves that way. It might very well be that there indeed is a bug hidden (although it still makes interesting sounds... ;)
Frank, I replaced the formula with the one in this paper:
www.ccrma.www/~stilti/papers/blit.pdf
That's www-ccrma.stanford.edu/~stilti/papers/blit.pdf
The forumula is in section 3.5.
Some details I've found, that you can see by looking at the summation form: N is actually the number of harmonics plus one, so that you need N=2 to generate a sinusoid. Also, the amplitude of the fundamental is scaled by a, which maybe is not very intuitive. I would more expect the fundamental to stay constant and have the other partial amplitudes relative to that (in which case you could just multiply the formula by 1/a). But maybe we should see how csound does it.
Other thoughts:
(o) It would be nice if the a parameter could be a DSP signal as well.
(o) I didn't bother with the theta (initial phase) parameter that's used in the formula - I just set it to zero and didn't compute it. I think it's only usefull if the output is then nonlinearized of if FM is used on it, right?
(o) csound has gbuzz which lets you set the starting harmonic as well. I think you would just subtract two buzz's to do this, but maybe something in the formula cancels out when you do this, reducing the computation
(o) Would it make sense to have a version that takes input from an external
phasor, rather than using one internally? In this way the computation would
be reduced when using a few of these to generate a complete spectrum as is
described in the paper.
Larry
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
On Sunday 26 October 2003 09:13, Larry Troxler wrote:
On Friday 24 October 2003 15:12, Frank Barknecht wrote:
Yes, you're right, it behaves that way. It might very well be that there indeed is a bug hidden (although it still makes interesting sounds... ;)
Frank, I replaced the formula with the one in this paper:
www.ccrma.www/~stilti/papers/blit.pdf
That's www-ccrma.stanford.edu/~stilti/papers/blit.pdf
Here it's in $HOME/audio/doc/blit.pdf ;)
Did you alter the C or the flext version? Maybe it also would be useful to write this as a SndObj object. SndObj includes a Buzz opcode, but last time I looked it was generating strange sound, probably because of rounding errors (It uses table lookups for sin/cos generation).
Well, anyway I'd love to test your code (lazy me)
Some details I've found, that you can see by looking at the summation form: N is actually the number of harmonics plus one, so that you need N=2 to generate a sinusoid. Also, the amplitude of the fundamental is scaled by a, which maybe is not very intuitive. I would more expect the fundamental to stay constant and have the other partial amplitudes relative to that (in which case you could just multiply the formula by 1/a). But maybe we should see how csound does it.
Other thoughts:
(o) It would be nice if the a parameter could be a DSP signal as well.
Yes, but it will however make it more expensive, because you cannot precalculate several of the variables anymore.
(o) I didn't bother with the theta (initial phase) parameter that's used in the formula - I just set it to zero and didn't compute it. I think it's only usefull if the output is then nonlinearized of if FM is used on it, right?
I think, a mean of resetting it (for oscillator sync) would still be useful.
(o) Would it make sense to have a version that takes input from an external
phasor, rather than using one internally? In this way the computation would be reduced when using a few of these to generate a complete spectrum as is described in the paper.
Yes, I think this would make sense, although I didn't read the blit paper for some time now.
Frank Barknecht _ ______footils.org__
On Sunday 26 October 2003 10:12, Frank Barknecht wrote:
Did you alter the C or the flext version? Maybe it also would be useful to write this as a SndObj object. SndObj includes a Buzz opcode, but last time I looked it was generating strange sound, probably because of rounding errors (It uses table lookups for sin/cos generation).
The C version, only because I still don't have a handle on flext, SndObj (I'm not sure even what that is!), or the PD build process. Your C version was much easier to build for me.
(o) It would be nice if the a parameter could be a DSP signal as well.
Yes, but it will however make it more expensive, because you cannot precalculate several of the variables anymore.
That's true; there should be two versions of the DSP loop.
(o) I didn't bother with the theta (initial phase) parameter that's used in the formula - I just set it to zero and didn't compute it. I think it's only usefull if the output is then nonlinearized of if FM is used on it, right?
I think, a mean of resetting it (for oscillator sync) would still be useful.
I should have elaborated. This is not the same thing. In the formula you can set the initial phase of all the harmonics to (the same) specific angle. This is independent of setting the iniial phase of the phasor, which sets the initial phases to ( k * theta).
(o) Would it make sense to have a version that takes input from an external phasor, rather than using one internally? In this way the computation would be reduced when using a few of these to generate a complete spectrum as is described in the paper.
Yes, I think this would make sense, although I didn't read the blit paper for some time now.
ciao
Larry