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

[Olli Niemitalo]

A simple way to stabilize most quadrature oscillators including
Martin's quadrature oscillator is to multiply each state variable by a
temporary variable:

  g = 1.5 - 0.5*(u*u + v*v)

where u and v are unit-amplitude quadrature oscillator outputs. The
correction does not need to be done very often, but this depends on
the oscillator algorithm and the precision of its state variables. The
variable g is a Taylor approximation of the exact normalization factor
1/sqrt(u*u + v*v) about u*u + v*v = 1. The Taylor approximation can
only lead to oscillator blow-up if u*u + v*v >= 4, and otherwise
corrects the sinusoid amplitude to 1 or below. For u*u + v*v < 2 the
correction brings the amplitude closer to 1. An amplitude error of -92
dB or less will already be corrected to below the quantization error
of double precision floating point state variables, so the
stabilization method need not be more complicated.

-olli
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

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

[Olli Niemitalo]

On Thu, Feb 21, 2019 at 11:16 PM robert bristow-johnson
 wrote:

> But Martin, if you let this thing run for days on end, would not eventually 
> the amplitude of the output change a bit?

Short answer: yes, sometimes significantly for audio purposes when
using 32-bit float state variables, but not significantly when using
64-bit doubles.

Even as poles lie exactly on the unit circle, limited precision in the
state variables leads to rounding errors. Because of the recursive
nature of the algorithm, rounding errors accumulate in manner of a
(pseudo)random walk. Almost always a past state will be encountered
again, and the system enters a limit cycle, locking the error into a
range of error values close to what was accumulated thus far. With
32-bit floating point state variables, sometimes significant numerical
error is accumulated before a limit cycle is entered, depending on
pseudo-luck with the sinusoid frequency. With 64-bit floating point
state variables the problem seems to be almost never significant even
though entering a limit cycle becomes a rare occasion.

The error accumulation and limit cycles can be visualized by plotting
the magnitude of the quadrature pair output of Martin's algorithm
(red), and the same for a Goertzel algorithm based quadrature
oscillator (blue) for comparison, as function of output sample number:

  https://imgur.com/a/cE5R50d

For this plot, 32-bit float variables were used, and rounding mode was
set to round-to-nearest, and angular frequency arbitrarily to (float)
sqrt(2.0) radians to get visible and somewhat lengthy limit cycles.
For the Goertzel algorithm, about 4 periods of a limit cycle, and for
Martin's algorithm, about 2 periods of a limit cycle are visible, for
the first one million output samples.

Based on testing with random frequencies and single (32-bit) and
double (64-bit) precision floating point numbers, compared to
Goertzel, Martin's algorithm tends to have faster error accumulation
(due to a longer cascade of rounded operations per iteration), giving
a larger error, measured as absolute log magnitude, for about 62 % of
random frequencies, both for floats and doubles (tested over 10^4
replications, measured at 10^4 samples generated).

At one million samples generated, the root mean square magnitude error
was roughly 0.0002 for Goertzel and 0.002 for Martin's algorithm using
single precision state variables, and roughly 7*10^-13 for Goertzel
and 3*10^-12 for Martin's algorithm using double precision floating
point state variables (tested over 1000 replications).

C++ test code below.

-olli

// Compile with: g++ -std=c++0x -O3 -ffloat-store -fno-unsafe-math-optimizations
#define _USE_MATH_DEFINES
typedef float FLOAT_TYPE; // float or double
const bool printStats = true; // Print statistics
const bool printData = false; // Print (last) data
#include 
#include 
#include 
#include 
#include 

main() {
  long int numReps = 1000;
  long int numSamples = 1000;
  long int decimate = 1; // Decimate results by this ratio (useful if
huge numReps)
  unsigned seed = std::chrono::system_clock::now().time_since_epoch().count();
  std::mt19937 rng(seed);
  std::uniform_real_distribution uniform(0.0, 1.0);
  int numDecimated = numSamples/decimate + 1;
  long double *magGoertzel = new long double[numDecimated];
  long double *magMartin = new long double[numDecimated];
  long double *sseGoertzel = new long double[numDecimated];
  long double *sseMartin = new long double[numDecimated];
  for (long int count = 0; count < numDecimated; count++) {
sseGoertzel[count] = 0;
sseMartin[count] = 0;
  }
  fesetround(FE_TONEAREST); // FE_TONEAREST, FE_UPWARD, FE_DOWNWARD,
