[music-dsp] different waveforms from a single

[kernel]

oscillator. legend has it that a triangle wave can be derived by
sending a square wave thorugh a leaky integrator. this legend is true.
i can get a sinewave by waveshaping the triangle so that's 3
waveforms. anyone know if sawtooth waves can be achieved somehow from
a square/pulse wave oscillator?

pulse > (leaky integrator) > triangle > (waveshaper) > sine

thanks, kernel.

[James Chandler Jr]

Hi kernel

Neglecting possibly horrible aliasing in digital domain (not a problem in analog
however), you can derive a 2X freq Sawtooth wave from a Triangle by toggling the
gain between +1 and -1 on slope changes in the triangle wave.

If you have the original Square wave in pretty good phase-alignment with the
Triangle and derived 2X freq Sawtooth, you can get a 1X freq Sawtooth by mixing
the 2X freq Sawtooth with the original Square wave. That can work pretty well in
analog, where you don't have to worry a lot about aliasing. If phase and levels
are well-matched, each half of the Square wave will offset the two cycles of the
2X freq Sawtooth to 'connect the dots' between the two cycles. Each two cycles
of the 2X freq Sawtooth are 'connected together' by the square wave offset, to
draw one cycle of the derived 1X freq Sawtooth.

Anti-aliasing strategies in digital synthesis could mess up the phase
relationship between the Square and derived Triangle, so it might be difficult
to guarantee that the derived waves 'line up' in a sufficiently anti-aliased
digital oscillator, to get a 1X Sawtooth by adding the 2X Sawtooth with the
original Square wave. Dunno, never tried to write a digital synth.

=====

The problem with deriving a Triangle wave from a master Square wave via a leaky
integrator, is that as frequency of the driving Square wave increases, the
amplitude of the derived Triangle wave will diminish. So the derived Triangle
would at least need some kind of frequency-dependent gain adjustment if you
require the Square wave to have a wide frequency range, and you also require a
constant amplitude from the derived Triangle wave.

That is why in many analog synths, the Sawtooth was the first primary wave
generated by the oscillator. The current drive to the oscillator controls the
slope of the Sawtooth, and an amplitude comparator rapidly resets the Sawtooth
to zero when the Sawtooth hits a threshold. That way, the output level of the
Sawtooth stays constant over a wide frequency range, and a higher input current
drive makes a higher frequency output. With amplitude clamped by the comparator,
higher slope == higher frequency.

Once you have the Sawtooth from the primary oscillator stage (in analog), you
can derive the Square (or a variable-width Pulse) by driving the Sawtooth into a
comparator that toggles high above a threshold on the Sawtooth, and then toggles
low below the threshold.

Given a Sawtooth and a Square wave, you can use various tricks to get a
constant-amplitude Triangle wave. For instance, invert the gain of the Sawtooth
depending on the state of the Square wave. Then the easiest way to get a 'fairly
clean' constant-amplitude sine wave, is to drive the Triangle wave into a
multi-stage waveshaper (perhaps using diodes for soft-clippinig).

JCJR

Hmm, just re-read your question, and you didn't require that the Sawtooth be
derived from the Triangle.

If you don't care about aliasing, just add to an acumulator on every sample to
generate the Sawtooth, and reset the accumulator on each positive-to-negative
transition of the Square wave. Simpler than a leaky integrator. But this derived
Sawtooth would also dimish in amplitude as frequency increases, just as with the
leaky-integrator derived Triangle.

Maybe it would work to generate all your waves the simple 'analog way' starting
from a Sawtooth (modulate frequency by changing the accumulator increment, and
reset when Sawtooth amplitude reaches 1.0 or whatever). Derive all the waves as
simple as possible ala analog, but generate them oversampled, and then hope to
quash aliasing when you downsample? But that might be computationally expensive
because each wave would need its own dedicated downsampler, and good
downsamplers can use a fair amount of CPU. The multiple downsamplers could
easily squander more CPU than you save by simple oscillator code. Dunno, never
tried it in digital. Its easy in Analog.

----- Original Message -----
From: "kernel" <***@troniczoo.net>
To: "music DSP music-related DSP" <music-***@music.columbia.edu>
Sent: Monday, August 21, 2006 5:06 PM
Subject: [music-dsp] different waveforms from a single

oscillator. legend has it that a triangle wave can be derived by sending a
square wave thorugh a leaky integrator. this legend is true. i can get a
sinewave by waveshaping the triangle so that's 3 waveforms. anyone know if
sawtooth waves can be achieved somehow from a square/pulse wave oscillator?
pulse > (leaky integrator) > triangle > (waveshaper) > sine
thanks, kernel.
--
dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ,
source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

