Re: [music-dsp] Time-variant 2nd-order sinusoidal resonator

[Evan Balster]

Hello —

The method Ethan recommends is sometimes known as a Variable Phasor
<https://en.wikipedia.org/wiki/Phasor>, and I'm quite fond of these!  I
like to visualize them as the hand of a clock.  The update function is
effectively a complex product (which works like a rotation) and you can use
a fast inverse square root
<https://en.wikipedia.org/wiki/Fast_inverse_square_root> to control the
magnitude of your  vector.

I've learned to be careful about relying too much on LTI filter methodology
in applications where the parameters need to change — breaking linearity
can undermine the assumptions that make those filter designs work in the
first place, especially with higher-order filters and biquad chains.

If you need a resonator (transforming audio input) rather than an
oscillator (creating a new signal from frequency and amplitude parameters),
there is a way to adapt Ethan's design to work as a filter:

a(t+1) = d * (C*a(t) - S*b(t)) + (1 - d) * x(t)
b(t+1) = d * (S*a(t) + C*b(t))

Where x(t) is an input signal and d is a decay-per-sample factor (0 < d <
1) that affects the resonator's bandwidth.  With this design, you don't
need to adjust the magnitude with a fast inverse square root.  For more
control over the bandwidth and general responsiveness, it's possible to
replace the decay math (which is basically a one-pole filter
<https://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filter>)
with another low-pass filter design of your choice.

– Evan Balster
creator of imitone <http://imitone.com>


On Wed, Feb 20, 2019 at 3:10 PM Ethan Fenn  wrote:

> A very simple oscillator recipe is:
>
> a(t+1) = C*a(t) - S*b(t)
> b(t+1) = S*a(t) + C*b(t)
>
> Where C=cos(w), S=sin(w), w being the angular frequency. a and b are your
> two state variables that are updated every sample clock, either of which
> you can use as your output.
>
> There won't be any phase or amplitude discontinuity when you change C and
> S. However, it's not stable as is, so you periodically have to make an
> adjustment to make sure that a^2 + b^2 = 1.
>
> -Ethan
>
>
> On Wed, Feb 20, 2019 at 12:26 PM Ian Esten  wrote:
>
>> The problem you are experiencing is caused by the fact that after
>> changing the filter coefficients, the state of the filter produces
>> something different to the current output. There are several ways to solve
>> the problem:
>> - The time varying bilinear transform:
>> http://www.aes.org/e-lib/browse.cfm?elib=18490
>> - Every time you modify the filter coefficients, modify the state of the
>> filter so that it will produce the output you are expecting. Easy to do.
>>
>> I will also add that some filter structures are less prone to problems
>> like this. I used a lattice filter structure to allow audio rate modulation
>> of a biquad without any amplitude problems. I have no idea how it would
>> work for using the filter as an oscillator.
>>
>> Best,
>> Ian
>>
>> On Wed, Feb 20, 2019 at 9:07 AM Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> wrote:
>>
>>> Hello, list.
>>>
>>> I'm currently working with digital resonators for sinusoidal oscillators
>>> and I was wondering if you have worked with some design which allows for
>>> frequency variations without discontinuities in phase or amplitude.
>>>
>>> Thank you so much for your help.
>>>
>>> Dario
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Sound Analysis

[Evan Balster]

Hello, Frank —

I tentatively ask what the "value under the curve would be" up to this
> zero-crossing.  If the value is close enough to zero, then I treat the
> difference between this interpolated crossing and the first as a candidate
> wavelength.
>

If you're doing this, you certainly want to do some kind of high-pass
filter to remove low frequencies from your signal.  Over a sufficiently
short interval of time, low tones look like DC and they'll offset your
integral.

I would caution you against setting your ambitions too high with a design
based on zero-crossings.  That technique might work well enough within
certain parameters (high SNR, low harmonic brightness) but you'll quickly
run into a need for more sophistication if you are attempting to implement
a more general-purpose pitch analyzer.  (Alternative techniques worthy of
note include autocorrelation, cepstrums and adaptive filters.)

However when run on the Hammond recording, it's detecting a wavelength of
> perhaps 0.7 cent off.  And this probably accounts for an entire wall of
> ghost frequencies to be detected as well.
>

Any noise in your signal can potentially offset the signal near your
zero-crossing, pushing that crossing forward or backward in time.  This
problem worsens with the level of noise in the signal, especially if the
tone is dark.  Suppressing the noise requires an estimate of the pitch,
creating something of a chicken-and-egg problem — but you can refine an
estimate over time.

– Evan Balster
creator of imitone <http://imitone.com>


On Tue, Jan 1, 2019 at 6:48 PM Frank Sheeran  wrote:

> Summary
>
> I'm having trouble identifying exact frequencies in what should be an
> extremely easy-to-process WAV file, as  a first step to doing a harmonic
> analysis with a Fourier transform.
>
>
>
> Details of Project
>
> I have a file which contains a second's worth of sound of each of the 91
> tonewheels of  a Hammond B-3 organ in order.  (Hammonds have spinning disks
> whose edge is fluted in a shape of a desired output sound wave.  This spins
> in front of a mechanical pickup, which converts that undulating edge into
> an electronic signal.)
>
> I want to do a harmonic analysis of each disk in turn.
>
> Given the volume of example sounds, I'm hoping for the utility program
> doing this analysis to be as automated as possible.  I see the first
> project as a first step towards a utility that will let me conveniently
> analyze other sounds as well going forward, such as guitar notes.
>
>
>
> Current Status
>
> I'm properly detecting the notes' start and end, with a heuristic of
> looking for a running string of individual samples less than some
> threshold.  By experimentation, length and threshold values that work were
> obtained.
>
> Since the Hammond sounds don't change from beginning to end, except for
> some instability at the start and finish, I'm taking the middle 80% of each
> detected note.
>
> I'm currently then scanning that range for an upwards zero-crossing.  I
> linear-interpolate that starting value, so that if say sample 100 is -.04
> and 100 is +.01, I assume the waveform starts at 100.8.
>
> I then keep a running "value under the curve", manually
> piecewise-integrating the waveform, as I scan forward for more upwards
> zero-crossings.
>
> For each subsequent upwards zero-crossing, I again linear-interpolate a
> fractional sample value.  This is possibly the end of the waveform.  I
> tentatively ask what the "value under the curve would be" up to this
> zero-crossing.  If the value is close enough to zero, then I treat the
> difference between this interpolated crossing and the first as a candidate
> wavelength.
>
> When run on test tones I compose of sine waves at various harmonics, the
> method succeed to 5-6 decimal places.  The resulting harmonic analysis
> gives the proper strengths of the Harmonics I put in, and detects the other
> harmonics at values of -90dB or so.  When allowed to continue on and detect
> a candidate wavelength in fact twice the actual, the noise floor drops to
> -195dB.  Three wavelengths
>
> However when run on the Hammond recording, it's detecting a wavelength of
> perhaps 0.7 cent off.  And this probably accounts for an entire wall of
> ghost frequencies to be detected as well.
>
> SO Am I going about this totally wrong?  Is there a different and
> better approach to use?  Or do I just need to keep tweaking, such as adding
> a DC filter, an 60Hz AC hum filter (I see some in an FFT at maybe -95dB),
> additionally using a low-pass filter before the pitch-detection stage but
> don't use once I've detected a wavelength, and so on?  One idea I have is
> that I should use the detected wavelength to select the closest know

Re: [music-dsp] WSOLA on RealTime

[Evan Balster]

A simpler answer:

You can't double the speed of the audio coming from a microphone as you
play it out the speaker, because the microphone only provides 1 second of
audio every second.  If you doubled the speed you would only have 1/2
second of audio output every second.

You can *totally *double the speed of a sound file, synthesizer or some
other non-realtime sound source.  You just need to grab twice as much audio
before you use your speed-changing algorithm to "resize" to the necessary
amount.

If you're doing the latter, just ignore all the confusing "it can't be
done" responses.  If you're trying to change the pitch on mic input, what
you need to do is time-stretch (or time-squish) the audio and then use
resampling to resize it back to the original length.  That will leave you
with 1 second per second of audio, just at a different pitch.  Make sure
the length comes out *exactly *the same or you'll get crackles!

– Evan Balster
creator of imitone <http://imitone.com>


On Wed, Oct 3, 2018 at 3:56 PM Alex Dashevski  wrote:

> Hi,
> Could you tell me how to use soundTouch API if I want only to do
> resampling ?
> I mean: convert from 48Khz to 8Khz or 8Khz to 48Khz
> I guess that setRate with SETTING_USE_AA_FILTER. What length should put ?
>
> I talk about
> https://gitlab.com/soundtouch/soundtouch/tree/master/source/SoundTouch
>
> Thanks,
> Alex
>
> ‫בתאריך יום ב׳, 1 באוק׳ 2018 ב-19:46 מאת ‪Nuno Santos‬‏ <‪
> nunosan...@imaginando.pt‬‏>:‬
>
>> Hey Alex,
>>
>> Have you seen this article before?
>>
>> https://www.surina.net/article/time-and-pitch-scaling.html
>>
>> It has a complete and detailed description on how time and pitch scaling
>> works.
>>
>> Hope it helps!
>>
>> Best regards,
>>
>> Nuno
>>
>> On 1 Oct 2018, at 17:30, Alex Dashevski  wrote:
>>
>> Hi,
>>
>> I got this answer from Robert:
>> WSOLA fundamentally does time-scaling.  time compression or time
>> stretching without changing pitch.  time-scaling is not normally thought of
>> as real-time because your input and output buffer pointers will collide.
>>
>>
>> My question is:
>> Why buffers will collide ?
>>
>> Thanks,
>> Alex
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Antialias question (Kevin Chi)

[Evan Balster]

Hey, Frank —

I use four-point, third-order hermite resampling everywhere.  It's fast,
relatively simple, and as good as will be necessary for most applications.
Linear resampling can introduce some perceptible harmonic distortion into
higher frequencies.  This will be especially noticeable when slowing down
or upsampling audio with high-frequency content.

Aliasing in audio occurs when frequencies outside the representable range
are generated, by resampling, synthesis or other sources of harmonic
distortion.  Aliased frequencies "wrap around"; generating a 1700hz
frequency in a signal with 1000hz nyquist will result in a 300hz
frequency.  As a rule of thumb, when speeding up audio, you first filter
out those frequencies which will be pushed over Nyquist and wrap around;
when slowing it down, you afterward filter out those frequencies which
should not exist (but come into existence because of harmonic distortion).
I made a great improvement in a resampling-heavy soundscape application by
implementing fourth-order butterworth filters in my pitch-shifters, which
had formerly implemented no antialiasing; a great deal of "harshness" was
eliminated in one sweep.

Here is a wonderful, very skimmable paper that tells you everything you
could ever want to know about resampling and provides example code for many
techniques:  http://yehar.com/blog/wp-content/uploads/2009/08/deip.pdf

– Evan Balster
creator of imitone <http://imitone.com>

On Fri, Jun 1, 2018 at 1:03 PM, Frank Sheeran  wrote:

> Hi Kevin.
>
> I'm the least-expert guy here I'm sure, but as a fellow newbie I might
> have some newbie-level ideas for you.
>
> Just to mention something simple: linear interpolating between samples is
> a huge improvement in reducing aliasing over not interpolating.  For
> instance if your playback math says to get sample 171.25 out of the buffer,
> use .75 of sample 171 and .25 of sample 172.  I don't know the math but my
> listening tests of tricky test waveforms (eg, a waveform with a fundamental
> at 100Hz and a 60th harmonic at 6kHz pumped up to 10, 20,30x the power,
> showed aliasing reduced by about the same amount that quadrupling the
> buffer sample rate did.
>
> I looked into other interpolations besides linear, and they didn't seem
> effective enough to bother programming.  Just to give a feeling for it, if
> linear eliminated 90% of aliasing, then then more complex interpolation
> might eliminate 95%.  So they might reduce it by half compared to linear,
> but only a tiny bit better compared to none at all.  (The percentages are
> just meant to be illustrative and actually everything totally depends on
> your input data.)
>
> Another thing is to make sure your input data has been filtered out such
> that there's no frequencies over the Nyquist frequency.  But if you're
> dealing with a PC or smart phone I'd imagine the computer hardware handles
> that for you.  Once the data is in memory you cannot filter it out, as it
> will already have morphed into an alias in your input buffer and be "baked
> in" no matter how you try to play the data back.
>
> Finally, listen with good headphones; you'll hear things you probably
> won't in a room even if you have a good amp and speakers.
>
> Frank
> http://moselle-synth.com/
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] band-limited website

[Evan Balster]

I can confirm the error.

Maybe if we sample it over a shorter time interval, the bandwidth will
increase?

– Evan Balster
creator of imitone <http://imitone.com>

On Sat, Dec 23, 2017 at 6:42 PM, Phil Burk <philb...@mobileer.com> wrote:

> I was not looking for the mail list archives.
> We used to have a music-dsp code archive with lots of example DSP code.
> It was under this website:
>
> http://www.musicdsp.org/
>
> That website is now bandwidth limited, which for a website is a bad
> thing. The site will not open.
>
> Is anyone else seeing that error?
>
> > You need to sample it more frequently.
>
> Thanks James. That's sound advice.
>
>
> On Sat, Dec 23, 2017 at 2:49 PM, James McCartney <asy...@gmail.com> wrote:
> > You need to sample it more frequently.
> >
> > On Sat, Dec 23, 2017 at 1:06 PM, Phil Burk <philb...@mobileer.com>
> wrote:
> >>
> >> I tried to access the Archive at http://musicdsp.org/archive.php
> >> and got this message:
> >>
> >> Bandwidth Limit Exceeded
> >>
> >> The server is temporarily unable to service your request due to the
> >> site owner reaching his/her bandwidth limit. Please try again later.
> >> ___
> >> dupswapdrop: music-dsp mailing list
> >> music-dsp@music.columbia.edu
> >> https://lists.columbia.edu/mailman/listinfo/music-dsp
> >>
> >
> >
> >
> > --
> > --- james mccartney
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] intensity of Doppler effect

[Evan Balster]

Hey, Renato —

Per the other recent thread on this topic, the power of a sound wave is
proportional to the square of (frequency x displacement).  So even though
there's no increase in displacement, the doppler effect for an approaching
object will cause an increase in its sound's AC power (and loudness, to an
ideal listener, and signal amplitude, to a microphone).

Summarizing the other thread:  Microphone voltage typically corresponds to
the differential of the diaphragm's displacement (because magnet/coil
movement causes electrical induction).  Because this differential (dx/dt
where x=sin(ωt)) becomes steeper as frequency increases, an increase in
sound frequency will produce an increase in signal amplitude even as the
air displacement remains constant.  This is why we measure power as a
simple RMS in signal processing systems even though it's
frequency-dependent in physics.

– Evan Balster
creator of imitone <http://imitone.com>

On Wed, Oct 11, 2017 at 8:25 AM, Renato Fabbri <renato.fab...@gmail.com>
wrote:

> Dear Music-DSPers,
>
> These considerations about the intensity of the Doppler
> effect is quite estrange and seems really to have not
> received a note in the literature, probably IMHO because
> it only changes the DC component (mean pressure)
> and thus has not been detected in experiments.
>
> Therefore, if we can manage to give a decent
> account of it, I am willing to write a short note
> and upload to arXiv.
> And maybe send it to a minor conference
> to which I attend or a minor journal.
> (Citing this group and in co-authorship
> with whomever helps in the derivation
> of the description.)
>
> Also, I've found some posts with the same question
> in online forums: it seems to be a quite
> often difficulty.
>
> Best,
> R.
>
>
> On Mon, Oct 9, 2017 at 2:30 PM, Renato Fabbri <renato.fab...@gmail.com>
> wrote:
>
>> Ok, I think I managed to better express the problem.
>>
>> the power of the wave is P = DE/DT (D is Delta, E is energy, T is time).
>> If the receiver is not moving and the source is moving
>> in the direction of the receiver with speed s,
>> and DT=1:
>>
>> DE2 = DE + DE(s/c) + mv^2/2
>>
>> (c is the sonic speed ~340)
>>
>> The first term is the energy emitted by the source.
>> The second term is due to the additional amount of the wave
>> that is being received in the same time span.
>> The third term is just the kinetic energy.
>>
>> Naively, one might think that:
>> P2 = DE2/DT
>>
>> and the decibel difference is:
>> dB = 10log_10(DE2/DE)
>>
>> But.
>> What we hear is the pressure oscillation amplitude,
>> with the DC component (bias, offset) not being relevant.
>>
>> So, my conclusion, at the moment, is that,
>> in fact, the loudness difference we have in the Doppler
>> effect is only due to the distance between the source and
>> the receiver.
>> This is because the second and third terms in DE2
>> really exist but introduce only a DC component.
>> The DC component varies but such variation
>> should yield quite
>> an irrelevant contribution to the intensity of the wave.
>>
>> *If* all these thoughts are right,
>> then the question still remains:
>> what (probably negligible) is the contribution
>> of the variation of the DC component
>> to the intensity (or power) of the wave.
>>
>> (???)
>>
>> Best,
>> R.
>>
>>
>>
>>
>> On Mon, Oct 9, 2017 at 8:24 AM, Renato Fabbri <renato.fab...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sun, Oct 8, 2017 at 11:29 PM, Evan Balster <e...@imitone.com> wrote:
>>>
>>>> Hey, Renato —
>>>>
>>>> .
>>>>
>>>
>>>
>>>> Imagine a 330-meter-long wavefront moving right at 330 meters per
>>>> second toward a quarter-sized object; if the object is still, it receives
>>>> sound sound energy on its surface over the course of one second.  If it's
>>>> moving left, it received the energy over a smaller window of time,
>>>> experiencing it as a higher frequency.
>>>>
>>>
>>> That's about it: if one is receiving the same amount of energy over a
>>> shorter time span,
>>> (my hint is that) there should be an increase in the power, intensity
>>> and thus loudness
>>> (with the care to notice that loudness depends on more things so its
>>> increase is not assured).
>>>
>>> R.
>>>
>>>
>>>> – Evan Balster
>>>> creator of imitone
>>>

Re: [music-dsp] intensity of Doppler effect

[Evan Balster]

Hey, Renato —

Kinetic energy is proportional to velocity squared times mass.  The maximum
speed of an oscillating particle of air is proportional to both the
amplitude (or displacement) of the wave and the frequency.  Vibrating
further = moving faster.  Vibrating faster = moving faster.

If some sound wave is hitting a surface and displacing it, the same rule
applies.  Velocity is proportional to displacement times frequency, and
energy is proportional to the square of that.  The doppler effect increases
the frequency of the wave, and thus the rate at which energy is delivered
(the power).

The doppler effect isn't magically increasing or decreasing the energy in
the sound wave.  We're just receiving that energy faster because we're
moving in the opposite direction.

Imagine a 330-meter-long wavefront moving right at 330 meters per second
toward a quarter-sized object; if the object is still, it receives sound
sound energy on its surface over the course of one second.  If it's moving
left, it received the energy over a smaller window of time, experiencing it
as a higher frequency.

– Evan Balster
creator of imitone <http://imitone.com>

On Sun, Oct 8, 2017 at 6:26 PM, Renato Fabbri <renato.fab...@gmail.com>
wrote:

> Ok that the Doppler effect changes the frequency of the received sound.
>
> But, at the same time, it seems to me that there *might* be a change in
> the intensity of the wave, not due to the change in the relative
> localization
> of the source to the receiver, but due to the relative speed.
>
> I already searched about this a few times in the past years
> and found nothing.
> Maybe because the intensity of the wave just doesn't change
> for the emitted energy is conserved. (?)
> And all we are left with is the standard change in the
> intensity of the wave due to the distance.
>
> Any thoughts?
>
> R.
>
> --
> Renato Fabbri
> GNU/Linux User #479299
> labmacambira.sourceforge.net
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] PCM audio amplitudes represent pressure or displacement?

[Evan Balster]

A few other notes I should add:

1.  Per the reasoning above, the PCM of a sine wave is going *tend to* to
be proportional to the wave's physical amplitude (speaker
displacement) *multiplied
by* its frequency — again, in an ideal system without frequency-dependent
effects (and those are inevitable).

2.  Just because PCM encodes velocity doesn't mean there's some inherent
delay or phase shift as suggested by others here.  Those artifacts come
from frequency-dependent effects.  For example, if I have a circuit
composed of two identical transducer coils wired to one another, and I
whack the first one, the acceleration of its coil is going to create a
voltage that drives an acceleration of the other coil.  In an "ideal"
physics scenario the second coil might copy the first's movement perfectly
and instantaneously, but it doesn't because we have electrical resistance,
friction, momentum, etc.

– Evan Balster
creator of imitone <http://imitone.com>

On Sun, Oct 1, 2017 at 12:56 PM, Evan Balster <e...@imitone.com> wrote:

> DSP programmer recently getting into transducer experimentation here.
> Gonna walk through the dimensional analysis:
>
>
> 1.  Sound waves are a form of energy.  Energy doesn't exchange directly
> with other units like voltage, velocity, momentum, etc, because those units
> are in different dimensions.
>
> 2.  If the displacement distance is constant, a higher-frequency sound
> wave means the air is traveling back an forth at higher velocity (directly
> proportional to frequency).
>
> 3.  Kinetic energy is proportional to velocity squared.
>
> 4.  *Thus*, it takes four times as much energy to vibrate with the same
> displacement at twice the frequency (because the velocity is doubled).
>
> 5.  Power is the rate of energy flow in an electrical system.
>
> 6.  In an ideal digital/analog conversion (with no frequency-dependent
> effects) PCM values are directly proportional to voltage.
>
> 7.  In an electrical system, power is (voltage x current).  Current is
> (voltage / impedance).  Ideally impedance is fixed, so power is
> proportional to voltage squared.
>
> 8.  *Thus*, power is proportional to PCM squared, and energy is
> proportional to PCM squared per second (mean-square).
>
> 9.  Thus, because mean-square PCM is proportional to energy, and energy is
> proportional to speaker displacement times frequency squared, PCM is *not*
> proportional to displacement.  In an ideal electrical system, it's
> proportional to velocity.
>
>
> Filter-like (frequency-dependent) effects can change things, because they
> can mix a signal together with its integrals and derivatives.  It's simple
> to transform that velocity signal into a displacement signal or vice versa,
> but in practice any filtering effects will result in a frequency-dependent
> mixture of the two (and potentially other degrees of integration).
>
> – Evan Balster
> creator of imitone <http://imitone.com>
>
> On Sun, Oct 1, 2017 at 11:31 AM, Renato Fabbri <renato.fab...@gmail.com>
> wrote:
>
>>
>>
>> On Sun, Oct 1, 2017 at 1:23 PM, robert bristow-johnson <
>> r...@audioimagination.com> wrote:
>>
>>>
>>>
>>> i know relatively little about transducers.  but these are getting to be
>>> pretty fundamental questions.
>>>
>>> Renato, we don't know exactly how much the digital value will translate
>>> to a precise loudspeaker piston displacement because there is an amplifier
>>> with a volume control in between the D/A converter and the loudspeakers.
>>>
>>> when we talk of gain and scaling of the digital numbers coming out of a
>>> DSP process, we can only really discuss what is "full scale" and, perhaps
>>> if you're a hardware geek, what the reference voltage is for the D/A
>>> converter (or A/D on the input side) which will map to full scale.
>>> usually, as integers, the A/D and D/A integer values are left-justified.
>>> if your D/A word was a puny 16 bits, that means -32768 and +32767 are your
>>> full scale values.  how they get translated to loudspeaker piston
>>> displacement depends on the analog hardware in between (and the volume
>>> control) and of the loudspeaker.
>>>
>>> also about instantaneous pressure vs. displacement, it's really a
>>> combination of the two and the two are related by some LTI acoustic
>>> filtering function.
>>>
>> one is the derivative of the other I guess
>> (
>> as in
>> http://physics.bu.edu/~duffy/semester1/c20_disp_pressure.html
>> )
>>
>> PS. I am getting quite convinced that PCM samples by standard represent
>> the displacement of the

Re: [music-dsp] PCM audio amplitudes represent pressure or displacement?

[Evan Balster]

DSP programmer recently getting into transducer experimentation here.
Gonna walk through the dimensional analysis:


1.  Sound waves are a form of energy.  Energy doesn't exchange directly
with other units like voltage, velocity, momentum, etc, because those units
are in different dimensions.

2.  If the displacement distance is constant, a higher-frequency sound wave
means the air is traveling back an forth at higher velocity (directly
proportional to frequency).

3.  Kinetic energy is proportional to velocity squared.

4.  *Thus*, it takes four times as much energy to vibrate with the same
displacement at twice the frequency (because the velocity is doubled).

5.  Power is the rate of energy flow in an electrical system.

6.  In an ideal digital/analog conversion (with no frequency-dependent
effects) PCM values are directly proportional to voltage.

7.  In an electrical system, power is (voltage x current).  Current is
(voltage / impedance).  Ideally impedance is fixed, so power is
proportional to voltage squared.

8.  *Thus*, power is proportional to PCM squared, and energy is
proportional to PCM squared per second (mean-square).

9.  Thus, because mean-square PCM is proportional to energy, and energy is
proportional to speaker displacement times frequency squared, PCM is *not*
proportional to displacement.  In an ideal electrical system, it's
proportional to velocity.


Filter-like (frequency-dependent) effects can change things, because they
can mix a signal together with its integrals and derivatives.  It's simple
to transform that velocity signal into a displacement signal or vice versa,
but in practice any filtering effects will result in a frequency-dependent
mixture of the two (and potentially other degrees of integration).

– Evan Balster
creator of imitone <http://imitone.com>

On Sun, Oct 1, 2017 at 11:31 AM, Renato Fabbri <renato.fab...@gmail.com>
wrote:

>
>
> On Sun, Oct 1, 2017 at 1:23 PM, robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>>
>>
>> i know relatively little about transducers.  but these are getting to be
>> pretty fundamental questions.
>>
>> Renato, we don't know exactly how much the digital value will translate
>> to a precise loudspeaker piston displacement because there is an amplifier
>> with a volume control in between the D/A converter and the loudspeakers.
>>
>> when we talk of gain and scaling of the digital numbers coming out of a
>> DSP process, we can only really discuss what is "full scale" and, perhaps
>> if you're a hardware geek, what the reference voltage is for the D/A
>> converter (or A/D on the input side) which will map to full scale.
>> usually, as integers, the A/D and D/A integer values are left-justified.
>> if your D/A word was a puny 16 bits, that means -32768 and +32767 are your
>> full scale values.  how they get translated to loudspeaker piston
>> displacement depends on the analog hardware in between (and the volume
>> control) and of the loudspeaker.
>>
>> also about instantaneous pressure vs. displacement, it's really a
>> combination of the two and the two are related by some LTI acoustic
>> filtering function.
>>
> one is the derivative of the other I guess
> (
> as in
> http://physics.bu.edu/~duffy/semester1/c20_disp_pressure.html
> )
>
> PS. I am getting quite convinced that PCM samples by standard represent
> the displacement of the sonic wave.
>
>>   for me, it's easiest to imagine that the instantaneous pressure
>> (actually the *difference* between instantaneous absolute pressure and the
>> ambient atmospheric pressure, the DC component, which is about 100 kPa) is
>> proportionally mapped to the signal sample in the DSP.  but i never worry
>> about the constant of proportionality because it simply is what it after i
>> set the volume control to a desired setting.
>>
>> that's my pedantic spin on it.
>>
>> r b-j
>>
>>
>>
>>
>>  Original Message 
>> Subject: Re: [music-dsp] PCM audio amplitudes represent pressure or
>> displacement?
>> From: "Renato Fabbri" <renato.fab...@gmail.com>
>> Date: Sun, October 1, 2017 12:58 am
>> To: "A discussion list for music-related DSP" <
>> music-dsp@music.columbia.edu>
>> 
>> --
>>
>> > tx for the infos and thoughts.
>> >
>> > I am getting the same difficulty when I
>> > look at texts in the subject.
>> >
>> > Making the question very objective,
>> > is anyone able to state very briefly if
>> > LPCM 

Re: [music-dsp] What happened to that FPGA for DSP idea

[Evan Balster]

Hey, Theo —

Rather than expensive math library calls, I'd be interested to see results
from an experiment with linear filtering.  How much space does a biquad
filter take up?  What about a delay line?  How much does that decrease when
you drop to single-precision?  Can you disable denormals to save even more
space?

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Sep 14, 2017 at 4:02 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> well, i know of at least one company that uses an FPGA to replace the ASIC
> they used to use.  they use it to fetch samples, interpolate and loop.
>  also to do some post-processing DSP to the note.
>
>
>
> --
>
> r b-j  r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] ± 45° Hilbert transformer for pitch detection?

[Evan Balster]

That jitter, eh?  https://en.wikipedia.org/wiki/Kalman_filter

Your algorithm won't work for general pitch sources, become many in the
wild will lack a prominent fundamental frequency.  That said, it's pretty
fun and some good creative mischief might be had with it.  For example, try
multiplying a sine wave at 1/3 or 1/4 the detected pitch by the input
signal, and then mixing some of the dry signal back in...

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Feb 9, 2017 at 8:47 AM, gm <g...@voxangelica.net> wrote:

> Here is another test with more difficult input
> Also works an drums, kind of
>
> https://soundcloud.com/magnetic_winter/adaptive-ap-pitchtrack-2/s-FCoKI
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] ± 45° Hilbert transformer using pair of IIR APFs

[Evan Balster]

If there are zeroes on the unit circle in the z-plane, I don't think it
will be a very good all-pass filter...  (Because some sinusoid frequencies
would be blocked entirely)

Neat topic so far!  I'd love to see an illustration of this real-line
"zebra stripe" design.  Also wondering what sort of filter a similar
pattern on the imaginary line produces!  (I should improve my own filter
testbed...)

– Evan Balster
creator of imitone <http://imitone.com>

On Mon, Feb 6, 2017 at 8:57 PM, Sampo Syreeni <de...@iki.fi> wrote:

> On 2017-02-06, Eric Brombaugh wrote:
>
> well, with a single sinusoid, there should be no intermodulation product
>>> so the analytic envelope should be exactly correct.  but consider:
>>>
>> [...]
>
> I might be way off base here, but... As Olli said, both the poles and the
> zeroes sorta "like to be" on the real line.
>
> To me that is kind of a canary. Typically when something works on the real
> line, it tends to work better when distributed over the unit circle. Often
> even reflected over the unit point.
>
> Olli, I *know* this is again highly intuitionistic. But could you still,
> as the kind of guy who actually follows through with his math, check this
> out? I am reasonably, intuitionistically sure, that you started your
> optimization from a local basin. I'm pretty sure there is at least one
> other basin even given your optimization criteria, given by alternating
> zeroes and poles over the left half of the unit circle over the z-plane,
> just as you said they worked alternately over the real line. Or perchance
> over some elliptical locus.
>
> Please, try that original setup as well. Then tell us what your
> optimization machinery did with it. I'm reasonably sure it wouldn't
> converge to what you originally had, even if it converged to *something*
> good. :)
> --
> Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front
> +358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Recognizing Frequency Components

[Evan Balster]

Philosophy rant:  Frequency is a model.  You can use tools that build on
that model to describe your signal in terms of frequency, but none of them
are going to be perfect.  A pure 10hz tone is a mathematical abstraction
which you'll not find in any digital signal or measurable phenomenon.
But, *ooh
boy!* is that abstraction useful for modeling real things.

If you have an extremely clean signal and you want an extremely accurate
measurement, my recommendation is to forgo fourier transforms (which
introduce noise and resolution limits) and use optimization or measurement
techniques in the time domain.  In your example, *zero crossings are the
easiest and best solution* as Steffan suggests.

Another interesting approach, which I mention for scholarly purposes, would
be to design a digital filter with a sloping magnitude response (even the
simplest one-pole lowpass could do) and apply it across the signal.  You
can measure the change in the signal's power (toward the end, because the
sudden beginning of a sine wave produces noise) and find the frequency for
which the filter's transfer function produces that attenuation.  This
filter-based technique (and related ones) can generalize to other problems
where zero-crossings are less useful.

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Jan 26, 2017 at 9:20 AM, STEFFAN DIEDRICHSEN <sdiedrich...@me.com>
wrote:

> At that length, you can count zero-crossings. But that’s not a valid
> answer, I’d assume.
> But I found a nice paper on determining frequencies with FFTs using a
> gaussian window.  Pretty accurate results.
>
> Best,
>
> Steffan
>
>
> On 26.01.2017|KW4, at 15:24, Theo Verelst <theo...@theover.org> wrote:
>
> Say the sample length is long enough for any purpose, like 10 seconds.
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Using an actual database for storage of DSP settings

[Evan Balster]

This is an interesting idea.  I wonder if sqlite would be a good fit for
that problem scale?

– Evan Balster
creator of imitone <http://imitone.com>

On Wed, Dec 28, 2016 at 7:52 AM, Sampo Syreeni <de...@iki.fi> wrote:

> On 2016-12-28, Theo Verelst wrote:
>
> Did anyone here do any previous work on such subject ? I mean I don't
>> expect some to come up and say : "sure ! here's a tool that automatically
>> does that for all Ladspa's" or something, but maybe people have ideas...
>>
>
> I can't say I've done anything specialized towards sound, but in what
> career I did once have, I've modelled my fair share of data within the
> relational framework. If you need help in that regard, I'm available.
> Enthusiastic, even. :)
> --
> Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front
> +358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Can anyone figure out this simple, but apparently wrong, mixing technique?

[Evan Balster]

The sum of two uncorrelated signals will tend to have a power which is the
sum of the power of the original signals.  This is easy to demonstrate with
white noise.  At one point I studied how this rule changes for harmonic
sounds, and I believe my conclusion was that it's tricky for small numbers
of these sounds but ultimately converges toward a power sum as with
uncorrelated noise.

I usually like to visualize the worst case (many sines at one frequency) in
terms of a spatial convolution of many unit circles (which converges to a
gaussian in the limit), but a simpler rule establishes it well:  for
independent random variable, the variance of the sum is the sum of the
variances
<https://stats.stackexchange.com/questions/31177/does-the-variance-of-a-sum-equal-the-sum-of-the-variances>.
Ergo, for independent signals, the power of the mix will typically be
proportional to the sum of the signals' powers.  This is especially true
with many voices owing to the central limit theorem.  So, in general, 5
more bits should be enough to accommodate 1024 times as many voices, *so
long as* there are no magical phase correlations.

The crossover between stats and signal processing can show up in surprising
places.

– Evan Balster
creator of imitone <http://imitone.com>

On Tue, Dec 20, 2016 at 9:07 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
>  Original Message 
> Subject: Re: [music-dsp] Can anyone figure out this simple, but apparently
> wrong, mixing technique?
> From: "Theo Verelst" <theo...@theover.org>
> Date: Tue, December 20, 2016 6:13 pm
> To: r...@audioimagination.com
> music-dsp@music.columbia.edu
> --
>
> >
> > To me it seems the preoccupation of maximizing the mix output isn't
> wrong, but the digital
> > domain problems usually has other handles. The choir example of adding
> say a thousand
> > voices and needing 10 more bits
>
> you would need 10 more bits only if there was much of a possibility of all
> 1000 voices singing a synchronized-phase tone, a coherent waveform like an
> acoustic laser beam.  you wouldn't need 10 more bits otherwise (assuming
> each of the 1000 has the same power as 1).  every bit gains you 6dB of
> headroom and every time you double the power, you lose 3 dB of headroom.
>
> regarding Viktor Toth's alg, it was stated for adding two sources without
> reducing either amplitude if either one is at a low level. i am starting to
> warm to it a teeny bit.  i wonder if it were N sources being combined, if
> it would be the sum of the N sources minus every cross product (and there
> would be (N^2-N)/2 of those cross products)?
>
>
> --
>
> r b-j  r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Allpass filter

[Evan Balster]

>
> *The magnitude of ap = 1, so ap applies only phase shifts. Its group delay
> is inverse to the group delay of p.*
>

I think the idea here is to derive a filter with the same magnitude
characteristics as p, but zero group delay --- so as to transform arbitrary
filters into zero-phase / zero-delay filters.  Generally, deriving one of
these for a causal filter p is possible, but will result in an anti-causal
ap filter that can't be implemented, because it requires information from
the future.  The zero-phase lp filter will generally require information
from the past *and *the future.  If you're willing to tolerate a long,
constant delay (increasing in proportion to the accuracy of the magnitude
response) you can approximate your lp filter with a symmetric FIR filter
design.

Sadly you can't cheat the laws of filter theory --- at least, not without
venturing outside it.

– Evan Balster
creator of imitone <http://imitone.com>

On Wed, Dec 7, 2016 at 12:53 PM, Ethan Duni <ethan.d...@gmail.com> wrote:

> I'm not sure I quite follow what the goal is here? If you already have lp
> and p, then there aren't any additional calculations needed to obtain ap -
> it's an IIR filter with numerator coefficients given by lp, and denominator
> coefficients given by p. The pulse response is obtained by running the
> filter for a pulse input.
>
> Is the goal to get an FIR approximation of ap? As Stefan has pointed out,
> an FIR allpass is a simple delay. If you are willing to relax the allpass
> criterion, you can get an FIR approximation by just truncating the pulse
> response at whatever length is sufficient for your application.
>
> Unless I'm missing something, seems like all of the difficulties are in
> obtaining p and lp in the first place?
>
> Ethan
>
> On Wed, Dec 7, 2016 at 4:10 AM, Uli Brueggemann <uli.brueggem...@gmail.com
> > wrote:
>
>> Hi,
>>
>> I'm searching a solution for an allpass filter calculation with following
>> conditions:
>>
>> There is a given pulse response p with a transfer function H. It is
>> possible to derive a linear phase pulse response lp from the magnitude of H.
>>
>> Now there is an equation
>> p * ap = lp  (* = convolution, ap = allpass)
>>
>> Thus
>> ap = lp * p^-1
>>
>> The magnitude of ap = 1, so ap applies only phase shifts. Its group delay
>> is inverse to the group delay of p.
>>
>> Is there a solution to elegantly calculate the pulse response ap ? The
>> calculation of p^-1 may be difficult or numerically unstable.
>>
>> Cheers
>> Uli
>>
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Help with "Sound Retainer"/Sostenuto Effect

[Evan Balster]

>
> I was thinking of taking freeverb and removing the comb
> filters and just using the allpass filters with 100% feedback thinking
> it would make it a "cleaner" sustain.
>

I think that's worth a try.  Using comb filters would be problematic in
your case because the harmonics of the guitar might align with the nulls.

– Evan Balster
creator of imitone <http://imitone.com>

On Fri, Sep 16, 2016 at 3:58 PM, gm <g...@voxangelica.net> wrote:

> I never tried the Freeverb algorithm.
> Just form inspecting the flow chart I suspect its rather colored with all
> the comb filters.
>
> A classical reverb algorithm would be the allpass diffusors inside a comb
> filter loop like this
>
> Input -> +-> AP -> AP -> AP -> Delay -> Feedback -> Out
>  ^|
>  ||
>
> search for Datorro Effects Design for an example of this
>
> Designing reverbs is a huge topic of its own, what you also can try is an
> FDN
> (Feedback Delay Network) structure, with the delays tuned to very low
> pitches spaced in semitones
> which will give an effect similar to that of open strings in a piano
>
> Am 16.09.2016 um 22:29 schrieb Spencer Jackson:
>
> Wow, thanks all for the replies!
>
> If I used a reverb would it end up giving the sustained voice too much
> character? I was thinking of taking freeverb and removing the comb
> filters and just using the allpass filters with 100% feedback thinking
> it would make it a "cleaner" sustain. I'm leaning this way because I'd
> like to keep it lightweight and I think this will be less overhead
> than a phase vocoder. Is that a naive approach?
>
> Thanks again,
> _Spencer
>
>
>
> On Fri, Sep 16, 2016 at 1:59 PM, Emanuel 
> Landeholm<emanuel.landeh...@gmail.com> <emanuel.landeh...@gmail.com> wrote:
>
> Simple OLA will produce warbles. I recommend a phase vocoder.
>
>
> ___
> dupswapdrop: music-dsp mailing 
> listmusic-dsp@music.columbia.eduhttps://lists.columbia.edu/mailman/listinfo/music-dsp
>
> ___
> dupswapdrop: music-dsp mailing 
> listmusic-dsp@music.columbia.eduhttps://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Help with "Sound Retainer"/Sostenuto Effect