or FE_TOWARDZERO
  long int numGoertzelWorse = 0;
  long int numMartinWorse = 0;
  for (long int rep = 0; rep < numReps; rep++) {
FLOAT_TYPE w = M_PI*uniform(rng);
// Goertzel
FLOAT_TYPE coef = 2*cos(w);
FLOAT_TYPE outHistory1 = 0, outHistory2 = 0;
FLOAT_TYPE input = 1; // First input value
FLOAT_TYPE cosw = cos(w);
FLOAT_TYPE sinw = sin(w);
// Martin
FLOAT_TYPE k1 = tan(w/2);
FLOAT_TYPE k2 = 2*k1/(1 + k1*k1);
FLOAT_TYPE u = 1;
FLOAT_TYPE v = 0;
numDecimated = 0;
for (long int count = 0; count < numSamples; count++) {
  // Goertzel
  FLOAT_TYPE out = input + coef*outHistory1 - outHistory2;
  outHistory2 = outHistory1;
  outHistory1 = out;
  input = 0;
  FLOAT_TYPE re = outHistory1 - outHistory2*cosw;
  FLOAT_TYPE im = outHistory2*sinw;
  // Martin
  FLOAT_TYPE tmp = u - k1*v;
  v = v + k2*tmp;
  u = tmp - k1*v;
  // Results
  if (count % decimate == 0) {
magGoertzel[numDecimated] = sqrt(re*(long double)re + im*(long
double)im);
magMartin[numDecimated] = (FLOAT_TYPE)sqrt(u*(long double)u +
v*(long double)v);
sseGoertzel[numDecimated] += pow(magGoertzel[numDecimated] - 1, 2);
sseMartin[numDecimated] += pow(magMartin[numDecimated] - 1, 2);
numDecimated++;
  }
   

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

[Olli Niemitalo]

On Fri, Feb 22, 2019 at 9:08 AM robert bristow-johnson <
r...@audioimagination.com> wrote:

> i just got in touch with Olli, and this "triangle wave to sine wave"
> shaper polynomial is discussed at this Stack Exchange:
>
>
>
> https://dsp.stackexchange.com/questions/46629/finding-polynomial-approximations-of-a-sine-wave/46761#46761
>
I'll just summarize the results here. The polynomials f(x) approximate
sin(pi/2*x) for x=-1..1 and are solutions with minimum peak harmonic
distortion compared to the fundamental frequency. Both solutions with
continuous and discontinuous derivative are given. In summary:

Shared polynomial approximation properties and constraints:
x = -1..1, f(-1) = -1, f(0) = 0, f(1) = 1, and f(-x) = -f(x).

If continuous derivative:
f'(-1) = 0 and f'(1) = 0 for the anti-periodic extension f(x + 2) = -f(x).

5th order, continuous derivative, -78.99 dB peak harmonic distortion:
f(x) = 1.569778813*x - 0.6395576276*x^3 + 0.06977881382*x^5

5th order, discontinuous derivative, -91.52 dB peak harmonic distortion:
f(x) = 1.570034357*x - 0.6425216143*x^3 + 0.07248725712*x^5

7th order, continuous derivative, -123.8368 dB peak harmonic distortion:
f(x) = 1.570781972*x - 0.6458482979*x^3 + 0.07935067784*x^5
- 0.004284352588*x^7

7th order, discontinuous derivative, -133.627 dB peak harmonic distortion:
f(x) = 1.5707953785726114835*x -
0.64590724797262922190*x^3 + 0.079473610232926783079*x^5
- 0.0043617408329090447344*x^7

Also the exact coefficients that are rational functions of pi are given in
the answer, in case anyone needs more precision.

-olli
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] tracking drum partials

[Olli Niemitalo]

Thomas,

you could try https://github.com/mangledjambon/drumbooth to separate
sinusoidal and impulse-like parts of sounds, and then do your additive
analysis on the sinusoidal part only. The deconstruction is based on Derry
FitzGerald HARMONIC/PERCUSSIVE SEPARATION USING MEDIAN FILTERING, Proc. of
the 13th Int. Conference on Digital Audio Effects (DAFx-10), Graz, Austria
, September 6-10, 2010,
http://dafx10.iem.at/papers/DerryFitzGerald_DAFx10_P15.pdf .

-olli

On Thu, Jul 27, 2017 at 3:08 AM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
>
>
> Thomas, are you recording single isolated drum hits that you analyze?  or
> are you trying to lift this partial information from a drum track with many
> hits?
>
> if the latter, you'll need to do a transient detection which should be
> pretty easy with monophonic drum hits.  if the former, then you just need
> to trim off the silence preceding the onset of the hit.  and the
> Levine/Smith model is good, but you can probably do it most easily on
> isolated drum hits even without much reference.
>
> then you want a window (or a half-window, like the latter half of a Hann
> window) to capture the attack transient and window down to zero at the
> "steady-state".  if there are no snare wires or beads, then i don't think
> there should be much of a noise component after the initial transient that
> you window off.  so what is left after the transient should be a collection
> of decaying sinusoidal partials
>
> since it's a drum and not a string or horn, the partials are not likely
> harmonic.  so then you need to use well-overlapped windowed frames and FFT
> it.  for analysis, the windows need not be a Hann or Hamming or some
> complementary window.  for analysis, i would recommend Gaussian windows
> because each partial will have it's own gaussian bump in the frequency
> domain and there should be very little sidelobe behavior between partials.
>  the frequency and amplitude of the partial should be the horizontal
> location and height of the interpolated peak of each gaussian bump in the
> frequency domain.  remember the phase for a particular partial of a frame
> should be the phase of the same partial in the previous frame plus the
> (angular) frequency times the elapsed time between frames.  that should
> help confirm tracking of the partial to make sure you're connecting each
> partial to it's counterpart in the previous frame.  if you're careful, the
> envelopes should be smooth and mostly monotonically decreasing in amplitude.
>
> then synthesize with basic sinusoidal additive synthesis, adding to the
> windowed attack.
>
> good luck.
>
> r b-j
>
> >
> > Sinusoidal-only modeling could be limiting for some of the intrinsic
> > features of percussive sounds.
> > A possibility would be to encode partials + noise (Serra and Smith, 89)
> > or partials + noise + transients (Levine and Smith, 98).
> >
> >
> >
> > On 7/26/2017 4:37 PM, Thomas Rehaag wrote:
> >>
> >> can anybody tell me how to track drum partials? Is it even possible?
> >> What I'd like to have are the frequency & amplitude envelopes of the
> >> partials so that I can rebuild the drum sounds with additive synthesis.
> >>
> >> I've tried it with heavily overlapping FFTs and then building tracks
> >> from the peaks.
> >> Feeding the results into the synthesis (~60 generators) brought
> >> halfway acceptable sounds. Of course after playing with FFT- and
> >> overlapping step sizes for a while.
> >>
> >> But those envelopes were strange and it was very frustrating to see
> >> the results when I analyzed a synthesized sound containing some simple
> >> sine sweeps this way.
> >> Got a good result for the loudest sweep. But the rest was scattered in
> >> short signals with strange frequencies.
> >>
> >> Large FFTs have got the resolution to separate the partials but a bad
> >> resolution in time so you don't even see the higher partials which are
> >> gone within a short part of the buffer.
> >> With small FFTs every bin is crowded with some partials. And every
> >> kind of mask adds the more artifacts the smaller the FFT is.
> >>
> >> Also tried BP filter banks. Even worse!
> >> It's always resolution in time and frequency fighting each other too
> >> much for this subject.
> >>
>
>
> --
>
>
>
>
> 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 using pair of IIR APFs

[Olli Niemitalo]

Sampo, it is not the poles and zeros that alternate on the real line but
the poles of the two all-pass filter paths. The 90 deg phase difference
band is almost from 0 to Nyquist. In my filter pair they are from 0.001 pi
to 0.999 pi. On z-plane those corner frequencies are at (0.95, 0.003)
and (-0.95, 0.003) so any elliptic or similar function would connect
the two corner frequencies roughly via the real line.

-olli

On Thu, Feb 9, 2017 at 2:57 PM, Sampo Syreeni  wrote:

>
> As I said above, I'm questioning Olli's analysis from a highly
> intuitionistic viewpoint. Typically I'd then be wrong, while Olli does his
> math and can show me to be so. But still, I have to ask. :)
>
> --
> 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] ± 45° Hilbert transformer using pair of IIR APFs