[David Lowenfels]

Like JCJR said, make the sawtooth first.
A well-known method to get a square/pulse wave from a sawtooth is by
a comb filter (delay and subtract). Changing the delay will change
the pulse width.
Basically, this removes the even harmonics.
Control the gain of the delayed copy and you get waveform morphing.
Modulate the parameters and more fun stuff happens.
I wrote an AES paper on this..

Virtual Analog Synthesis with a Time-Varying Comb Filter

The bandlimited digital synthesis model of Stilson and Smith is
extended with a single feed-forward comb filter. Time-varying comb
filter techniques are shown to produce a variety of classic analog
waveform effects, including waveform morphing, pulse-width
modulation, harmonization, and frequency modulation. The techniques
discussed are not guaranteed to maintain perfect bandlimiting;
however, they are generally applicable to other synthesis models.

Preprint Number: 5960 Convention: 115 (September 2003)

Post by kernel
oscillator. legend has it that a triangle wave can be derived by
sending a square wave thorugh a leaky integrator. this legend is
true. i can get a sinewave by waveshaping the triangle so that's 3
waveforms. anyone know if sawtooth waves can be achieved somehow
from a square/pulse wave oscillator?
pulse > (leaky integrator) > triangle > (waveshaper) > sine
thanks, kernel.

[Didier Dambrin]

Post by kernel
oscillator. legend has it that a triangle wave can be derived by
sending a square wave thorugh a leaky integrator. this legend is true. i
can get a sinewave by waveshaping the triangle so that's 3

waveshaping a band-limited triangle?

Or is it for an LFO? I've done an LFO go from triangle to sine-alike &
square aline by just waveshaping a triangle, it looks easier. Also from the
triangle you can do saws easily. But that's for LFO's..

Post by kernel
waveforms. anyone know if sawtooth waves can be achieved somehow from a
square/pulse wave oscillator?
pulse > (leaky integrator) > triangle > (waveshaper) > sine
thanks, kernel.
--
dupswapdrop -- the music-dsp mailing list and website: subscription info,
FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.1/421 - Release Date: 16/08/2006

[kernel]

Post by Didier Dambrin

Post by kernel
oscillator. legend has it that a triangle wave can be derived by
sending a square wave thorugh a leaky integrator. this legend is
true. i can get a sinewave by waveshaping the triangle so that's 3

waveshaping a band-limited triangle?

ahh, I've been waveshaping non bandlimited triangles. why would that
matter tho? think i'd better read up on band limiting techniques.

Post by Didier Dambrin
Or is it for an LFO? I've done an LFO go from triangle to sine-alike &
square aline by just waveshaping a triangle, it looks easier. Also
from the triangle you can do saws easily. But that's for LFO's..

I've used it lots for low frequency stuff not necessarily LFOs but low
pitched sounds. I'm after something I can use for both regular
oscillators and LFOs which provides a wide range of traditional
(tri/pulse etc) as well as more unusual waveforms.

thanks to you and JCJR for the tips...

kernel

[David Lowenfels]

My personal favorite for oscillator coolness is Yamaha-flavored
feedback FM (actually phase modulation):

Take a phasor (naive sawtooth aka wrapped accumulator) and feed it
into a sine lookup table (linear interpolation is fine). Feed back
the output with a gain control, and sum it back with the phasor
before table lookup.

(industry practice is to put a 2-point running average in the
feedback chain to control wild self-oscillation at nyquist... the
yammy patent calls it a "hunting filter" ??! )

No feedback yields a regular sinewave.
The feedback gain controls the harmonic rolloff slope, kind of like a
lowpass filter.
Increasing feedback gain approximates a quasi-bandlimited sawtooth-
like wave.
If you square (and invert?) the feedback you get a quasi-bandlimited
square-like wave.

You can approximate a triangle wave by using the a low feedback gain
on the square wave. Or just integrate (not sure if it needs to be
leaky as there should be no DC in the original waveform?)
Use comb filter tricks on the sawtooth to get PWM, etc.

-David

Post by kernel
I've used it lots for low frequency stuff not necessarily LFOs but
low pitched sounds. I'm after something I can use for both regular
oscillators and LFOs which provides a wide range of traditional
(tri/pulse etc) as well as more unusual waveforms.

[Urs Heckmann]

Hi all,

I'm a bit late here, but there's something that bothered me for a while.

Post by kernel
pulse > (leaky integrator) > triangle > (waveshaper) > sine

I think that the best way to create a sine from a triangle is
waveshaping a triangle that is *not* bandlimited. This may sound
weird at first, but here is why:

The waveshaper can be seen as one of those quick and dirty methods to
calculate sin() from 0 to pi/2, i.e. a Taylor series, thus I'll call
it sineApprox( x ) for now. The triangle would be scaled to an
amplitude of -pi/2 to + pi/2, so that we get:

y( x ) = sign( triangle( x ) ) * sineApprox( abs( triangle( x ) * pi/
2 ) )
-> quite perfect sine

If the triangle was bandlimitted, one would get anything but a sine
out of it, which can easily be shown by the case when the fundamental
frequency came close to Nyquist and thus the triangle itself became a
sine:

y( x ) = sign( sin( x ) ) * sineApprox( abs( sin( x ) * pi/2 ) )
-> equals sin( sin( x ) * pi/2 ), no good, aliasing inclusive

It's not all that bad because the amplitude of a bandlimitted
triangle decreases a bit while higher partials are taken away. Thus
for high frequencies the sine-waveshaper is mostly applied on the
more or less linear part of the sine. This might let the principle
sound right, but the results of a non-bandlimitted triangle will
still sound better.

A similar case here is, a phase accumulator for a wavetable readout
equals a non-bandlimitted sawtooth, while the waveform generated from
the wavetable can still be perfectly bandlimitted.

Sorry if this was obvious, I had just missed that aspect in the
thread...

Cheers,

;) Urs


urs heckmann
***@u-he.com
www.u-he.com

[a***@smartelectronix.com]

Post by kernel
pulse > (leaky integrator) > triangle > (waveshaper) > sine

I think that the best way to create a sine from a triangle is waveshaping a
triangle that is *not* bandlimited. This may sound weird at first, but here

This can be considered a form of phase modulation with the triangle or
sawtooth acting as carrier and the sine as modulator with f = 0.
Any ripples in the carrier will cause FM artifacts. Any DC offset (for
triangle) or scale error will warp the sine wave.

I can't see why anyone would want to make a sine out of triangle or
sawtooth digitally though - much easier to just calculate the sine
directly based on the oscillator phase. Sine was derived from triangle in
analog synths because sine oscillators are quite hard to do and you also
want the waveforms to be in phase. Waveshaping a triangle was a relatively
easy way to get not too horrible sine.

Antti

[David Olofson]

On Wednesday 30 August 2006 16:27, ***@smartelectronix.com wrote:
[...]

Post by a***@smartelectronix.com
I can't see why anyone would want to make a sine out of triangle or
sawtooth digitally though - much easier to just calculate the sine
directly based on the oscillator phase.

[...]

Well... Speed? If you can actually implement one that runs faster than
a wavetable oscillator of comparable, that is. For an LFO, it may be
more important to avoid problems near Nyqvist, but for audible
frequencies, it may be more important to get a pure sine - provided
you can't afford generating a pure sine with minimal distortion, of
course.

Below is one simple and not very optimized LFO variant I'm using in an
FM synth. (DSSI plugin with SDL based GUI; not yet released.) It's
not good enough for audible frequencies IMHO, as the undesired
harmonics are clearly audible, but when used as an LFO, one has to do
some rather extreme modulation to tell the difference from a true
sine LFO.

-------------------------------------------------------------
static void lfo_process_adding(FM_LFOParams *p, FM_LFO *l,
float *out, int frames)
{
int s = 0;
float ph = l->phase;
float a = l->a;
while(s < frames)
{
ph += p->phaseinc;
if(ph > 1.0f)
ph -= 2.0f;
a += (l->ta - a) * l->fade;
out[s++] += (ph * ph - 1.0f) * ph * 2.59f * a;
}
l->phase = ph;
l->a = a;
}
-------------------------------------------------------------


//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'

[a***@smartelectronix.com]

Post by David Olofson
Well... Speed? If you can actually implement one that runs faster than
a wavetable oscillator of comparable, that is. For an LFO, it may be

Lookup table is merely one way to calculate sine. You could also use
polynomial approx etc. Implementation details.
The important thing is that you have access to the phase, so you can use
that directly and not rely on tricky waveshaping.

Antti

[David Olofson]

Post by a***@smartelectronix.com

Post by David Olofson
Well... Speed? If you can actually implement one that runs faster
than a wavetable oscillator of comparable, that is. For an LFO, it
may be

Lookup table is merely one way to calculate sine. You could also use
polynomial approx etc. Implementation details.
The important thing is that you have access to the phase, so you can
use that directly and not rely on tricky waveshaping.

Yeah... I just realized that that's actually what I'm doing. It's just
a matter of whether you want to think of the [-1, 1] 'ph' variable as
a phase accumulator, or as a sawtooth output. ;-)


//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'