[Evan Balster]

Regarding reverbs, one classic element is the Schroeder allpass:
https://ccrma.stanford.edu/~jos/pasp/Schroeder_Allpass_Sections.html  You
can use it to smear a signal without any constructive or destructive
interference.  Generally speaking this lack of "color" is a disadvantage,
but for your application it's probably very desirable.

Another observation:

It works well on simple signals
> but on something not perfectly periodic like a guitar chord it always
> has the rhythmic noise of a poor loop.


It's generally easier to recognize artifacts when they repeat at regular
intervals.  If you're taking the granular approach, I suggest randomizing
as much as possible.  If you want to avoid interference between the grains,
try to synchronize them based on a cross-correlation
<https://en.wikipedia.org/wiki/Cross-correlation>.

– Evan Balster
creator of imitone <http://imitone.com>

On Fri, Sep 16, 2016 at 12:30 PM, Spencer Jackson <ssjackso...@gmail.com>
wrote:

> On Fri, Sep 16, 2016 at 11:24 AM, gm <g...@voxangelica.net> wrote:
> > Did you consider a reverb or an FFT time stretch algorithm?
> >
>
> I haven't looked into an FFT algorithm. I'll have to read up on that,
> but what do you mean with reverb? Would you feed the loop into a
> reverb or apply some reverberant filter before looping?
>
> Thanks,
> _Spencer
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Bandlimited morphable waveform generation

[Evan Balster]

General note:  As things get clearer in the time domain, they tend to get
fuzzier in the frequency domain.  "Perfect" frequency-domain solutions
(like sinc interpolation) tend to smear the signal in the time domain; that
is the mirror image of the problem you're experiencing now.  Don't forget
that one of these is just a mathematical model for the other.

It's my observation that when people ask for the best of both worlds on
music-dsp, they tend to get overwhelmed by suggestions, opinions and
academic papers devoted to overcoming a basic law of signal processing
<https://en.wikipedia.org/wiki/Uncertainty_principle#Signal_processing>,
when far simpler techniques will often suffice.

So here's my suggestion:  Don't be too clever.  Just try smoothing out the
waveforms a bit to combat the aliasing.  It comes, roughly, from
discontinuity in the waveform.  Oversample and filter, or sample from
"soft" square and sawtooth functions with a smoothing parameter built in.


Given any f(x): Is it possible to sample f(x) with a given sample-rate
> ignoring all frequencies (slopes) higher than SF/2?


*This question is a pathway into madness.*

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Sep 15, 2016 at 2:07 PM, André Michelle <andre.miche...@gmail.com>
wrote:

> I could phrase my question more general:
>> Given any f(x): Is it possible to sample f(x) with a given sample-rate
>> ignoring all frequencies (slopes) higher than SF/2?
>>
>>
> Couldn't you just implement a brickwall FIR filter in your signal chain,
> after whatever signal you're deciding to generate (prior to sampling, if
> your in the analog domain)?
>
>
> From what I understand it is impossible to get rid of aliased frequencies
> after sampling.
>
> ~
> André
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

> i can't accept that at all.

> especially for this mailing list.  we are discussing algs that run on
music and audio signals.  sample rates might be as low as 22.05 kHz and
might be as high as 192 kHz.  if it's not streaming real-time, then the
sound file might likely be 10 minutes long.  or a half hour.  it's gonna be
a pretty big N.  much, much bigger than R.
I didn't say it was practical to run the algorithm without dropping
samples.  Just that it was possible --- and what that implies provides
important insights into the algorithm's capabilities.  For instance. the
window size can be changed in real-time by popping and pushing at different
rates.

While it's true that in the world of DSP almost nobody uses algorithms
whose complexity is not linear with respect to signal length, it's still
important for purposes of demonstrating computational complexity.  This
algorithm does its job; I mention signal length simply for the purpose of
demonstrating that for sufficiently long sections of signal R ceases to
affect its computational complexity.


> it can't possibly do better than O(log2(R)) in these spikes.  if that is
the case, it is no better than the binary tree.

The worst-case complexity for a single sample is logarithmic, like the
binary tree.  But the worst case over a sequence of samples becomes linear,
provided the sequence is longer than the wedge.

If we perform a binary tree search at every sample over R
monotonically-decreasing samples, our worst-case performance over R samples
is O(R log2(R)), because the wedge's size is always R and we're performing
a binary search every sample.  This is sub-optimal and even the original
Lemire algorithm with an O(N) search can provide higher efficiency.  Please,
read his paper. <https://arxiv.org/abs/cs/0610046>

If we use Ethan Fenn's search, the worst-case performance over any R
samples is O(R).  *Beyond a size of R samples, worst-case complexity for
processing a block of size N is O(N)*, or constant per-sample (which is why
I keep mentioning N).  I've explained the reasoning here to the best of my
ability; if you doubt it, instrument the code to count comparator calls and
see for yourself.

– Evan Balster
creator of imitone <http://imitone.com>

On Sat, Sep 3, 2016 at 1:45 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> okay, so it appears, all of this time, that i have mixed up the roles of N
> and R.
>
>
>
>  Original Message 
> Subject: Re: [music-dsp] efficient running max algorithm
> From: "Evan Balster" <e...@imitone.com>
> Date: Sat, September 3, 2016 1:40 pm
> To: "robert bristow-johnson" <r...@audioimagination.com>
> music-dsp@music.columbia.edu
> --
>
> > Samples do not need to be processed in blocks. You can push and pop them
> > one by one with no change in cost. R would be the parameter you're
> > interested in---the length of the window---while N is the total number of
> > samples processed.
>
> so for a streaming alg, like a limiter/compressor that runs at 96 kHz and
> has been running for hours, what would N be?
>
> like N = infinity?
>
>
> > I describe N separate from R for various reasons. One of these is
> > that you *don't need*
> > to drop samples from the front of the wedge to use the algorithm.
>
> if N = infinity, that will require a lotta memory.
>
> and in a running max, the maximum is only a function of x[n] to x[n-R+1].
>  how is it that you don't forget about x[n-R] and x[n-R-1] and x[n-R-2]?
>
>
> > Provided sufficient storage, you can compute min/max information for a
> > signal of arbitrary length without taking more than O(N) total time. (The
> > other reason is that it isn't conventional to think in terms of infinity
> > when describing algorithm complexity.)
>
> i can't accept that at all.
>
> especially for this mailing list.  we are discussing algs that run on
> music and audio signals.  sample rates might be as low as 22.05 kHz and
> might be as high as 192 kHz.  if it's not streaming real-time, then the
> sound file might likely be 10 minutes long.  or a half hour.  it's gonna be
> a pretty big N.  much, much bigger than R.
>
> a **running** max is not the same idea as the max of an entire file (like
> for normalization purposes).  a **running** max is about what's been
> happening for precisely the most current R samples, x[n] to x[n-R+1].
>  x[n-R] has fallen offa the edge of the delay line and we don't care about
> it.  in fact, it must not contribute to the output y[n].  it *must* be
> forgotten about.  now, we get to have the history of what has been
> happening in the past, then for each and every new sa

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

Samples do not need to be processed in blocks.  You can push and pop them
one by one with no change in cost.  R would be the parameter you're
interested in---the length of the window---while N is the total number of
samples processed.

I describe N separate from R for various reasons.  One of these is
that you *don't
need* to drop samples from the front of the wedge to use the algorithm.
Provided sufficient storage, you can compute min/max information for a
signal of arbitrary length without taking more than O(N) total time.  (The
other reason is that it isn't conventional to think in terms of infinity
when describing algorithm complexity.)

A Lemire wedge describing the range (t-R, t] has all the information you
need to find the min and/or max in any range (t-R+n, t) where 0<n=R,
the complexity will be proportional to N in the worst case.  If your range
encompasses the whole signal, R equals N.  Regardless, the average
computation per sample is bounded by O(1) even in the worst case.  The
worst-case for an individual sample is O(log2(R)).

– Evan Balster
creator of imitone <http://imitone.com>

On Sat, Sep 3, 2016 at 11:49 AM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> sorry to have to get to the basics, but there are no *two* length
> parameters to this alg.  there is only one.
>
>define the streaming real-time input sequence as x[n].  the length of
> this signal is infinite.
>
>output of running max alg is y[n].  the length of this signal is
> infinite.
>
> which is it?:
>
>y[n] = max{ x[n], x[n-1], x[n-2], ... x[n-N+1] }
>
> or
>
>y[n] = max{ x[n], x[n-1], x[n-2], ... x[n-R+1] }
>
> i've been under the impression it's the first one. using "N".  earlier i
> had been under the impression that you're processing R samples at a time,
> like processing samples in blocks of R samples. now i have no idea.
>
>
> r b-j
>
>
>  Original Message 
> Subject: Re: [music-dsp] efficient running max algorithm
> From: "Ross Bencina" <rossb-li...@audiomulch.com>
> Date: Sat, September 3, 2016 3:36 am
> To: music-dsp@music.columbia.edu
> --
>
>
> > On 3/09/2016 5:00 PM, Evan Balster wrote:
> >> Robert: R refers to range ("delay line" size, one could say) and N
> >> refers to signal length.
> >
> > In that case R, is what I've been calling windowSize. and when I say
> > O(1) I mean Evan's O(N).
> >
> > Ross.
> > ___
> > dupswapdrop: music-dsp mailing list
> > music-dsp@music.columbia.edu
> > https://lists.columbia.edu/mailman/listinfo/music-dsp
> >
> >
>
>
> --
>
>
>
>
> r b-j  r...@audioimagination.com
>
>
>
>
> "Imagination is more important than knowledge."
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

Ross' explanation is solid.

Robert:  R refers to range ("delay line" size, one could say) and N refers
to signal length.


Clarifying about the weird linear/binary search:  It's necessary to
maintain O(N) complexity for processing N samples.  This took me a while to
grasp:

If we do a backward linear search (as in the original Lemire algorithm) we
get that O(N) complexity but get an O(R) worst case per sample.  Lemire's
paper explains why the former is the case.

If we do a binary search, we get O(log2(R)) worst case per sample, but the
total complexity is O(N*log2(R)) in the worst case where the signal is
monotonically decreasing---because our wedge will be size R at all times.

If we do a linear search over the first log2(R) samples, though, we get the
best of both worlds:  The Lemire-Fenn algorithm.  The reasoning is that
once we've done log2(R) steps of the linear search, performing a log2(R)
binary search only multiplies the work by a constant factor.  Think of this
as "clamping" the worst-case performance of the search to log2(R) without
increasing the complexity of cheaper search-and-prune operations.

(If anyone can explain that better, I invite them to!)


Re:  Using STL for DSP, I largely agree (though I'll often do it when I can
effectively control allocations).  The GitHub code is suitable for
high-level use and as a reference implementation.

– Evan Balster
creator of imitone <http://imitone.com>

On Sat, Sep 3, 2016 at 12:42 AM, Ross Bencina <rossb-li...@audiomulch.com>
wrote:

> On 3/09/2016 2:14 PM, robert bristow-johnson wrote:
>
>> and in discussing iterators, says nothing about push_back()
>> and the like.
>>
>
> push_back(), push_front(), pop_back(), pop_front() are methods generally
> available on queue-like containers.
>
>
> from online i can get an idea, but it seems to me to be a
>> LIFO stack, not a FIFO buffer.  so a sample value gets pushed onto this
>> thing and pop_back() pops it off, but how does the oldest sample get
>> pushed off the front?  what makes this vector a circular FIFO thingie?
>>
>
> What you're missing is that the code to drop the oldest samples is omitted
> from my example entirely, and is in a separate file in Evan's code.
>
> You're kinda right though, there's a LIFO process that deals with the
> incoming data, and old samples drop off the far end of the queue (FIFO)
> when they age beyond the window size. The running maximum is always at the
> far end of the queue (since the sequence in the queue is decreasing)
>
> In my code, /front/ is the oldest value and /back/ is the newest value.
> The queue only contains the decresing segments, so it's a discontiguous
> history -- the oldest value in the queue is not usually windowSize samples
> old, it's probably newer than that.
>
> Each queue entry is a pair (value, index). The index is some integer that
> counts input samples.
>
> During decreasing segments, (value, index) are pushed on the back of the
> queue. During increasing segments, samples are trimmed off the back. (This
> is the LIFO part)
>
> Samples are dropped off the front when index is older than the current
> input index (This is the FIFO part).
>
>
> that said, the "10 lines of code" is deceptive.  it's 10 lines of code
>> with function calls.  you gotta count the cost of the function calls.
>>
>
> I agree that it's opaque. But a modern C++ compiler will inline everything
> and optimize away most of the overhead. I know this sounds like fanboy
> talk, but the C++ optimizers are surprisingly good these days.
>
> Personally I steer clear of STL for dsp code.
>
>
> now, Ross, this is Evan's diagram (from earlier today), but maybe you
>> can help me:
>>
>>
>> [image: Inline image 3]
>> http://interactopia.com/archive/images/lemire_algorithm.png
>>
>
> I read that with time running from left to right.
>
> The newest samples are added on the right, the oldest samples are dropped
> from the left.
>
> The red segments are the portions stored in the running max history buffer.
>
>
> The algorithm can safely forget anything in grey because it has been
>>> "shadowed" by newer maximum or minimum values.
>>>
>> >
>
>> what is not shown on the diagram is what happens when the current
>> running max value expires (or falls off the edge of the delay buffer)?
>>  when the current max value falls offa the edge, what must you do to
>> find the new maximum over the past N samples?
>>
>
> Let's call the edge "front". That's the leftmost sample in Evan's picture.
> So we expire that one, it falls of the edge, it's no longer there. Notice
> how the stored (red) samples are all in a decreas

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

For one wedge, the worst case is a monotonic signal, which will saturate
the wedge with R samples.

For two wedges, the worst case is the situation where the absolute distance
from previous samples to the latest sample is monotonically decreasing.  In
this case the wedges will contain R+1 samples between them (because the
latest sample always appears in both).

– Evan Balster
creator of imitone <http://imitone.com>

On Fri, Sep 2, 2016 at 12:36 PM, Ethan Duni <ethan.d...@gmail.com> wrote:

> Right aren't monotonic signals the worst case here? Or maybe not, since
> they're worst for one wedge, but best for the other?
>
> Ethan D
>
> On Fri, Sep 2, 2016 at 10:12 AM, Evan Balster <e...@imitone.com> wrote:
>
>> Just a few clarifications:
>>
>> - Local maxima and first difference don't really matter.  The maximum
>> wedge describes global maxima for all intervals [t-x, t], where x=[R-1..0].
>>
>> - If two equal samples are encountered, the algorithm can forget about
>> the older of them.
>>
>> It has been very helpful for my purposes to visualize the algorithm thus:
>>  Imagine drawing lines rightward from all points on the signal.  Those
>> which extend to the present time without intersecting other parts of the
>> signal form the minimum and maximum wedge.  The newest sample, and only the
>> newest sample, exists in both wedges.
>>
>> [image: Inline image 3]
>> http://interactopia.com/archive/images/lemire_algorithm.png
>>
>> The algorithm can safely forget anything in grey because it has been
>> "shadowed" by newer maximum or minimum values.
>>
>> – Evan Balster
>> creator of imitone <http://imitone.com>
>>
>> On Fri, Sep 2, 2016 at 1:50 AM, Ross Bencina <rossb-li...@audiomulch.com>
>> wrote:
>>
>>> On 2/09/2016 4:37 PM, Ross Bencina wrote:
>>>
>>>> When the first difference is positive, the history is trimmed. This is
>>>> the only time any kind of O(N) or O(log2(N)) operation is performed.
>>>> First difference positive implies that a new local maximum is achieved:
>>>> in this case, all of the most recent history samples that are less than
>>>> the new maximum are trimmed.
>>>>
>>>
>>> Correction:
>>>
>>> [The new local maximum dominates all
>>>> history up to the most recent *history sample* that exceeds it, which is
>>>> retained.]
>>>>
>>>
>>> I had said "most recent local maximum" but the history contains a
>>> monotonic non-increasing sequence.
>>>
>>> Ross.
>>>
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>>
>>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

Just a few clarifications:

- Local maxima and first difference don't really matter.  The maximum wedge
describes global maxima for all intervals [t-x, t], where x=[R-1..0].

- If two equal samples are encountered, the algorithm can forget about the
older of them.

It has been very helpful for my purposes to visualize the algorithm thus:
 Imagine drawing lines rightward from all points on the signal.  Those
which extend to the present time without intersecting other parts of the
signal form the minimum and maximum wedge.  The newest sample, and only the
newest sample, exists in both wedges.

[image: Inline image 3]
http://interactopia.com/archive/images/lemire_algorithm.png

The algorithm can safely forget anything in grey because it has been
"shadowed" by newer maximum or minimum values.

– Evan Balster
creator of imitone <http://imitone.com>

On Fri, Sep 2, 2016 at 1:50 AM, Ross Bencina <rossb-li...@audiomulch.com>
wrote:

> On 2/09/2016 4:37 PM, Ross Bencina wrote:
>
>> When the first difference is positive, the history is trimmed. This is
>> the only time any kind of O(N) or O(log2(N)) operation is performed.
>> First difference positive implies that a new local maximum is achieved:
>> in this case, all of the most recent history samples that are less than
>> the new maximum are trimmed.
>>
>
> Correction:
>
> [The new local maximum dominates all
>> history up to the most recent *history sample* that exceeds it, which is
>> retained.]
>>
>
> I had said "most recent local maximum" but the history contains a
> monotonic non-increasing sequence.
>
> Ross.
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

Hey, Robert ---

Check out Lemire's paper, or my summary in the third message in this
thread.  When computing both minimum and maximum over a range of size R and
over N samples, the total computational complexity is bounded by O(N) ---
that is, amortized constant time per sample --- while the worst case for
any sample is O(log2(R)) --- or just O(R) in Lemire's original algorithm.

If you do a binary search every sample, you get O(log2(R)) worst case per
sample but you lose the amortized constant time characteristic.  To keep
that, you need to use a hybrid search as proposed by Ethan here and
implemented in my code.