[Olli Niemitalo]

typofix: "and their companion poles" -> "and their companion zeros"

-olli

On Sun, Feb 5, 2017 at 1:52 PM, Olli Niemitalo <o...@iki.fi> wrote:

> 90 deg phase difference all-pass filter pairs... Lemme wave my hands a bit:
>
> It's been years, but I recall I first tried a structure with complex
> conjugate pairs of poles (and their companion poles to make the filters
> all-pass). Globally optimizing that using Differential Evolution, the poles
> "wanted to be" near the real line. The ripples in the phase response
> difference of the optimized filters got finer by having two real poles in
> place of each complex conjugate pair of poles. The real poles and real
> zeros of the two filter paths alternate on the real line like a zebra
> stripe black pearl white pearl necklace. One of the paths is delayed
> (z^-1) by one sample, which gives the "center pearl" pole. I think the
> alternating order reflects the fact that a first-order all-pass filter
> gives a 180 deg phase shift end-to-end, and alternating the poles of the
> two paths corrects the phase response difference up and down so that we can
> stay approximately half-way between 0 deg and 180 deg, at 90 deg. One
> optimization here was to make the filter requirements symmetric around
> frequency pi/4, so that each positive pole can have a negative companion
> pole. This symmetry simplifies the all-pass filter computation.
>
> Artur Krukowski's papers were always over my head.
>
> -olli
>
___
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

[Olli Niemitalo]

90 deg phase difference all-pass filter pairs... Lemme wave my hands a bit:

It's been years, but I recall I first tried a structure with complex
conjugate pairs of poles (and their companion poles to make the filters
all-pass). Globally optimizing that using Differential Evolution, the poles
"wanted to be" near the real line. The ripples in the phase response
difference of the optimized filters got finer by having two real poles in
place of each complex conjugate pair of poles. The real poles and real
zeros of the two filter paths alternate on the real line like a zebra
stripe black pearl white pearl necklace. One of the paths is delayed
(z^-1) by one sample, which gives the "center pearl" pole. I think the
alternating order reflects the fact that a first-order all-pass filter
gives a 180 deg phase shift end-to-end, and alternating the poles of the
two paths corrects the phase response difference up and down so that we can
stay approximately half-way between 0 deg and 180 deg, at 90 deg. One
optimization here was to make the filter requirements symmetric around
frequency pi/4, so that each positive pole can have a negative companion
pole. This symmetry simplifies the all-pass filter computation.

Artur Krukowski's papers were always over my head.

-olli
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Microphones for measuring stuff, your opinions

[Olli Niemitalo]

To make a reference microphone from scratch, one can use reciprocity
calibration. You take three uncalibrated mics that can act as
low-power speakers as well. Not all mics are suitable for this. Then
you pair the three mics the three possible ways. For each pair, the
first mic of the pair will act as a speaker and the second mic will
act as the microphone, and the composite response is measured. The
frequency responses A, B and C of the three mics can be calculated
from the three measured composite frequency responses A*B = X, B*C = Y
and C*A=Z. For the first mic the solution of that group of equations
is A = sqrt(X/Y*Z). All of X, Y, and Z were measured so no prior
knowledge is needed.

-olli

On Wed, Aug 27, 2014 at 10:55 PM, robert bristow-johnson
r...@audioimagination.com wrote:
 On 8/26/14 9:13 PM, julian wrote:

 There are free field, diffuse field and pressure field measurement
 microphone types.


 http://blog.prosig.com/2010/01/19/what-is-the-difference-between-microphone-types/

 The article says there is no big difference but there is a lot in my
 opinion, especially if you are going to hear what you are recording. A
 thing that usually no one never does with that type of mics.


 that has always been a curiosity to me.  why aren't instrumentation mics
 ever used to mic musical instruments?

 like why mic a guitar amp with an SM-57?  why don't we mic them with an
 instrumentation mic and more clearly capture the sound coming outa the
 amp?


 Every measurement mic has its frecuency response curve, a diffuse or
 pressure field one, with too much hi end compensation can be very accurate
 for measurement, but not natural if you use it to record instruments at
 0degres.

 There are a few measurement microphones that made it to the studio, but if
 your intention is to hear also what you record I recommend the use of some
 Neumann or some studio grade mic. They can be as clean and accurate as a
 measurement mic and a bit more natural sounding if you intend to capture
 what we really perceive from an instrument.

 It depends on what are you specifically intent to do.


 so these BK instrumentation mics are not so good for close up where the
 particle velocity is more outa phase with the instantaneous pressure?  is
 that why they don't make good mics for musical sources?

 sorry to be pedantic.  to me, as long as any mic has a known frequency
 response (and it doesn't get too close to any -inf dB nulls in that
 frequency response) and remains LTI, then as long as you don't hafta divide
 by zero, the rest seems to be correction issue in post-processing.  just me
 thinking pedantically about it.

 here's another pedantic question for ya:  when Shure or similar measures a
 mic frequency response curve, don't they do it against some reference
 transducer like a BK?  how does a microphone get calibrated or have its
 frequency response measured without a reference?  what is the seminal
 reference?

 :-/

 just curious.

 --

 r b-j  r...@audioimagination.com

 Imagination is more important than knowledge.




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

Re: [music-dsp] Instant frequency recognition

[Olli Niemitalo]

I see, so the limiting case that turns the inequality to an equality
is a sinusoid (or a corresponding complex exponential). If the signal
is band-limited, it must be a bounded sum of those, and the
derivatives must thus also be bounded sums of derivatives of those,
and your criterion will be satisfied. At least that part of your
theory seems consistent.

-olli