[a***@smartelectronix.com]

Post by David Olofson
Yeah... I just realized that that's actually what I'm doing. It's just
a matter of whether you want to think of the [-1, 1] 'ph' variable as
a phase accumulator, or as a sawtooth output. ;-)

You can even use 5th order polynomial to shape abs(phase)
(-1 <= phase < 1) to get pretty decent sinewave. Again the important part
is direct access to phase so that there's no source of error.

Antti

[Didier Dambrin]

There are several algo's to generate sinewaves with a couple of muls & adds.
Still, while surely faster than waveshaping a triangle, they're slower than
a wavetable-based one, so it only matters if you can't afford the memory.

I too can't imagine waveshaping a triangle as a usable way to produce a
sinewave.

For LFO's I too waveshape a triangle, for the simple reason that the user
can smoothly morph from triangle to a square-like, passing by a sine-like,
by just tweaking a knob.

Post by David Olofson
[...]

Post by a***@smartelectronix.com
I can't see why anyone would want to make a sine out of triangle or
sawtooth digitally though - much easier to just calculate the sine
directly based on the oscillator phase.

[...]
Well... Speed? If you can actually implement one that runs faster than
a wavetable oscillator of comparable, that is. For an LFO, it may be
more important to avoid problems near Nyqvist, but for audible
frequencies, it may be more important to get a pure sine - provided
you can't afford generating a pure sine with minimal distortion, of
course.
Below is one simple and not very optimized LFO variant I'm using in an
FM synth. (DSSI plugin with SDL based GUI; not yet released.) It's
not good enough for audible frequencies IMHO, as the undesired
harmonics are clearly audible, but when used as an LFO, one has to do
some rather extreme modulation to tell the difference from a true
sine LFO.
-------------------------------------------------------------
static void lfo_process_adding(FM_LFOParams *p, FM_LFO *l,
float *out, int frames)
{
int s = 0;
float ph = l->phase;
float a = l->a;
while(s < frames)
{
ph += p->phaseinc;
if(ph > 1.0f)
ph -= 2.0f;
a += (l->ta - a) * l->fade;
out[s++] += (ph * ph - 1.0f) * ph * 2.59f * a;
}
l->phase = ph;
l->a = a;

you should try an integer (auto-wrapping) phase, because testing a float
isn't the best idea as for speed.

Post by David Olofson
}
-------------------------------------------------------------
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
--
subscription info, FAQ, source code archive, list archive, book reviews,
dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.7/433 - Release Date: 30/08/2006

[David Olofson]

On Wednesday 30 August 2006 18:00, Didier Dambrin wrote:
[...]

Post by Didier Dambrin
For LFO's I too waveshape a triangle, for the simple reason that the
user can smoothly morph from triangle to a square-like, passing by a
sine-like, by just tweaking a knob.

Yeah, that's a nice bonus. (One that I'm not making available in that
synth, BTW... Yet!)


[...]

Post by Didier Dambrin
you should try an integer (auto-wrapping) phase, because testing a
float isn't the best idea as for speed.

Yeah, I know, but then I run into this int<->float cast deal, and I
want this code portable, so I decided not to go there until it's
really time to start optimizing...

Anyway, as we're dealing with low frequencies, one option is to remove
the wrap test from the inner loop and handle the wrapping in an outer
loop instead. That method is also very handy when dealing with
arbitrary loop lengths, attack-loop-release looping and that sort of
stuff in sampleplayers.


//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'

[Paul Sernine]

Here is an implementation of this algo :
http://www.musicdsp.org/archive.php?classid=4#221
it is quite nice.

regards

Reply-To: A discussion list for music-related DSP
Subject: Re: [music-dsp] different waveforms from a single
Date: Tue, 22 Aug 2006 11:48:14 -0700
My personal favorite for oscillator coolness is Yamaha-flavored feedback
Take a phasor (naive sawtooth aka wrapped accumulator) and feed it into a
sine lookup table (linear interpolation is fine). Feed back the output
with a gain control, and sum it back with the phasor before table lookup.
(industry practice is to put a 2-point running average in the feedback
chain to control wild self-oscillation at nyquist... the yammy patent
calls it a "hunting filter" ??! )
No feedback yields a regular sinewave.
The feedback gain controls the harmonic rolloff slope, kind of like a
lowpass filter.
Increasing feedback gain approximates a quasi-bandlimited sawtooth- like
wave.
If you square (and invert?) the feedback you get a quasi-bandlimited
square-like wave.
You can approximate a triangle wave by using the a low feedback gain on
the square wave. Or just integrate (not sure if it needs to be leaky as
there should be no DC in the original waveform?)
Use comb filter tricks on the sawtooth to get PWM, etc.
-David