High frequencies won't really make a difference.  In any case the combined
sizes of the two wedges will never exceed R+1, and will typically be much
smaller.  Feel free to customize the unit test in the GitHub to your
satisfaction if you're doubtful.

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Sep 1, 2016 at 11:52 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> i think i understand the algorithm.  let's assume running max.  you will,
> for each wedge, keep a record of the height and location of the maximum.
>
> and for only two wedges, the wedge that is falling of the edge of the
> delay buffer and the new wedge being formed from the new incoming samples,
> only on those two wedges you need to monitor and update on a
> sample-by-sample basis. as a wedge is created on the front end and as it
> falls offa the back end, you will have to update the value and location of
> the maxima of each of those two wedges.
>
> each time the first derivative (the difference between the most current
> two samples) crosses zero from a positive first difference to a negative
> first difference (which is when you have a maximum), you have to record a
> new wedge, right?
>
> and then you do a binary max tree for the entire set of wedge maxima?  is
> that how it works?
>
> the latter part is O(log2(N)) worst case.  are you expecting a computation
> savings over the straight binary search tree because the number of wedges
> are expected to be a lot less than the buffer length?
>
> if it's a really high frequency signal, you'll have lotsa wedges.  then i
> think there won't be that much difference between the O(log2(N)) worst case
> of this Lemire thing and the O(log2(N)) worst case of a straight binary
> tree.  and the latter has **very** simple self-contained code (which was
> previously posted).
>
> i just wanna know, most specifically, what is the expectation of gain of
> speed (or reduction of execution time) of this Lemire alg over the simpler
> binary tree alg.  it doesn't seem to me to be a lot better for memory
> requirements.
>
>
> --
>
> r b-j  r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
>
>
>  Original Message 
> Subject: Re: [music-dsp] efficient running max algorithm
> From: "Evan Balster" <e...@imitone.com>
> Date: Fri, September 2, 2016 12:12 am
> To: music-dsp@music.columbia.edu
> --
>
> > Hello, all ---
> >
> > Reviving this topic to mention I've created an STL-compatible header
> > implementing what I'm calling the "Lemire-Fenn" algorithm for rolling
> > minimum and maximum:
> >
> > https://github.com/EvanBalster/STL_mono_wedge
> >
> > This was a little pet project I undertook today to familiarize myself
> with
> > Github; the algorithm itself is about ten lines of code, but I've
> > documented it obsessively and run it through a series of unit tests. It's
> > compatible with std::vector, std::deque, and (I imagine) any
> STL-compliant
> > ringbuffer class exposing random-access iterators.
> >
> > Feel free to share any feedback or thoughts about this.
> >
> > – Evan Balster
> > creator of imitone <http://imitone.com>
> >
> > On Thu, Jul 21, 2016 at 10:16 AM, Evan Balster <e...@imitone.com> wrote:
> >
> >> Ahh, smart! Thanks for the insight; I understand now.
> >>
> >> It occurs to me that you could slightly tighten the bound on per-sample
> >> work, because it's not necessary to include the elements of the linear
> >> search in the binary one. The worst-case would then be O(J) per sample,
> >> where J=log2(w-J). But this is a very marginal improvement and it's
> >> difficult to write out the bound in a clearer way.
> >>
> >> – Evan Balster
> >> creator of imitone <http://imitone.com>
> >>
> >> On Thu, Jul 21, 2016 at 7:40 AM,

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

Hello, all ---

Reviving this topic to mention I've created an STL-compatible header
implementing what I'm calling the "Lemire-Fenn" algorithm for rolling
minimum and maximum:

https://github.com/EvanBalster/STL_mono_wedge

This was a little pet project I undertook today to familiarize myself with
Github; the algorithm itself is about ten lines of code, but I've
documented it obsessively and run it through a series of unit tests.  It's
compatible with std::vector, std::deque, and (I imagine) any STL-compliant
ringbuffer class exposing random-access iterators.

Feel free to share any feedback or thoughts about this.

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Jul 21, 2016 at 10:16 AM, Evan Balster <e...@imitone.com> wrote:

> Ahh, smart!  Thanks for the insight; I understand now.
>
> It occurs to me that you could slightly tighten the bound on per-sample
> work, because it's not necessary to include the elements of the linear
> search in the binary one.  The worst-case would then be O(J) per sample,
> where J=log2(w-J).  But this is a very marginal improvement and it's
> difficult to write out the bound in a clearer way.
>
> – Evan Balster
> creator of imitone <http://imitone.com>
>
> On Thu, Jul 21, 2016 at 7:40 AM, Ethan Fenn <et...@polyspectral.com>
> wrote:
>
>> Yeah, with a binary search, you're doing O(log(w)) work, but you might
>> not end up discarding any samples. With the paper's linear search, you
>> might do O(w) work, but only if you end up discarding O(w) samples. So, it
>> turns out to be worth it, as long as you can tolerate the spike.
>>
>> The thinking with the partial linear search is sure, let's spend
>> O(log(w)) time doing a binary search, but only if we first confirm we'll be
>> discarding at least O(log(w)) samples.
>>
>> -Ethan
>>
>>
>>
>>
>> On Wed, Jul 20, 2016 at 6:37 PM, Evan Balster <e...@imitone.com> wrote:
>>
>>> Ethan ---
>>>
>>> If we use only a binary search in the discard step, isn't the amortized
>>> complexity still O(N)?  I suppose not...  We'd be doing a log2(w) search
>>> every sample in the worst case where a monotonic decrease occurs.
>>>
>>> I'll have to look over the paper to get a better understanding, but
>>> would be very interested to hear your thought process with the partial
>>> linear search.
>>>
>>> – Evan Balster
>>> creator of imitone <http://imitone.com>
>>>
>>> On Wed, Jul 20, 2016 at 1:23 PM, Dan Gillespie <
>>> dgilles...@cosineaudio.com> wrote:
>>>
>>>> Regarding the Lemire paper his code is provided here:
>>>> https://github.com/lemire/runningmaxmin
>>>>
>>>> It's been a while since I've read the paper, but iirc it reports fast
>>>> average O(.), not worst case.  Specifically it's good if the signal has few
>>>> changes in direction, but the worst case is not better than other
>>>> algorithms.
>>>>
>>>> Dan Gillespie
>>>>
>>>> ___
>>>> dupswapdrop: music-dsp mailing list
>>>> music-dsp@music.columbia.edu
>>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>>>
>>>>
>>>
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>>
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Oversized FFT windows --- why so little literature?

[Evan Balster]

True, but the "oversizing factor" you suggest isn't a function of window
length.  It's more accurate to say it's a function of window *distribution*.
Whether we oversize or not, the peak "width" in a Gaussian FFT bin's
frequency response is inversely proportional
<http://mathworld.wolfram.com/FourierTransformGaussian.html> to the sigma
value defining the window.  If we choose an excessive sigma, the clipping
*will* limit the severity of this effect, limiting the window's actual time
distribution and making it more like a rectangular one.  But at that point
we are losing out on the advantages of Gaussian windowing.

Realistic analysis applications might choose a sigma value such that the
width of the peak corresponds to one bin, to avoid aliasing effects.  (One
simple scheme would be frequency sigma = 1 bin.)  If we evaluate that peak
based on the expected behavior of an "ideal" (infinite) Gaussian window,
then with sufficient wrap-around we should be able to get a mostly positive
and Gaussian frequency response for each bin without any worries about
aliasing.

– Evan Balster
creator of imitone <http://imitone.com>

On Sun, Aug 28, 2016 at 8:05 PM, Ethan Fenn <et...@polyspectral.com> wrote:

> Perfect reconstruction isn't my interest in oversized windows,
>> either---and I don't believe it would be possible.  My interest is, rather,
>> expanding the available characteristics of window functions for purposes of
>> frequency-domain analysis.  For instance, the frequency response of a bin
>> when using a sufficiently oversized Gaussian window would converge toward a
>> (monotonic) Gaussian function, regardless of the size of the FFT used.  The
>> noise in the frequency response
>> <https://en.wikipedia.org/wiki/Window_function#/media/File:Window_function_and_frequency_response_-_Gaussian_(sigma_%3D_0.4).svg>
>>  of
>> the clipped Gaussian window results from the discontinuity induced by
>> clipping.
>
>
> So that's true, in that the values of the bins you compute will be exactly
> the same as if you had done the full FFT at your larger (oversized) window
> size. So, you get some more precision in those bins "for free" without
> having to do a larger FFT.
>
> The downside is that you're not computing all of the bins at the larger
> window size, so all of the energy that would normally be in those other
> bins goes unaccounted for. If your "oversizing" factor is large enough
> you'll start missing spectral peaks completely.
>
> -Ethan
>
>
>
>
> On Sat, Aug 27, 2016 at 2:14 PM, Evan Balster <e...@imitone.com> wrote:
>
>> Andy:
>>
>> Substituting TeX:
>>
>> So, the value of a DFT bin when using a window of size N is proportional
>>> to:
>>>
>>> \sum_{n=0}^N e^{-i\omega n} W[n]x[t+n-K]
>>>
>>> Where omega is the complex frequency of the bin and K is an arbitrary
>>> time offset.
>>>
>>> We can define any filter we like using this formula:
>>>
>>> y[t] = \sum_{n=0}^N IR[n]x[t+n-K]
>>>
>>> Where IR, length N, is the impulse response of the filter and K is once
>>> again an arbitrary time offset.
>>>
>>> We can express each DFT bin as a different filter using this equivalence:
>>>
>>> IR[n]=e^{-i\omega n} W[n]
>>>
>>
>>
>> Corey:
>>
>> IIR filters don't necessarily improve latency, but there are a number of
>> common designs that are minimum-phase.
>>
>> Perfect reconstruction isn't my interest in oversized windows,
>> either---and I don't believe it would be possible.  My interest is, rather,
>> expanding the available characteristics of window functions for purposes of
>> frequency-domain analysis.  For instance, the frequency response of a bin
>> when using a sufficiently oversized Gaussian window would converge toward a
>> (monotonic) Gaussian function, regardless of the size of the FFT used.  The
>> noise in the frequency response
>> <https://en.wikipedia.org/wiki/Window_function#/media/File:Window_function_and_frequency_response_-_Gaussian_(sigma_%3D_0.4).svg>
>> of the clipped Gaussian window results from the discontinuity induced by
>> clipping.
>>
>> – Evan Balster
>> creator of imitone <http://imitone.com>
>>
>> On Sat, Aug 27, 2016 at 5:25 AM, Corey K <corey...@gmail.com> wrote:
>>
>>> I'm not sure how using IIR filters would improve latency? You still have
>>> to worry about the duration of the filters transient response, no?
>>>
>>> There are also the matters of 1) perfect reconstruction; and, 2)
>>> subsampling that a

Re: [music-dsp] Oversized FFT windows --- why so little literature?

[Evan Balster]

Andy:

Substituting TeX:

So, the value of a DFT bin when using a window of size N is proportional to:
>
> \sum_{n=0}^N e^{-i\omega n} W[n]x[t+n-K]
>
> Where omega is the complex frequency of the bin and K is an arbitrary time
> offset.
>
> We can define any filter we like using this formula:
>
> y[t] = \sum_{n=0}^N IR[n]x[t+n-K]
>
> Where IR, length N, is the impulse response of the filter and K is once
> again an arbitrary time offset.
>
> We can express each DFT bin as a different filter using this equivalence:
>
> IR[n]=e^{-i\omega n} W[n]
>


Corey:

IIR filters don't necessarily improve latency, but there are a number of
common designs that are minimum-phase.

Perfect reconstruction isn't my interest in oversized windows, either---and
I don't believe it would be possible.  My interest is, rather, expanding
the available characteristics of window functions for purposes of
frequency-domain analysis.  For instance, the frequency response of a bin
when using a sufficiently oversized Gaussian window would converge toward a
(monotonic) Gaussian function, regardless of the size of the FFT used.  The
noise in the frequency response
<https://en.wikipedia.org/wiki/Window_function#/media/File:Window_function_and_frequency_response_-_Gaussian_(sigma_%3D_0.4).svg>
of the clipped Gaussian window results from the discontinuity induced by
clipping.

– Evan Balster
creator of imitone <http://imitone.com>

On Sat, Aug 27, 2016 at 5:25 AM, Corey K <corey...@gmail.com> wrote:

> I'm not sure how using IIR filters would improve latency? You still have
> to worry about the duration of the filters transient response, no?
>
> There are also the matters of 1) perfect reconstruction; and, 2)
> subsampling that are often important considerations
>
>
>
> On Sat, Aug 27, 2016 at 12:08 AM, Andy Farnell <padawa...@obiwannabe.co.uk
> > wrote:
>
>>
>> Hi Evan,
>>
>> On Fri, Aug 26, 2016 at 03:17:25PM -0500, Evan Balster wrote:
>> > In the days since my first post, I've had a background train of thought
>> > going on about this...
>> >
>> > So, the value of a DFT bin when using a window of size N is
>> proportional to:
>> > [image: Inline image 2]
>> > Where omega is the complex frequency of the bin and K is an arbitrary
>> time
>> > offset.
>>
>> Its not a strict list etiquette here, but it would be helpful
>> to a whole lot of people and to posterity of archived posts
>> if you might use text. Either TeX or freehand style ascii equations
>> will do fine. Otherwise a whole lot gets lost in translation
>> as you can see above.
>> many thanks
>> Andy Farnell
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Floating-point round-off noise and phase increments

[Evan Balster]

Often, when you find yourself running out of floating-point precision, it's
a signal to change the way you model your information.  In this case, you
have an ever-increasing floating-point variable representing phase.

Generally speaking, phase is a cyclic domain:  0 degrees is equal to 360
degrees.  This has two implications:  First, it is safe to "wrap around"
your phase signal so that it exists within some standard interval such as
[0,2pi), [-pi,pi) or [-1,1).  Doing this will avoid the lower fractional
precision associated with large floating-point values.  Second, there is no
particular reason for values near zero to be more precise than values far
away from it---and within any finite range, fixed-point will yield higher
accuracy than float in the worst-case.

Combining these two points, you could use an unsigned integer phase state
and phase increment, where the full range of the integer is mapped to the
phase cycle.  The integer will wrap around at no cost when it overflows,
and will yield higher accuracy than a float of equivalent size.  The only
caveat is the cost of int-to-float conversion; applications serious enough
to worry over this can typically justify one of the many fast conversion
hacks.


Another "good to know" that can greatly enhance the accuracy of any
*floating-point* sum is Kahan summation
<https://en.wikipedia.org/wiki/Kahan_summation_algorithm>.  It's a far more
accurate way of summing many floats, which comes at a performance cost.
Kahan summation of 32-bit floats quickly becomes more accurate than naive
summation of doubles.

– Evan Balster
creator of imitone <http://imitone.com>

On Fri, Aug 26, 2016 at 9:25 AM, Michael Gogins <michael.gog...@gmail.com>
wrote:

> Multiply not increment.
>
> Not phase += increment but phase = index * increment.
>
> Adding lets the error add up also. Multiplying keeps the error minimal.
>
> On Aug 26, 2016 10:10 AM, "Hanns Holger Rutz" <cont...@sciss.de> wrote:
>
>> Hi there,
>>
>> probably there is some good knowledge about this, so I'm looking for a
>> pointer: I'm currently rewriting some code and I'm wondering about the
>> drift of phase-increment.
>>
>> I.e. I have for example an oscillator or I have a resampling function,
>> each of which needs to trace a fractional phase. So somewhere in some
>> inner loop there is a `phase += phaseIncr` for each sample processed.
>>
>> Now I already encountered some problems, for instance when using an
>> `Impulse` oscillator with a fixed increment of `1.0 / windowSize` for
>> triggering some windowing actions. This goes fine for a while, but for
>> longer sound files or sound productions, inevitably there will be an
>> error compared to the exact phase `framesProcessed * phaseIncr`, so
>> instead of emitting an impulse precisely every `windowSize` samples, it
>> may jump to `windowSize +/- 1`.
>>
>> So I'm tempted to introduce a stabilisation for the case where
>> `phaseIncr` remains constant and one can thus "analytically integrate".
>> Something like
>>
>>   // definitions (pseudo code)
>>
>>   var inPhase0  := 0.0
>>   var inPhaseCount  := 0L
>>   def inPhase   = inPhase0 + inPhaseCount * phaseIncr
>>
>>   For every sample processed, we increent `inPhaseCount`,
>>   and whenever `phaseIncr` changes, we flush first:
>>
>>   inPhase0  := inPhase
>>   inPhaseCount  := 0L
>>
>> So obviously this avoids the drift, but now my thought is that this
>> result in an increases of phase distortion over time, because the 64-bit
>> floating point number needs to use more digits for the pre-decimal point
>> positions. For example, in a sine oscillator, if this runs for an hour
>> or so, will this result in phase distortions and thus a widened spectral
>> line?
>>
>> Perhaps a compromise is to "flush" from time to time?
>>
>> Thanks, ..h.h..
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] idealized flat impact like sound

[Evan Balster]

The most essentially flat signal is a delta function or impulse, which is
also phase-aligned.  Apply any all-pass filter or series thereof to the
impulse, and the fourier transform over infinite time will remain flat.  I
recommend investigating Schroeder filters.

– Evan Balster
creator of imitone <http://imitone.com>

On Sat, Jul 30, 2016 at 5:39 PM, gm <g...@voxangelica.net> wrote:

> I think it's interesting for instance for early echoes in a reverb.
> For longer sequences it seems to become very self-similar?
>
> I only looked into the thing under "Additive recurrence", the rest is
> totally above my head, and played around with this a little bit, since it's
> basically a random number generator with "bad parameters" there.
> I tried similar things before with the golden ratio, bascially even the
> same thing I just realize.
> Like panning in a seemingly random fashion with golden ratio mod 1.
>
> With little sucess in reverbs, though, for instance most of the time it's
> not a great
> idea to just tune delay lengths to golden ratios...
>
> But maybe it's useful for setting delay lengths in a different way?
>
> Just seeing the similarity between a classical reverb algorithm and random
> number generators
> with the feedback loop acting as mod operator.. didn't see it like that
> before
>
> Did anybody build a reverb based on a random generator algorithm?
> Or are reverbs just that and it just never occured to me?
>
> What I also wonder is the difference between a sequence like that (or any
> random sequence)
> and a sequence thats synthesized with FFT to be flat but with random
> phases.
> I wonder what's better in terms of what and why, when it comes to reverb
> and/or convolution,
>
>
>
> Am 30.07.2016 um 19:57 schrieb Patric Schmitz:
>
>> Hi,
>>
>> On 07/28/2016 08:43 PM, gm wrote:
>>
>>> My problem was that a short segment of random isn't spectrally
>>> straigh-line flat.
>>>
>> On 07/30/2016 07:22 PM, gm wrote:
>>
>>> Just a short sequence of random numbers really exhibits large
>>> formant like fluctuations .
>>>
>> I tried following this discussion even though, admittedly, most
>> of it is way over my head. Still, I wonder if the problem of
>> short random sample sets being too non-uniformly distributed
>> could be alleviated somehow, by not using white noise for the
>> samples, but what they call a low-discrepancy quasi- or subrandom
>> sequence of numbers.
>>
>>> https://en.wikipedia.org/wiki/Low-discrepancy_sequence
>>>
>> I heard about them in a different context, and it seems their
>> main property is that they converge against the equally
>> distributed limit distribution much quicker than true random
>> samples taken from that distribution. Maybe they could be useful
>> here to get a spectrally more flat distribution with a fewer
>> number of samples?
>>
>> As said, I'm by far no expert in the field and most of what has
>> been said is above my level of understanding, so please feel free
>> to discard this as utter nonsense!
>>
>> Best regards,
>> Patric Schmitz
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Supervised DSP architectures (vs. push/pull)

[Evan Balster]

Here's my current thinking.  Based on my current and foreseeable future
use-cases, I see just a few conditions that would play into automatic
prioritization:

   - (A) Does the DSP depend on a real-time input?
   - (B) Does the DSP factor into a real-time output?
   - (C) Does the DSP produce side-effects?  (EG. observers, sends to
   application thread)

Any chain of effects with exactly one input and one output could be grouped
into a single task with the same priority.  Junction points whose sole
input or sole output is such a chain could also be part of it.

This would yield a selection of DSP jobs which would be, by default,
prioritized thus:

   1. A+B+C
   2. A+B
   3. A+C
   4. B+C
   5. B
   6. C

Any DSPs which do not factor into real-time output or side-effects could
potentially be skipped (though it's worth considering that DSPs will
usually have state which we may want updating).

It is possible that certain use-cases may favor quick completion of
real-time processing over latency of observer data.  In that case, the
following scheme could be used instead:

   1. A+B (and A+B+C)
   2. B+C
   3. B
   4. A+C
   5. C

(Where steps 4 and 5 may occur after the callback has been satisfied)

To make the prioritization more flexible, individual DSPs could be assigned
priority values above, below or between the automatic ones.  The priority
of a chain would be the priority of its most essential element, and chains
whose inputs have not yet been computed could be withheld from the priority
queue until such time as they are ready for processing.