On Wed, Jul 16, 2014 at 1:39 PM, Vadim Zavalishin
vadim.zavalis...@native-instruments.de wrote:
 On 16-Jul-14 12:31, Olli Niemitalo wrote:

 What does O(B^N) mean?

 -olli


 This is the so called big O notation.
 f^(N)(t)=O(B^N) means (for a fixed t) that there is K such that
 |f^(N)(t)|K*B^N
 where f^(N) is the Nth derivative. Intuitively, f^(N)(t) doesn't grow
 faster than B^N

 Regards,
 Vadim





 On Thu, Jul 10, 2014 at 4:02 PM, Vadim Zavalishin
 vadim.zavalis...@native-instruments.de wrote:

 Hi all,

 a recent question to the list regarding the frequency analysis and my
 recent
 posts concerning the BLEP led me to an idea, concerning the theoretical
 possibility of instant recognition of the signal spectrum.

 The idea is very raw, and possibly not new (if so, I'd appreciate any
 pointers). Just publishing it here for the sake of
 discussion/brainstorming/etc.

 For simplicity I'm considering only continuous time signals. Even here
 the
 idea is far from being ripe. In discrete time further complications will
 arise.

 According to the Fourier theory we need to know the entire signal from
 t=-inf to t=+inf in order to reconstruct its spectrum (even if we talk
 Fourier series rather than Fourier transform, by stating the periodicity
 of
 the signal we make it known at any t). OTOH, intuitively thinking, if I'm
 having just a windowed sine tone, the intuitive idea of its spectrum
 would
 be just the frequency of the underlying sine rather than the smeared peak
 arising from the Fourier transform of the windowed sine. This has been
 commonly the source of beginner's misconception in the frequency
 analysis,
 but I hope you can agree, that that misconception has reasonable
 foundations.

 Now, recall that in the recent BLEP discussion I conjectured the
 following
 alternative definition of bandlimited signals: an entire complex
 function
 is bandlimited (as a function of purely real argument t) if its
 derivatives
 at any chosen point are O(B^N) for some B, where B is the band limit.

 Thinking along the same lines, an entire function is fully defined by its
 derivatives at any given point and (therefore) so is its spectrum. So, we
 could reconstruct the signal just from its derivatives at one chosen
 point
 and apply Fourier transform to the reconstructed signal.

 In a more practical setting of a realtime input (the time is still
 continuous, though), we could work under an assumption of the signal
 being
 entire *until* proven otherwise. Particularly, if we get a mixture of
 several static sinusoidal signals, they all will be properly restored
 from
 an arbitrarily short fragment of the signal.

 Now suppose that instead of sinusoidal signals we get a sawtooth. In the
 beginning we detect just a linear segment. This is an entire function,
 but
 of a special class: its derivatives do not fall off smoothly as O(B^N),
 but
 stop immediately at the 2nd derivative. From the BLEP discussion we know,
 that so far this signal is just a generalized version of the DC offset,
 thus
 containing only a zero frequency partial. As the sawtooth transition
 comes
 we can detect the discontinuity in the signal, therefore dropping the
 assumption of an entire signal and use some other (yet undeveloped)
 approach
 for the short-time frequency detection.

 Any further thoughts?

 Regards,
 Vadim

 --
 Vadim Zavalishin
 Reaktor Application Architect
 Native Instruments GmbH
 +49-30-611035-0

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

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


 --
 Vadim Zavalishin
 Reaktor Application Architect
 Native Instruments GmbH
 +49-30-611035-0

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

Re: [music-dsp] a weird but salient, LTI-relevant question

[Olli Niemitalo]

If there, by chance, happens to be a feature in the noise that
catches the ear and creates a sort of (possibly first subconscious)
memory, then the choo-choo effect will be more audible as that feature
can be more easily recognized again, reinforcing the memory. I
generated 10 seconds of Gaussian white noise and can consistently
recognize a certain short rhythmic feature from it. And, minutes after
stopping playback, I can still recall that memory in my mind. It's
even more easy to recognize the periodicity if you train your ears to
recognize a shorter piece before playing back the whole (10 second or
so) loop. So I think it boils down to two things: features and
learning. Learning can also turn non-features into features.

Sampo's test should be carried out multiple times to gather
statistics, and because repetition will aid in reinforcement of the
memory, also the number of repetitions should be controlled or
recorded. How about tap to the rhythm of it?

Feature-stripped noise should work better in some applications than
truly random noise. Perhaps multi-band compression could be used to
level it out.

-olli

On Thu, May 8, 2014 at 9:56 AM, Stefan Stenzel
stefan.sten...@waldorfmusic.de wrote:
 As someone already pointed out, spend an evening to hack a website for this.
 Otherwise I just don’t feel like it’s worth the hassle, this is why-oh-why I 
 don’t.

 Stefan

 On 08 May 2014, at 7:25 , Sampo Syreeni de...@iki.fi wrote:

 Yet why-oh-why doesn't anybody just pop up their Audacity and a few 
 megabytes of randomness, the way I originally asked? Because the stuff I'm 
 talking


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

Re: [music-dsp] Inquiry: new systems for Live DSP

[Olli Niemitalo]

On Fri, Mar 14, 2014 at 4:46 PM, Richard Dobson
richarddob...@blueyonder.co.uk wrote:
 On 14/03/2014 14:27, Olli Niemitalo wrote:

 http://yehar.com/Fast%20Track%20Ultra%2048%20kHz%20output-input%20ir.jpg

 It looks more like a minimum-phase lowpass filter. The marker at
 sample #29 indicates what PortAudio thinks the latency is: 29 samples.

 But portaudio only states the software i/o buffer latency, it knows nothing
 directly of internal codec latencies.

OK, my misunderstanding, I simply used paStreamInfo-inputLatency +
paStreamInfo-outputLatency.

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

Re: [music-dsp] Frequency bounded DSP

[Olli Niemitalo]

There are no exactly bandlimited functions that have non-zero-length
constant-valued intervals in the time domain. So any transients in an
exactly bandlimited time domain signal will have to be premeditated. You
can't keep a signal exactly bandlimited if you make a causal decision at
some point in time that you want to introduce a change in the signal. This
is reflected in the fact that there is no minimum phase analog of a sinc
function, unless you count an infinitely delayed sinc as one.

In the real world things need not be exact though!

-olli