I've used it lots for low frequency stuff not necessarily LFOs but low
pitched sounds. I'm after something I can use for both regular
oscillators and LFOs which provides a wide range of traditional
(tri/pulse etc) as well as more unusual waveforms.

--
dupswapdrop -- the music-dsp mailing list and website: subscription info,
FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

_________________________________________________________________
Ten : profite de ton Messenger en illimité sur ton mobile !
http://mobile.live.fr/messenger/ten/

[James Chandler Jr]

Here is a dumb question about calculating error of a measured value against an
expected value. Shoulda paid more attention in math classes.

The context of this question is in comparing detected audio beat timing against
'ideal' timing, but obviously there are many situations where one might want to
calculate an 'unbiased' error measurement.

Have used with some success a simple formula (where MeasuredValue and
ExpectedValue are always positive):

ErrorVal = abs(MeasuredValue - ExpectedValue) / ExpectedValue;

If MeasuredValue == 0, ErrorVal == 1

If MeasuredValue == ExpectedValue, ErrorVal == 0.

If MeasuredValue is larger than ExpectedValue, ErrorVal grows arbitrarily big.

So it does tend toward zero when MeasuredValue gets close to ExpectedValue.

However, it does not seem perfect to compare average ErrorVal's computed with
different ExpectedValues. Perhaps I'm explaining it poorly, but it seems that as
ExpectedValue increases, the calculated average ErrorVal's tend to be smaller,
not directly comparable against each other.

For simple example, if I scan a bunch of beat delta times against an
ExpectedValue of a quarter-note, at various probe BPM tempos, only summing the
errors of 'close matches'--

For instance if the actual tempo of the measured music delta times is 'supposed
to be' 100 (with human inaccurate jitter of course), and I'm probing around that
tempo to find the least cumulative error, using the above simple method of
computing error--

If some tempo slower than 100 should have the same approximate error as some
tempo faster than 100, the above simple error calculation will tend to return a
slightly lower average error for the slower tempo (larger expected delta times),
biasing the results toward lower tempo choices.

Is there a simple way to un-bias this simple error calculation, so if a probe
tempo of 99.8 would be expected to have about the same error as a probe tempo of
100.2 or whatever, that the cumulative error figures of these two calculations
would be in exactly the same ballpark for comparison?

Or could a better error formula be suggested?

I'm currently just summing errors of matched deltas and dividing by N matches,
for a simple average error at each probe tempo, so it would be nice if different
probe tempo average errors were directly comparable.

I realize that accurate tempo extraction is considered a thorny problem, and
have read a lot of academic papers on the topic. Many of the papers use pretty
fancy math and still report imperfect results.

So this question isn't about the intricate details of tempo extraction, only
about the best way to make average error calculations against different expected
values, which are directly comparable, so that the minimum calculated average
error is the TRUE minimum error.

Thanks for any ideas.

JCJR

[Martin Eisenberg]

Post by James Chandler Jr
The context of this question is in comparing detected audio
beat timing against 'ideal' timing, but obviously there are
many situations where one might want to calculate an
'unbiased' error measurement.
Have used with some success a simple formula (where
ErrorVal = abs(MeasuredValue - ExpectedValue)
/ ExpectedValue;
However, it does not seem perfect to compare average ErrorVal's
computed with different ExpectedValues. Perhaps I'm explaining
it poorly, but it seems that as ExpectedValue increases, the
calculated average ErrorVal's tend to be smaller, not directly
comparable against each other.

You ought to have stated the units of those values.

[Andreas Ehmann]

Just to throw out a link for you, there is an audio beat tracking evaluation
'competition' for this year's MIREX (Music Information Retrieval Evaluation
eXchange). Their proposed evaluation metric is presented up on the wiki.
http://www.music-ir.org/mirex2006/index.php/Audio_Beat_Tracking .

Post by James Chandler Jr
I'm currently just summing errors of matched deltas and dividing by N
matches, for a simple average error at each probe tempo, so it would be
nice if different probe tempo average errors were directly comparable.

Why can't you? And how do you define match?

One possible way to maybe address this accross different probes, is to set a
window around each probe event (e.g. 1/5 of the probe tempo as above). If
the algorithm returns a value within this window, you flag a match, and
calculate the time deviation between the probe and the algorithm output for
this match. Count all matches into a number M. If your algorithm returns
nothing within a window of a probe point, you mark a 'False Negative'. The
count of all false negatives can be denoted FN. If your algorithm returns a
value where there is no probe point you can tally a 'False Positive'. The
count of all false positives can be denoted FP. You can then calculate
Precision as P = M/(M+FP) and Recall as R = M/(M+FN). An F1-Measure can then
be calculated as 2*P*R/(P+R).