Note that I haven't made much consideration toward scratch memory in the
scheme above.  The reason for this is that, as I'm realizing, the temporary
memory needs of even a complex DSP tree are small compared to permanent
memory such as samples, delay lines, et cetera.  As I'm learning recently,
cache coherency gains from memory re-use are typically most relevant within
small pieces of code.  If anyone has evidence to the contrary, though, I'd
love to see it.

– Evan Balster
creator of imitone <http://imitone.com>

On Sun, Jul 31, 2016 at 3:55 PM, Ethan Fenn <et...@polyspectral.com> wrote:

> A few years ago I built a mixing engine for games. Some aspects of the
> design sound similar to what you're thinking about.
>
> Every audio frame (I think it was every 256 samples at 48k), the
> single-threaded "supervisor" would wake up and scan the graph of audio
> objects, figuring out what needed doing and what the dependencies were. As
> its output it produced a vector of "job" structures, describing the dsp to
> take place, where to pull the input and settings from and where to write
> the output. Then the pool of worker threads would wake up, pluck jobs one
> by one from the front of array and get to work on them.
>
> I did it this way partly because one of the target platforms was the PS3
> with the Cell processor, and this was the preferred programming model for
> using the SPE's, the auxiliary computation cores of the Cell. But it mapped
> just fine onto other platforms.
>
> I didn't have any notion of "priority" -- everything in the graph just
> needed to get done every frame. My synchronization model was also pretty
> crude. When there were any dependencies on previous steps, I would insert a
> fence into the job vector, and workers reaching the fence would just wait
> until all the previous jobs were complete before moving on. Not the most
> flexible structure for sure, but I could get away with it because my mixing
> graphs were wide rather than deep -- a lot of sound effects playing at
> once, but only very few mix/effect buses. So all of the sound effect
> processing would get parallelized perfectly, which was really all I needed
> for my needs.
>
> This kind of model is too simple for lots of applications, and it may not
> do what you need. But I'd strongly recommend thinking about what your
> typical graphs are going to look like and about what the simplest possible
> supervisor would be that would handle that kind of graph well. Writing a
> perfect general scheduler is something you could easily spend 100% of your
> time doing if you wanted to, and you probably don't!
>
> -Ethan
>
>
> On Thu, Jul 28, 2016 at 4:46 PM, Evan Balster <e...@imitone.com> wrote:
>
>> Haha, Ross, I'm not sure I'll be going *quite* so deep just yet.
>>
>> My most pressing need is simply to access more processing power than one
>> callback will give me (without underflow).  To that end, I'll be setting up
>> a signaling system whereby one stream can have "helper threads" that are
>> notified when new input is available and do their best to keep output
>> available.  For the first implementation I'll permit the slave thread's
>> output to have higher late

Re: [music-dsp] Supervised DSP architectures (vs. push/pull)

[Evan Balster]

Haha, Ross, I'm not sure I'll be going *quite* so deep just yet.

My most pressing need is simply to access more processing power than one
callback will give me (without underflow).  To that end, I'll be setting up
a signaling system whereby one stream can have "helper threads" that are
notified when new input is available and do their best to keep output
available.  For the first implementation I'll permit the slave thread's
output to have higher latency...  Easy job.

>From there, I'm interested in starting with a single-threaded supervisor
which can break the processing graph into chunks and run them according to
a simple prioritization scheme* while keeping the amount of scratch-memory
used within reasonable bounds.  In my current system, most DSPs just
operate on their output buffer, and a scratch-memory stack is made
available for any temporary allocations in the rendering tree...  That will
need to change, though.

Later on, though, I may very well investigate a supervisor with multi-core
capabilities.  (I certainly want to get a better grip on multi-threaded
scheduling for purposes outside DSP.)  I've relied thus far on a small
number of handy lock-free abstractions** to synchronize state in my audio
framework, but for things like worker threads I want to get a grip on the
practicalities of using things like condition variables in a low-latency
DSP system.

– Evan Balster
creator of imitone <http://imitone.com>

* I expect a "simple prioritization scheme" to prioritize different parts
of the graph depending on whether their inputs and/or outputs lead to
real-time or non-real-time sources or sinks.  For instance, a microphone
level metric might be quite high, while a synthesizer that feeds into a
recorder (and not the speakers) would be very low.


On Thu, Jul 28, 2016 at 12:20 AM, Ross Bencina <rossb-li...@audiomulch.com>
wrote:

> Hi Evan,
>
> Greetings from my little cave deep in the multi-core scheduling rabbit
> hole! If multi-core is part of the plan, you may find that multicore
> scheduling issues dominate the architecture. Here are a couple of starting
> points:
>
> Letz, Stephane; Fober, Dominique; Orlarey, Yann; P.Davis,
> "Jack Audio Server: MacOSX port and multi-processor version"
> Proceedings of the first Sound and Music Computing conference – SMC’04,
> pp. 177–183, 2004.
> http://www.grame.fr/ressources/publications/SMC-2004-033.pdf
>
> CppCon 2015: Pablo Halpern “Work Stealing"
> https://www.youtube.com/watch?v=iLHNF7SgVN4
>
> Re: prioritization. Whether the goal is lowest latency or highest
> throughput, the solutions come under the category of Job Shop Scheduling
> Problems. Large classes of multi-worker multi-job-cost scheduling problems
> are NP-complete. I don't know where your particular problem sits. The Work
> Stealing schedulers seem to be a popular procedure, but I'm not sure about
> optimal heuristics for selection of work when there are multiple possible
> tasks to select -- it's further complicated by imperfect information about
> task cost (maybe the tasks have unpredictable run time), inter-core
> communication costs etc.
>
> Re: scratch storage allocation. For a single-core single-graph scenario
> you can use graph coloring (same as a compiler register allocator). For
> multi-core I guess you can do the same, but you might want to do something
> more dynamic. E.g. reuse a scratch buffer that is likely in the local CPUs
> cache.
>
> Cheers,
>
> Ross.
>
>
>
> On 28/07/2016 5:38 AM, Evan Balster wrote:
>
>> Hello ---
>>
>> Some months ago on this list, Ross Bencina remarked about three
>> prevailing "structures" for DSP systems:  Push, pull and *supervised
>> architectures*.  This got some wheels turning, and lately I've been
>> confronted by the need to squeeze more performance by adding multi-core
>> support to my audio framework.
>>
>> I'm looking for wisdom or reference material on how to implement a
>> supervised DSP architecture.
>>
>> While I have a fairly solid idea as to how I might go about it, there
>> are a few functions (such as prioritization and scratch-space
>> management) which I think are going to require some additional thought.
>>
>> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] Supervised DSP architectures (vs. push/pull)

[Evan Balster]

Hello ---

Some months ago on this list, Ross Bencina remarked about three prevailing
"structures" for DSP systems:  Push, pull and *supervised architectures*.
This got some wheels turning, and lately I've been confronted by the need
to squeeze more performance by adding multi-core support to my audio
framework.

I'm looking for wisdom or reference material on how to implement a
supervised DSP architecture.

While I have a fairly solid idea as to how I might go about it, there are a
few functions (such as prioritization and scratch-space management) which I
think are going to require some additional thought.


*Background on my use case*:  (optional reading)

I have a mature audio processing framework that I use in a number of
applications.  (I may open-source it in the future.)

   - *imitone*, which performs low-latency, CPU-intensive audio analysis.
   I plan on adding support for signaled multi-core processing for users who
   want to process many voices from a single device.

   - *SoundSelf*, a VR application which places excessive demands on audio
   rendering with close to a thousand DSPs routinely operating in the output
   stream.  (The sound designer has free reign and uses it!)  The application
   also uses one or more input streams which may be ring-buffered to output.
   I plan on adding worker threads for less latency-sensitive audio.

My current architecture is pull-based:  The DSP graph assumes a tree
structure, where each unit encapsulates both DSP and state-synchronization,
and "owns" its inputs, propagating sync events and pulling audio as needed.

This scheme has numerous inelegances and limitations.  To name a few:
 Analysis DSP requires that audio be routed through to a sink, a "splitter"
mechanism must be used to share a source between multiple consumers, and
all units' audio formats must be fixed throughout their lifetimes.  It is
not directly possible to insert DSPs into a chain at run-time, or to
migrate the graph to a different stream.

Thinking about a supervised architecture, I can see how I might be able to
solve all these problems and more.  By building a rendering and state
manager, I can reduce the implementation burden involved in building new
DSPs, prioritize time-sensitive processing and skip unnecessary work.
Lastly, it could help me to build much more elegant and robust multi-steam
and multi-core processing mechanisms.

I would be very interested to hear from others who have used this type of
architecture:  Strengths, weaknesses, gotchas, et cetera.

– Evan Balster
creator of imitone <http://imitone.com>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Are kalman filters used often in music or audio DSP?

[Evan Balster]

Hey, Alan ---

When we talk about filters in audio, we're usually talking about some
variation on "linear time-invariant filters"
<https://en.wikipedia.org/wiki/Linear_filter> used to alter signal content
based on frequency.  Typically, these are processes where each output
sample is a weighted sum of some number past input samples.  The weighting
determines the effect the filter will have on different frequencies in the
signal.

Kalman filters <https://en.wikipedia.org/wiki/Kalman_filter> are a
different beast entirely.  Instead of operating on signals, these operate
on probability distributions.  And instead of summing past inputs, Kalman
filters *multiply* probability distributions in order to refine estimates
and convolve them in order to account for various sources of uncertainty:
their inputs and outputs must be distributions rather than scalar signals.
If the factors governing these changes, the "process noise" and
"measurement noise", do not change over time, a Kalman filter will
eventually behave just like a trivial low-pass filter
<https://en.wikipedia.org/wiki/Low-pass_filter#Discrete-time_realization> with
regard to the mean-value of its input and output.  But in the general case
it is much more dynamic.

For practical purposes, we use Kalman filters when we want to get a "best
guess" at the mean value of a variable based on noisy data.  We use linear
filters when we want to adjust the frequency content of a signal, or
introduce phase shift or delay.

– Evan Balster
creator of imitone <http://imitone.com>

On Sun, Jul 24, 2016 at 12:41 AM, Alan Wolfe <alan.wo...@gmail.com> wrote:

> I've read about kalman filters being used in dsp for things like flight
> controls.
>
> I was wondering though, do they have much use in audio and/or music
> applications?
>
> Thanks!!
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

Ahh, smart!  Thanks for the insight; I understand now.

It occurs to me that you could slightly tighten the bound on per-sample
work, because it's not necessary to include the elements of the linear
search in the binary one.  The worst-case would then be O(J) per sample,
where J=log2(w-J).  But this is a very marginal improvement and it's
difficult to write out the bound in a clearer way.

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Jul 21, 2016 at 7:40 AM, Ethan Fenn <et...@polyspectral.com> wrote:

> Yeah, with a binary search, you're doing O(log(w)) work, but you might not
> end up discarding any samples. With the paper's linear search, you might do
> O(w) work, but only if you end up discarding O(w) samples. So, it turns out
> to be worth it, as long as you can tolerate the spike.
>
> The thinking with the partial linear search is sure, let's spend O(log(w))
> time doing a binary search, but only if we first confirm we'll be
> discarding at least O(log(w)) samples.
>
> -Ethan
>
>
>
>
> On Wed, Jul 20, 2016 at 6:37 PM, Evan Balster <e...@imitone.com> wrote:
>
>> Ethan ---
>>
>> If we use only a binary search in the discard step, isn't the amortized
>> complexity still O(N)?  I suppose not...  We'd be doing a log2(w) search
>> every sample in the worst case where a monotonic decrease occurs.
>>
>> I'll have to look over the paper to get a better understanding, but would
>> be very interested to hear your thought process with the partial linear
>> search.
>>
>> – Evan Balster
>> creator of imitone <http://imitone.com>
>>
>> On Wed, Jul 20, 2016 at 1:23 PM, Dan Gillespie <
>> dgilles...@cosineaudio.com> wrote:
>>
>>> Regarding the Lemire paper his code is provided here:
>>> https://github.com/lemire/runningmaxmin
>>>
>>> It's been a while since I've read the paper, but iirc it reports fast
>>> average O(.), not worst case.  Specifically it's good if the signal has few
>>> changes in direction, but the worst case is not better than other
>>> algorithms.
>>>
>>> Dan Gillespie
>>>
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>>
>>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] efficient running max algorithm

[Evan Balster]

Ethan ---

If we use only a binary search in the discard step, isn't the amortized
complexity still O(N)?  I suppose not...  We'd be doing a log2(w) search
every sample in the worst case where a monotonic decrease occurs.

I'll have to look over the paper to get a better understanding, but would
be very interested to hear your thought process with the partial linear
search.

– Evan Balster
creator of imitone <http://imitone.com>

On Wed, Jul 20, 2016 at 1:23 PM, Dan Gillespie <dgilles...@cosineaudio.com>
wrote:

> Regarding the Lemire paper his code is provided here:
> https://github.com/lemire/runningmaxmin
>
> It's been a while since I've read the paper, but iirc it reports fast
> average O(.), not worst case.  Specifically it's good if the signal has few
> changes in direction, but the worst case is not better than other
> algorithms.
>
> Dan Gillespie
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] up to 11

[Evan Balster]

The power of a digital signal is proportional to the mean-square of its
samples.  We can't hear DC (zero-frequency content) and we can compensate
for that by subtracting the squared mean of the samples from the power
measurement.  If we wanted to maximize that value, a sensible approach
would be to generate a sound which uses only the highest and lowest sample
values in equal quantities, such as a 100%-depth square wave.  (Obviously
output filters can throw a wrench in this.)

Our next concern would be concentrating as much energy as possible into the
3K-4K frequency range and other dips in the loudness curve.  PWM is your
friend here---you can transform
<https://en.wikipedia.org/wiki/Delta-sigma_modulation> a real signal into a
binary one, and the extraneous content will all lie at higher frequencies
(though these may alias).  Given the lower sensitivity of the ear *to*
those higher frequencies, though, it's hard to say whether this is an
optimal strategy.



Lastly, I recall reading somewhere that there are two major resonant
frequencies of the ear canal are related by a ratio close to 2.  There
might be a way to make a harmonic sound that hits both of them, but then
you don't see two dips in the equal-loudness contour so that might not be
right.


A more interesting line of thought is this:  Given a signal which has been
amplified as much as possible without exceeding the signal range, how can
we raise its power by a factor of N while incurring minimal distortion?
Can the minimum degree of distortion (as expressed by some admissible
metric thereof) be bounded as a function of N?  Has anyone experimented
with algorithms that achieve this through adaptive phase shifting or other
means?

– Evan Balster
creator of imitone <http://imitone.com>

On Tue, Jun 21, 2016 at 11:10 AM, Alan Wolfe <alan.wo...@gmail.com> wrote:

> In case you don't get any other responses, in Andy Farnell's book
> "Designing Sound" there is a section on psycho-acoustics that I'm reading
> right now that I think may be able to answer this question.
>
> I don't understand enough of it to answer it for you, but it is talking in
> great detail about this sort of thing.
>
> It also mentions for instance how you can increase the perceived loudness
> of a sound (It might only work for sounds which are already short?) by
> making it slightly longer.  Apparently that works for up to about 200ms of
> stretch time.
>
> A really good read!
> https://mitpress.mit.edu/books/designing-sound
>
> On Tue, Jun 21, 2016 at 8:51 AM, Ethan Fenn <et...@polyspectral.com>
> wrote:
>
>> Purely for amusement and edification:
>>
>> Let's say I wanted to make a one second, 44.1/16 mono wav file which was
>> as loud as it could possibly be.
>>
>> The only real results I know about loudness are the equal loudness
>> contours, which suggest I should put as much energy as possible in the
>> region around 3-4kHz, although the whole mid/high-mid band is pretty
>> effective.
>>
>> But, those contours are really about pure sine tones... I don't know
>> anything about the relative loudness of tones vs. noise. There's also the
>> question of how to pack as much energy as possible into the sensitive bands
>> without exceeding the limited signal range.
>>
>> What would your approach be?
>>
>> -Ethan
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] R: Anyone using unums?

[Evan Balster]

Ethan:  Take care not to overlook the solution proposed for SORN size:
 Yes, a comprehensive SORN for the set of N-bit unums takes 2^N bits.  But
in most practical applications we'll use SORNS representing continuous
ranges of unums on the "circle" (which may cross infinity).  As the author
notes, common operations (+-*/^) on continuous ranges produces another
continuous range.  We can represent these ranges with 2N bits which are
homologous to two unums, where the range is the clockwise path from the
first to the second.*  (I'll confess this took me a while to understand as
the presentation doesn't explain it clearly.)

To operate on practical (range) SORNs, we simply need to apply the
operation to each range, such that the new range is the union of all
possible results.  We can define this in terms of operator implementations
which yield the "most clockwise" and "least clockwise" results given the
four argument values.  So a SORN addition (a+b) would yield (a.min+b.min,
a.max+b.max).

All this said, I won't necessarily disagree with the "snake oil and
conspiracy theories" argument yet -- but *if this system can be made into
something practical* it would certainly yield some interesting benefits.
Even if it can't, perhaps it can inspire something better.


* In the case of the complete set and the zero set, the two halves of the
range equal; in this case we would want to use an odd or even MSB, or some
other pattern, to distinguish between the special cases.

– Evan Balster
creator of imitone <http://imitone.com>

On Fri, Apr 15, 2016 at 9:38 AM, Ethan Fenn <et...@polyspectral.com> wrote:

> Sorry, you don't need 2^256 bits, my brain was just getting warmed up and
> I got ahead of myself there. There are 2^256 different SORNs in this
> scenario and you need 256 bits to represent them all. But the point stands
> that if you actually want good precision (2^32 different values, for
> instance), the SORN concept quickly becomes untenable.
>
> -Ethan
>
>
>
> On Fri, Apr 15, 2016 at 9:03 AM, Ethan Fenn <et...@polyspectral.com>
> wrote:
>
>> I really don't think there's a serious idea here. Pure snake oil and
>> conspiracy theory.
>>
>> Notice how he never really pins down one precise encoding of unums...
>> doing so would make it too easy to poke holes in the idea.
>>
>> For example, this idea of SORNs is presented, wherein one bit represents
>> the presence or absence of a particular value or interval. Which is fine if
>> you're dealing with 8 possible values. But if you want a number system that
>> represents 256 different values -- seems like a reasonable requirement to
>> me! -- you need 2^256 bits to represent a general SORN. Whoops! But of
>> course he bounces on to a different topic before the obvious problem comes
>> up.
>>
>> -Ethan
>>
>>
>>
>> On Fri, Apr 15, 2016 at 4:38 AM, Marco Lo Monaco <
>> marco.lomon...@teletu.it> wrote:
>>
>>> I read his slides. Great ideas but the best part is when he challenges
>>> Dr. Kahan with the star trek trasing/kidding. That made my day.
>>> Thanks for sharing Alan
>>>
>>>
>>>
>>> Inviato dal mio dispositivo Samsung
>>>
>>>
>>>  Messaggio originale 
>>> Da: Alan Wolfe <alan.wo...@gmail.com>
>>> Data: 14/04/2016 23:30 (GMT+01:00)
>>> A: A discussion list for music-related DSP <music-dsp@music.columbia.edu>
>>>
>>> Oggetto: [music-dsp] Anyone using unums?
>>>
>>> Apologies if this is a double post.  I believe my last email was in
>>> HTML format so was likely rejected.  I checked the list archives but
>>> they seem to have stopped updating as of last year, so posting again
>>> in plain text mode!
>>>
>>> I came across unums a couple weeks back, which seem to be a plausible
>>> replacement for floating point (pros and cons to it vs floating
>>> point).
>>>
>>> One interesting thing is that division is that addition, subtraction,
>>> multiplication and division are all single flop operations and are on
>>> "equal footing".
>>>
>>> To get a glimpse, to do a division, you do a 1s compliment type
>>> operation (flip all bits but the first 1, then add 1) and you now have
>>> the inverse that you can do a multiplication with.
>>>
>>> Another interesting thing is that you have different accuracy
>>> concerns.  You basically can have knowledge that you are either on an
>>> exact answer, or between two exact answers.  Depending on how you

Re: [music-dsp] Anyone using unums?

[Evan Balster]

This is *really* interesting; thanks for bringing it up and expanding my
world a little, Alan.  While it's a little difficult to put the concepts
here to practice, they have my brain spinning in some new directions.  I'm
curious as to whether there's some lattice whose operations could be easily
and robustly implemented with standard arithmetic and bitwise
operations...  I'm also driven to wonder whether error in non-independent
variables could be mitigated with some kind of matrix representation,
similar to the ellipsoid matrix form or covariance matrix.

Tangentally, I read some slides
<http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf>
about the previous unum format, which seems to describe a "meta-float" with
very different characteristics that the ones here.  That format's design
seems to be motivated by the way most software is bandwidth-limited rather
than processing-limited these days; while the designer seems to think that
"garbage collection and bit addressability" would be a necessity of
implementation, I suspect it would be more practical to maintain unums at
"full" size in memory and only transmit the relevant bits when sending them
over serial connections.  It goes without saying that such would require
new bus protocols / memory controllers / etc...

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Apr 14, 2016 at 7:57 PM, Nigel Redmon <earle...@earlevel.com> wrote:

> Interesting, thanks for pointing it out (and yes, your first message made
> it here—the list is more forgiving about html text formatting these days).
>
> Interesting stuff, so i was curious if anyone here on the list has heard
> of them, has used them for dsp, etc?
>
>
> I’m thinking it’s not likely that people here are using them for DSP—I
> only had time to glance, but no hardware support yet, right? We usually
> need to do things with more speed than precision and accuracy  ;-)
>
> Also, it seems like a hard sell to be put in common (cheap) processors.
> It’s not the average bit-length that's important—there’s a big speed
> advantage for hardware if the the storage size and format is uniform. Plus,
> this becomes incompatible with all computers in the worldwide installed
> base. Intel comes out with a new processor—it would need to handle the old
> and new, for a long time.
>
> Worse, if you write new software using unums, it will run on a small
> number of computers—so what do you do, write in both (or develop compilers
> that can spit out both)? For 99+% of applications, there would be little
> motivation to leave the current format—after all, you don’t need the new
> benefits, and the new processors must support the old format anyway. And if
> emulation were good enough, you probably didn’t need the advantages of
> unums to start.
>
> For audio DSP, numerical accuracy is an issue, but rarely when using
> double precision (and such cases can be avoided pretty easily). And the
> same is true for most applications I can think of. Maybe for big computers
> for certain uses, and those are already expensive and have custom software.
> Still unlikely to trickle down.
>
> Again, I only glanced, so tell me if I’m missing something.
>
> tl;dr: Seems a tough sell to change the hardware, for mainstream
> computing, with insufficient motivation from software needs.
>
>
> On Apr 14, 2016, at 2:23 PM, Alan Wolfe <alan.wo...@gmail.com> wrote:
>
> I came across unums a couple weeks back, which seem to be a plausibe
> replacement for floating point (pros and cons to it vs floating point).
>
> One interesting thing is that division is that addition, subtraction,
> multiplication and division are all single flop operations and are on
> "equal footing".
>
> To get a glimpse, to do a division, you do a 1s compliment type operation
> (flip all bits but the first 1, then add 1) and you now have the inverse
> that you can do a multiplication with.
>
> Another interesting thing is that you have different accuracy concerns.
> You basically can have knowledge that you are either on an exact answer, or
> between two exact answers.  Depending on how you set it up, you could have
> the exact answers be inegral multiples of some fraction of pi, or whatever
> else you want.
>
> Interesting stuff, so i was curious if anyone here on the list has heard
> of them, has used them for dsp, etc?
>
> Fast division and the lack of denormals seem pretty attractive.
>
> http://www.johngustafson.net/presentations/Multicore2016-JLG.pdf
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] High quality really broad bandwidth pinknoise (ideally more than 32 octaves)