On Fri, Jan 3, 2014 at 8:03 PM, Wen Xue mr.x@gmail.com wrote:

 i have an impression that no band-limited signal can remain constant for
 any duration above zero. if that holds then one just can't switch it on and
 off and still expect it bounded below nyquist.

 w.x

 
 


 -Original Message- From: Theo Verelst
 Sent: Saturday, January 04, 2014 12:46 AM

 To: A discussion list for music-related DSP
 Subject: Re: [music-dsp] Frequency bounded DSP


 Well, the questions are good, there's a reason for trying to make a
 theoretically bandwidth limited wave and envelope, and if possible also
 modulations, or something that resembles modulations.

 The AM example is random in itself, but indeed says something about
 the possibility to modulate a wave, and that there's then as a result an
 infinitely correct expression for a wave that can be sampled error free.

 Of course if somehow magically or not you are able to say I have this
 function or this set of samples, for which you know that the
 spectrum is limited, there's no reason not to use that, and to multiply
 an equally known-as-limited envelope with that.

 But what I did was make sure all the normal theory should be without
 problems, yet without creating a difficult equation. Like I said,
 there's nothing wrong with taking *any* number of sine waves, as long as
 each individual sine wave is lower than Nyquist, and add them up with
 any phase relation, to create an actually perfectly bandwidth limited
 wave. Good.

 But now we switch the wave on at some point. Or we want to determine the
 theoretical spectrum of a non-repeating envelope, how can we, preferably
 in an elegant and/or simple enough way, get this done ? Hint: a step
 function has infinite spectrum.

 Oh, and another thing: an iFFT creates sine waves, so that's cool. But
 for many tonal applications, there's only a pretty limited number of
 frequencies that properly fit in the bins of the FFT. Surely there are
 also Equal Loudness Curve and limiting the mid-range reflections
 criteria to add to the perfectly re-constructable waves idea.

 T.V.

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

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

Re: [music-dsp] OSC problem on STM32F4Discovery

[Olli Niemitalo]

On Tue, Apr 10, 2012 at 12:06 PM, Julian Schmidt
julian_schm...@chipmusik.de wrote:
 okay, i used exactly RBJs code with 1024 samples tablesize and  I get a  -60
 dB spectral distortion floor.

That's again what no interpolation would give, so probably there is
a bug in the interpolation code, like RBJ suggested in the renamed
thread.

Here are formulas for spectral distortion floor for a sinusoidal wavetable:

No interpolation:
20*ln(N*sin(pi/N)/(pi*(N-1)))/ln(10) dB

Linear interpolation:
40*ln(N*sin(pi/N)/(pi*(N-1)))/ln(10) dB

N is the wavetable size in samples.

 if i output silence to the codec and run the osc code in the background
 without outputting it i can see harmonics corresponding to the oscillator
 frequency in the FFT at around -66 to -72dB.

Gah! Not too hi-fi.

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

Re: [music-dsp] OSC problem on STM32F4Discovery

[Olli Niemitalo]

On Tue, Apr 10, 2012 at 12:06 PM, Julian Schmidt
julian_schm...@chipmusik.de wrote:
 okay, i used exactly RBJs code with 1024 samples tablesize and  I get a  -60
 dB spectral distortion floor.

That's again exactly what no interpolation gives, so probably there is
a bug in the interpolation code, like RBJ suggested in the renamed
thread.

Here are formulas for spectral distortion floor for a sinusoidal wavetable:

No interpolation:
20*ln(N*sin(pi/N)/(pi*(N-1)))/ln(10) dB

Linear interpolation:
40*ln(N*sin(pi/N)/(pi*(N-1)))/ln(10) dB

N is the wavetable size in samples.

 if i output silence to the codec and run the osc code in the background
 without outputting it i can see harmonics corresponding to the oscillator
 frequency in the FFT at around -66 to -72dB.

Gah! Not too hi-fi.

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

Re: [music-dsp] OSC problem on STM32F4Discovery

[Olli Niemitalo]

On Tue, Apr 10, 2012 at 6:54 PM, Nigel Redmon earle...@earlevel.com wrote:
 Clicks, especially 2-3 seconds apart doesn't describe aliasing

Here are clicks created by aliasing for you to listen (loudness warning!):

http://wurstcaptures.untergrund.net/music/?oneliner=256*t*440%2F44002.75oneliner2=t0=0tmod=0duration=10separation=100rate=44100

They repeat more often than 2-3 seconds apart though.

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

Re: [music-dsp] OSC problem on STM32F4Discovery

[Olli Niemitalo]

If you don't interpolate the wavetable then you may be simply getting
some aliasing problems. Every Nth cycle of the generated waveform will
be one sample shorter than the others, and that will sound like a
click. Try setting your phaseInc to an integer value. Also, somewhere
along the analog signal chain you may be getting nonlinearities with
the Gibbs phenomenon peaks if you are running your wavetable
oscillator at full-scale amplitude. Try reducing the wavetable
amplitude.

-olli

On Mon, Apr 9, 2012 at 4:28 PM, Julian Schmidt
julian_schm...@chipmusik.de wrote:

 phase += phaseInc(440); // calculate the phase increment for 440 hz and add
 it to phase
 if(phase = TABLESIZE) phase -= TABLESIZE;
 return phase/TABLESIZE;

 [...] My problem is that i get periodic amplitude modulations on the overtones
 about 2-3 times a second.
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] OSC problem on STM32F4Discovery

[Olli Niemitalo]

On Mon, Apr 9, 2012 at 7:17 PM, Julian Schmidt
julian_schm...@chipmusik.de wrote:

 setting the phase increment to an integer value solves the problem.
 [...]
 adding linear or cubic interpolation makes it a little better, but the
 pulsing is still very audible.
 [...]
 The nearer i get to an integer phase increment, the slower the amplitude
 of the harmonics is pulsating. at an integer value it stops.

All of these findings support the hypothesis that it is an aliasing
problem. So it doesn't need to have to do with phase wrapping. Saw
wave and similarly discontinuous waveforms are particularly nasty when
it comes to aliasing problems because the harmonics decay so slowly
(amplitude of Nth harmonic = 1/N). I bet the reason why you had so
little problems with the sine wave is because it was greatly
oversampled (that is, the highest frequency, in this case the
fundamental frequency, is less than sampling frequency / 2).

Do a mental check on what the bandwidth of your wavetable is, and
whether you will get aliasing by playing back the wavetable at a
different rate than 1:1 and by resampling it to the target sampling
frequency.

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