Basically, the F-Measure will tell how well your algorithm's beat tracking
output has a match to the probe (with a slight window around each probe
event). Calculating the abs time difference around each matched event, and
dividing by M, will give an average time deviation.

So basically the F-Measure would adress a sort of pathological case in which
your algorithm is operating on a 100 BPM song, and returns as such. A 100
bpm probe, should have a very high F-Measure. A 200 bpm probe will have beat
events at all the places they should be, but also at locations halfway
between each true beat event. This will result in a lot of FalseNegatives,
and therefore a lower F-Measure. In both cases you would get a similar time
deviation of the matched events, but the F Measure is saying that the 100 is
probably a better match. This is pretty much the approach in MIREX's audio
onset detection tasks, which although different, does have some
similarities:
http://www.music-ir.org/mirex2005/index.php/Audio_Onset_Detection

Well anyhow, I'm just throwing out ideas, hope I was some help.

Andreas Ehmann

[Michael Gogins]

According to my tests, the Goetzel recurrence is a somewhat faster means of calculating a sine or cosine in C++ than an interpolating wavetable oscillator. I did not test a non-interpolating wavetable.

Regards,
Mike

-----Original Message-----

Sent: Aug 30, 2006 12:00 PM
Subject: Re: [music-dsp] different waveforms from a single
There are several algo's to generate sinewaves with a couple of muls & adds.
Still, while surely faster than waveshaping a triangle, they're slower than
a wavetable-based one, so it only matters if you can't afford the memory.
I too can't imagine waveshaping a triangle as a usable way to produce a
sinewave.
For LFO's I too waveshape a triangle, for the simple reason that the user
can smoothly morph from triangle to a square-like, passing by a sine-like,
by just tweaking a knob.

Post by David Olofson
[...]

Post by a***@smartelectronix.com
I can't see why anyone would want to make a sine out of triangle or
sawtooth digitally though - much easier to just calculate the sine
directly based on the oscillator phase.

[...]
Well... Speed? If you can actually implement one that runs faster than
a wavetable oscillator of comparable, that is. For an LFO, it may be
more important to avoid problems near Nyqvist, but for audible
frequencies, it may be more important to get a pure sine - provided
you can't afford generating a pure sine with minimal distortion, of
course.
Below is one simple and not very optimized LFO variant I'm using in an
FM synth. (DSSI plugin with SDL based GUI; not yet released.) It's
not good enough for audible frequencies IMHO, as the undesired
harmonics are clearly audible, but when used as an LFO, one has to do
some rather extreme modulation to tell the difference from a true
sine LFO.
-------------------------------------------------------------
static void lfo_process_adding(FM_LFOParams *p, FM_LFO *l,
float *out, int frames)
{
int s = 0;
float ph = l->phase;
float a = l->a;
while(s < frames)
{
ph += p->phaseinc;
if(ph > 1.0f)
ph -= 2.0f;
a += (l->ta - a) * l->fade;
out[s++] += (ph * ph - 1.0f) * ph * 2.59f * a;
}
l->phase = ph;
l->a = a;

you should try an integer (auto-wrapping) phase, because testing a float
isn't the best idea as for speed.

Post by David Olofson
}
-------------------------------------------------------------
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
--
subscription info, FAQ, source code archive, list archive, book reviews,
dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.7/433 - Release Date: 30/08/2006

--
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

[Didier Dambrin]

through my tests, that algo appeared to be faster than a non-interpolated
table (but it was a big one, so maybe there were cache problems), in SSE
packed single processing. But the error was accumulating too quickly, so it
had to be turned to packed double, and then the table was slightly faster.
Both being in full asm btw.

Post by Michael Gogins
According to my tests, the Goetzel recurrence is a somewhat faster means
of calculating a sine or cosine in C++ than an interpolating wavetable
oscillator. I did not test a non-interpolating wavetable.
Regards,
Mike
-----Original Message-----

Sent: Aug 30, 2006 12:00 PM
Subject: Re: [music-dsp] different waveforms from a single
There are several algo's to generate sinewaves with a couple of muls & adds.
Still, while surely faster than waveshaping a triangle, they're slower than
a wavetable-based one, so it only matters if you can't afford the memory.
I too can't imagine waveshaping a triangle as a usable way to produce a
sinewave.
For LFO's I too waveshape a triangle, for the simple reason that the user
can smoothly morph from triangle to a square-like, passing by a sine-like,
by just tweaking a knob.

Post by David Olofson
[...]

Post by a***@smartelectronix.com
I can't see why anyone would want to make a sine out of triangle or
sawtooth digitally though - much easier to just calculate the sine
directly based on the oscillator phase.

[...]
Well... Speed? If you can actually implement one that runs faster than
a wavetable oscillator of comparable, that is. For an LFO, it may be
more important to avoid problems near Nyqvist, but for audible
frequencies, it may be more important to get a pure sine - provided
you can't afford generating a pure sine with minimal distortion, of
course.
Below is one simple and not very optimized LFO variant I'm using in an
FM synth. (DSSI plugin with SDL based GUI; not yet released.) It's
not good enough for audible frequencies IMHO, as the undesired
harmonics are clearly audible, but when used as an LFO, one has to do
some rather extreme modulation to tell the difference from a true
sine LFO.
-------------------------------------------------------------
static void lfo_process_adding(FM_LFOParams *p, FM_LFO *l,
float *out, int frames)
{
int s = 0;
float ph = l->phase;
float a = l->a;
while(s < frames)
{
ph += p->phaseinc;
if(ph > 1.0f)
ph -= 2.0f;
a += (l->ta - a) * l->fade;
out[s++] += (ph * ph - 1.0f) * ph * 2.59f * a;
}
l->phase = ph;
l->a = a;

you should try an integer (auto-wrapping) phase, because testing a float
isn't the best idea as for speed.

Post by David Olofson
}
-------------------------------------------------------------
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
--
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.7/433 - Release Date: 30/08/2006

--
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

--
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.7/433 - Release Date: 30/08/2006

[Stephen Sinclair]

Post by Didier Dambrin
There are several algo's to generate sinewaves with a couple of muls & adds.
Still, while surely faster than waveshaping a triangle, they're slower than
a wavetable-based one, so it only matters if you can't afford the memory.

Isn't it also a problem in using a recurrence relation that due to
limitions with precision, you can have small errors slowly creep up
over time and compound into some kind of distortion? (Because each new
value is based on previous values, which themselves may have had
errors..) How much is this a problem in a real implementation?

Steve

[Didier Dambrin]

Post by Stephen Sinclair

Post by Didier Dambrin
There are several algo's to generate sinewaves with a couple of muls & adds.
Still, while surely faster than waveshaping a triangle, they're slower than
a wavetable-based one, so it only matters if you can't afford the memory.

Isn't it also a problem in using a recurrence relation that due to
limitions with precision, you can have small errors slowly creep up
over time and compound into some kind of distortion? (Because each new
value is based on previous values, which themselves may have had
errors..) How much is this a problem in a real implementation?

as I wrote, with single floats the error accumulates too noticably. But with
double (at least for sines in the audible range at 44khz), it was near
perfect, you could run a sine for an unrealistic time until you get a
noticable error. At least this is what I tested.
I don't remember if the error was in the phase and/or level, though.

[Andrew Simper]

The only reason I can see to waveshape a triangle to get a sin is to model
an old analog synth. I've only really checked out the schematic of the arp
2600 so in what follows I'll be talking about that. The triangle is derived
from the saw output (0V to 10V) which uses an npn and pnp transistor to
shape the saw into a triangle (5V to 10V), which then goes through an opamp
to boost it back up again (-5V to 5V). Because of various manufacturing
constants and the drain of the two transistors the edge of the saw is
slightly apparent at one end of the tri and looks like a sync jump (well
that's what my simulation says, I don't have a real arp). There is an
asymmetry pot to minimise this. The tri output is then fed into a jfet pair
which rounds the ends off using a second order non-linearity. If there was a
way to shape a saw directly into a sin in analog I'm sure people would have
used it.

Andy


-----Original Message-----
From: Urs Heckmann [mailto:***@u-he.com]
Sent: 30 August 2006 09:47
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] different waveforms from a single

Hi all,

I'm a bit late here, but there's something that bothered me for a while.

Post by kernel
pulse > (leaky integrator) > triangle > (waveshaper) > sine

I think that the best way to create a sine from a triangle is waveshaping a
triangle that is *not* bandlimited. This may sound weird at first, but here
is why:

The waveshaper can be seen as one of those quick and dirty methods to
calculate sin() from 0 to pi/2, i.e. a Taylor series, thus I'll call it
sineApprox( x ) for now. The triangle would be scaled to an amplitude of
-pi/2 to + pi/2, so that we get:

y( x ) = sign( triangle( x ) ) * sineApprox( abs( triangle( x ) * pi/
2 ) )
-> quite perfect sine

If the triangle was bandlimitted, one would get anything but a sine
out of it, which can easily be shown by the case when the fundamental
frequency came close to Nyquist and thus the triangle itself became a
sine:

y( x ) = sign( sin( x ) ) * sineApprox( abs( sin( x ) * pi/2 ) )
-> equals sin( sin( x ) * pi/2 ), no good, aliasing inclusive

It's not all that bad because the amplitude of a bandlimitted
triangle decreases a bit while higher partials are taken away. Thus
for high frequencies the sine-waveshaper is mostly applied on the
more or less linear part of the sine. This might let the principle
sound right, but the results of a non-bandlimitted triangle will
still sound better.

A similar case here is, a phase accumulator for a wavetable readout
equals a non-bandlimitted sawtooth, while the waveform generated from
the wavetable can still be perfectly bandlimitted.

Sorry if this was obvious, I had just missed that aspect in the
thread...

Cheers,

;) Urs


urs heckmann
***@u-he.com
www.u-he.com

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

[robert bristow-johnson]

Post by James Chandler Jr
----- Original Message -----
Subject: Re: [music-dsp] different waveforms from a single
Date: Wed, 30 Aug 2006 18:00:17 +0200
There are several algo's to generate sinewaves with a couple of muls & adds.

i can think of 2 off-hand. one essentially is a two-pole filter with the (conjugate) poles right on the unit circle. the other generates both a sine and cosine waveform and is useful for making a frequency shifter with a Hilbert transformer.

Post by James Chandler Jr
Still, while surely faster than waveshaping a triangle, they're slower than a
wavetable-based one, so it only matters if you can't afford the memory.

can't agree with that. you can generate the two-pole filter sinusoid with



y[n] = 2*cos(omega0)*y[n-1] - y[n-2]


Y(z) = 2*cos(omega0)*z^(-1)*Y(z) - z^(-2)*Y(z)

Y(z)*(z^2 - 2*cos(omega0)*z + 1) = 0

(z - e^(omega0))*(z - e^(-omega0)) = 0


omega0 is the frequency (radians/sample) and the phase and amplitude are determined by the initial conditions y[-1] and y[-2] (assuming y[0] is the first sample you are computing). one multiply and one subtract. compare that with the address arithmetic you need to do the phase accumulator and wavetable, and that doesn't include any interpolation between points.

i used to think that, for numerical reasons, this could not be stable and sustain forever (because of my experience with the other quadrature method) but James SuperCollider McCartney disabused me of that misconception.

Post by James Chandler Jr
I too can't imagine waveshaping a triangle as a usable way to produce a
sinewave.

i can. probably not the best way to do it with a DSP, but it's what the old analog VCOs did.

Post by James Chandler Jr
For LFO's I too waveshape a triangle, for the simple reason that the user can
smoothly morph from triangle to a square-like, passing by a sine-like, by
just tweaking a knob.

well someone might want to do that with audio. still might not be the best way to do it.

--

r b-j ***@audioimagination.com

"Imagination is more important than knowledge."

[Didier Dambrin]

Post by robert bristow-johnson
omega0 is the frequency (radians/sample) and the phase and amplitude are
determined by the initial conditions y[-1] and y[-2] (assuming y[0] is the
first sample you are computing). one multiply and one subtract. compare
that with the address arithmetic you need to do the phase accumulator and
wavetable, and that doesn't include any interpolation between points.
i used to think that, for numerical reasons, this could not be stable and
sustain forever (because of my experience with the other quadrature
method) but James SuperCollider McCartney disabused me of that
misconception.

Let me dig back my tests. It was for an additive synth, so it's not just
generating the sine, there's a volume & ramping, I don't much remember.
I think it was just 2 MOVAPD, a MULPD, and 2 ADDPD (one for the ramping).

Sounds very little, no? However, the (non-interpolated, but big) table
version was slightly faster. The single version was slightly faster than the
table version, though, BUT the error was accumulating too quickly.

Now: I have an AMD. It may be faster on an intel, I don't know. I'd suspect
it wouldn't be, since it's not really SSE that's faster on Intel's, but the
FPU that's slower (so that comparatively, SSE is faster than FPU on Intels,
but for wrong reasons). Plus the table version was barely using the FPU,
only for the ramping.


Another problem: with the algo you still have to compute real sines when you
need to change the frequency. Even though you can chunk this, for an
additive synth it raised the CPU usage significantly.

[Martin Eisenberg]

Post by robert bristow-johnson
i used to think that, for numerical reasons, this could not be
stable and sustain forever (because of my experience with the
other quadrature method) but James SuperCollider McCartney
disabused me of that misconception.

So the biquad sine oscillator is guaranteed stable in the
presence of roundoff error? Do you have a reference with details?


Martin