[Evan Balster]

As was mentioned earlier, the top-octave scale is 2^16 times the
bottom-octave scale (actually 2^(31/2) to be pedantic).  Pink noise halves
in *power* each octave, not amplitude.  I remark because I made the same
mistake in reasoning earlier.

– Evan Balster
creator of imitone <http://imitone.com>

On Tue, Apr 12, 2016 at 7:07 AM, Stefan Stenzel <
stefan.sten...@waldorfmusic.de> wrote:

> Seth,
>
> Did you consider my pink noise implementation
> https://github.com/Stenzel/newshadeofpink ?
>
> There is one implementation with 20 octaves in pink-low.h - doing much
> more octaves would require to rewrite it using double precision.
> Spectrum of generated noise is not yet perfect but slightly bettern than
> all methods with filtered white noise I have seen so far.
>
> In case you really want 32 octaves you would need double precision anyway
> because the scale of your highest band is roughly 2^-32 times your lowest
> band and there is no way the 23-bit mantissa of a single precision float
> can properly handle this.
>
> Stefan
>
>
> > On 11 Apr 2016, at 18:57 , Seth Nickell <snick...@gmail.com> wrote:
> >
> > I'm applying an iterative function to an input signal, in this instance
> pinknoise. Because of the iteration, spectral characteristics in input
> signals tend to "blow up" really quickly, so I'm looking for a really high
> bandwidth and high quality source of pink noise.
> >
> > My understanding is that most of the approaches like the supercollider
> PinkNoise.ar ugen are mostly accurate, but over a limited bandwidth. As the
> number of octaves grows, the accurcary drops. Is my understanding correct?
> >
> > I'm hoping to find a way to generate pink noise that is:
> > 1) Accurate over an arbitrarily wide bandwidth, at least 32 octaves
> > 2) Tractable to generate an arbitrarily large number of samples
> (billions, so can't fft the whole thing in one pass)
> >
> > Any suggestions? I've read through
> http://www.firstpr.com.au/dsp/pink-noise/#Pseudo, but everyone seems
> focused on fast-generation of pink noise of moderate quality and a
> relatively narrow bandwidth. I'm sort of looking for the other side of
> things... what's the most ideal pink noise I can generate en masse?
> >
> > Thanks,
> > -Seth
> > ___
> > dupswapdrop: music-dsp mailing list
> > music-dsp@music.columbia.edu
> > https://lists.columbia.edu/mailman/listinfo/music-dsp
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] High quality really broad bandwidth pinknoise (ideally more than 32 octaves)

[Evan Balster]

I haven't yet come across an automated process for designing high-quality
pinking filters, so if someone can offer one up I'd also love to hear about
it!

Seth -- as you say, "the error from 1/f can't be corrected by increasing
the number of iterations".  Adding octaves to the Voss-McCartney algorithm
only lowers its bottom frequency.  But do consider my suggestion above...
The ripple in VM noise has a logarithmic periodicity of 1 octave in the
frequency domain...  You could eliminate it by way of destructive
interference if you generate the pink noise at equally-spaced sampling
rates between N (inclusive) and 2N (exclusive).  With this approach you
could get an arbitrarily flat slope -- if you're willing to pay the cost!

Your project sounds totally bonkers, but I'll give you the benefit of the
doubt on that.  :)

– Evan Balster
creator of imitone <http://imitone.com>

On Mon, Apr 11, 2016 at 6:59 PM, Seth Nickell <snick...@gmail.com> wrote:

> Hi Robert,
>
> I know very little about filter design (hazy undergrad memories, you know
> the type), is this something I could sanely rig for myself, or is that
> total madness as a filter novice? Could you point me toward the right terms
> I need to read up about to learn more about this?
>
> -Seth
>
> On Mon, Apr 11, 2016 at 10:47 AM robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>> being that this is a discussion group about music, which is a subset of
>> audio.  and being that our hearing is at best 10 or 11 octaves, why do you
>> need 32 octaves?
>>
>> and then how closely, in dB, does your pink noise need to conform to the
>> 1/f power spectrum?  +/- 0.1 dB?  0.01 dB?
>>
>> all this can be done with a good white noise source and a filter
>> alternating real poles and real zeros placed at just the right values.  for
>> 32 octaves, i would hate to guess how many pole/zero pairs you would need.
>>  maybe 10.
>>
>>
>>
>> r b-j
>>
>>
>>  Original Message 
>> Subject: [music-dsp] High quality really broad bandwidth pinknoise
>> (ideally more than 32 octaves)
>> From: "Seth Nickell" <snick...@gmail.com>
>> Date: Mon, April 11, 2016 12:57 pm
>> To: music-dsp@music.columbia.edu
>> --
>>
>>
>>
>> > I'm applying an iterative function to an input signal, in this instance
>> > pinknoise. Because of the iteration, spectral characteristics in input
>> > signals tend to "blow up" really quickly, so I'm looking for a really
>> high
>> > bandwidth and high quality source of pink noise.
>> >
>> > My understanding is that most of the approaches like the supercollider
>> > PinkNoise.ar ugen are mostly accurate, but over a limited bandwidth. As
>> the
>> > number of octaves grows, the accurcary drops. Is my understanding
>> correct?
>> >
>> > I'm hoping to find a way to generate pink noise that is:
>> > 1) Accurate over an arbitrarily wide bandwidth, at least 32 octaves
>> > 2) Tractable to generate an arbitrarily large number of samples
>> (billions,
>> > so can't fft the whole thing in one pass)
>> >
>> > Any suggestions? I've read through
>> > http://www.firstpr.com.au/dsp/pink-noise/#Pseudo, but everyone seems
>> > focused on fast-generation of pink noise of moderate quality and a
>> > relatively narrow bandwidth. I'm sort of looking for the other side of
>> > things... what's the most ideal pink noise I can generate en masse?
>> >
>> > Thanks,
>> > -Seth
>>
>>
>> --
>>
>> r b-j  r...@audioimagination.com
>>
>> "Imagination is more important than knowledge."
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] High quality really broad bandwidth pinknoise (ideally more than 32 octaves)

[Evan Balster]

Hey, Seth --

Check out the Voss-McCartney algorithm on that page.  It's wonderfully
cheap and you can extend it to as many octaves as you like without an
increase in operations per sample.  Obviously the resulting noise isn't
perfect -- it's a little distorted near Nyquist and has some ripple between
the "octaves" of white noise -- but additional octaves do not (as far as I
understand) degrade quality.

The ripple could be mitigated by mixing independent sources of pink noise
generated at different sampling rates between N and 2N, and the top-end
could be fixed (if necessary) by a process of high-quality downsampling.
Combining these solutions, one could imagine an process whereby we generate
wideband white noise using the Voss-McCartney algorithm at rates of, say,
96K, 112K, 128K, 144K, 160K and 176K, apply a high-quality downsampling
algorithm to produce 48K versions, then amplify and mix them according to
the -3dB trend.

– Evan Balster
creator of imitone <http://imitone.com>

On Mon, Apr 11, 2016 at 11:57 AM, Seth Nickell <snick...@gmail.com> wrote:

> I'm applying an iterative function to an input signal, in this instance
> pinknoise. Because of the iteration, spectral characteristics in input
> signals tend to "blow up" really quickly, so I'm looking for a really high
> bandwidth and high quality source of pink noise.
>
> My understanding is that most of the approaches like the supercollider
> PinkNoise.ar ugen are mostly accurate, but over a limited bandwidth. As the
> number of octaves grows, the accurcary drops. Is my understanding correct?
>
> I'm hoping to find a way to generate pink noise that is:
> 1) Accurate over an arbitrarily wide bandwidth, at least 32 octaves
> 2) Tractable to generate an arbitrarily large number of samples (billions,
> so can't fft the whole thing in one pass)
>
> Any suggestions? I've read through
> http://www.firstpr.com.au/dsp/pink-noise/#Pseudo, but everyone seems
> focused on fast-generation of pink noise of moderate quality and a
> relatively narrow bandwidth. I'm sort of looking for the other side of
> things... what's the most ideal pink noise I can generate en masse?
>
> Thanks,
> -Seth
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] confirm a2ab2276c83b0f9c59752d823250447ab4b666

[Evan Balster]

This happened to me also, but I didn't give it much thought.