Re: [music-dsp] OSC problem on STM32F4Discovery

[Olli Niemitalo]

On Mon, Apr 9, 2012 at 11:32 PM, Julian Schmidt
julian_schm...@chipmusik.de wrote:
 I really think it is an aliasing problem.
 but not due to the wrong wavetable content, but due to a cheap audio codec
 with poor filters.
 [...]
 even when i output a single 440hz sine i get harmonics starting at -48db up
 to nyquist and beyond.

Lemme guess your wavetable size is 256? That's the amount of
distortion that would be expected from using no interpolation. If
that's what you have then the codec is not at fault.

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

Re: [music-dsp] OSC problem on STM32F4Discovery

[Olli Niemitalo]

On Tue, Apr 10, 2012 at 12:25 AM, Julian Schmidt
julian_schm...@chipmusik.de wrote:
 Am 09.04.2012 23:22, schrieb Olli Niemitalo:

 On Mon, Apr 9, 2012 at 11:32 PM, Julian Schmidt
 julian_schm...@chipmusik.de  wrote:

 I really think it is an aliasing problem.
 but not due to the wrong wavetable content, but due to a cheap audio
 codec with poor filters.
 [...]
 even when i output a single 440hz sine i get harmonics starting at -48db
 up to nyquist and beyond.

 Lemme guess your wavetable size is 256? That's the amount of
 distortion that would be expected from using no interpolation. If
 that's what you have then the codec is not at fault.

 i use code similar to what RBJ has posted with linear interpolation
 (although with a tablesize of 256 at the moment).

Okay, that should give a -96 dB spectral distortion floor for a
single-sinusoid wavetable, compared to your -48 dB. If the codec is
causing all that then it should also show up if you use a sin()
function instead of playing back the wavetable. I'm just a bit
skeptical because the specs of the codec don't seem that bad.

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

Re: [music-dsp] very cheap synthesis techniques

[Olli Niemitalo]

On Wed, Feb 29, 2012 at 1:37 AM, Andrew Jerrim andrew.jer...@gmail.com wrote:
 [On bytebeat:] Oooh, Olli - that's fantastic! Wouldn't that make a great 
 little phone app :)

There's Glitch Machine for iPhone/iPad, does much the same but in
reverse Polish notation.

http://madgarden.net/apps/glitch-machine/

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

Re: [music-dsp] stereo-wide pan law?

[Olli Niemitalo]

On Fri, Feb 10, 2012 at 8:48 AM, Ross Bencina
rossb-li...@audiomulch.com wrote:

 On 9/02/2012 11:02 AM, Jerry wrote:

 (Good grief, people.) You want the *very famous* Bauer's Law of Sines:
...
 Sin theta_I   (S_l - S_r)
 --- = ---
 Sin theta_A   (S_l + S_r)

 Solving for S_l^2 + S_r^2 = 1 it seems to work very well for my needs. It
 doesn't suffer from the dip in level in the middle which Olli's previous
 solution did.

 For my case I set the speaker angle very narrow (7.5 degrees) so that I can
 get extreme-antiphase gain out of the equations.

Got something like this?

  S_r = (0.7071 sin(theta_I) + 0.09230) / sqrt(sin(theta_I)^2 + 0.01703)

I wonder about the very narrow speaker angle. For a mono input signal,
the normalization S_l^2 + S_r^2 = 1 would work perfectly for a speaker
angle theta_A = 45 degrees. Bauer gives for a speaker angle theta_A =
45 degrees a maximum negative ratio between S_l and S_r as 0.17. Maybe
this is too little for your purposes, so it is a good idea to put the
speakers closer together. But for arbitrary values of theta_A, a
correct normalization for a mono input signal is defined in terms of
the length of the sum vector as

  sqrt((S_l + S_r*cos(2*theta_A))^2 + (S_r*sin(2*theta_A))^2) = 1
  == (S_l + S_r*cos(2*theta_A))^2 + (S_r*sin(2*theta_A))^2 = 1
  == 2*S_l*S_r*cos(2*theta_A) + S_l^2 + S_r^2 = 1
  == S_l = sqrt(1 - S_r^2*sin(2*theta_A)^2) - r*cos(2*theta_A).

An equilateral triangle between the speakers and the listener is often
recommended for stereo listening, meaning theta_A = 30 degrees. In
this configuration, Bauer says, you can get a negative ratio between
S_l and S_r of up to 1/3, about the same what you currently use at
most, -0.313. Doing the normalization according to the equilateral
triangle speaker-head-speaker configuration theta_A = 30 and applying
Bayer's law of sines, this is what gets spit out:

  S_r = (1 - 2*sin(theta_I)) / sqrt(4*sin(theta_I)^2 + 3)

There is a slight dip (S_r = S_i = 0.577) in the middle, but it's not
an effective dip with that speaker configuration. Also the loudness of
the in-phase speaker increases beyond unity going past the point
theta_I = +-theta_A. Another justification for the S_l^2 + S_r^2 = 1
normalization might be that left and right inputs are independent, but
that cannot be the because the theory here is based on mono input and
in-phase or opposite polarity speaker output. Anyhow, if the dip or
the excess loudness puts you off, there's still the case theta_A = 45
degrees to explore. What it yields is

  S_r = (sqrt(1/2) - sin(theta_I)) / sqrt(2*sin(theta_I)^2 + 1.

No dip and it behaves nicely: The in-phase speaker loudness peaks at
theta_I = +-theta_A. But as said, you don't get very large opposite
polarity values out of it.

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

Re: [music-dsp] stereo-wide pan law?

[Olli Niemitalo]

Knowing that you're panning chorus voices to be summed with the input
signal gives something to work on.

Let's say there's just one chorus voice and someone sets up the
delays, volume and whatnot so that it is actually identical to the
input signal. Now, it would be unreasonable if, compared to input, the
output would have an opposite polarity in L or R. So, the most extreme
panning should be no more extreme than to have a gain of -1 in either
channel of the chorus voice. Let's define exactly that as the most
extreme setting. So at extreme-L or extreme-R, output R or L will be
muted. Now, at the same time, what should the gain of the other chorus
voice channel be? In all fairness, it should be as loud as the
inverted other channel, so the gain should be at least 1. It would
also be weird if it was louder than the input signal, so let's fix the
value at exactly 1.

Done all that, the extended-range panning of the chorus voice
effectively amplifies the input signal by 6 dB and pans it in the
regular fashion. So you might require that in the described situation,
the output, with respect to the input, is panned by your favorite
panning law f(p), where p = -1..1, such that the total gains of the
two channels are 2*f(p) and 2*f(-p). We can write the extended-range
panning law g in terms of f as:

1 + g(p) = 2*f(p)
== g(p) =2*f(p) - 1
== g(p) = f(p) - 0.5

For a chorus voice, as channel gains, use g(p) = f(p) - 0.5 and g(-p)
= f(-p) - 0.5, where p = -1..1 is the panning and f(p) is a vanilla
panning law of your choice. This means that with g(p), you will have
to re-label full left and full right to mean the values of p for
which f(p) = 0.5 or f(-p) = 0.5. Consequently, f(p) can't be a linear
panning law, but must satisfy f(0)  0.5. A constant-power panning law
can be used as f(p).

Well, that's the best I could come up with!

-olli

On Wed, Feb 8, 2012 at 8:10 AM, Ross Bencina rossb-li...@audiomulch.com wrote:
 What I'm aiming to achieve is one slider that can pan each voice between
 from left to right, and also smoothly cross into dubious beyond the
 speakerness by sending inverse phase to the opposite speaker. It could be
 as simple as ramping up the inverse phase signal but I thought it might be
 possible to formulate something that has some kind of basis in stereo
 panning law theory -- not necessarily concerning spatial perception but at
 least concerning perceived signal energy.
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] stereo-wide pan law?

[Olli Niemitalo]

On Tue, Feb 7, 2012 at 12:20 PM, Ross Bencina
rossb-li...@audiomulch.com wrote:
 Hi Everyone,

 Does anyone know if there's a standard way to calculate pan laws for
 stereo-wide panning ?

 By stereo-wide I mean panning something beyond the speakers by using
 180-degree shifted signal in the opposite speaker.

You could cook up something from the Dolby Stereo mixing matrix, but
the implementation is going to need a Hilbert transformer.

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

Re: [music-dsp] anyone care to take a look at the Additive synthesis article at Wikipedia?

[Olli Niemitalo]

No, it was my doing that the paragraphs had the synth name as their
first word(s). We don't have the or a/an in the Finnish language,
so I'm not always sure if they are needed, like in front of names (of
synthesizers) here. But I'm going to claim that most of that text
looked even worse before. :-)

-olli

On Mon, Jan 16, 2012 at 6:16 PM, robert bristow-johnson
r...@audioimagination.com wrote:
 On 1/16/12 1:16 AM, Nigel Redmon wrote:

 Nice improvements.

 This may seem like nitpicking, but the Timeline of additive synthesizers
 section seems to choose keeping the instrument name as the start of the
 sentence over proper grammar. For instance:

   Hammond organ, invented in 1934[26], is an electronic organ that uses
 nine drawbars to mix several harmonics, which are generated by a set of
 tonewheels.

 This should either read

   The Hammond organ, invented in 1934[26], is an electronic organ that
 uses...

 or something like

   Hammond organ—invented in 1934[26], the Hammond organ is an electronic
 organ that uses...

 or

   Hammond organ: Invented in 1934[26], the Hammond organ is an electronic
 organ that uses...

 (Note that one entry, EMS Digital Oscillator Bank (DOB) and Analysing
 Filter Bank: According to..., does it this way already.)

 You have enough cooks working on that page right now, so I'd rather leave
 it up to you guys what route you go. But if you use a sentence, it should
 read like one.


 well, there is evidence that Clusternote is from Japan.  dunno if these
 sentences were written by him.

 i wouldn't discourage you from editing at all.

 L8r,


 --

 r b-j                  r...@audioimagination.com

 Imagination is more important than knowledge.



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

Re: [music-dsp] A theory of optimal splicing of audio in the timedomain.

[Olli Niemitalo]

That won't be a problem if you measure the correlation locally, but
how exactly? Certainly anything outside the cross-fade region should
be excluded from the measurement. And inside it matters most wherever
the mixing ratio is close to 50-50, as in that cases phase difference
of the two signals gives the greatest contribution to the resulting
measurable volume envelope of the mixed signal. Probably the data
should be windowed for measurement of correlation (and volume),
depending on the mixing function...

-olli

On Fri, Jul 15, 2011 at 2:24 PM, Wen Xue xue@eecs.qmul.ac.uk wrote:
 I have the following made-up scenarios -
 1) If I twist the 2nd half of some x(t) by 180 degrees then it becomes
 orthogonal to the original x(t). How do we cross-fade it with x(t)?
 2) If I twist the 1st third of x(t) by 180 degrees and 3rd third by 90
 degrees?
 3) If I twist 2nd and 4th and quarters of x(t) by 180 degrees?
 In all such cases the correlation is 0. Do we cross-fade them in the same
 way?

 Xue



 -Original Message-
 My objective has not been to find a method for automatic splicing, but
 to do nice cross-fades at given splice points.

 There were multiple objectives:
 * Intuitive definition of the cross-fade shape. Mixing ratio as a
 function of time is a good definition.
 * For stationary signals, there should be no clicks or transients
 produced. This is taken care of by the smoothness of the cross-fade
 envelopes.
 * For stationary signals, the resulting measurable transition from the
 volume level of signal 1 to volume level of signal 2 should follow the
 chosen cross-fade shape. This can be accomplished knowing the volume
 levels of the two signals and the correlation coefficient between the
 two signals.

 -olli

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

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

Re: [music-dsp] A theory of optimal splicing of audio in the time domain.

[Olli Niemitalo]

On Thu, Jul 14, 2011 at 9:22 PM, robert bristow-johnson
r...@audioimagination.com wrote:

      g(t)  =  1/sqrt( (1+r)/2 + 2*(1-r)*(p(t))^2 )

 might this result match what you have?

Yes! I only derived the formula for the linear ramp, p(t) = t/2,
because one can get the other shapes by warping time and I didn't want
to bloat the cumbersome equations. With the linear ramp our results
match exactly.

 okay.  i would still like to hunt for a splice displacement around that
 quiet region that would have correlation better than zero

Sometimes you are stuck with a certain displacement. Think drum loops;
changing tau would change tempo.

 i think it's better to define p(t) (with the same restrictions as o(t)) and 
 find g(t) as a
 function of r than it is to do it with o(t) and e(t).

I agree, even though the theory was quite elegant with o(t) and e(t)...

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

Re: [music-dsp] A theory of optimal splicing of audio in the time domain.

[Olli Niemitalo]

On Sat, Jul 9, 2011 at 10:53 PM, robert bristow-johnson
r...@audioimagination.com wrote:
 On Dec 7, 2010, at 5:27 AM, Olli Niemitalo wrote:

  [I] chose that the ratio a(t)/a(-t) [...] should be preserved

 by preserved, do you mean constant over all t?

Constant over all r.

 what is the fundamental reason for preserving a(t)/a(-t) ?

I'm thinking outside your application of automatic finding of splice
points. Think of crossfades between clips in a multi-track sample
editor. For a cross-fade in which one signal is faded in using a
volume envelope that is a time-reverse of the volume envelope using
which the other signal is faded out, a(t)/a(-t) describes by what
proportions the two signals are mixed at each t. The fundamental
reason then is that I think it is a rather good description of the
shape of the fade, to a user, as it will describe how the second
signal swallows the first by time. The user might choose one shape
for a particular crossfade. Then, depending on the correlation between
the superimposed signals, an appropriate symmetrical volume envelope
could be applied to the mixed signal to ensure that there is no peak
or dip in the contour of the mixed signal. Because the envelope is
symmetrical, applying it preserves a(t)/a(-t). It can also be
incorporated directly into a(t).

All that is not so far off from the application you describe.

 but i don't think it is necessary to deal with lags where Rxx(tau)  0.  why
 splice a waveform to another part of the same waveform that has opposite
 polarity?  that would create an even a bigger glitch.

Splicing at quiet regions with negative correlation can give a smaller
glitch than splicing at louder regions with positive correlation. This
applies particularly to rhythmic material like drum loops, where the
time lag between the splice points is constrained, and it may make
most sense to look for quiet spots. However, if it's already so quiet
in there, I don't know how much it matters what you use for a
cross-fade.

Apart from it's so quiet it doesn't matter, I can think of one other
objection against using cross-fades tailored for r  0: For example,
let's imagine that our signal is white noise generated from a Gaussian
distribution, and we are dealing with given splice points for which
Rxx(tau)  0 (slightly). Now, while the samples of the signal were
generated independently, there is by accident a bit of negative
correlation in the instantiation of the noise, between those splice
points. Knowing all this, shouldn't we simply use a constant-power
fade, rather than a fade tailored for r  0, because random deviations
in noise power are to be expected, and only a constant-power fade will
produce noise that is statistically identical to the original. I would
imagine that noise with long-time non-zero autocorrelation (all the
way across the splice points) is a very rare occurrence. Then again,
do we really know all this, or even that we are dealing with noise.

I should note that Rxx(tau)  0 does not imply opposite polarity, in
the fullest sense of the adjective. Two equal sinusoids that have
phases 91 degrees apart have a correlation coefficient of about
-0.009.

RBJ, I'd like to return the favor and let you know that I have great
respect for you in these matters (and absolutely no disrespect in any
others :-) ). Hey, I wonder if you missed also my other post in the
parent thread? You can search for
AANLkTim=eM_kgPeibOqFGEr2FdKyL5uCCB_wJhz1Vne

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

Re: [music-dsp] Factorization of filter kernels

[Olli Niemitalo]

Find the roots, pair the complex conjugate roots and distribute the
pairs and single real roots evenly (how exactly?) in the two filters.
Matlab at least has facilities finding roots of large polynomials.

-olli

On Wed, Jan 19, 2011 at 4:56 PM, Uli Brueggemann
uli.brueggem...@gmail.com wrote:
 Hi,

 thanks for the answer so far.
 A polyphase filter is a nice idea but it does not answer the problem.
 The signal has to be demultiplexed (decimated), the different streams
 have to be filtered, the results must be added to get the final output
 signal.

 My question has a different target.
 Imagine you have two system (e.g. some convolution  boards with DSP).
 Each system can just run a 512 tap filter. Now I like to connect the
 two systems in series to mimic a desired 1024 tap filter. The 1024
 kernel is known and shall be generated by the two 512 tap filters.
 So what's a best way to decompose the known kernel into two parts ? Is
 there any method described somewhere?

 Uli


 2011/1/19 João Felipe Santos joao@gmail.com:
 Hello,

 a technique that allows something similar to what you are suggesting
 is to use polyphase filters. The difference is that you will not
 process contiguous vectors, but (for a 2-phase decomposition example)
 process the even samples with one stage of the filter and the odd
 samples with another stage. It is generally used for multirate filter
 design, but it makes sense to use this kind of decomposition if you
 can process the stages in parallel... or at least it is what I think
 makes sense.

 You can search for references to this technique here [1] and here [2].
 A full section on how to perform the decomposition is presented on
 Digital Signal Processing: a Computer-based approach by Sanjit K.
 Mitra.

 [1] 
 http://www.ws.binghamton.edu/fowler/fowler%20personal%20page/EE521_files/IV-05%20Polyphase%20FIlters%20Revised.pdf
 [2] https://ccrma.stanford.edu/~jos/sasp/Multirate_Filter_Banks.html

 --
 João Felipe Santos



 On Tue, Jan 18, 2011 at 5:46 AM, Uli Brueggemann
 uli.brueggem...@gmail.com wrote:
 Hi,

 a convolution of two vectors with length size n and m gives a result
 of length n+m-1.
 So e.g. two vectors of length 512 with result in a vector of length 1023.

 Now let's assume we have a vector (or signal or filter kernel) of size
 1024, the last taps is 0.
 How to decompose it to two vectors of half length? The smaller vectors
 can be of any arbitrary contents but their convolution must result
 must be equal to the original vector.

 It would be even interesting to factorize  given kernel into n
 smaller kernels. Again the smaller kernels may have any arbitrary but
 senseful contents, they can be identical but this is not a must.

 Is there a good method to carry out the kernel decomposition? (e.g.
 like calculating n identical factors x of a number y by x =
 Exp(Log(y)/n) with x^n = x*x*...*x = y)

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

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

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

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