On Mon, Mar 28, 2016 at 4:31 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> h.  i wonder if someone is trying to tell me something
>
>
>
>  Original Message 
> Subject: confirm a2ab2276c83b0f9c59752d823250447ab4b666
> From: music-dsp-requ...@music.columbia.edu
> Date: Mon, March 28, 2016 2:31 pm
> To: r...@audioimagination.com
> --
>
> > Mailing list removal confirmation notice for mailing list music-dsp
> >
> > We have received a request for the removal of your email address,
> > "r...@audioimagination.com" from the music-dsp@music.columbia.edu
> > mailing list. To confirm that you want to be removed from this
> > mailing list, simply reply to this message, keeping the Subject:
> > header intact. Or visit this web page:
> >
> >
> https://lists.columbia.edu/mailman/confirm/music-dsp/a2ab2276c83b0f9c59752d823250447ab4b666
> >
> >
> > Or include the following line -- and only the following line -- in a
> > message to music-dsp-requ...@music.columbia.edu:
> >
> > confirm a2ab2276c83b0f9c59752d823250447ab4b666
> >
> > Note that simply sending a `reply' to this message should work from
> > most mail readers, since that usually leaves the Subject: line in the
> > right form (additional "Re:" text in the Subject: is okay).
> >
> > If you do not wish to be removed from this list, please simply
> > disregard this message. If you think you are being maliciously
> > removed from the list, or have any other questions, send them to
> > music-dsp-ow...@music.columbia.edu.
> >
> >
>
> i think *someone* is being a wee bit malicious.  or at least a bit
> mischievous.
>
> (BTW, i changed the number enough that i doubt it will work for anyone.
>  but try it, if you want.)
>
>
>
>
>
>  Original Message 
> Subject: Re: [music-dsp] Changing Biquad filter coefficients on-the-fly,
> how to handle filter state?
> From: "vadim.zavalishin" 
> Date: Mon, March 28, 2016 2:20 pm
> To: r...@audioimagination.com
> music-dsp@music.columbia.edu
> --
>
> > robert bristow-johnson писал 2016-03-28 17:57:
> >> using the trapezoid rule to model/approximate the integrator of an
> >> analog filter is no different than applying bilinear transform
> >> (without compensation for frequency warping) to the same integrator.
> >>
> >> s^(-1) <--- T/2 * (1 + z^(-1)) / (1 - z^(-1))
> >
> > This statement implies the LTI case, where the concept of the transfer
> > function exists.
>
> i didn't say that.  i said "applying ... to the same integrator."  about
> each individual "transfer function" that looks like "s^(-1)"
>
>
>
> > In the topic of this thread we are talking about
> > time-varying case, this means that the transfer function concept doesn't
> > apply anymore.
>
>
>
> well, there's slow time and there's fast time.  and the space between the
> two depends on how wildly one twists the knob.  while the filter properties
> are varying, we want the thing to sound like a filter (with properties that
> vary).  there *is* a concept of frequency response (which may vary).
>
>
>
> for each individual integrator you are replacing the
> continuous-time-domain equivalent of s^(-1) with the discrete-time-domain
> equivalent of T/2 * (1 + z^(-1)) / (1 - z^(-1)), which is the same as the
> trapezoid rule.
>
>
>
> > Specifically, filters with identical *formal* transfer
> > functions will behave differently and this is exactly the topic of the
> > discussion.
>
> i didn't say anything about a "transfer function", until this post.  i am
> saying that the trapezoidal rule for modeling integrators is replacing
> those integrators (which by themselves are LTI and *do* happen to have a
> transfer function of "s^(-1)") with whatever "T/2 * (1 + z^(-1)) / (1 -
> z^(-1))"  means.  and that's the same as the trapezoid rule.  (the stuff
> connected in-between might be neither L nor TI.)
>
> time-varying filters is the topic of the email.  your VA paper along with
> others (like Jean Laroche) speak to it.  there are other LTI forms than
> either emulating a circuit or using simple biquads.  there's Hal's SVF (oh,
> that's emulating a circuit, sorta, but Hal is doing the "Naive" emulation
> of s^(-1)) and, what i would recommend, is the use of 2nd-order Lattice (if
> you have floating point) or Normalized Ladder (if you're doing this in
> fixed point) if you want to wildly modulate resonant frequency.  that's
> actually pretty commonly known in the industry.
>
> a "transfer function" is not enough information to fully define a system
> unless other assumptions are made (like "observability" or
> "controllability").  that's why the general state-variable system (Hal's
> title is a little bit 

Re: [music-dsp] Delays: sampling rate modulation vs. buffer size modulation

[Evan Balster]

Matthias --

Resampling (sample rate change) and delay are distinct but related
operations -- I think it is helpful to consider them separately when
considering any variable-delay implementation.

First, imagine a black box containing a large amount of magnetic tape which
can be drawn out through a slit.  If we run this tape through a playhead,
we hear its signal.  If we pull it out faster, the signal is pitched up --
analogous to resampling to a higher rate.  If we pull slowly, the signal is
pitched down -- analogous to a lower rate.  There is no meaningful concept
of delay here -- the contents of the box existed before we used them, so in
absence of a second playhead it makes little difference if we're a second
ahead or behind.

Now, imagine that instead of the black box we have a recording device
writing over magnetic tape, which is produced (pushed) from the slit at a
constant rate.  The rate of production is constant, so that if there is any
change to our rate of consumption (playback), tape will either accumulate
between the recorder and the player (increasing delay) or the accumulated
length will shorten to some minimum.  If we wish to change the delay, we
must change the rate of playback for some time, such that the difference
between recording rate and playback rate integrates to the desired change
in delay.

A more sensible way of constructing the above system is with a taut length
of tape emerging from the slit and a playhead capable of moving back and
forth along this length.  The position of the playhead on the moving tape
determines the delay.  If we move the playhead to a new position, its
velocity will change on the way there; the playback rate is equal to the
difference between the speed of the tape and the speed of the playhead.

With these metaphors in mind, the math is easy to understand:  When dealing
with a fixed-samplerate producer, the delay in samples is equal to the
initial delay plus the integral of the difference between producer
samplerate and consumer samplerate (which may change over time).  The
consumer samplerate is equal to the derivative of the delay plus the
producer samplerate.

– Evan Balster
creator of imitone <http://imitone.com>

On Wed, Mar 23, 2016 at 4:04 AM, Vadim Zavalishin <
vadim.zavalis...@native-instruments.de> wrote:

> On 23-Mar-16 00:45, Matthias Puech wrote:
>
>> Does this mean for instance that if I provide a control over the
>> integral of D in 1/ I will get the exact same effect as in 2/?
>>
>
> I have been thinking about this question a while ago (in terms of tape
> rather than BBD delay, but that's more or less the same). It seems that you
> need to solve an integral equation, something like (latex notation)
>
> \int_{t-T}^t v(\tau)d\tau = L
>
> where
>
> t = the current time moment
> T = the delay time (the unknown to be found)
> v(\tau) = tape speed
> L = distance between the read and write heads
>
> For an arbitrary v(t) this can be solved only numerically. For a
> predefined v(t) this can be done analytically.
>
> Regards,
> Vadim
>
> --
> Vadim Zavalishin
> Reaktor Application Architect
> Native Instruments GmbH
> +49-30-611035-0
>
> www.native-instruments.com
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Cheap spectral centroid recipe

[Evan Balster]

For my own benefit and that of future readers, I'm going to summarize the
thread so far.


The discussion here concerns metrics of "brightness" -- that is, the
tendency of a given signal toward higher or lower signal content.  The
method proposed for analyzing brightness involves inspecting "moments" of
power in the frequency domain -- that is, the statistical distribution of
power among frequencies.


The algorithm I originally proposed uses a simple differentiator to
approximate what I thought was a "mean frequency" -- the first moment of
the distribution of power among frequencies in the signal.  As others have
remarked, the revised algorithm <http://pastebin.com/EfRv4HRC> (as seen in
the latest pastebin code) computes a *standard deviation* of frequencies in
a real signal.  If you take out the square-root operation, it becomes the
variance, or second moment.  The first moment (mean) is in fact *always
zero* for real signals due to the symmetry of the frequency domain.

The flaw of my algorithm is that, given a signal comprising two sinusoid
frequencies of equal power, it will produce a quadratic mean
<https://en.wikipedia.org/wiki/Root_mean_square> of the two frequencies
rather than a linear mean.  If the frequencies are 100hz and 200hz, for
instance, my algorithm will produce a centroid of about 158.1hz.  It's
reasonable that we would prefer an algorithm that instead yields a more
intuitive result 150hz -- the first moment of power in the *positive *frequency
domain.

To achieve this linear spectral centroid then we need to use a filter
approximating a semi-derivative -- also known as a "+3dB per octave" or
"reverse-pinking" filter.  With one of these, we may compute a ratio of the
power of the "un-pinked" signal to the power of the original signal,
without a square-root operation -- and this gives us a "mean frequency"
that will behave as we desire.

Each of these techniques may be extended with further levels of
differentiation or semi-differentiation step to compute additional moments:
 in the case of the original technique, we can use a second-derivative
approximation to get the fourth moment of the symmetric frequency domain.
In the case of the "linear spectral centroid" technique, we can either
apply the reverse-pinking filter again (or use a simple differentiator) to
get the second moment, corresponding to the variance of frequencies in the
signal.

Lastly, it's important to note that differentiation and
semi-differentiation filters are always approximate for sampled signals,
and will tend to exhibit poor behavior for very high frequencies and (for
semi-differentiation) very low ones.  The band of frequencies which will be
handled accurately is a function of the filters used to approximate
differentiation and semi-differentiation.


When working with tonal signals, it has been proposed that brightness be
normalized through division by fundamental frequency.  This produces a
dimensionless (?) metric which is orthogonal to the tone's pitch, and does
not typically fall below a value of one.  Whether such a metric corresponds
more closely to brightness than the spectral centroid in hertz depends on a
psychoacoustics question:  Do humans perceive brightness as a quality which
is independent from pitch?

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Feb 25, 2016 at 1:04 PM, Theo Verelst <theo...@theover.org> wrote:

> Evan Balster wrote:
>
>> ...
>>
>> To that end:  A handy, cheap algorithm for approximating the
>> power-weighted spectral
>> centroid -- a signal's "mean frequency" -- which is a good heuristic for
>> perceived sound
>> brightness <https://en.wikipedia.org/wiki/Brightness#Brightness_of_sounds>.
>> In spite of
>> its simplicity, ...
>>
> Hi,
>
> Always interesting to learn a few more tricks, and thanks to Ethan's
> explanation I get there are certain statistical ideas involved. I wonder
> however where those ideas in practice lead to, because of a number of
> assumptions, like the "statistical variance" of a signal. I get that a self
> correlation of a signal in some normal definition gives an idea of the
> power, and that you could take it that you compute power per frequency
> band. But what does it mean when you talk about variance ? Mind you I know
> the general theoretics up to the quantum mechanics that worked on these
> subjects long ago fine, but I wonder what the understanding here is?
>
> Some have remarked about the analysis of a signal into ground frequency
> and harmonics that it might be hard to summarize and make an ordinal
> measure for "brightness" as a one dimensional quantity, I mean of you look
> at a number of peaks in a frequency graph, how do you sum up the frequency
> of the sign

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Evan Balster]

A note to Kjetil and future readers:  Bear in mind that using code derived
from JUCE source in a non-opensource application may be a transgression of
the GPL license under which the original code is offered!  (Unless you've
purchased a commercial license to JUCE)

– Evan Balster
creator of imitone <http://imitone.com>

On Wed, Feb 24, 2016 at 11:54 AM, Kjetil Matheussen <
k.s.matheus...@gmail.com> wrote:

>
>
> On Mon, Feb 22, 2016 at 1:52 PM, Kjetil Matheussen <
> k.s.matheus...@gmail.com> wrote:
>
>> Hi all,
>>
>> I wonder if anyone has a tip for a C or C++ of an implementation of a
>> Cubic interpolating resampler.
>> I'm not asking about the algorithm itself, that is all covered (currently
>> I'm using a Catmull-Rom spline algorithm,
>> but that is not so important here). What I'm asking about is a framework
>> for using the algorithm.
>>
>>
> For future readers, I ended up using the Lagrange interpolator from JUCE
> as base code, but rewrote most
> of it and replaced the Lagrange code with a Catmull-Rom interpolator
> instead, since the
> Catmull-Rom code sounded much better.
>
> The interpolator, based on JUCE-code:
>
> https://github.com/kmatheussen/radium/blob/master/audio/SampleInterpolator.cpp
>
> A callback-based resampler, using the interpolator above:
> https://github.com/kmatheussen/radium/blob/master/audio/Resampler.cpp#L73
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Evan Balster]

I'm working on a game application that routinely runs around 60-80 of these
pitch shifters in a real-time callback on consumer hardware.  Performance
is fine.

To clarify, the state of the resampler is:

   - Four stored samples for continuity between runs
   - The fractional offset from the last sample of the last input chunk
   - Resampling rate settings

The resampling procedure and state management work as follows

   1. Ascertain the required quantity of input (through simulation, in my
   case)
   2. Allocate* an input buffer of this length, plus four.
   3. Copy stored samples to the beginning of the input buffer.
   4. Render source audio into the remaining samples of the input buffer
   5. Resample from the working buffer into the output buffer (with rate
   interpolation)
   6. Copy the final samples of the input buffer to storage for the next
   run.

Note that this scheme is meant for rendering to an output of fixed sampling
rate from an on-demand input.  If both the input and output are streaming
data, I would use a variable delay line rather than a rate-based resampler
-- which sounds like what you're talking about.

* Allocations come from a stack-buffer which is a staple of my audio
processing framework; all allocations from this buffer occur in constant
time and are relinquished when processing is complete.

Tying back into the central topic of the thread, the state management
really isn't too bad.  The only complicated bit is -- as always -- the
lock-free settings propagation, and that's easily solved with standard data
structures.

– Evan Balster
creator of imitone <http://imitone.com>

On Mon, Feb 22, 2016 at 8:52 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
>  Original Message 
> Subject: Re: [music-dsp] Tip for an audio resampler library doing cubic
> interpolation
> From: "Evan Balster" <e...@imitone.com>
> Date: Mon, February 22, 2016 6:45 pm
> To: music-dsp@music.columbia.edu
> --
>
> >
> > Robert --
> >
> > Look again; no circular buffer is used.
>
> that might explain why i couldn't see any code that would indicate such.
>
> > The sampling buffer consists of
> > the last four samples from the previous buffer, followed by the input
> > chunk. The "length" value indicates the length of the input chunk.
>
>
>
> so you're copying those four samples from the end of the previous chunk to
> the beginning of the current chunk?  and you're doing this every chunk time?
>
> well, then i dunno how i would use it for a real-time pitch shifter or a
> real-time asynchronous sample-rate-converter or something where i am
> striding though the sample record, for a sustained period where the stride
> is not equal to 1 sample (output) per sample (input).  usually what you
> have is a circular buffer and a mean delay of around half the length of the
> circular buffer and then *some* operation to deal with if your output
> pointer (or read pointer, which has both integer and fractional components)
> gets too close to the either edge of the buffer (or too close to the input
> or write pointer).
>
> there are two ways i have dealt with this.  one has a better *average*
> execution time and the other a better *worst case* execution time.  the
> former, when the write pointer wraps around to the beginning of the buffer,
> i copy a segment of sufficient length from the beginning of the buffer and
> append it to the end.  then my read pointer can always be considered linear
> (it wraps, too, but i don't have to worry about it regarding 4+chunksize or
> more valid contiguous samples).  the latter, i just make my circular buffer
> with size equal to a power of two and mask the bits of the index (modulo
> 2^p) of the read pointer every time i use it.
>
>
>
> --
>
>
>
>
> r b-j  r...@audioimagination.com
>
>
>
>
> "Imagination is more important than knowledge."
>
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Evan Balster]

Kjetil --

I suspect you'll have a very hard time finding a library with the functions
you need that doesn't include quite a lot else.  If you'd like to reference
a more comprehensive implementation (with anti-aliasing and rate
interpolation) I can provide my current code -- but it's part of a larger
framework which does a lot of things you wouldn't need.


Robert --

Look again; no circular buffer is used.  The sampling buffer consists of
the last four samples from the previous buffer, followed by the input
chunk.  The "length" value indicates the length of the input chunk.

This is an outdated version of my resampler and it has various minutiae
worthy of criticism -- with the most glaring being a lack of antialiasing.
I supplied it here because it gets the job done and my current
implementation relies on a rather large body of filter design code for
Chebychev-II antialiasing.

– Evan Balster
creator of imitone <http://imitone.com>

On Mon, Feb 22, 2016 at 5:36 PM, Ross Bencina <rossb-li...@audiomulch.com>
wrote:

> On 23/02/2016 1:24 AM, Kjetil Matheussen wrote:
>
>> On Mon, Feb 22, 2016 at 2:59 PM, Ross Bencina
>> <rossb-li...@audiomulch.com <mailto:rossb-li...@audiomulch.com>> wrote:
>>
>> Hi Kjetil,
>>
>> On 22/02/2016 11:52 PM, Kjetil Matheussen wrote:
>>
>> I wonder if anyone has a tip for a C or C++ of an implementation
>> of a
>> Cubic interpolating resampler. I'm not asking about the algorithm
>> itself, that is all covered (currently I'm using a Catmull-Rom
>> spline
>> algorithm, but that is not so important here). What I'm asking
>> about
>> is a framework for using the algorithm.
>>
>>
>> It's hard to suggest a framwork out of thin air. One thing: it
>> probably doesn't matter what kind of interpolation you use. The
>> interface is concerned with samples in, samples out, current
>> interpolation phase, conversion ratio. Here's a few questions that
>> come to mind:
>>
>>
>> Thanks Ross. I'm sorry I didn't provide more information. I did actually
>> answer all your questions,
>> through code, but I guess it was quite arrogant of me not to explain the
>> somewhat hairy interface.
>>
>
> Hi Kjetil,
>
> Thanks for the clarification. Sorry, I misunderstood your question. When
> you ask for "a framework for using the algorithm." I thought you meant the
> best way to structure the interface to the code. But it sounds like you
> have already decided on the interface.
>
> The interpolation is a function of the lookup phase and a few input
> samples. What else do you need to resolve?
>
> If I was going to implement that interface, I'd write some tests and the
> simplest possible implementation (probably, pulling single samples from the
> source as needed, maybe just using linear or 0-order interpolation to start
> with). Then I'd profile, refactor and optimize as needed.
>
> Ross.
>
> P.S. Using a C function pointer in C++ is not very flexible. You could
> either define an abstract interface for the source, or use std::function.
>
> P.P.S. How do you communicate the amount of source data needed? the
> callback has no "count" parameter.
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Evan Balster]

Hey, Kjetil --

Pulling in a library for just this seems like massive overkill.  The
venerable pink elephant paper
<http://yehar.com/blog/wp-content/uploads/2009/08/deip.pdf> describes
several cubic resampling algorithms (I prefer four-point hermite) and it's
fairly straightforward to implement the necessary state management.

Attached is the source file for an older implementation of my rate-change
class.  (It's a version without anti-aliasing as that adds a number of
dependencies.)  It's ~200 lines of C++ and while it won't compile without
various modifications it should be relatively straightforward as reference
code or a basis for your own adaptation.

– Evan Balster
creator of imitone <http://imitone.com>

On Mon, Feb 22, 2016 at 11:08 AM, Kjetil Matheussen <
k.s.matheus...@gmail.com> wrote:

>
>
> On Mon, Feb 22, 2016 at 5:38 PM, Kjetil Matheussen <
> k.s.matheus...@gmail.com> wrote:
>
>>
>> Thank you, but I found something else.
>>
>> It seems like JUCE actually have a resampling class that seems to do the
>> right thing:
>>
>> https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_basics/sources/juce_ResamplingAudioSource.cpp
>>
>>
> No, this seems to be just linear interpolation with a lowpass filter.
>
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
#include 
#include 

//#include "../effects.h"


namespace plaid
{
	//HEADER
	
	struct Pitch_Node {float rate; Uint32 alg;};
	/*
		Pitch:  Allows volume/pitch modulation and pausing of a stream.

		Frequency modulation can be constant, based on another

		WARNING:  Pitch takes in audio from the source stream at an altered
			rate; thus, performance issues will arise from the use of very
			high Pitches as large amounts of data are consumed, and certain
			streams such as Microphones will be unable to keep up with demand.
	*/
	class Pitch : public AudioEffect
	{
	public:
		//Interpolation styles
		enum RESAMPLER
			{
			NONE=0, //Bottom-of-the-barrel
			LINEAR=1, //Low-quality linear
			HERMITE=2, HERMITE_43=2, //4-point 3rd order hermite.
			//Coming: sinc interpolation
			};

	public:
		//Bind to signal
		Pitch(Signal source, float rate=1.0f, Uint32 alg=HERMITE);
		virtual ~Pitch();

		//Choose the resampling algorithm.  Default is HERMITE.
		void resampling(Uint32 alg);

		//Set and interpolate to the given pitch.  "Note" is in semitones.
		void rate(float factor)   {settings.rate = std::max(factor,.0f);}
		void note(float note) {settings.rate = Semitones(note);}

		//Query current pitch
		float rate()  {return settings.rate;}
		float note()  {return Semitones(settings.rate);}

	protected:
		virtual void pull(AudioChunk ,
			const Pitch_Node , const Pitch_Node );
		virtual Pitch_Node interpolate(
			const Pitch_Node , const Pitch_Node , float mid);

		virtual void effectTick(Uint64) {}

	private:
		float offset;
		std::vector mem;
	};
}


using namespace plaid;


static Pitch_Node makeNode(float rate, Uint32 alg)
{
	Pitch_Node node = {rate, alg};
	return node;
}


Pitch::Pitch(Signal source, float rate, Uint32 alg) :
	AudioEffect(source, makeNode(rate, alg))
{
	offset = 0.0f;
	for (int i = 4*source.format().channels; i--;) mem.push_back(0);
}
Pitch::~Pitch()
{
}

void Pitch::resampling(Uint32 alg)
{
	settings.alg = alg;
}


void Pitch::pull(AudioChunk , const Pitch_Node , const Pitch_Node )
{
	Uint32 length = chunk.length(), chan = source.format().channels;

	/*{
		static float sanity = 0.0f;
		if (a.rate != sanity)
			std::cout << "TIME BREAK " << sanity << " -> " << a.rate << std::endl;
		sanity = b.rate;
	}*/

	//Compute rate and offset
	float rate = a.rate, inc = std::pow(b.rate/a.rate, 1.0f/float(length));
	float off = offset;

	//"simulate" the render to figure out how many samples are needed.
	Uint32 count = 0, steps;
	if (inc == 1.0f)
	{
		for (Uint32 i = length; i--;)
		{
			off += rate;
			steps = off; off -= steps;
			count += steps;
		}
	}
	else
	{
		for (Uint32 i = length; i--;)
		{
			off += rate; rate *= inc;
			steps = off; off -= steps;
			count += steps;
		}
	}

	//Allocate temp buffer from scratch pool; account for failure
	AudioChunk sub(chunk, (4 + count), source.format());
	if (!sub.ok()) {chunk.silence(); return;}

	//Pull source audio into temp buffer
	{
		//Copy from memory to beginning of buffer
		Sint32 *forward[PG_MAX_CHANNELS];
		for (Uint32 i=0; i<chunk.format().channels; ++i)
		{
			std::memcpy((void*) sub.start(i), (void*) [4*i], 4*4);
			forward[i]=sub.start(i)+4;
		}

		//Fill rest of buffer with new data from source stream
		AudioChunk pull(chunk.process(), chunk.format(), forward, count,
			chunk.sync);
		source.pull(pull);

		//Copy 

Re: [music-dsp] Cheap spectral centroid recipe

[Evan Balster]

In late 2013 (I think) I experimented with a preliminary implementation of
the brightness articulation in my pitch tracking software.  I normalized it
based on fundamental frequency, which at the time seemed like common sense
due to the mathematical elegance of a well-defined minimum.

Since then I've reconsidered that decision on the basis of formant
structure:  the spectral centroid in hertz corresponds more closely to
mouth and throat shape than to pitch, especially for tenor and bass
registers.  While certainly present, the correlation between spectral
centroid and pitch can be *very* loose for deep vocal sounds -- I wouldn't
be surprised if it was non-monotonic.

I think my brightness metric at the time used first-order filters, but I
have implemented pinking-related techniques since then and I can confirm
they work quite well.  (Well enough that I forgot about the biases induced
by first-order implementations, anyway.)

– Evan Balster
creator of imitone <http://imitone.com>

On Fri, Feb 19, 2016 at 7:30 PM, Douglas Repetto <doug...@music.columbia.edu
> wrote:

> Robert,
>
> On Fri, Feb 19, 2016 at 3:38 PM, robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>> geez, i wish i could cut and paste text without getting all of that HTML
>> crap in there.  i dunno how this is going through majordomo or whatever
>> Douglas has running the list.
>
>
>
> That's a function of your email client, not the list. The list just sends
> through whatever you send to it. Your mail looks fine to me, no HTML to be
> seen, nice formatting, etc. This is in Chrome/gmail. So if you're seeing
> markup then it's your client that's displaying it as code instead of
> rendering it.
>
> douglas
>
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Time-domain noisiness estimator

[Evan Balster]

Noise is an elusive concept.  One way of thinking about it is that the real
signal can be decomposed into a sum of two theoretical signals, comprising
desirable and undesirable information.  What isn't signal is noise; and
what isn't noise is signal -- so our definitions or models for these must
be complementary.  This implies that isolating noise -- or what noise even
*is* in a given context -- depends on what kind of information we're trying
to extract from the raw signal.

While it's not uncommon for the undesirable information to exhibit a white
spectral envelope, this quality is highly situational and depends heavily
on the context.  I've been bitten in the past when designing algorithms
around a white noise model and then running my software on systems with
integrated noise cancellation.

– Evan Balster
creator of imitone <http://imitone.com>

On Sun, Feb 21, 2016 at 6:16 AM, Corey K <corey...@gmail.com> wrote:

> I haven't researched this at all, so take the following with a grain of
> salt. But, how about looking at different features of the auto-correlation
> (e.g., flatness, peakiness, ...)?
>
> On Fri, Feb 19, 2016 at 1:49 PM, Dario Sanfilippo <
> sanfilippo.da...@gmail.com> wrote:
>
>> Hello everybody.
>>
>> Following on a discussion about cheap/time-domain spectral centroid
>> estimators, I thought it could have been interesting to also discuss
>> time-domain noisiness estimators.
>>
>> I think that a common approach is the FFT-based spectral flatness
>> algorithm. In the time-domain, zero-crossing rate is another common
>> approach, although it seems to only work for specific cases like voiced Vs.
>> unvoiced sounds, or percussive Vs. non-percussive. A very high frequency
>> sinewave would also have a high ZCR, although it is not noisy.
>>
>> I tried implementing a rudimentary noisiness estimator based on the idea
>> that a noisy signal is characterised by a varying ZCR, rather than a high
>> ZCR. What I did was to use a differentiator on successive averaging windows
>> of ZCR, and then I averaged the absolute value of differentiator's output
>> to obtain an index.
>>
>> The algorithm seems to work fine for most cases, although some particular
>> frequencies of a sinusoidal input result in unexpected indexes. I guess
>> that a problem here is to find a good compromise in the averaging windows
>> of the ZCR. I am using 10-msec windows which seemed to work OK. I was also
>> thinking that I could make the averaging window time-variant, piloting it
>> based on a centroid estimation in order to optimes it according to the
>> spectral content of the signal.
>>
>> Does any of the above make sense for you? Are you aware of other
>> algorithms using a similar technique?
>>
>> If you're familiar with the Pure Data audio environment, you can have a
>> look at the patch here:
>> https://dl.dropboxusercontent.com/u/43961783/noisiness.jpg
>>
>> Thanks,
>> Dario
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Cheap spectral centroid recipe

[Evan Balster]

I don't think I got the message containing this question:

*again, Evan, what i would like to hear from you is, given your offered
algorithm for spectral centroid, if you play, say a piano into it, one note
at a time, does C# have a 6% greater spectral centroid or 12% higher than
C?  or less than 6%?*

...But I would be wary of this thinking.  Brightness and pitch are very
different metrics, as evidenced by the human voice:  A man with a nasal or
gravelly voice can drop from an E3 to an E2 with only a small change in the
spectral centroid.


As it happens, I've implemented a brightness metric involving an "unpinking
filter" and it works as you describe.  That's the "very different
implementation" I mentioned earlier.  No square root is required and the
result is a simple power-based mean.

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Feb 18, 2016 at 3:11 PM, Ethan Fenn <et...@polyspectral.com> wrote:

> again, Evan, what i would like to hear from you is, given your offered
>> algorithm for spectral centroid, if you play, say a piano into it, one note
>> at a time, does C# have a 6% greater spectral centroid or 12% higher than
>> C?  or less than 6%?
>
>
> It seems to me, with the sqrt in the latest version of the sample code, it
> will be 6% higher as you'd like.
>
> But with more than one frequency present, the weighting is a little funny
> -- if we're looking at a sum of two sines with equal amplitude at 100Hz and
> 200Hz, I think this technique will give you a "spectral centroid" of
> sqrt((100^2 + 200^2)/2), roughly 158Hz instead of the 150Hz you might want.
>
> I like your idea of unpinking first, I think that will push the result in
> this scenario back to 150Hz.
>
> Riffing on this idea, if we wanted to make it one step more perceptually
> correct, we might try combining this unpinking filter with a filter that
> aproximates the inverse of an equal loudness contour. I'd expect adding
> some energy at 4kHz to do a heck of a lot more to my brightness perception
> than adding the same amount of energy at 60Hz or 15kHz.
>
> -Ethan
>
>
>
> On Thu, Feb 18, 2016 at 3:08 PM, robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>>
>>
>>  Original Message 
>> Subject: Re: [music-dsp] Cheap spectral centroid recipe
>> From: "Evan Balster" <e...@imitone.com>
>> Date: Thu, February 18, 2016 1:55 pm
>> To: music-dsp@music.columbia.edu
>> --
>>
>> > Anyway, that's why -- in spite of my extensive research in pitch
>> tracking
>> > -- I don't touch perception modeling with a ten-foot pole.
>>
>>
>>
>> that's sorta a self-contradiction.
>>
>>
>>
>> "pitch" is a perceptual attribute of a tone or sound.
>>
>> "fundamental frequency" is a physical attribute.
>>
>>
>>
>> "loudness" is a perceptual attribute.
>>
>> "amplitude" is a physical attribute.
>>
>>
>>
>> "brightness" is a perceptual attribute.
>>
>> "spectral centroid" (however it's mathematically defined) is a physical
>> attribute.
>>
>>
>>
>> again, Evan, what i would like to hear from you is, given your offered
>> algorithm for spectral centroid, if you play, say a piano into it, one note
>> at a time, does C# have a 6% greater spectral centroid or 12% higher than
>> C?  or less than 6%?
>>
>>
>>
>> also, Evan, i would be very interested in hearing (or reading) what you
>> might be willing to tell us about pitch detection or pitch tracking.  i
>> realize you may be keeping this trade secret, but to the extent that you're
>> willing to openly discuss even principles, if not algorithms, i would pay
>> close attention.  (and i am not terribly stingy about knowledge assets.)
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>>
>>
>> r b-j  r...@audioimagination.com
>>
>>
>> "Imagination is more important than knowledge."
>>
>>
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Cheap spectral centroid recipe

[Evan Balster]

*To use log magnitude you'd first have to normalize it to look like a
probability density (non-negative, sums to one). Meaning you add an offset
so that the lowest value is zero, and then normalize.  Obviously that puts
restrictions on the class of signals it can handle - there can't be any
zeros on the unit circle (in practice we'd just apply a minimum threshold
at, say, -60dB or whatever) - and involves other complications (I'm not
sure there's a sensible time-domain interpretation).*

I've solved a lot of problems in the past by "massaging" numbers into
ranges or formats where they suit the problem I'm trying to solve.  That
approach -- adding mathematical complexity according to convenience and
intuition rather than specific theoretical justification -- is
unscientific, and time and time again it has led me to false leads and
discouraging results when solving low-level problems.  (That said, the
failures that result from "fumbling in the dark" can sometimes lead to
groundbreaking discoveries.)

Research into perception tells us that most phenomena are perceived
proportional to the logarithm of their intensity.  It tells us further that
auditory stimuli are received in a form *resembling *the frequency domain.
We're mathematicians, not neuroscientists, and that discipline comes with a
powerful confirmation bias for simple, "elegant" solutions.  But the
cochlea is not cleanly modeled
<http://www.cns.nyu.edu/~david/courses/perception/lecturenotes/pitch/pitch.html>
by a fourier transform, and as to what happens beyond, Minsky said it best:
the simplest explanation is that there is no simple explanation.  In
absence of hard research, we can't reasonably expect to add logarithm
flavoring to such a simple formula and expect it to converge with the
result of billions of years of evolution.

Anyway, that's why -- in spite of my extensive research in pitch tracking
-- I don't touch perception modeling with a ten-foot pole.  It's a soft
science and it's all too easy to develop the misconception that you know
what you're doing.  Because it will be a long time before the perceptual
properties of any brightness metric can be clearly understood, I'll stick
to formulas whose mathematical properties are transparent -- these lend
themselves infinitely better to being small pieces of larger systems.

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Feb 18, 2016 at 11:24 AM, Ethan Duni <ethan.d...@gmail.com> wrote:

> >Weighting a mean with log-magnitude can quickly lead to nonsense.
>
> To use log magnitude you'd first have to normalize it to look like a
> probability density (non-negative, sums to one). Meaning you add an offset
> so that the lowest value is zero, and then normalize. Obviously that puts
> restrictions on the class of signals it can handle - there can't be any
> zeros on the unit circle (in practice we'd just apply a minimum threshold
> at, say, -60dB or whatever) - and involves other complications (I'm not
> sure there's a sensible time-domain interpretation).
>
> >I apply Occam's razor when making decisions about what metrics correspond
> most closely to nature
>
> What is the natural phenomenon that we're trying to model here?
>
> > log-magnitude is rarely sensible outside of perception modeling
>
> But isn't the goal here to estimate the "brightness" of a signal?
> Perceptual modelling is exactly why I bring log spectra up.
>
> E
>
>
>
> On Thu, Feb 18, 2016 at 7:42 AM, Evan Balster <e...@imitone.com> wrote:
>
>> Weighting a mean with log-magnitude can quickly lead to nonsense.
>> Trivial examples:
>>
>>- 0dB sine at 100hz, 6dB sine at 200hz --> log centroid is 200hz
>>- -6dB sine at 100hz, 12dB sine at 200hz --> log centroid is 300hz (!)
>>
>> Sanfillipo's adaptive median finding technique is still applicable, but
>> will produce the same result as a power or magnitude version.
>>
>> I apply Occam's razor when making decisions about what metrics correspond
>> most closely to nature.  I choose the formula which is mathematically
>> simplest while utilizing operations that make sense for the dimensionality
>> of the operands and do not induce undue discontinuities.  Power is simpler
>> to compute than magnitude, log-magnitude is rarely sensible outside of
>> perception modeling, and (unlike zero-crossing techniques) a small change
>> in the signal will always produce a proportionally small change in the
>> metrics.
>>
>> At next opportunity I should post up some code describing how to compute
>> higher moments with the differential brightness estimator.
>>
>> – Evan Balster
>> creator of imitone <http://imitone.com>
>>
>> On Thu, Feb 18, 2016 at 1:00 AM, Ethan Duni &

Re: [music-dsp] Cheap spectral centroid recipe

[Evan Balster]

Weighting a mean with log-magnitude can quickly lead to nonsense.  Trivial
examples:

   - 0dB sine at 100hz, 6dB sine at 200hz --> log centroid is 200hz
   - -6dB sine at 100hz, 12dB sine at 200hz --> log centroid is 300hz (!)

Sanfillipo's adaptive median finding technique is still applicable, but
will produce the same result as a power or magnitude version.

I apply Occam's razor when making decisions about what metrics correspond
most closely to nature.  I choose the formula which is mathematically
simplest while utilizing operations that make sense for the dimensionality
of the operands and do not induce undue discontinuities.  Power is simpler
to compute than magnitude, log-magnitude is rarely sensible outside of
perception modeling, and (unlike zero-crossing techniques) a small change
in the signal will always produce a proportionally small change in the
metrics.

At next opportunity I should post up some code describing how to compute
higher moments with the differential brightness estimator.

– Evan Balster
creator of imitone <http://imitone.com>

On Thu, Feb 18, 2016 at 1:00 AM, Ethan Duni <ethan.d...@gmail.com> wrote:

> >normalized to fundamental frequency or not
> >normalized (so that no pitch detector is needed)?
>
> Yeah tonal signals open up a whole other can of worms. I'd like to
> understand the broadband case first, with relatively simple spectral
> statistics that correspond to the clever time-domain estimators discussed
> so far in the thread.
>
> The ideas for time-domain approaches got me thinking about what the
> optimal time-domain approach would look like. But of course it depends on
> what definition of spectral centroid you use. For the mean of the power
> spectrum it seems relatively straightforward to get some tractable
> expressions - I guess this is the inspiration for the one based on an
> approximate differentiator. But I suspect that mean of the log power
> spectrum is more perceptually meaningful.
>
> E
>
> On Wed, Feb 17, 2016 at 8:34 PM, robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>>
>>
>>  Original Message 
>> Subject: Re: [music-dsp] Cheap spectral centroid recipe
>> From: "Ethan Duni" <ethan.d...@gmail.com>
>> Date: Wed, February 17, 2016 11:21 pm
>> To: "A discussion list for music-related DSP" <
>> music-dsp@music.columbia.edu>
>> --
>>
>> >>It's essentially computing a frequency median,
>> >>rather than a frequency mean as is the case
>> >>with the derivative-power technique described
>> >> in my original approach.
>> >
>> > So I'm wondering, is there any consensus on what is the best measure of
>> > central tendency for a music signal spectrum? There's the median vs the
>> > mean (vs trimmed means, mode, etc). But what is the right domain in the
>> > first place: magnitude spectrum, power spectrum, log power spectrum or
>> ???
>>
>> normalized to fundamental frequency or not normalized (so that no pitch
>> detector is needed)?  should identical waveforms at higher pitches have the
>> same centroid parameter or a higher centroids?
>>
>> spectral "brightness" is a multi-dimensional perceptual parameter.  you
>> can have two tones with the same spectral centroid (however consistent way
>> you measure it) and sound very different if the "second moment" or
>> "variance" is much different.
>>
>>
>>
>> --
>>
>>
>> r b-j   r...@audioimagination.com
>>
>>
>>
>>
>> "Imagination is more important than knowledge."
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Cheap spectral centroid recipe

[Evan Balster]

Dario's adaptive approach is interesting.  It's essentially computing a
frequency median, rather than a frequency mean as is the case with the
derivative-power technique described in my original approach.

Dario, I would suggest experimenting with zero-phase FIR filters if you're
doing offline music analysis.  This would allow you to iteratively refine
your median "in-place" for different points in time.

– Evan Balster
creator of imitone <http://imitone.com>

On Wed, Feb 17, 2016 at 7:52 AM, STEFFAN DIEDRICHSEN <sdiedrich...@me.com>
wrote:

> This reminds me a bit of the voiced / unvoiced detection for vocoders or
> level independent de-essers. It works quite well.
>
>
> Steffan
>
>
>
> On 17.02.2016|KW7, at 13:08, Diemo Schwarz <diemo.schw...@ircam.fr> wrote:
>
>1. Apply a first-difference filter to input signal A, yielding signal B.
> 2. Square signal A, yielding signal AA; square signal B, yielding
> signal BB.
> 3. Apply a low-pass filter of your choice to AA, yielding PA, and BB,
>yielding PB.
> 4. Divide PB by PA, then multiply the result by the input signal's
> sampling
>rate divided by pi.
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Cheap spectral centroid recipe

[Evan Balster]

Oriol Romani Picas pointed out a few errors in my implementation of the
algorithm above.  Thanks, Oriol!

Specifically, in step 4, the *square root* of PB/PA -- effectively an RMS
-- is used, and we multiply by the sampling rate divided by two pi.
The example
code <http://pastebin.com/EfRv4HRC> has been updated to reflect this.

Apologies for the misinformation and any confusion it might have caused --
I was referencing a very different implementation of the algorithm when
writing the original post.

– Evan Balster
creator of imitone <http://imitone.com>

On Tue, Feb 2, 2016 at 10:35 AM, Risto Holopainen <ebel...@ristoid.net>
wrote:

>
>
> On February 1, 2016 at 7:41:49 pm +01:00, Evan Balster <e...@imitone.com>
> wrote:
>
>
>
>1. Apply a first-difference filter to input signal A, yielding signal
>B.
>2. Square signal A, yielding signal AA; square signal B, yielding
>signal BB.
>3. Apply a low-pass filter of your choice to AA, yielding PA, and BB,
>yielding PB.
>4. Divide PB by PA, then multiply the result by the input signal's
>sampling rate divided by pi.
>
>
> The low-pass filter used in step 3 determines the time-domain weighting
> for the frequency average.  (I recommend a rectangular or triangular
> average.)
>
>
> You don't see that formula as often as the one involving spectral bins,
> but it can be found in a few places such as the DAFX book by Zölzer. It's a
> nice trick when you want to track fast changes in the centroid without
> having to do lots of overlapped windows.
>
> Another simple way if you do an FFT would be to accumulate the amplitude
> of successive bins, counting from 0 Hz upwards as well as from f_s/2
> downwards, stopping at the bin where the summed amplitudes match.
>
> And welcome to the list!
>
> Risto Holopainen
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Cheap spectral centroid recipe

[Evan Balster]

Robert --

Yeah, a DC offset spells trouble for my algorithm -- but it's nothing a bit
of gentle pre-filtering (or a sane ADC) won't solve.

I'll discuss the tangental stuff with you off-list where it doesn't go into
hundreds of inboxes.  :)

– Evan Balster
creator of imitone <http://imitone.com>

On Mon, Feb 1, 2016 at 2:31 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

> >
> > Evan Balster
> > creator of imitone <http://imitone.com>
>
> so Evan, i took a look at your website.  your product looks very cool.  in
> 2013 i worked on something similar (Zya), but cloud based.
>
>
>
> so you clearly have a pitch detector goin' on there.  are you converting
> vocal pitch into fully formed MIDI notes with NoteOn and NoteOff?  if so,
> how well do you detect new notes when the voice glides from one note to
> another, without any kind of attack?  do you try to track it and issue MIDI
> pitch bend?
>
>
>
> just curious.
>
>
>
> --
>
>
>
> r b-j   r...@audioimagination.com
>
>
>
>
> "Imagination is more important than knowledge."
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] Cheap spectral centroid recipe

[Evan Balster]

Hey, all --

First posting here.  I'm an outsider to the DSP world, but I do quite a lot
of DSP research and development.  In the course of my work I have turned up
a number of simple tricks which I imagine would prove handy to other
developers.  I have combed through a handful of classic music-dsp
discussions (eg. pink noise generation) and I get the idea that sharing
techniques is encouraged here -- so I would like to make a habit of doing
this.


To that end:  A handy, cheap algorithm for approximating the power-weighted
spectral centroid -- a signal's "mean frequency" -- which is a good
heuristic for perceived sound brightness
<https://en.wikipedia.org/wiki/Brightness#Brightness_of_sounds>.  In spite
of its simplicity, I can't find any mention of this trick online -- the
literature almost always prescribes FFT.

   1. Apply a first-difference filter to input signal A, yielding signal B.
   2. Square signal A, yielding signal AA; square signal B, yielding signal
   BB.
   3. Apply a low-pass filter of your choice to AA, yielding PA, and BB,
   yielding PB.
   4. Divide PB by PA, then multiply the result by the input signal's
   sampling rate divided by pi.

[example code] <http://pastebin.com/EfRv4HRC>

The low-pass filter used in step 3 determines the time-domain weighting for
the frequency average.  (I recommend a rectangular or triangular average.)


Further exercises for the reader:

   - Advanced differentiation methods may be applied in step 1 to achieve
   superior accuracy for high-frequency content, or equate the group delay of
   the A and B signals.
   - A second-order derivative may be used to compute a standard deviation
   of frequency content in the signal, handy for controlling filter bandwidth.


Lastly, to help readers understand the inaccuracy of the first-difference
filter, I've pictured its magnitude response with 1/pi gain below:

[image: Inline image 1]

(An ideal differentiator would be a straight diagonal line.  The "droop"
can be rendered almost harmless through oversampling.)


Anyway, I hope this is useful to somebody!  I've certainly gotten quite a
lot of mileage out of it.


Evan Balster
creator of imitone <http://imitone.com>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] MIDI Synth Design Advice Please

[Evan Balster]

Hey, Scott --

You may run into unpleasant surprises if you assume a PC processor uses
deterministic time under any circumstances.  Common knowledge
<http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing>
dictates that synchronization primitives, disk access and memory
allocations will give you a world of hurt -- I will assume you're familiar
with those principles.  The more insidious danger is caching -- even
without the OS troubling you, if anything in the system is liable to have
you working outside of a *very *small area of memory (often in the range of
256B - 4KB depending on the CPU), you're going to have L1 and L2 cache hits
and misses which will cause dramatic fluctuations in time usage.

Generally speaking, writing high-performance DSP for modern CPUs is a
matter of optimizing for the worst case.  Buffering improves cache
performance quite a lot, which is why CPU usage rises dramatically as
buffer-size falls -- and also why you almost never see buffers smaller than
about 16 samples.

Evan Balster
creator of imitone
http://imitone.com

On Mon, Feb 1, 2016 at 9:12 AM, Theo Verelst <theo...@theover.org> wrote:

> Scott Gravenhorst wrote:
>
>> I'm looking for advice regarding the design of a MIDI synthesizer.
>> ...
>>
>> Advice regarding this endeavor would be appreciated.  Questions include
>> which of the
>> transfer methods will come closest to my goal of low latency (from time
>> to MIDI message
>> receipt to ..
>>
>
> Hi Scott,
>
> Good to hear you're working with the new PI, it seems you've answered a
> lot of your own questions already!
>
> I haven't looked into everything about the time slicer, memory management
> (+ associated kernel sources about page and segment management) and the
> connections of the various hardware controls with the RPI cores and the
> various memory bus and other kinds of contentions going on, I do recall
> from the Parallella forums that some one was using a Linux boot command
> alteration to make the 2 core Zynq into essentially a 1-core Linux+ free
> core, if you want I could look that up for you.
>
> My experiments with cors and Midi (like my long ago DSO based design
> http://www.theover.org/Synth ) is very good in the sense of getting low
> latency going, so I'd have some interest myself in connecting the graphics
> accelerated, 4-Usb port RPi sensibly to (FPGA based) synthesis modules. It
> seems to me, given that any response speed up to per-sample accurate (i.e.
> one audio sample delay between receipt of message and starting a tone)
> could be your target, the following setup might be interesting to think
> about (not necessarily to implement).
>
> A (or more) midi message(s), or a message coming from a relatively simple
> piece of FPGA that much quicker than MIDI scans a musical keyboard (I have
> some old keyboards lying around that I wouldn't mind turbo charging) could
> be time stamped by FPGA, relatively (but not super fast needed) send to for
> instance the RPI (or a Zynq based linux process, or like in my case a
> classic version 1 RPI) , processed including the time stamp, send back to
> the FPGA or send to a software module, and then WITH FIXED DELAY played
> into the chosen audio stream. That way, latency can be small, but not near
> zero, which in a real time OS is harder, but constant.
>
> Theo V.
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp