Re: [music-dsp] Practical filter programming questions

[Nigel Redmon]

Hi Frank—As far as I know, GPU processing of audio in plug-ins is pretty rare, 
and I don’t know that it would be a great fit for filters, but you can recall 
coefficients as needed (as Davide pointed out), and interpolation between 
points my be OK, it would take some analysis and dependent on the interpolation 
accuracy…mainly I wanted to say you might try kvraudio DSP forum, where 
practical synth filters have been discussed quite a bit over the years.

> On Jan 11, 2020, at 10:06 PM, Frank Sheeran  wrote:
> 
> I have a couple audio programming books (Zolzer DAFX and Pirkle Designing 
> Audio Effect Plugins in C++).  All the filters they describe were easy enough 
> to program.
> 
> However, they don't discuss having the frequency and resonance (or whatever 
> inputs a given filter has--parametric EQ etc.) CHANGE.
> 
> I am doing the expensive thing of recalculating all the coefficients every 
> sample, but that uses a lot of CPU.
> 
> My questions are:
> 
> 1. Is there a cheaper way to do this?  For instance can one pre-calculate a 
> big matrix of filter coefficients, say 128 cutoffs (about enough for each 
> semitone of human hearing) and maybe 10 resonances, and simply interpolating 
> between them?  Does that even work?
> 
> 2. when filter coefficients change, are the t-1 and t-2 values in the 
> pipeline still good to use?  I am using them and it SEEMS fine but now and 
> then the filters in rare cases go to infinity (maybe fast changes with high 
> resonance?) and I wonder if this is the cause.
> 
> 3. Would you guess that most commercial software is using SIMD or GPU for 
> this nowadays?  Can anyone confirm at least some implementations use SIMD or 
> GPU?
> 
> Frank

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

Re: [music-dsp] high & low pass correlated dither noise question

[Nigel Redmon]

> Rolling one die at a time, or two,

Read: Rolling one die at a time, OF two,

> On Jun 27, 2019, at 9:00 AM, Nigel Redmon  wrote:
> 
> I think this becomes more obvious if you separate out the random and the 
> filtering:
> 
> Rolling one die at a time, or two, is equivalent to rolling one die, but 
> writing down or remembering the previous value before the roll. In there 
> words, it’s like a like having a delay element to use for the sum or 
> difference, and that gives the lowpass or highpass response.
> 
> But if we remove the filter and just look at rolling dice:
> 
> Rectangular PDF: roll one die each time
> 
> Triangular PDF: roll two dice each time, take the sum
> 
> Gaussian: roll a bunch of dice (to whatever degree of accuracy you want, but 
> six is pretty good) each time, take the sum
> 
> So, if you want the same highpass filtering as the algorithm you gave, but 
> with Gaussian noise, generate Gaussian, then run it though a one-zero 
> highpass.
> 
> As to whether that’s worth it…I assume you’re just experimenting
> 
> 
>> On Jun 27, 2019, at 7:42 AM, Alan Wolfe > <mailto:alan.wo...@gmail.com>> wrote:
>> 
>> I read a pretty cool article the other day:
>> https://www.digido.com/ufaqs/dither-noise-probability-density-explained/ 
>> <https://www.digido.com/ufaqs/dither-noise-probability-density-explained/>
>> 
>> It says that if you have two dice (A and B) that you can roll both dice and 
>> then...
>> 1) Re-roll die A and sum A and B
>> 2) Re-roll die B and sum A and B
>> 3) Re-roll die A and sum A and B
>> 4) repeat to get a low pass filtered triangular noise distribution.
>> 
>> It says that you can modify it for high pass filtered triangle noise by 
>> rolling both dice and then...
>> 1) Re-roll die A and take A - B
>> 2) Re-roll die B and take B - A
>> 3) Re-roll die A and take A - B
>> 4) repeat to get a high pass filtered triangular noise distribution.
>> 
>> What i'm wondering is, what is the right thing to do if you want to do this 
>> with more than 2 dice? (going higher order)
>> 
>> For low pass filtered noise with 3+ more dice (which would be more gaussian 
>> distributed than triangle), would you only re-roll one die each time, or 
>> would you reroll all BUT one die each time.
>> 
>> I have the same question about the high pass filtered noise with 3+ more 
>> dice, but in that case I think i know what to do about the subtraction 
>> order...  I think the right thing to do if you have N dice is to sum them 
>> all up, but after each "roll" you flip the sign of every die.
>> 
>> What do you guys think?
> 
> ___
> 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 & low pass correlated dither noise question

[Nigel Redmon]

I think this becomes more obvious if you separate out the random and the 
filtering:

Rolling one die at a time, or two, is equivalent to rolling one die, but 
writing down or remembering the previous value before the roll. In there words, 
it’s like a like having a delay element to use for the sum or difference, and 
that gives the lowpass or highpass response.

But if we remove the filter and just look at rolling dice:

Rectangular PDF: roll one die each time

Triangular PDF: roll two dice each time, take the sum

Gaussian: roll a bunch of dice (to whatever degree of accuracy you want, but 
six is pretty good) each time, take the sum

So, if you want the same highpass filtering as the algorithm you gave, but with 
Gaussian noise, generate Gaussian, then run it though a one-zero highpass.

As to whether that’s worth it…I assume you’re just experimenting


> On Jun 27, 2019, at 7:42 AM, Alan Wolfe  wrote:
> 
> I read a pretty cool article the other day:
> https://www.digido.com/ufaqs/dither-noise-probability-density-explained/ 
> 
> 
> It says that if you have two dice (A and B) that you can roll both dice and 
> then...
> 1) Re-roll die A and sum A and B
> 2) Re-roll die B and sum A and B
> 3) Re-roll die A and sum A and B
> 4) repeat to get a low pass filtered triangular noise distribution.
> 
> It says that you can modify it for high pass filtered triangle noise by 
> rolling both dice and then...
> 1) Re-roll die A and take A - B
> 2) Re-roll die B and take B - A
> 3) Re-roll die A and take A - B
> 4) repeat to get a high pass filtered triangular noise distribution.
> 
> What i'm wondering is, what is the right thing to do if you want to do this 
> with more than 2 dice? (going higher order)
> 
> For low pass filtered noise with 3+ more dice (which would be more gaussian 
> distributed than triangle), would you only re-roll one die each time, or 
> would you reroll all BUT one die each time.
> 
> I have the same question about the high pass filtered noise with 3+ more 
> dice, but in that case I think i know what to do about the subtraction 
> order...  I think the right thing to do if you have N dice is to sum them all 
> up, but after each "roll" you flip the sign of every die.
> 
> What do you guys think?

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

Re: [music-dsp] Job posts?

[Nigel Redmon]

As long as it’s related, I’ve never seen anyone complain here.

> On Mar 19, 2019, at 7:42 AM, Bram de Jong  wrote:
> 
> Hey MusicDSP,
> 
> what is the general feeling about job posts / spam on this list?
> of course I'm talking about something very related to the list (i.e. plugin 
> development in specific).
> 
> Bram


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

Re: [music-dsp] Sound Analysis

[Nigel Redmon]

> However when run on the Hammond recording, it's detecting a wavelength of 
> perhaps 0.7 cent off.

Interesting…I looked at this quickly, not an authority, but power line 
frequency regulation (Hammond relying on synchronous motors for pitch, of 
course)—in North America for 60 Hz—is adjusted for long term accuracy by ± 0.02 
Hz. At 60 Hz, 0.7 cents is about 0.024 Hz (that is, 60.02 is about +0.6 cents 
sharp)...



> On Jan 1, 2019, at 4:45 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 known 
> wavelength (I know the exact frequency of each wheel) but to do so would make 
> the utility program less general-purpose.
> 
> Best regards,
> Frank Sheeran
> 
> ___
> 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] WSOLA on RealTime

[Nigel Redmon]

I think if you try to code up a simple pitch shifter—say, with linear 
interpolation—you’ll figure it out pretty quickly. You have to write a sample 
before you read it, obviously, and to pitch up, the read pointer is moving 
faster than the write pointer—or slower to pitch down. The faster one will 
overtake the slower in a circular buffer. The bigger the buffer (and more 
initial delay to pitch up), the longer you can go before the collision, but the 
farther you get from anything resembling real time.

Depending on the circumstances, you can do tricks like resetting the read 
pointer (like a ramp waveform), relative to write, and chop up the audio. For 
instance, I did that in Echo Farm for the reverse echos. But as Robert said, if 
you stretch/compress time, and do pitch shifting up/down but he same factor, 
your position doesn’t grow or shrink over time. You just have a constant delay.

> On Oct 1, 2018, at 10:00 AM, Alex Dashevski  wrote:
> 
> Hi,
> Yes. I have seen it but I didn't find the answer on my question.
> 
> 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] Antialiased OSC

[Nigel Redmon]

Arg, no more lengthy replies while needing to catch a plane. Of course, I 
didn’t mean to say Alesis synths (and most others) were drop sample—I meant 
linear interpolation. The point was that stuff that seems to be substandard can 
be fine under musical circumstances...

Sent from my iPhone

> On Aug 6, 2018, at 11:57 AM, Nigel Redmon  wrote:
> 
> Hi Robert,
> 
> On the drop-sample issue:
> 
> Yes, it was a comment about “what you can get away with”, not about 
> precision. First, it’s frequency dependent (a sample or half is a much bigger 
> relative error for high frequencies), frequency content (harmonics), relative 
> harmonic amplitudes (upper harmonics are usually low amplitude), relative 
> oversampling (at constant table size, higher tables are more oversampled), 
> etc. So, for a sawtooth for instance, the tables really don’t have to be so 
> big before it’s awfully hard to hear the difference between that and linear 
> interpolation. The 512k table analysis is probably similar to looking at 
> digital clipping and figuring out the oversampling ratio needed. But the 
> numbers, the answer would be that you need to upsample to something like a 5 
> MHz rate (using that number only because I recall reading that conclusion of 
> someone’s analysis once). In reality, you can get away with much less, 
> because when you calculate worst-case expected clipping levels, you tend to 
> forget you’ll have a helluva time hearing the aliased tones amongst all the 
> “correct” harmonic grunge, despite what your dB attenuation calculations tell 
> you. :-)
> 
> To be clear, though, I’m not advocating zero-order—linear interpolation is 
> cheap. The code on my website was a compile-time switch, for the intent that 
> the user/student can compare the effects. I think it’s good to think about 
> tradeoffs and why some may work and others not. In the mid ‘90s, I went to 
> work for my old Oberheim mates at Line 6. DSP had been a hobby for years, and 
> at a NAMM Marcus said hey why don’t you come work for us. Marcus was an 
> analog guy, not a DSP guy. But he taught me one important thing, early on: 
> The topic of interpolation came up, or lack thereof, came up. I remember I 
> said something like, “but that’s terrible!”. He replied that every Alesis 
> synth ever made was drop sample. He didn’t have to say more—I immediately 
> realized that probably most samplers ever made were that way (not including 
> E-mu), because samplers typically didn’t need to cater to the general case. 
> You didn’t need to shift pitch very far, because real instruments need to be 
> heavily multisampled anyway. And, of course, musical instruments only need to 
> sound “good” (subjective), not fit an audio specification.
> 
> It’s doubtful that people are really going to come down to a performance 
> issue where skipping linear interpolation is the difference in realizing a 
> plugin or device or not. On the old Digidesign TDM systems, I ran into 
> similar tradeoffs often. Where I’d have to do something that on paper seemed 
> to be a horrible thing to do, but to the ear it was fine, and it kept the 
> product viable by staying within the available cycle count.
>> Nigel, i remember your code didn't require big tables and you could have 
>> each wavetable a different size (i think you had the accumulated phase be a 
>> float between 0 and 1 and that was scaled to the wavetable size, right?) but 
>> then that might mean you have to do better interpolation than linear, if you 
>> want it clean.
>> 
> 
> Similar to above—for native computer code, there’s little point in variable 
> table sizes, mainly a thought exercise. I think somewhere in the articles I 
> also noted that if you really needed to save table space (say in ROM, in a 
> system with limited RAM to expand), it made sense to reduce/track the table 
> sizes only up to a point. I think I gave an audio example of one that tracked 
> octaves with halved table lengths, but up to a minimum of 64 samples. Again, 
> this was mostly a thought exercise, exploring the edge of overt aliasing.
> 
> Hope it’s apparent I was just going off on a thought tangent there, some 
> things I think are good to think about for people getting started. Would have 
> been much shorter if just replying to you ;-)
> 
> Robert
> 
>> On Aug 5, 2018, at 4:27 PM, robert bristow-johnson 
>>  wrote:
>> 
>> 
>> 
>>  Original Message 
>> Subject: Re: [music-dsp] Antialiased OSC
>> From: "Nigel Redmon" 
>> Date: Sun, August 5, 2018 1:30 pm
>> To: music-dsp@music.columbia.edu
>> --
>> 

Re: [music-dsp] Antialiased OSC

[Nigel Redmon]

Hi Robert,

On the drop-sample issue:

Yes, it was a comment about “what you can get away with”, not about precision. 
First, it’s frequency dependent (a sample or half is a much bigger relative 
error for high frequencies), frequency content (harmonics), relative harmonic 
amplitudes (upper harmonics are usually low amplitude), relative oversampling 
(at constant table size, higher tables are more oversampled), etc. So, for a 
sawtooth for instance, the tables really don’t have to be so big before it’s 
awfully hard to hear the difference between that and linear interpolation. The 
512k table analysis is probably similar to looking at digital clipping and 
figuring out the oversampling ratio needed. But the numbers, the answer would 
be that you need to upsample to something like a 5 MHz rate (using that number 
only because I recall reading that conclusion of someone’s analysis once). In 
reality, you can get away with much less, because when you calculate worst-case 
expected clipping levels, you tend to forget you’ll have a helluva time hearing 
the aliased tones amongst all the “correct” harmonic grunge, despite what your 
dB attenuation calculations tell you. :-)

To be clear, though, I’m not advocating zero-order—linear interpolation is 
cheap. The code on my website was a compile-time switch, for the intent that 
the user/student can compare the effects. I think it’s good to think about 
tradeoffs and why some may work and others not. In the mid ‘90s, I went to work 
for my old Oberheim mates at Line 6. DSP had been a hobby for years, and at a 
NAMM Marcus said hey why don’t you come work for us. Marcus was an analog guy, 
not a DSP guy. But he taught me one important thing, early on: The topic of 
interpolation came up, or lack thereof, came up. I remember I said something 
like, “but that’s terrible!”. He replied that every Alesis synth ever made was 
drop sample. He didn’t have to say more—I immediately realized that probably 
most samplers ever made were that way (not including E-mu), because samplers 
typically didn’t need to cater to the general case. You didn’t need to shift 
pitch very far, because real instruments need to be heavily multisampled 
anyway. And, of course, musical instruments only need to sound “good” 
(subjective), not fit an audio specification.

It’s doubtful that people are really going to come down to a performance issue 
where skipping linear interpolation is the difference in realizing a plugin or 
device or not. On the old Digidesign TDM systems, I ran into similar tradeoffs 
often. Where I’d have to do something that on paper seemed to be a horrible 
thing to do, but to the ear it was fine, and it kept the product viable by 
staying within the available cycle count.
> Nigel, i remember your code didn't require big tables and you could have each 
> wavetable a different size (i think you had the accumulated phase be a float 
> between 0 and 1 and that was scaled to the wavetable size, right?) but then 
> that might mean you have to do better interpolation than linear, if you want 
> it clean.
> 

Similar to above—for native computer code, there’s little point in variable 
table sizes, mainly a thought exercise. I think somewhere in the articles I 
also noted that if you really needed to save table space (say in ROM, in a 
system with limited RAM to expand), it made sense to reduce/track the table 
sizes only up to a point. I think I gave an audio example of one that tracked 
octaves with halved table lengths, but up to a minimum of 64 samples. Again, 
this was mostly a thought exercise, exploring the edge of overt aliasing.

Hope it’s apparent I was just going off on a thought tangent there, some things 
I think are good to think about for people getting started. Would have been 
much shorter if just replying to you ;-)

Robert

> On Aug 5, 2018, at 4:27 PM, robert bristow-johnson 
>  wrote:
> 
> 
> 
>  Original Message 
> Subject: Re: [music-dsp] Antialiased OSC
> From: "Nigel Redmon" 
> Date: Sun, August 5, 2018 1:30 pm
> To: music-dsp@music.columbia.edu
> --
> 
> > Yes, that’s a good way, not only for LFO but for that rare time you want to 
> > sweep down into the nether regions to show off.
>  
> 
> i, personally, would rather see a consistent method used throughout the MIDI 
> keyboard range; high notes or low.  it's hard to gracefully transition from 
> one method to a totally different method while the note sweeps.  like what if 
> portamento is turned on?  the only way to clicklessly jump from wavetable to 
> a "naive" sawtooth would be to crossfade.  but crossfading to a wavetable 
> richer in harmonics is already built in.  and what if the "classic" waveform 
> wasn't a saw but something else?  m

Re: [music-dsp] Antialiased OSC

[Nigel Redmon]

Yes, that’s a good way, not only for LFO but for that rare time you want to 
sweep down into the nether regions to show off. I think a lot fo people don’t 
consider that the error of a “naive” oscillator becomes increasingly smaller 
for lower frequencies. Of course, it’s waveform specific, so that’s why I 
suggested bigger tables. (Side comment: If you get big enough tables, you could 
choose to skip linear interpolation altogether—at constant table size, the 
higher frequency octave/whatever tables, where it matters more, will be 
progressively more oversampled anyway.)

Funny thing I found in writing the wavetable articles. One soft synth developer 
dismissed the whole idea of wavetables (in favor of minBLEPs, etc.). When I 
pointed out that wavetables allow any waveform, he said the other methods did 
too. I questioned that assertion by giving an example of a wavetable with a few 
arbitrary harmonics. He countered that it wasn’t a waveform. I guess some 
people only consider the basic synth waves as “waveforms”. :-D

Hard sync is another topic...

> On Aug 4, 2018, at 1:39 PM, Phil Burk  wrote:
> 
> On Sat, Aug 4, 2018 at 10:53 AM, Nigel Redmon  <mailto:earle...@earlevel.com>> wrote: 
> With a full-bandwidth saw, though, the brightness is constant. That takes 
> more like 500 harmonics at 40 Hz, 1000 at 20 Hz. So, as Robert says, 2048 or 
> 4096 are good choices (for both noise and harmonics).
> 
>  As I change frequencies  above 86 Hz, I interpolate between wavetables with 
> 1024 samples. For lower frequencies I interpolate between a bright wavetable 
> and a pure sawtooth phasor that is not band limited. That way I can use the 
> same oscillator as an LFO.
> 
> https://github.com/philburk/jsyn/blob/master/src/com/jsyn/engine/MultiTable.java#L167
>  
> <https://github.com/philburk/jsyn/blob/master/src/com/jsyn/engine/MultiTable.java#L167>
> 
> Phil Burk

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

Re: [music-dsp] Antialiased OSC

[Nigel Redmon]

> even though the wavetables can be *archived* with as few as 128 or 256 
> samples per wavetable (this can accurately represent the magnitude *and* 
> phase of each harmonic up to the 63rd or 127th harmonic), i very much 
> recommend at Program Change time, when the wavetables that will be used are 
> loaded from the archive to the memory space where you'll be 
> rockin'-n-rollin', that these wavetables be expanded (using bandlimited 
> interpolation) to 2048 or 4096 samples and then, in the oscillator code, you 
> do linear interpolation in real-time synthesis.  that wavetable expansion at 
> Program Change time will take a few milliseconds (big fat hairy deal).
> 
I know what you’re saying when you say “can be” (for many possible waves, or 
all waves if you’re willing to accept limitations), but to save possible grief 
for implementors: First, I’m sure many digital synths use 256 sample tables 
(and probably very common for synths that let you “draw” or manipulate wave 
tables), so it’s certainly not wrong. Just realize that 127 harmonics isn’t 
nearly enough if you expect to play a low sawtooth, filter open, with all the 
splendor of an analog synth. At 40 Hz, harmonics will top out at 5 kHz. As you 
play higher or lower notes, you’ll hear the harmonics walk up or down with the 
notes, as if a filter were tracking. With a full-bandwidth saw, though, the 
brightness is constant. That takes more like 500 harmonics at 40 Hz, 1000 at 20 
Hz. So, as Robert says, 2048 or 4096 are good choices (for both noise and 
harmonics).

I just didn’t want someone writing a bunch of code based on 256-sample tables, 
only to be disappointed that it doesn’t sound as analog as expected. We like 
our buzzy sawtooths ;-)



> On Aug 3, 2018, at 2:56 PM, robert bristow-johnson 
>  wrote:
>  Original Message 
> Subject: [music-dsp] Antialiased OSC
> From: "Kevin Chi" 
> Date: Fri, August 3, 2018 2:23 pm
> To: music-dsp@music.columbia.edu
> --
> >
> > Is there such a thing as today's standard for softSynth antialiased
> > oscillators?
> 
> i think there should be, but if i were to say so, i would sound like a stuck 
> record (and there will be people who disagree).
>  
> 
> stuck record:  "wavetable ... wavetable ... wavetable ..."
> 
> 
> >
> > I was looking up PolyBLEP oscillators, and was wondering how it would relate
> > to a 1-2 waveTables per octave based oscillator or maybe to some other
> > algos.
> >
> > thanks for any ideas and recommendations in advance,
> 
> if you want, i can send you a C file to show one way it can be done.  Nigel 
> Redmon also has some code online somewhere.
> 
> if your sample rate is 48 kHz and you're willing to put in a brickwall LPF at 
> 19 kHz, you can get away with 2 wavetables per octave, no aliasing, and 
> represent each surviving harmonic (that is below 19 kHz) perfectly.  if your 
> sample rate is 96 kHz, then there is **really** no problem getting the 
> harmonics down accurately (up to 30 kHz) and no aliases.
> 
> even though the wavetables can be *archived* with as few as 128 or 256 
> samples per wavetable (this can accurately represent the magnitude *and* 
> phase of each harmonic up to the 63rd or 127th harmonic), i very much 
> recommend at Program Change time, when the wavetables that will be used are 
> loaded from the archive to the memory space where you'll be 
> rockin'-n-rollin', that these wavetables be expanded (using bandlimited 
> interpolation) to 2048 or 4096 samples and then, in the oscillator code, you 
> do linear interpolation in real-time synthesis.  that wavetable expansion at 
> Program Change time will take a few milliseconds (big fat hairy deal).
> 
> lemme know, i'll send you that C file no strings attached.  (it's really 
> quite simple.)  and anyone listening in, i can do the same if you email me.  
> now this doesn't do the hard part of **defining** the wavetables (the C file 
> is just the oscillator with morphing).  but we can discuss how to do that 
> here later.
> 
> 
> --
> 
> 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

Re: [music-dsp] Antialiased OSC

[Nigel Redmon]

Robert mentioned I have some code (and more importantly, I think, discussion):

http://www.earlevel.com/main/category/digital-audio/oscillators/wavetable-oscillators/?order=ASC
 



> On Aug 3, 2018, at 2:23 PM, Kevin Chi  wrote:
> 
> Hi,
> 
> Is there such a thing as today's standard for softSynth antialiased 
> oscillators?
> 
> I was looking up PolyBLEP oscillators, and was wondering how it would relate
> to a 1-2 waveTables per octave based oscillator or maybe to some other algos.
> 
> thanks for any ideas and recommendations in advance,
> Kevin

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

Re: [music-dsp] resampling

[Nigel Redmon]

Oops, meant “as Tom points out…”

> On Jul 24, 2018, at 9:36 AM, Nigel Redmon  wrote:
> 
> (Not sure why I didn’t receive Rolf’s email directly…)
> 
> Hi Rolf,
> 
> First, I should have pointed to this newer series of articles (of mine), not 
> old ones, earlier in this thread. You’ll get a detailed explanation of why 
> zeroes (and as Alex points out, the zeros can be handled efficiently so it’s 
> a good thing anyway):
> 
> http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC 
> <http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC>
> 
> Nigel
> 
> 
>> On Jul 24, 2018, at 7:53 AM, Tom O'Hara > <mailto:tom_i...@ticino.com>> wrote:
>> 
>> Adding zeros is an advantage as then you don't need to calculate their 
>> multiplication, as 0 x coefficient = 0
>> 
>> The filter order will be the same with zeros or repeated samples.
>> Tom
>> 
>> On 7/24/2018 4:37 PM, rolfsassin...@web.de <mailto:rolfsassin...@web.de> 
>> wrote:
>>> Hello Nigel
>>>  
>>> could you please say a word more to what you mean by "2x", "3x"?
>>> 
>>> Also I am again not sure why in this case, adding zeros is an advantage. I 
>>> had expected to just copy the samples to have less work to do in filtering. 
>>> I tested such things in MATLAB and found that feeding zeros needs more 
>>> filter TAPs to come to the same result.
>>>  
>>> Rolf
>>>  
>>>  
>>> Gesendet: Montag, 23. Juli 2018 um 18:25 Uhr
>>> Von: "Nigel Redmon"  <mailto:earle...@earlevel.com>
>>> An: music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>>> Betreff: Re: [music-dsp] resampling
>>> Some articles on my website: 
>>> http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/ 
>>> <http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/>,
>>>  especially the 2010 articles, but the Amp Sim article might be a helpful 
>>> overview.
>>>  
>>> 48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, throw 
>>> away 5, repeat.
>>>  
>>> 8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, repeat; 
>>> filter with a lowpass filter with cutoff below 4k.
>>>  
>>> 
>>>  
>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>Virus-free. www.avg.com 
>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>  
>>> 
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp 
>>> <https://lists.columbia.edu/mailman/listinfo/music-dsp>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu <mailto: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] resampling

[Nigel Redmon]

(Not sure why I didn’t receive Rolf’s email directly…)

Hi Rolf,

First, I should have pointed to this newer series of articles (of mine), not 
old ones, earlier in this thread. You’ll get a detailed explanation of why 
zeroes (and as Alex points out, the zeros can be handled efficiently so it’s a 
good thing anyway):

http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC 
<http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC>

Nigel


> On Jul 24, 2018, at 7:53 AM, Tom O'Hara  wrote:
> 
> Adding zeros is an advantage as then you don't need to calculate their 
> multiplication, as 0 x coefficient = 0
> 
> The filter order will be the same with zeros or repeated samples.
> Tom
> 
> On 7/24/2018 4:37 PM, rolfsassin...@web.de <mailto:rolfsassin...@web.de> 
> wrote:
>> Hello Nigel
>>  
>> could you please say a word more to what you mean by "2x", "3x"?
>> 
>> Also I am again not sure why in this case, adding zeros is an advantage. I 
>> had expected to just copy the samples to have less work to do in filtering. 
>> I tested such things in MATLAB and found that feeding zeros needs more 
>> filter TAPs to come to the same result.
>>  
>> Rolf
>>  
>>  
>> Gesendet: Montag, 23. Juli 2018 um 18:25 Uhr
>> Von: "Nigel Redmon"  <mailto:earle...@earlevel.com>
>> An: music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>> Betreff: Re: [music-dsp] resampling
>> Some articles on my website: 
>> http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/ 
>> <http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/>,
>>  especially the 2010 articles, but the Amp Sim article might be a helpful 
>> overview.
>>  
>> 48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, throw 
>> away 5, repeat.
>>  
>> 8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, repeat; 
>> filter with a lowpass filter with cutoff below 4k.
>>  
>> 
>>  
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> Virus-free. www.avg.com 
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>  
>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>> https://lists.columbia.edu/mailman/listinfo/music-dsp 
>> <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] resampling

[Nigel Redmon]

Some articles on my website: 
http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/ 
, 
especially the 2010 articles, but the Amp Sim article might be a helpful 
overview.

48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, throw 
away 5, repeat.

8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, repeat; 
filter with a lowpass filter with cutoff below 4k.

Nuances:

A linear phase FIR is a popular choice for the lowpass filter (odd length, 
Kaiser windowed sinc is a good choice). In downsampling, you don’t have to 
calculate the samples you intend to discard, and in upsampling, you don’t need 
to do the operations for added 0-valued samples.

You want the filter stop band (above 4k) to have suitable attenuation (Kaiser 
is nice for this, because you can specify it, trading off with transition 
sharpness).

Advance topic: You can optimize performance by doing it in two stages (3x, 2x). 
You win by noting that the first stage doesn’t have to be perfect, and long as 
the second stage cleans up after it.


> On Jul 19, 2018, at 11:15 AM, Alex Dashevski  wrote:
> 
> Hi,
> 
> I need to convert 48Khz to 8KHz on input and convert 8Khz to 48Khz on audio 
> on output.
> Could you explain how to do it ?
> I need to implement this on android(NDK).
>  
> Thanks,
> Alex

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

Re: [music-dsp] wavetable filtering

[Nigel Redmon]

Hi Alexandre,

A couple of comments:

It looks like you’re saying that you’re taking the 256-sample wavetables, and 
want to create addition levels of bandlimited version fo them, but using 
time-domain filtering. It would be better to take and FFT, and manipulating the 
harmonics int he frequency domain. Because these are single-cycle waveform, 
manipulation in the frequency domain (e.g., zeroing out highs “bins”) will 
produce perfect results. That is, if you have a harmonic-rich wavetable from 
WaveEdit, and you want to make a version that can be transposed up an octave 
without aliasing, FFT the wave, zero out the upper half of the terms, iFFT  
back to a wavetable. Of course, you only need to convert it to the frequency 
domain ones, then make as many “filtered” copies of it as you want.

Note that 256 is a small wavetable. As pointed out in my articles, you can’t 
get both low frequencies and high harmonics with such a small table. A 
256-sample sawtooth played at 40 Hz will sound dull (lowpass filtered).

Regards,

Nigel

> On Jun 29, 2018, at 7:19 AM, alexandre niger  wrote:
> 
> 
> Hello everyone,
> 
> I just joined the list in order to find help in making a wavetable synth. 
> This synth would do both morphing and frequency wavetables. Morphing is a way 
> to play different waveforms over time and so to get an additional sound 
> dimension. Frequency wavetables are used to avoid aliasing by filtering 
> harmonics the higher the frequency go. I started with the frequency 
> wavetables and then I will do the morphing between different waveforms.
> 
> As an intern at Rebel Technology, I started making wavetables patches from 
> earlevel articles. In those patches, common waveforms are generated inside 
> the code (tri, square, saw). Now I want to generate some more complex 
> waveforms from an editor called WaveEdit (free). They come as 256 samples 
> single cycle .wav files. Then I change them into static data in a header 
> file. Once I have this, I can start with frequency wavetables. The key point 
> of frequency wavetables is the filtering. I have to filter enough harmonics 
> so the aliased frequencies do not come back under 18KHz (audiable range). But 
> I must not filter too much if I don't want to get gain loss.
> 
> At the moment I managed to make a 3550 taps FIR to filter every octave 
> wavetables. Unfortunately, with complex harmonic rich waveforms, I still have 
> audiable aliasing from 2kHz and gain/amplitude difference when wavetables 
> cross.
> So now I am wondering:
> About aliasing, should I cascade two FIR instead of increasing the taps? 
> That could be a solution if the stop band is not attenuated enough. According 
> to octave fir1, stop band attenuation is 50dB to 70dB.
> About gain loss, will "harmonic rich signal" always sound lower when filtered 
> even if gain is the same?
> I haven't normalize wavetables yet. I might have my answer afterwards. 
> 
> You can have a look at the patch code but you won't be able to try it if you 
> don't get Rebel Technology Owl files.
> https://github.com/alexniger/OLWpatches-RebelTech/blob/master/WTExtWavePatch.hpp
> All other links are in the readme.
> 
> Best,
> 
> 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

Re: [music-dsp] Blend two audio

[Nigel Redmon]

Suggestions of crossfading techniques, but I’m not convinced that solves the 
problem the OP posed:

"given [two] identical audio inputs...A1 is ahead of A2 by t sec, when switch 
from A1 to A2...it should be seamless”

If the definition of “seamless” is glitch-free, crossfading will solve it. But 
then why mention “identical" and “ahead”?

I think he’s talking about synchronization. And it’s unclear whether t is known.


> On Jun 16, 2018, at 10:45 AM, Benny Alexandar  wrote:
> 
> Hi,
> 
> I'm looking for an algorithm to blend two audio.  My requirement is 
> given tow identical audio inputs say A1 & A2.
> A1 is ahead of A2 by t sec, when switch from A1 to A2 
> it should be seamless and vice versa. 
> 
> -ben

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

Re: [music-dsp] Real-time pitch shifting?

[Nigel Redmon]

I think the key, in the request, is “realtime” (although he also says "ideally 
in the frequency domain”—not that they are mutually exclusive for practical 
use, just that it raises questions in my mind exactly what he’s after). I’ve 
never used Melodyne, but I think it’s designed around non-realtime, no? It’s 
been around a long time, so maybe it is usable realtime, but for old questions 
on the web I see the answer “no”.

Again, my knowledge of Melodyne is limited (to seeing a demo years ago), but I 
assume it’s based on somewhat similar techniques to those taught by Xavier 
Serra (https://youtu.be/M4GRBJJMecY )—anyone know 
for sure?

> On May 17, 2018, at 5:32 PM, robert bristow-johnson 
>  wrote:
> 
>  
> the current state of the art for pitch manipulation is, of course, Melodyne.
> 
> dunno how Peter Neubacker does it.
> 
> somewhere, i have some old MATLAB code that does a time-scaling via 
> phase-vocoder.  you can combine that with resampling to get a pitch shifter.
> 
> if it's pitch shifting a monophonic note, i would recommend a decent 
> time-domain cross-fading method that has a decent pitch detector so that the 
> splice displacements are good.
> 
> a Laroche/Dolson did a real-time phase vocoder pitch shifter.  all doable but 
> it's not a small project.
> 
> 
>  Original Message 
> Subject: [music-dsp] Real-time pitch shifting?
> From: "Matt Ingalls" 
> Date: Thu, May 17, 2018 4:24 pm
> To: music-dsp@music.columbia.edu
> --
> 
> > I tried porting Stephan Bernsee’s code from his old DSP Dimension blog:
> > http://blogs.zynaptiq.com/bernsee/pitch-shifting-using-the-ft/ 
> > 
> >
> > But it sounds pretty crappy, even compared to simple time-domain linear 
> > interpolation.
> >
> > And now wondering what's the state of the art for real-time pitch 
> > manipulation?
> > (for my purposes, ideally in the frequency domain)
> >
> > Is it still just phase vocoder with peak-detection ala Laroche/Dolson?
> > https://www.ee.columbia.edu/~dpwe/papers/LaroD99-pvoc.pdf
> >
> > Thanks!
> > Matt
> >
> > ___
> > 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] Build waveform sample array from array of harmonic strengths?

[Nigel Redmon]

Hi Frank,

Just a minor point, but yes, you want the inverse FFT. (Um, it’s the same 
thing, pretty much, the main issue being scaling, depending on implementation. 
Just highlighting that specifying frequency and converting to time domain is 
“inverse”, the other is plain or “forward”.)

My series on wavetable oscillators may or may not help. But in a nutshell, the 
FFT gives a vast improvement in the speed of calculating harmonically related 
sines, and the longer the table, the bigger the win.

http://www.earlevel.com/main/category/digital-audio/oscillators/wavetable-oscillators/?order=ASC
 



> On Apr 16, 2018, at 8:46 AM, Frank Sheeran  wrote:
> 
> RBJ says:
> 
> > are you making wavetables, Frank?? is that what you're doing?
> 
> Well yes.
> 
> More specifically, I'm adding Wavetable SYNTHESIS to my long-standing 
> software synthesizer.
> 
> It's been generating waveforms the patch-writer specifies by formula, and/or 
> by setting individual harmonics, and the like, for years.  It takes a portion 
> of a second to do for a single wave.   I generate several bandwidth-limited 
> versions (by default 1/4 octave apart).  Some call the resulting data 
> structure a mipmap, some call it a wavetable, but the salient point is that 
> there's only one spectrum (at least, at any given pitch range).
> 
> The problem is that now I'd doing it for say 32 or 64 or 256 waveforms at 
> once it can take a full second on a fast modern CPU.
> 
> So, the simple symmetry-based solution I had before isn't really fit for 
> purpose.
> 
> 
> 
> To all: thanks for all the pointers.  I'm not a maths/acoustics guy, just a 
> humble software developer, but I'll work through all the references and see 
> how much I understand.
> 
> 
> 
> ___
> 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] Wavetable File Formats?

[Nigel Redmon]

Hi Frank. I’ve never messed with these, but it seems obvious that they are 
either going to have a predictable format (that they specify *somewhere*, if 
they intend to let people sue anything but their own editor), or add/expect 
additional info bundled in the wave file (in which case they’d also need to 
specify).

In a quick search, I see that Serum expects 2048-sample wavetable (not a 
surprising number—let’s you span the audio range with all audible harmonics):

Wavetables in a Serum-compatible format can be directly loaded into Expanse. 
You can also make your own Serum-compatible wavetables using Serum or other 
audio software, or programming environments that offer wav file output. The 
format is as follows.
– 2048 samples per single-cycle
– Maximum of 256 frames (positions), less than 256 frames will be morphed or 
crossfaded according to the import setting.


> On Mar 6, 2018, at 6:27 AM, Frank Sheeran  wrote:
> 
> I've written a Wavetable Oscillator for my modular software synthesizer.
> 
> Surveying the synth software I can find (Serum, XRSDO, etc.) it seems that 
> they all store wavetables in WAV files, PCM format, which I'm able to read 
> and use with libsndfile.
> 
> However, is there any idea how I can tell how many samples per wave there is?
> 
> Clearly I can limit myself to factors of the file size.  EG a 65536 byte file 
> can have 256 waves of 256 samples, or 64 samples of 1024 samples, etc.
> 
> Is there any de-facto standard?  Or a short list of heuristics I could use?
> 
> I've tried integrating (simply summing) the waves, hoping to see the sum come 
> to zero right on a factor (and its multiples).  In some cases: perfect!  But 
> in fact many of these files seem to have either DC or simply wave changes 
> that keep these numbers from being zero, even when I can see by the harmonic 
> plot's orderliness that I have the correct sample count.
> 
> Thanks,
> Frank Sheeran
> 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] granular synth write up / samples / c++

[Nigel Redmon]

Hi Alan—extremely cool article, nice job!

This is related to your closing question, but if you have time, I found this 
course very interesting:

Audio Signal Processing for Music Applications
https://www.coursera.org/learn/audio-signal-processing

It’s a different thing—the main part pertaining to analysis and re-synthesis in 
the frequency domain, with pitch and time changing and including formant 
handling. It’s not as well suited for real time, since you need to capture 
something in its entirety before analyzing and re-synthesizing (unless you go 
to a lot more work). On the other hand, it knows about pitch and individual 
harmonics, so it allows more sophisticated processing, more akin to melodyne. I 
completed the first offering of it over three years ago, don’t know what 
improvements it might have now. The lab/home work revolves around a python 
toolkit.

If nothing else, it would give you idea about how to deal with formant (which 
will need frequency analysis anyway). You can also audit and just check out the 
course videos pertaining to the harmonic models, for instance.

Nigel

> On Mar 5, 2018, at 5:45 PM, Alan Wolfe  wrote:
> 
> Hello rbj!
> 
> My techniques are definitely not that sophisticated. It's really neat to hear 
> what the deeper layers of sophistication are.
> 
> I'm particularly surprised to hear it is in the neighborhood of vocoders. 
> That is another technique I'd like to learn sometime, but sounds "scary" 
> (granular synthesis sounded scary too before I did this post hehe).
> 
> Anyways, all I'm doing is placing grains after another, but repeating or 
> omitting them as needed to make the output buffer get to the target length 
> for whatever percentage the input buffer is at. I only place whole grains 
> into the output buffer.
> 
> There is a parameter that specifies a multiplier for playing the grains back 
> at (to make them slower or faster aka affecting pitch without really 
> affecting length).
> 
> Whenever a grain is placed down, say grain index N, if the previous grain 
> placed down isn't grain index N-1, but is grain index M, it does a cross fade 
> from grain index M+1 to N to keep things continuous.
> 
> In my setup, there is no overlapping of grains except for this cross fading, 
> and no discontinuities.
> 
> I use cubic hermite interpolation to get fractional samples, my grain size is 
> 20 milliseconds and the cross fade time is 2 milliseconds.
> 
> Would you consider this enough in the family of granular synthesis to call it 
> GS for a layman / introduction?
> 
> Thanks so much for the info!
> 
> PS do you happen to know any gentle / short introductions to formants or 
> vocoders?
> 
> On Mar 5, 2018 3:58 PM, "robert bristow-johnson"  > wrote:
>  
> this is very cool.  i had not read through everything, but i listened to all 
> of the sound examples.
> 
> so there are two things i want to ask about.  the first is about this 
> "granular" semantic:
> 
> Thing #1:  so the pitch shifting is apparently *not* "formant-corrected" or 
> "formant-preserving".  when you shift up, the voice becomes a little 
> "munchkinized" and when you shift down, Darth Vader (or Satan) comes through. 
>  that's okay (unless one does not want it), but i thought that with granular 
> synthesis (or resynthesis), that the grains that are windowed off and 
> overlap-added where not stretched (for downshifting) nor scrunched (for 
> up-shifting).  i.e. i thought that in granular synthesis, the amount of 
> overlap increases in up shifting and decreases during downshifting.  this 
> kind of pitch shifting is what Keith Lent writes about in Computer Music 
> Journal in 1989 (boy that's a long time ago) and i did a paper in the JAES 
> in, i think, 1995.
> 
> without this formant-preserving operation, i think i would call this either 
> "TDHS" (time-domain harmonic scaling), "OLA" (overlap-add), or "WOLA" 
> (windowed overlap-add), or if pitch detection is done "SOLA" (synchronous 
> overlap-add) or "PSOLA" (pitch synchronous overlap-add).  however i have read 
> somewhere the usage of the term PSOLA to mean this formant-preserving pitch 
> shifting a.la  Lent (or also a French dude named Hamon).  BTW, 
> IVL Technologies (they did the pitch-shifting products for Digitech) was 
> heavy into this and had a few patents, some i believe are now expired.
> 
> Thing #2: are you doing any pitch detection or some attempt to keep waveforms 
> coherent in either the time-scaling or pitch-shifting applications?  they 
> sound pretty good (the windowing smoothes things out) but might sound more 
> transparent if you could space the input grains by an integer number of 
> periods.
> 
> with pitch-detection and careful cross-fading (and windowing can be thought 
> of as a fade-up function concatenated to a fade-down function) you can make 
> time-scaling or pitch-shifting a monophonic voice or harmonic instrument 
> glitch free.  it can sound *very* goo

Re: [music-dsp] Listening Test: Virtual Analog Modeling of Guitar Amplifiers

[Nigel Redmon]

You probably should have left off “Annoying”, because they are all incredibly 
annoying without a cabinet simulation. The other choices make sense, degrees of 
difference compared with the reference. I can’t get past “Annoying”, though… ;-)


> On Feb 22, 2018, at 4:00 AM, Felix Eichas  wrote:
> 
> Dear music-dsp,
> 
> I am a research assistant currently working on modeling analog guitar 
> amplifiers (preferably with tubes). My current research needs qualified ears 
> to rate how well it performs (i.e. "How similar is the digital model to the 
> analog reference device?").
> 
> I thought that this community might be interested in participating in a 
> listening test which I designed.
> 
> The url to the test is:
> http://ant-s4.unibw-hamburg.de/listeningTest/
> 
> Thank you for participating!
> Felix
> 
> -- 
> M.Sc. Felix Eichas
> Dept. of Signal Processing and Communications
> Helmut Schmidt University
> Holstenhofweg 85
> 22043 Hamburg
> Germany
> Phone: +49-40-6541-2743
> http://www.hsu-hh.de/ant/
> ___
> 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] Triangle-Saw morph?

[Nigel Redmon]

Hi Frank,

> Parabolic being not so useful?  I'd say it's as useful as a triangle, though 
> that's not saying much.

Not sure if that question is to me—I don’t think I said that, just more more 
difficult for not much gain (as you say, as useful as a triangle), in the 
context of a basic analog synth.

> OK, you say it's easy to make straight lines from a few components.  What of 
> the morph from saw to tri, alternating one segment at a rising angle with 
> another at a falling angle?  That's all straight lines, and it seems 
> phenomenally useful.

It’s been a long time since my synth-hardware days, and I never tried a saw-tri 
morph, I’m sure someone else can support more. There are a number of ways to 
generate a triangle, either as the root waveform or derived. For instance, you 
can derive it from saw by switching between a rising ramp, and an inverted 
(falling ramp) version of it, by using a comparator set to half-way. 
Controlling the symmetry, for morphing upramp-tri-downramp is a little 
trickier, as you’d either need to juggle two ramp rates, or amplitude 
multipliers (that seems much easier). Just off the top of my head.

Nigel

> On Feb 12, 2018, at 3:41 AM, Frank Sheeran  wrote:
> 
> Nigel thanks for your insight on why hardware never (or rarely?) had a 
> parabolic wave output.  In a phrase, too many components.
> 
> Parabolic being not so useful?  I'd say it's as useful as a triangle, though 
> that's not saying much.
> 
> OK, you say it's easy to make straight lines from a few components.  What of 
> the morph from saw to tri, alternating one segment at a rising angle with 
> another at a falling angle?  That's all straight lines, and it seems 
> phenomenally useful.
> 
> (This video is a non-BWL oscillator though my BWL oscillator does the same 
> tri-saw morph, if not all of the other ones shown.)
> 
> https://www.youtube.com/watch?v=eDUkqtdgcXg 
> 
> 
> ___
> 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] music-dsp Digest, Vol 32, Issue 14

[Nigel Redmon]

> Any of the old hands in this group have any commentary why triangle waves 
> have been ubiquitous since the 70s but I've never seen a parabolic?  Indeed, 
> what hardware or software has even offered a parabolic?

For a ramp, you charge a capacitor via a constant current source, discharge the 
cap when it reached a threshold. A triangle is a variation on that (depends 
whether it’s derived or the base waveform for details, but my main point is 
linear segments are easy to make). A square/pulse can be made from that and a 
comparator—again, simple circuitry. Those waveforms not only work well for the 
task, but are handy shapes for testing and other purposes, so had already been 
around a long time in lab signal generators—what the first synthesists had 
available to work with. They fulfill important modulation needs well too.

Very few components to get to that point, most of the oscillator circuitry 
remaining is for tuning and stability over range and temperature. Parabolic 
would be tough for not much gain in a subtractive synth.

> On Feb 10, 2018, at 4:00 AM, Frank Sheeran  wrote:
> 
> In my software modular-style synthesizer Moselle (http://moselle-synth.com 
> ) I've added a parabolic waveform.
> 
> As most readers of this list know, it sounds like a "mellow sawtooth" in the 
> exact way a triangle sounds like a mellow square wave. Each harmonic's power 
> is divided by the harmonic number, and every other harmonic's phase is 
> reversed.
> 
> Moselle has several oscillators, but I implemented it in the SWO--Stored 
> Waveform Oscillator, which is by default bandwidth-limited;
> resampled every three semitones up the keyboard; interpolated and 2x 
> over-sampled (8x in the treble).
> 
> Any of the old hands in this group have any commentary why triangle waves 
> have been ubiquitous since the 70s but I've never seen a parabolic?  Indeed, 
> what hardware or software has even offered a parabolic?
> 
> Moselle's SWO implements a PW/PWM waveform by adding an inverted and 
> out-of-phase bandwidth-limited (BWL) sawtooth to another, producing a BWL 
> pulse.  Likewise, it offers a smooth morph between sawtooth and triangle by 
> doing the same trick with parabolics and a little scaling.  (I haven't seen 
> this in the literature but to scale the result to[-1,1] you divide by ( 6 * ( 
> duty - duty * duty ) ).  )  The result isn't simply a sawtooth fading out as 
> a triangle fades in, but rather the maximum point sliding from 0 degrees to 
> 90 degrees (and minimum from 360 degrees to 270 degrees).  Again same 
> question: what hardware or software has offered this waveform?  And it sounds 
> nice so why isn't it more popular?
> 
> 
> 
> On Fri, Feb 9, 2018 at 2:01 AM,  > wrote:
> Send music-dsp mailing list submissions to
> music-dsp@music.columbia.edu 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.columbia.edu/mailman/listinfo/music-dsp 
> 
> or, via email, send a message with subject or body 'help' to
> music-dsp-requ...@music.columbia.edu 
> 
> 
> You can reach the person managing the list at
> music-dsp-ow...@music.columbia.edu 
> 
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of music-dsp digest..."
> 
> 
> Today's Topics:
> 
>1. Re: Formants (Robert Marsanyi)
>2. [JOBS] C++ Developer at Le Sound By AudioGaming
>   (AudioGaming - Jobs)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 7 Feb 2018 10:08:45 -0800
> From: Robert Marsanyi mailto:r...@whidbey.com>>
> To: music-dsp@music.columbia.edu 
> Subject: Re: [music-dsp] Formants
> Message-ID:  >
> Content-Type: text/plain; charset="utf-8"
> 
> On Tue, Feb 6, 2018 at 8:56 PM, Frank Sheeran  
> >> wrote:
> >
> > I'm hoping to make some formant synthesis patches with my modular
> > soft synth Moselle. http://moselle-synth.com 
> >
> > I've looked around for formant tables and find tables with more
> > vowels and fewer formants, or fewer vowels and more formants.?
> > Tables with amplitude seem to have fewer vowels and only one I've
> > found shows Q.
> >
> I'm interested in the synthesis of consonants.? How are these typically
> handled in a formant-based system?
> 
> --rbt
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
>   
> 

Re: [music-dsp] minBLEP: advantages/disadvantages of ripple-after-step

[Nigel Redmon]

I played with minBLEPs about 15 years ago, and came to the same conclusion that 
I’ve seen many others come to over the years: there’s no significant advantage 
to minimum phase in typical synth use. Mainly, you need to have some delay to 
line up a minBLEP, and there’s no tangible downside to having a little more 
delay to align a symmetrical BLEP, and the latter is more convenient.

I would worry about the difference with non-linear processing exactly as much 
as you worry about filter phase characteristics when using filters ahead of 
non-linear processes—which is to say, typically not at all. ;-)


> On Dec 3, 2017, at 4:23 AM, Stefan Westerfeld  wrote:
> 
>   Hi!
> 
> I'm working on a minBLEP based oscillator. This means that my output signal
> will contain all ripple needed for bandlimiting the output after each step.
> 
> Other methods of generating bandlimited signals, for instance interpolation in
> an oversampled table will produce half of the ripple before and half of the
> ripple after each step. In frequency domain, both are equally valid results,
> that is, the frequencies contained in a minBLEP and those for other methods 
> are
> exactly the same, given similar filter desgin contstraints.
> 
> However, I have a vague idea that this is not all there is to know about the
> quality. For instance, what happens if I apply a non linear effect such as
> distortion after producing my signal. It could be that one of the two ways of
> introducing ripple in the oscillator would produce better results when 
> combined
> with such an effect.
> 
> I already know that the minBLEP provides a faster reaction for input from
> outside, for instance resetting the phase will be quicker if all ripple is
> introduced afterwards, but for my application that doesn't matter much. But if
> the time signal of one of the two methods would produce better results when
> using effects, this would matter to me. So are there advantages/disadvantages
> for each method?
> 
>   Cu... Stefan
> -- 
> Stefan Westerfeld, http://space.twc.de/~stefan
> ___
> 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?

[Nigel Redmon]

> I'm pretty sure an instantaneous [audio] voltage (or a number in a
> stream of PCM values) represents a pressure differential, and not
> displacement.

This is one of those point-of-view things…I used the “usually” caveat for that 
reason…

You strike a drum, you displace the head, create a pressure wave because the 
room has air, the pressure wave displaces the conducer capsule membrane 
resulting in a change of capacitance, which is converted to a change in 
voltage, it’s amplifier and used to displace a speaker, which creates a 
pressure wave, which displaces your ear drum…

So, whether the electrical signal is of the displacement of the capsule 
membrane, or the pressure differential over time hitting it…ultimately we’re 
normally recording sound as it exists in the air, so you could rightly say the 
electrical signal is an analog of the pressure changes over time—or you could 
look at it on the electro-mechanical level and say we use the pressure to 
displace and element and record that displacement.

I guess how firmly you stick to one or the other depends on conventions you're 
used to. As an engineer, I see it as representing the displacement. The reason 
I view it that way is because I’m intimately aware of the masses involved with 
dynamic or condenser mics, and their shortcomings. So, I think of it as the mic 
diaphragm trying its best to approximate the changes in pressure, and we 
convert that displacement approximation to an electrical signal.

It’s probably easier to view the flip side, the speaker—so many reasons for a 
bad approximation; you need a big surface to move a lot of air, particularly 
for low frequencies, but a big surface has enough mass that it sucks for 
quicker changes so we split up the audio band; all the while the surfaces are 
flexing and the cabinet and surface attachments are messing with the attempt, 
and you wonder how the heck we manage to put something out that’s listenable 
;-) Anyway, that’s why I view it as displacement; we’re trying like heck to 
make the displacement true, and the pressure changes follow (for speakers—the 
other way with a mic). It may be a different story with “plasma” approaches, 
I’m talking about our usual practical transducers.


> On Sep 30, 2017, at 1:37 PM, Ben Bradley  wrote:
> 
> I'm pretty sure an instantaneous [audio] voltage (or a number in a
> stream of PCM values) represents a pressure differential, and not
> displacement. A loudspeaker driver in air (within its rated response)
> is constrained by the air, above its resonant frequency (at the low
> end of its frequency range - for a woofer, this would be near the
> resonant frequency of a ported bass cabinet). Below its resonant
> frequency the output is a position proportional to voltage or current,
> but the coupling efficiency to the air goes down with frequency, so
> this isn't a good operating range. A woofer with a 1Hz input is going
> to have the same displacement as with a 0.1Hz input at the same
> voltage, because it doesn't have good coupling to the air at such low
> frequencies.
> 
> A speaker in air (operating within its intended frequency range) is
> like an oar in water. You can move it back and forth very far of
> you're doing it at a slow enough rate (low enough frequency). If you
> do it at a higher frequency, it takes more force to move it back and
> forth the same distance. If you use the same force, you end up moving
> back and forth a smaller distance due to the "strong coupling" of the
> oar to the water. This is how a speaker cone sees the air, and shows
> how cone displacement goes down as frequency goes up, even though the
> acoustic energy is the same. The voltage is proportional to
> [differential] pressure, and not (as one might easily believe, and
> probably some books say!) displacement.
> 
> Regarding phase, as displacement is the integral of pressure,
> displacement goes down with an increase in frequency, and there's a
> phase shift between pressure and displacement. I vaguely recall that
> the integral of a cosine is a sine, so there's a 90 degree (or pi/2,
> not pi/4 - you're perhaps thinking of 1/4 of a complete wave) phase
> shift between these two. But a dynamic microphone does the exact
> inverse of a speaker, so the sound-to-sound conversion actually works
> out without a phase shift. Even presuming a condenser mic does this
> phase shift (I can't quite visualize how or whether it does offhand),
> human ears are almost completely insensitive to phase shift vs.
> frequency, so in practice it doesn't matter.
> 
> 
> On Sat, Sep 30, 2017 at 3:39 PM, Stefan Sullivan
>  wrote:
>> 
>> so there might be a phase
>> offset between the recorded
>> and the reproduced sound.
>> 
>> 
>> Ah, I think I might be understanding your question more intuitively. Is your
>> question about positive voltages from microphones being represented as one
>> direction of displacement, whereas the positive voltages from speakers being
>> represented as the opposite di

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

[Nigel Redmon]

> I think mics usually converts
> pressure into voltage,

A Stefan pointed out, it’s really pressure to displacement to voltage (usually 
via capacitance or induction). A dynamic mic is basically a backwards speaker. 
It’s easy enough to see that a speaker converts voltage to deflection, which 
converts to pressure in the presence of air. You can shout into a speak (the 
smaller the better), and it will convert those air pressure waves to 
deflection, which will induce a small voltage that you’d want to run into a 
preamp—that’s a dynamic mic. With a condenser (another name for a capacitor) 
mic, the deflection of a membrane changes capacitance, which in turn changes a 
voltage.

> so there might be a phase
> offset between the recorded
> and the reproduced sound. 

Not 100% sure what you’re getting at, but it would really be a time offset. 
Phase is frequency-relative thing. I might be misunderstanding your point.


> On Sep 30, 2017, at 11:11 AM, Renato Fabbri  wrote:
> 
> I thinks I get it.
> But, as the samples are converted to analog signal
> and then sent to speakers,
> it seems reasonable to assume that there
> is a convention.
> 
> Probably displacement?
> 
> At the same time,
> I think mics usually converts
> pressure into voltage,
> which would lead to PCM samples
> that represent pressure.
> 
> One is proportional to the other,
> with a pi/4 phase difference,
> so there might be a phase
> offset between the recorded
> and the reproduced sound. (?? yes?)
> 
> My motivation is to know the fundamentals
> as I often read and write about audio and music
> (as an academic).
> 
> tx.
> R.
> 
> 
> 
> On Sat, Sep 30, 2017 at 2:24 PM, Nigel Redmon  <mailto:earle...@earlevel.com>> wrote:
> PCM audio samples usually represent an analog voltage, so, whatever the 
> analog voltage represents.
> 
> A mic usually converts pressure into displacement, and the displacement into 
> an analog voltage.
> 
> Sorry if I’m missing something, due to not understanding your motivation for 
> the questions.
> 
> The PCM samples themselves are a Pulse Code Modulated representation of the 
> analog voltage over time. If you want to understand that part better,
> 
> http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC 
> <http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC>
> 
> 
>> On Sep 30, 2017, at 9:03 AM, Renato Fabbri > <mailto:renato.fab...@gmail.com>> wrote:
>> 
>> I am not finding this information clearly.
>> 
>> BTW. microphones capture amplitude or displacement
>> or it depends?
>> 
>> -- 
>> Renato Fabbri
>> GNU/Linux User #479299
>> labmacambira.sourceforge.net <http://labmacambira.sourceforge.net/>
> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
> https://lists.columbia.edu/mailman/listinfo/music-dsp 
> <https://lists.columbia.edu/mailman/listinfo/music-dsp>
> 
> 
> 
> -- 
> Renato Fabbri
> GNU/Linux User #479299
> labmacambira.sourceforge.net 
> <http://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?

[Nigel Redmon]

PCM audio samples usually represent an analog voltage, so, whatever the analog 
voltage represents.

A mic usually converts pressure into displacement, and the displacement into an 
analog voltage.

Sorry if I’m missing something, due to not understanding your motivation for 
the questions.

The PCM samples themselves are a Pulse Code Modulated representation of the 
analog voltage over time. If you want to understand that part better,

http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC 



> On Sep 30, 2017, at 9:03 AM, Renato Fabbri  wrote:
> 
> I am not finding this information clearly.
> 
> BTW. microphones capture amplitude or displacement
> or it depends?
> 
> -- 
> 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

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

Somehow, combining the term "rat's ass" with a clear and concise explanation of 
your viewpoint makes it especially satisfying.

> On Sep 7, 2017, at 11:57 AM, robert bristow-johnson 
>  wrote:
> 
> 
> 
>  Original Message 
> Subject: Re: [music-dsp] Sampling theory "best" explanation
> From: "Ethan Duni" 
> Date: Wed, September 6, 2017 4:49 pm
> To: "robert bristow-johnson" 
> "A discussion list for music-related DSP" 
> --
> 
> > rbj wrote:
> >>what do you mean be "non-ideal"? that it's not an ideal brick wall LPF?
> > it's still LTI if it's some other filter **unless** you're meaning that
> > the possible aliasing.
> >
> > Yes, that is exactly what I am talking about. LTI systems cannot produce
> > aliasing.
> >
> > Without an ideal bandlimiting filter, resampling doesn't fulfill either
> > definition of time invariance. Not the classic one in terms of sample
> > shifts, and not the "common real time" one suggested for multirate cases.
> >
> > It's easy to demonstrate this by constructing a counterexample. Consider
> > downsampling by 2, and an input signal that contains only a single sinusoid
> > with frequency above half the (input) Nyquist rate, and at a frequency that
> > the non-ideal bandlimiting filter fails to completely suppress. To be LTI,
> > shifting the input by one sample should result in a half-sample shift in
> > the output (i.e., bandlimited interpolation). But this doesn't happen, due
> > to aliasing. This becomes obvious if you push the frequency of the input
> > sinusoid close to the (input) Nyquist frequency - instead of a half-sample
> > shift in the output, you get negation!
> >
> >>we draw the little arrows with different heights and we draw the impulses
> > scaled with samples of negative value as arrows pointing down
> >
> > But that's just a graph of the discrete time sequence.
> 
> well, even if the *information* necessary is the same, a graph of x[n] need 
> only be little dots, one per sample.  or discrete lines (without arrowheads).
> 
> but the use of the symbol of an arrow for an impulse is a symbol of something 
> difficult to graph for a continuous-time function (not to be confused with a 
> continuous function).  if the impulse heights and directions (up or down) are 
> analog to the sample value magnitude and polarity, those graphing object 
> suffice to depict these *hypothetical* impulses in the continuous-time domain.
> 
> 
> >
> >>you could do SRC without linear interpolation (ZOH a.k.a. "drop-sample")
> > but you would need a much larger table
> >>(if i recall correctly, 1024 times larger, so it would be 512Kx
> > oversampling) to get the same S/N. if you use 512x
> >>oversampling and ZOH interpolation, you'll only get about 55 dB S/N for an
> > arbitrary conversion ratio.
> >
> > Interesting stuff, it didn't occur to me that the SNR would be that low.
> > How do you estimate SNR for a particular configuration (i.e., target
> > resampling ratio, fixed upsampling factor, etc)? Is that for ideal 512x
> > resampling, or does it include the effects of a particular filter design
> > choice?
> 
> this is what Duane Wise and i ( 
> https://www.researchgate.net/publication/266675823_Performance_of_Low-Order_Polynomial_Interpolators_in_the_Presence_of_Oversampled_Input
>  ) were trying to show and Olli Niemitalo (in his pink elephant paper 
> http://yehar.com/blog/wp-content/uploads/2009/08/deip.pdf ).
> 
> so let's say that you're oversampling by a factor of R.  if the sample rate 
> is 96 kHz and the audio is limited to 20 kHz, the oversampling ratio is 2.4 . 
> but now imagine it's *highly* oversampled (which we can get from polyphase 
> FIR resampling) like R=32 or R=512 or R=512K.
> 
> when it's upsampled (like hypothetically stuffing 31 zeros or 511 zeros or 
> (512K-1) zeros into the stream and brick-wall low-pass filtering) then the 
> spectrum has energy at the baseband (from -Nyquist to +Nyquist of the 
> original sample rate, Fs) and is empty for 31 (or 511 or (512K-1)) image 
> widths of Nyquist, and the first non-zero image is at 32 or 512 or 512K x Fs.
> 
> now if you're drop-sample or ZOH interpolating it's convolving the train of 
> weighted impulses with a rect() pulse function and in the frequency domain 
> you are multiplying by a sinc() function with zeros through every integer 
> times R x Fs except for the one at 0 x Fs (the baseband, where the sinc 
> multiplies by virtually 1)  those reduce your image by a known amount.  
> multiplying the magnitude by sinc() is the same as multiplying the power 
> spectrum by sinc^2().
> 
> with linear interpolation, you're convolving with a triangular pulse, 
> multiplying the sample values by the triangular pulse function and in the 
> frequency domain you're multiplying by a sinc^2() function and in the power 
> spectrum you're multiplying by a sinc^4() function.
> 
> now that sinc^2 

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

Of course I mean that we store a representation of an impulse. I've said many 
times that the sample values "represent" impulses.

> On Sep 7, 2017, at 5:34 AM, Ethan Duni  wrote:
> 
> >For ADC, we effectively measure an instantaneous voltage and store it as an 
> >impulse.
> 
> I don't know of any ADC design that stores voltages as "impulse" signals, 
> even approximately. The measured voltage is represented through modulation 
> schemes such as PDM, PWM, PCM, etc. 
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

Ethan, I wasn't taking a swipe at you, by any stretch. In fact, I wasn't even 
addressing your ADC comment. It was actually about things like the idea of 
making DACs with impulses. As I noted, we don't because there are ways that are 
easier and accomplish the same goal, but it is feasible. I've had people say in 
the past to me it's absurd, and I've assured them that a reasonable and 
practical approximation of it would indeed produce a reasonable approximation 
of a decent DAC. That's a pretty relative statement because the quality depends 
on how hard you want try, but I subsequently saw that Julius Smith make the 
same assertion on his website.

Sorry you misinterpreted it.

> On Sep 7, 2017, at 5:34 AM, Ethan Duni  wrote:
> 
> Nigel Redmon wrote:
> >As an electrical engineer, we find great humor when people say we can't do 
> >impulses.
> 
> I'm the electrical engineer who pointed out that impulses don't exist and are 
> not found in actual ADCs. If you have some issue with anything I've posted, 
> I'll thank you to address it to me directly and respectfully.
> 
> Taking oblique swipes at fellow list members, impugning their standing as 
> engineers, etc. is poisonous to the list community. 
> 
> >What constitutes an impulse depends on the context—nano seconds, 
> >milliseconds...
> 
> If it has non-zero pulse width, it isn't an impulse in the relevant sense: 
> multiplying by such a function would not model the sampling process. You 
> would need to introduce additional operations to describe how this finite 
> region of non-zero signal around each sample time is translated into a unique 
> sample value. 
> 
> >For ADC, we effectively measure an instantaneous voltage and store it as an 
> >impulse.
> 
> I don't know of any ADC design that stores voltages as "impulse" signals, 
> even approximately. The measured voltage is represented through modulation 
> schemes such as PDM, PWM, PCM, etc. 
> 
> Impulse trains are a convenient pedagogical model for understanding aliasing, 
> reconstruction filters, etc., but there is a considerable gap between that 
> model and what actually goes on in a real ADC. 
> 
> >If you can make a downsampler that has no audible aliasing (and you can), I 
> >think the process has to be called linear, even if you can make a poor 
> >quality one that isn't.
> 
> I'm not sure how you got onto linearity, but the subject is time-invariance. 
> 
> I have no objection to calling resamplers "approximately time-invariant" or 
> "asymptotically time-invariant" or somesuch, in the sense that you can get as 
> close to time-invariant behavior as you like by throwing resources at the 
> bandlimiting filter. This is qualitatively different from other archetypical 
> examples of time-variant systems (modulation, envelopes, etc.) where 
> explicitly time-variant behavior is the goal, even in the ideal case. 
> Moreover, I agree that this distinction is important and worth highlighting.  
> 
> However, there needs to be *some* qualifier - the bare statement 
> "(re)sampling is LTI" is incorrect and misleading. It obscures that fact that 
> addressing the aliasing caused by the system's time-variance is the principle 
> concern in the design of resamplers. The fact that a given design does a good 
> job is great and all - but that only happens because the designer recognizes 
> that the system is time-invariant, and dedicates resources to mitigating the 
> impact of aliasing. 
> 
> >If you get too picky and call something non-linear, when for practical 
> >decision-making purposes it clearly is, it seem you've defeated the purpose.
> 
> If you insist on labelling all resamplers as "time-invariant," without any 
> further qualification, then it will mess up practical decision making. There 
> will be no reason to consider the effects of aliasing - LTI systems cannot 
> produce aliasing - when making practical system design decisions. You only 
> end up with approximately-LTI behavior because you recognize at the outset 
> that the system is *not* LTI, and make appropriate design decisions to limit 
> the impact of aliasing. So this is putting the cart before the horse.
> 
> The appropriate way to deal with this is not to get hung up on the label 
> "LTI" (or any specialized variations thereof), but to simply quote the actual 
> performance of the system (SNR, spurious-free dynamic range, etc.). In that 
> way, everything is clear to the designers and clients: the system is 
> fundamentally non-LTI, and deviation from LTI behavior is bounded by the 
> performance figures. Then the client can lo

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

Ooo, I like that, better than being vague...

I was implying that what constitutes a impulse depends on the context, but I 
like your idea.

Btw, interesting that when the LTI topic with downsampling came up years ago, 
several people shot down the TI part, and this time the discussion has been 
around L.

However, if you take L too literally, even a fixed point butterworth lowpass 
fails to be "linear". I think we have to limit ourselves to practicality on a 
mailing list called "music-dsp". If you can make a downsampler that has no 
audible aliasing (and you can), I think the process has to be called linear, 
even if you can make a poor quality one that isn't.

Linear and Tim Invariant are classifications, and we use them to help make 
decisions about how we might use a process. No? If you get too picky and call 
something non-linear, when for practical decision-making purposes it clearly 
is, it seem you've defeated the purpose.

> On Sep 5, 2017, at 11:57 PM, robert bristow-johnson 
>  wrote:
> 
> 
> 
>  Original Message 
> Subject: Re: [music-dsp] Sampling theory "best" explanation
> From: "Nigel Redmon" 
> Date: Tue, September 5, 2017 4:05 am
> To: music-dsp@music.columbia.edu
> --
> 
> > As an electrical engineer, we find great humor when people say we can't do 
> > impulses. What constitutes an impulse depends on the context—nano seconds, 
> > milliseconds...
>  
> 
> how 'bout a Planck Time.  i will define *my* rbj-dirac-impulse as a nascent 
> impulse that has area of 1 and a width of 1 Planck time.  Is that close 
> enough?  and the math guys cannot deny it's a real "function".
> 
> 
> --
> 
> 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] Sampling theory "best" explanation

[Nigel Redmon]

As an electrical engineer, we find great humor when people say we can't do 
impulses. What constitutes an impulse depends on the context—nano seconds, 
milliseconds...

For ADC, we effectively measure an instantaneous voltage and store it as an 
impulse. Arguing that we don't really do that...well, Amazon didn't really ship 
that Chinese garlic press to me, because they really relayed an order to some 
warehouse, the shipper did some crazy thing like send it in the wrong direction 
to a hub, to be more efficient...and it was on my doorstep when I checked the 
mail. What's the diff...

Well, that's the most important detail (ADC), because that defined what we're 
dealing with when we do "music-dsp". But as far as DAC not using impulses, it's 
only because the shortcut is trivial. Like I said, audio sample rates are slow, 
not that hard to do a good enough job for demonstration with "close enough" 
impulses.

Don't anyone get mad at me, please. Just sitting on a plane at LAX at 1AM, 
waiting to fly 14 hours...on the first leg...amusing myself before going 
offline for a while

;-)


> On Sep 4, 2017, at 10:07 PM, Ethan Duni  wrote:
> 
> rbj wrote:
> >1. resampling is LTI **if**, for the TI portion, one appropriately scales 
> >time. 
> 
> Have we established that this holds for non-ideal resampling? It doesn't seem 
> like it does, in general. 
> 
> If not, then the phrase "resampling is LTI" - without some kind of "ideal" 
> qualifier - seems misleading. If it's LTI then what are all these aliases 
> doing in my outputs?
> 
> >no one *really* zero-stuffs samples into the stream
> 
> Nobody does it *explicitly* but it seems misleading to say we don't *really* 
> do it. We employ optimizations to handle this part implicitly, but the 
> starting point for that is exactly to *really* stuff zeroes into the stream. 
> This is true in the same sense that the FFT *really* computes the DFT. 
> 
> Contrast that with pedagogical abstractions like the impulse train model of 
> sampling. Nobody has ever *really* sampled a signal this way, because 
> impulses do not exist in reality. 
> 
> >7. and i disagree with the statement: "The other big pedagogical problem 
> >with impulse train representation is that it can't be graphed in a >useful 
> >way."  graphing functions is an abstract representation to begin with, so we 
> >can use these abstract vertical arrows to represent >impulses.  
> 
> That is my statement, so I'll clarify: you can graph an impulse train with a 
> particular period. But how do you graph the product of the impulse train with 
> a continuous-time function (i.e., the sampling operation)? Draw a graph of a 
> generic impulse train, with the scaling of each impulse written out next to 
> it? That's not useful. That's just a generic impulse train graph and a 
> print-out of the sequence values. The useful graph here is of the sample 
> sequence itself.
> 
> >if linear interpolation is done between the subsamples, i have found that 
> >upsampling by a factor of 512 followed by linear interpolation >between 
> >those teeny-little upsampled samples, that this will result in 120 dB S/N
> 
> What is the audio use case wherein 512x upsampling is not already sufficient 
> time resolution? I'm curious why you'd need additional interpolation at that 
> point. 
> 
> Ethan D
> 
> 
> On Mon, Sep 4, 2017 at 1:49 PM, Nigel Redmon  wrote:
>>>> The fact that 5,17,-12,2 at sample rate 1X and 
>>>> 5,0,0,0,17,0,0,0,-12,0,0,0,2,0,0,0 at sample rate 4X are identical is 
>>>> obvious only for samples representing impulses.
>>> 
>>> 
>>> I agree that the zero-stuff-then-lowpass technique is much more obvious 
>>> when we you consider the impulse train corresponding to the signal. But I 
>>> find it peculiar to assert that these two sequences are "identical." If 
>>> they're identical in any meaningful sense, why don't we just stop there and 
>>> call it a resampler? The reason is that what we actually care about in the 
>>> end is what the corresponding bandlimited functions look like, and 
>>> zero-stuffing is far from being an identity operation in this domain. We're 
>>> instead done constructing a resampler when we end up with an operation that 
>>> preserves the bandlimited function -- or preserves as much of it as 
>>> possible in the case of downsampling.
>> 
>> 
>> Well, when I say they are identical, the spectrum is identical. In other 
>> words, they represent the same signal. The fact that it doesn’t mak

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

x27;s 
> counterproductive to discourage people from thinking about the discrete 
> signal <-> bandlimited function correspondence. I think real insight and 
> intuition in DSP is built up by comparing what basic operations look like in 
> each of these different universes (as well as in their frequency domain 
> equivalents).
> 
> -Ethan
> 
> 
> 
> On Mon, Sep 4, 2017 at 2:14 PM, Ethan Fenn  <mailto:et...@polyspectral.com>> wrote:
> Time variance is a bit subtle in the multi-rate context. For integer 
> downsampling, as you point out, it might make more sense to replace the 
> classic n-shift-in/n-shift-out definition of time invariance with one that 
> works in terms of the common real time represented by the different sampling 
> rates. So an integer shift into a 2x downsampler should be a half-sample 
> shift in the output. In ideal terms (brickwall filters/sinc functions) this 
> all clearly works out. 
> 
> I think the thing to say about integer downsampling with respect to time 
> variance is that it's that partitions the space of input shifts, where if you 
> restrict yourself to shifts from a given partition you will see time 
> invariance (in a certain sense). 
> 
> So this to me is a good example of how thinking of discrete time signals as 
> representing bandlimited functions is useful. Because if we're thinking of 
> things this way, we can simply define an operation in the space of discrete 
> signals as being LTI iff the corresponding operation in the space of 
> bandlimited functions is LTI. This generalizes the usual definition, and your 
> partitioned-shift concept, in exactly the way we want, and we find that ideal 
> resamplers (of any ratio, integer/rational/irrational) are in fact LTI as our 
> intuition suggests they should be.
> 
> -Ethan F
> 
> 
> 
> On Mon, Sep 4, 2017 at 1:00 AM, Ethan Duni  <mailto:ethan.d...@gmail.com>> wrote:
> Hmm this is quite a few discussions of LTI with respect to resampling that 
> have gone badly on the list over the years...
> 
> Time variance is a bit subtle in the multi-rate context. For integer 
> downsampling, as you point out, it might make more sense to replace the 
> classic n-shift-in/n-shift-out definition of time invariance with one that 
> works in terms of the common real time represented by the different sampling 
> rates. So an integer shift into a 2x downsampler should be a half-sample 
> shift in the output. In ideal terms (brickwall filters/sinc functions) this 
> all clearly works out. 
> 
> On the other hand, I hesitate to say "resampling is LTI" because that seems 
> to imply that resampling doesn't produce aliasing. And of course aliasing is 
> a central concern in the design of resamplers. So I can see how this rubs 
> people the wrong way. 
> .
> It's not clear to me that a realizable downsampler (i.e., with non-zero 
> aliasing) passes the "real time" definition of LTI?
> 
> I think the thing to say about integer downsampling with respect to time 
> variance is that it's that partitions the space of input shifts, where if you 
> restrict yourself to shifts from a given partition you will see time 
> invariance (in a certain sense). 
> 
> More generally, resampling is kind of an edge case with respect to time 
> invariance, in the sense that resamplers are time-variant systems that are 
> trying as hard as they can to act like time invariant systems. As opposed to, 
> say, modulators or envelopes or such, 
> 
> Ethan D
> 
> 
> On Fri, Sep 1, 2017 at 10:09 PM, Nigel Redmon  <mailto:earle...@earlevel.com>> wrote:
> Interesting comments, Ethan.
> 
> Somewhat related to your points, I also had a situation on this board years 
> ago where I said that sample rate conversion was LTI. It was a specific 
> context, regarding downsampling, so a number of people, one by one, basically 
> quoted back the reason I was wrong. That is, basically that for downsampling 
> 2:1, you’d get a different result depending on which set of points you 
> discard (decimation), and that alone meant it isn’t LTI. Of course, the fact 
> that the sample values are different doesn’t mean what they represent is 
> different—one is just a half-sample delay of the other. I was surprised a bit 
> that they accepted so easily that SRC couldn’t be used in a system that 
> required LTI, just because it seemed to violate the definition of LTI they 
> were taught.
> 
>> On Sep 1, 2017, at 3:46 PM, Ethan Duni > <mailto:ethan.d...@gmail.com>> wrote:
>> 
>> Ethan F wrote:
>> >I see your nitpick and raise you. :o) Surely there are uncountably many 
>> >such functions, 
>> >as the power at any a

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

OTOH, just about everything we do with digital audio doesn’t exactly work. 
Start with sampling. Do we give up if we can’t ensure absolutely no signal at 
and above half the sample rate? Fortunately, our ears have limitations (whew!). 
;-) Anyway, the aliasing occurred to me as I wrote that, but it’s always about 
the ideal, the objective, and what we can achieve practically. And we can get 
awfully good at the rate conversion, good enough people can’t hear the 
difference in ABX under ideal conditions. At the other end, the Ensoniq Mirage, 
for goodness sake. But it still managed to make it on albums people bought. We 
have some wiggle room. :-D

> On Sep 3, 2017, at 10:00 PM, Ethan Duni  wrote:
> 
> Hmm this is quite a few discussions of LTI with respect to resampling that 
> have gone badly on the list over the years...
> 
> Time variance is a bit subtle in the multi-rate context. For integer 
> downsampling, as you point out, it might make more sense to replace the 
> classic n-shift-in/n-shift-out definition of time invariance with one that 
> works in terms of the common real time represented by the different sampling 
> rates. So an integer shift into a 2x downsampler should be a half-sample 
> shift in the output. In ideal terms (brickwall filters/sinc functions) this 
> all clearly works out. 
> 
> On the other hand, I hesitate to say "resampling is LTI" because that seems 
> to imply that resampling doesn't produce aliasing. And of course aliasing is 
> a central concern in the design of resamplers. So I can see how this rubs 
> people the wrong way. 
> .
> It's not clear to me that a realizable downsampler (i.e., with non-zero 
> aliasing) passes the "real time" definition of LTI?
> 
> I think the thing to say about integer downsampling with respect to time 
> variance is that it's that partitions the space of input shifts, where if you 
> restrict yourself to shifts from a given partition you will see time 
> invariance (in a certain sense). 
> 
> More generally, resampling is kind of an edge case with respect to time 
> invariance, in the sense that resamplers are time-variant systems that are 
> trying as hard as they can to act like time invariant systems. As opposed to, 
> say, modulators or envelopes or such, 
> 
> Ethan D
> 
> 
> On Fri, Sep 1, 2017 at 10:09 PM, Nigel Redmon  <mailto:earle...@earlevel.com>> wrote:
> Interesting comments, Ethan.
> 
> Somewhat related to your points, I also had a situation on this board years 
> ago where I said that sample rate conversion was LTI. It was a specific 
> context, regarding downsampling, so a number of people, one by one, basically 
> quoted back the reason I was wrong. That is, basically that for downsampling 
> 2:1, you’d get a different result depending on which set of points you 
> discard (decimation), and that alone meant it isn’t LTI. Of course, the fact 
> that the sample values are different doesn’t mean what they represent is 
> different—one is just a half-sample delay of the other. I was surprised a bit 
> that they accepted so easily that SRC couldn’t be used in a system that 
> required LTI, just because it seemed to violate the definition of LTI they 
> were taught.
> 
>> On Sep 1, 2017, at 3:46 PM, Ethan Duni > <mailto:ethan.d...@gmail.com>> wrote:
>> 
>> Ethan F wrote:
>> >I see your nitpick and raise you. :o) Surely there are uncountably many 
>> >such functions, 
>> >as the power at any apparent frequency can be distributed arbitrarily among 
>> >the bands.
>> 
>> Ah, good point. Uncountable it is! 
>> 
>> Nigel R wrote:
>> >But I think there are good reasons to understand the fact that samples 
>> >represent a 
>> >modulated impulse train.
>> 
>> I entirely agree, and this is exactly how sampling was introduced to me back 
>> in college (we used Oppenheim and Willsky's book "Signals and Systems"). 
>> I've always considered it the canonical EE approach to the subject, and am 
>> surprised to learn that anyone thinks otherwise. 
>> 
>> Nigel R wrote:
>> >That sounds like a dumb observation, but I once had an argument on this 
>> >board: 
>> >After I explained why we stuff zeros of integer SRC, a guy said my 
>> >explanation was BS.
>> 
>> I dunno, this can work the other way as well. There was a guy a while back 
>> who was arguing that the zero-stuffing used in integer upsampling is 
>> actually not a time-variant operation, on the basis that the zeros "are 
>> already there" in the impulse train representation (so it's a "null 
>> operation" basically). He cou

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

polate any given set of samples. These get used in "bandpass 
> sampling," which is uncommon in audio but commonplace in radio applications. 
> 
> Ethan D
> 
> On Fri, Sep 1, 2017 at 1:31 PM, Ethan Fenn  <mailto:et...@polyspectral.com>> wrote:
> Thanks for posting this! It's always interesting to get such a good glimpse 
> at someone else's mental model.
> 
> I'm one of those people who prefer to think of a discrete-time signal as 
> representing the unique bandlimited function interpolating its samples. And I 
> don't think this point of view has crippled my understanding of resampling or 
> any other DSP techniques!
> 
> I'm curious -- from the impulse train point of view, how do you understand 
> fractional delays? Or taking the derivative of a signal? Do you have to pass 
> into the frequency domain in order to understand these? Thinking of a signal 
> as a bandlimited function, I find it pretty easy to understand both of these 
> processes from first principles in the time domain, which is one reason I 
> like to think about things this way.
> 
> -Ethan
> 
> 
> 
> 
> On Mon, Aug 28, 2017 at 12:15 PM, Nigel Redmon  <mailto:earle...@earlevel.com>> wrote:
> Hi Remy,
> 
>> On Aug 28, 2017, at 2:16 AM, Remy Muller > <mailto:muller.r...@gmail.com>> wrote:
>> 
>> I second Sampo about giving some more hints about Hilbert spaces, 
>> shift-invariance, Riesz representation theorem… etc
> 
> I think you’ve hit upon precisely what my blog isn’t, and why it exists at 
> all. ;-)
> 
>> Correct me if you said it somewhere and I didn't saw it, but an important 
>> implicit assumption in your explanation is that you are talking about 
>> "uniform bandlimited sampling”.
> 
> Sure, like the tag line in the upper right says, it’s a blog about "practical 
> digital audio signal processing".
> 
>> Personnally, my biggest enlighting moment regarding sampling where when I 
>> read these 2 articles:
> 
> Nice, thanks for sharing.
> 
>> "Sampling—50 Years After Shannon"
>> http://bigwww.epfl.ch/publications/unser0001.pdf 
>> <http://bigwww.epfl.ch/publications/unser0001.pdf>
>> 
>> and 
>> 
>> "Sampling Moments and Reconstructing Signals of Finite Rate of Innovation: 
>> Shannon Meets Strang–Fix"
>> https://infoscience.epfl.ch/record/104246/files/DragottiVB07.pdf 
>> <https://infoscience.epfl.ch/record/104246/files/DragottiVB07.pdf>
>> 
>> I wish I had discovered them much earlier during my signal processing 
>> classes.
>> 
>> Talking about generalized sampling, may seem abstract and beyond what you 
>> are trying to explain. However, in my personal experience, sampling seen 
>> through the lense of approximation theory as 'just a projection' onto a 
>> signal subspace made everything clearer by giving more perspective: 
>> The choice of basis functions and norms is wide. The sinc function being 
>> just one of them and not a causal realizable one (infinite temporal support).
>> Analysis and synthesis functions don't have to be the same (cf wavelets 
>> bi-orthogonal filterbanks)
>> Perfect reconstruction is possible without requiring bandlimitedness! 
>> The key concept is 'consistent sampling': one seeks a signal approximation 
>> that is such that it would yield exactly the same measurements if it was 
>> reinjected into the system. 
>> All that is required is a "finite rate of innovation" (in the statistical 
>> sense).
>> Finite support kernels are easier to deal with in real-life because they can 
>> be realized (FIR) (reminder: time-limited <=> non-bandlimited)
>> Using the L2 norm is convenient because we can reason about best 
>> approximations in the least-squares sense and solve the projection problem 
>> using Linear Algebra using the standard L2 inner product.
>> Shift-invariance is even nicer since it enables efficient signal processing.
>> Using sparser norms like the L1 norm enables sparse sampling and the whole 
>> field of compressed sensing. But it comes at a price: we have to use 
>> iterative projections to get there.
>> All of this is beyond your original purpose, but from a pedagocial 
>> viewpoint, I wish these 2 articles were systematically cited in a "Further 
>> Reading" section at the end of any explanation regarding the sampling 
>> theorem(s).
>> 
>> At least the wikipedia page cites the first article and has a section about 
>> non-uniform and sub-nyquist sampling but it's easy to miss the big pi

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

Hi Ethan,

Good comments and questions…I’m going to have to skip the questions for now 
(I’m in a race against time the next few days, then will been off the grid, 
relatively speaking, for a couple of weeks—but I didn’t want to seem like I was 
ignoring your reply; I think any quick answers to your questions will require 
some back and forth, and I won’t be here for the rest).

First, I want to be clear that I don’t think people are crippled by certain 
viewpoint—I’ve said this elsewhere before, maybe not it this thread or the 
article so much. It’s more than some things that come up as questions become 
trivially obvious when you understand that samples represent impulses (this is 
not so much a viewpoint as the basis of sampling). The fact that 5,17,-12,2 at 
sample rate 1X and 5,0,0,0,17,0,0,0,-12,0,0,0,2,0,0,0 at sample rate 4X are 
identical is obvious only for samples representing impulses. That sounds like a 
dumb observation, but I once had an argument on this board: After I explained 
why we stuff zeros of integer SRC, a guy said my explanation was BS. I said, 
OK, then why does inserting zeros work? He gave a one-word answer: 
“Serendipity.” So, he clearly knew how to get the job of SRC done—he wasn’t 
crippled—but he didn’t know why, was just following a formula (that’s OK—there 
are great cooks that only follow recipes).

But I think there are good reasons to understand the fact that samples 
represent a modulated impulse train. We all learn early on that we need the 
sample rate to be more than double the highest signal frequency. This usually 
is accompanies by diagram showing a sine wave under sampled, and a dotted line 
drawing of an alias at a lower frequency, maybe chat about wagon wheels going 
backwards in movies. But if you think about the frequency spectrum of a PAM 
signal, it’s apparent that the aliased image “sidebands” (radio term) will 
stretch down into the audio band (the band below half SR) if the signal 
stretches above it. So, you’d better filter it so that doesn’t happen. The best 
part is this doesn’t apply to just initial sampling, but is equally apparent 
for any interim upsampling and processing in the digital domain.

Cheers,

Nigel


> On Sep 1, 2017, at 1:31 PM, Ethan Fenn  wrote:
> 
> Thanks for posting this! It's always interesting to get such a good glimpse 
> at someone else's mental model.
> 
> I'm one of those people who prefer to think of a discrete-time signal as 
> representing the unique bandlimited function interpolating its samples. And I 
> don't think this point of view has crippled my understanding of resampling or 
> any other DSP techniques!
> 
> I'm curious -- from the impulse train point of view, how do you understand 
> fractional delays? Or taking the derivative of a signal? Do you have to pass 
> into the frequency domain in order to understand these? Thinking of a signal 
> as a bandlimited function, I find it pretty easy to understand both of these 
> processes from first principles in the time domain, which is one reason I 
> like to think about things this way.
> 
> -Ethan
> 
> 
> 
> 
> On Mon, Aug 28, 2017 at 12:15 PM, Nigel Redmon  <mailto:earle...@earlevel.com>> wrote:
> Hi Remy,
> 
>> On Aug 28, 2017, at 2:16 AM, Remy Muller > <mailto:muller.r...@gmail.com>> wrote:
>> 
>> I second Sampo about giving some more hints about Hilbert spaces, 
>> shift-invariance, Riesz representation theorem… etc
> 
> I think you’ve hit upon precisely what my blog isn’t, and why it exists at 
> all. ;-)
> 
>> Correct me if you said it somewhere and I didn't saw it, but an important 
>> implicit assumption in your explanation is that you are talking about 
>> "uniform bandlimited sampling”.
> 
> Sure, like the tag line in the upper right says, it’s a blog about "practical 
> digital audio signal processing".
> 
>> Personnally, my biggest enlighting moment regarding sampling where when I 
>> read these 2 articles:
> 
> Nice, thanks for sharing.
> 
>> "Sampling—50 Years After Shannon"
>> http://bigwww.epfl.ch/publications/unser0001.pdf 
>> <http://bigwww.epfl.ch/publications/unser0001.pdf>
>> 
>> and 
>> 
>> "Sampling Moments and Reconstructing Signals of Finite Rate of Innovation: 
>> Shannon Meets Strang–Fix"
>> https://infoscience.epfl.ch/record/104246/files/DragottiVB07.pdf 
>> <https://infoscience.epfl.ch/record/104246/files/DragottiVB07.pdf>
>> 
>> I wish I had discovered them much earlier during my signal processing 
>> classes.
>> 
>> Talking about generalized sampling, may seem abstract and beyond what you 
>> are trying to explain. However, in my personal experience, sampling seen 
>> throug

Re: [music-dsp] Sampling theory "best" explanation

[Nigel Redmon]

Hi Remy,

> On Aug 28, 2017, at 2:16 AM, Remy Muller  wrote:
> 
> I second Sampo about giving some more hints about Hilbert spaces, 
> shift-invariance, Riesz representation theorem… etc

I think you’ve hit upon precisely what my blog isn’t, and why it exists at all. 
;-)

> Correct me if you said it somewhere and I didn't saw it, but an important 
> implicit assumption in your explanation is that you are talking about 
> "uniform bandlimited sampling”.

Sure, like the tag line in the upper right says, it’s a blog about "practical 
digital audio signal processing".

> Personnally, my biggest enlighting moment regarding sampling where when I 
> read these 2 articles:

Nice, thanks for sharing.

> "Sampling—50 Years After Shannon"
> http://bigwww.epfl.ch/publications/unser0001.pdf 
> <http://bigwww.epfl.ch/publications/unser0001.pdf>
> 
> and 
> 
> "Sampling Moments and Reconstructing Signals of Finite Rate of Innovation: 
> Shannon Meets Strang–Fix"
> https://infoscience.epfl.ch/record/104246/files/DragottiVB07.pdf 
> <https://infoscience.epfl.ch/record/104246/files/DragottiVB07.pdf>
> 
> I wish I had discovered them much earlier during my signal processing classes.
> 
> Talking about generalized sampling, may seem abstract and beyond what you are 
> trying to explain. However, in my personal experience, sampling seen through 
> the lense of approximation theory as 'just a projection' onto a signal 
> subspace made everything clearer by giving more perspective: 
> The choice of basis functions and norms is wide. The sinc function being just 
> one of them and not a causal realizable one (infinite temporal support).
> Analysis and synthesis functions don't have to be the same (cf wavelets 
> bi-orthogonal filterbanks)
> Perfect reconstruction is possible without requiring bandlimitedness! 
> The key concept is 'consistent sampling': one seeks a signal approximation 
> that is such that it would yield exactly the same measurements if it was 
> reinjected into the system. 
> All that is required is a "finite rate of innovation" (in the statistical 
> sense).
> Finite support kernels are easier to deal with in real-life because they can 
> be realized (FIR) (reminder: time-limited <=> non-bandlimited)
> Using the L2 norm is convenient because we can reason about best 
> approximations in the least-squares sense and solve the projection problem 
> using Linear Algebra using the standard L2 inner product.
> Shift-invariance is even nicer since it enables efficient signal processing.
> Using sparser norms like the L1 norm enables sparse sampling and the whole 
> field of compressed sensing. But it comes at a price: we have to use 
> iterative projections to get there.
> All of this is beyond your original purpose, but from a pedagocial viewpoint, 
> I wish these 2 articles were systematically cited in a "Further Reading" 
> section at the end of any explanation regarding the sampling theorem(s).
> 
> At least the wikipedia page cites the first article and has a section about 
> non-uniform and sub-nyquist sampling but it's easy to miss the big picture 
> for a newcomer.
> 
> Here's a condensed presentation by Michael Unser for those who would like to 
> have a quick historical overview:
> http://bigwww.epfl.ch/tutorials/unser0906.pdf 
> <http://bigwww.epfl.ch/tutorials/unser0906.pdf>
> 
> 
> On 27/08/17 08:20, Sampo Syreeni wrote:
>> On 2017-08-25, Nigel Redmon wrote: 
>> 
>>> http://www.earlevel.com/main/tag/sampling-theory-series/?order=asc 
>>> <http://www.earlevel.com/main/tag/sampling-theory-series/?order=asc> 
>> 
>> Personally I'd make it much simpler at the top. Just tell them sampling is 
>> what it is: taking an instantaneous value of a signal at regular intervals. 
>> Then tell them that is all it takes to reconstruct the waveform under the 
>> assumption of bandlimitation -- a high-falutin term for "doesn't change too 
>> fast between your samples". 
>> 
>> Even a simpleton can grasp that idea. 
>> 
>> Then if somebody wants to go into the nitty-gritty of it, start talking 
>> about shift-invariant spaces, eigenfunctions, harmonical analysis, and the 
>> rest of the cool stuff. 
> 
> ___
> 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] Sampling theory "best" explanation

[Nigel Redmon]

> Nigel, i would be careful with superlative claims regarding one's own work.  
> it is too Trumpian in nature to be taken at face value. but i appreciate this 
> (and your other) work.
> 
Yeah, I just couldn’t think of anything that wasn’t “sampling theory—again”. As 
I noted elsewhere, it’s more like that Tenacious D song, “Tribute”—not the 
greatest song ever, but a song about the greatest song ever.

Anyway, the intent was not that it that everyone would think it was the best 
explanation they’ve ever heard, but that for some people, it will be the best 
explanation they’ve ever heard (that’s why “you’ve ever heard”, and not just 
the more compact claim of “the best explanation”). I never intended a title 
like that for the eventual youtube video, but I figured my blog could withstand 
it till I think of a better title to replace it, if I do.

;-)

> On Aug 27, 2017, at 9:01 AM, robert bristow-johnson 
>  wrote:
> 
>  
> in my opinion, this old version of the Wikipedia article on it was 
> mathematically the most concise:
> 
> https://en.wikipedia.org/w/index.php?title=Nyquist%E2%80%93Shannon_sampling_theorem&oldid=234842277#Mathematical_basis_for_the_theorem
>  
> 
> then someone named BobK started the processes of fucking it up and now it is 
> unrecognizable  it *does* require the leap of faith that the dirac delta 
> function is a "function" (without worrying much about the "delta as 
> distribution" stuff).  if you wanna be mathematically correct and not make a 
> reference to the naked dirac or dirac comb, then the Poisson Summation 
> Formula is probably the way to go, but it is not as direct conceptually as 
> multiplying by the dirac comb as the sampling function. 
> https://en.wikipedia.org/wiki/Poisson_summation_formula 
> 
> Nigel, i would be careful with superlative claims regarding one's own work.  
> it is too Trumpian in nature to be taken at face value. but i appreciate this 
> (and your other) work.
> 
> L8r,
> 
> r b-j
> 
> 
> 
>  Original Message 
> Subject: Re: [music-dsp] Sampling theory "best" explanation
> From: "Sampo Syreeni" 
> Date: Sun, August 27, 2017 2:20 am
> To: "A discussion list for music-related DSP" 
> --
> 
> > On 2017-08-25, Nigel Redmon wrote:
> >
> >> http://www.earlevel.com/main/tag/sampling-theory-series/?order=asc
> >
> > Personally I'd make it much simpler at the top. Just tell them sampling
> > is what it is: taking an instantaneous value of a signal at regular
> > intervals. Then tell them that is all it takes to reconstruct the
> > waveform under the assumption of bandlimitation -- a high-falutin term
> > for "doesn't change too fast between your samples".
> >
> > Even a simpleton can grasp that idea.
> >
> > Then if somebody wants to go into the nitty-gritty of it, start talking
> > about shift-invariant spaces, eigenfunctions, harmonical analysis, and
> > the rest of the cool stuff.
> > --
> > 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
> >
> >
> 
> 
> --
> 
>  
> 
> 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] Sampling theory "best" explanation

[Nigel Redmon]

Sampo, the purpose was to convince people that samples are impulses, and why 
that means the spectrum represented by a series of samples is the intended 
spectrum plus aliased images, forever. in the simplest, most intuitive way I 
could think of.

That’s why I put those points up front, before any background or explanation. 
The purpose was not to explain sampling to newbies or to satisfy the 
rigor-inclined who already know sampling theory.

> On Aug 26, 2017, at 11:20 PM, Sampo Syreeni  wrote:
> 
> On 2017-08-25, Nigel Redmon wrote:
> 
>> http://www.earlevel.com/main/tag/sampling-theory-series/?order=asc
> 
> Personally I'd make it much simpler at the top. Just tell them sampling is 
> what it is: taking an instantaneous value of a signal at regular intervals. 
> Then tell them that is all it takes to reconstruct the waveform under the 
> assumption of bandlimitation -- a high-falutin term for "doesn't change too 
> fast between your samples".
> 
> Even a simpleton can grasp that idea.
> 
> Then if somebody wants to go into the nitty-gritty of it, start talking about 
> shift-invariant spaces, eigenfunctions, harmonical analysis, and the rest of 
> the cool stuff.
> -- 
> 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] Sampling theory "best" explanation

[Nigel Redmon]

Well, it’s a DSP blog. The intended audience is whoever reads it, I’m not 
judgmental. So, the question is probably more like “who can benefit from it”. 
At the novice end, I’d say they can probably benefit at least from the 
revelation that it comes from solving issues in analog communication, and 
subsequently figuring out the math of it. And if they don’t yet grok digital, 
but have a background (modular synthesist, electrical engineer) that gives them 
an intuitive grasp of amplitude modulation, I think they will benefit big over 
the typical classroom approach.

At the other end, there are certainly DSP experts who do not understand that 
samples represent impulses and the ramifications to the spectrum. This is no 
knock on them, there are good circuit designers who don’t know how generators 
work, of capable mechanics that don’t know how and why carburetors work. You 
don’t have to simultaneously know everything to be successful. But I think this 
lesson is an important one and that’s why I put it out there. For instance, 
sample rate conversion is a black art for many—they do the steps, but in cases 
that are a little out of the ordinary, they need to ask what to do. I think if 
you understand the points I made, SRC becomes incredibly obvious (particularly 
at integer ratios). Just an example.

I’m glad it was of some help to you, thanks for saying.

> On Aug 26, 2017, at 9:07 PM, Bernie Maier  wrote:
> 
>> Please check out my new series on sampling theory, and feel free to comment
>> here or there. The goal was to be brief, but thorough, and avoid abstract
>> mathematical explanations. In other words, accurate enough that you can
>> deduce correct calculations from it, but intuitive enough for the math-shy.
>> 
>> http://www.earlevel.com/main/tag/sampling-theory-series/?order=asc
>> 
> 
> Echoing the comments so far, thanks from me also for this and in particular 
> taking a new, or at least not commonly adopted, approach to explaining this.
> 
> That said, I felt unclear about who your intended audience is. I'm on this 
> list not out of any real DSP expertise, but more out of an interest in music, 
> audio software and (a long time ago) some mathematical background. But your 
> very opening section in part one appears to me to require quite a bit of 
> assumed background knowledge. The reader is expected to already know what an 
> impulse is, then a bandlimited impulse and so on.
> 
> Maybe your intended audience is DSP practitioners needing to solidify their 
> theoretical background. If so, perhaps you could be more clear about that in 
> the prologue. If your intention is, like I at first assumed, to make this a 
> thorough introduction to those with no DSP background then I suggest you may 
> need to spend some more time in the introduction defining terms at the very 
> least.
> 
> But even with my limited background theory, I did appreciate this 
> perspective, and it does correct some mistaken perceptions I had about 
> sampling theory. ___
> 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] Sampling theory "best" explanation

[Nigel Redmon]

Well, it’s quiet here, why not…

Please check out my new series on sampling theory, and feel free to comment 
here or there. The goal was to be brief, but thorough, and avoid abstract 
mathematical explanations. In other words, accurate enough that you can deduce 
correct calculations from it, but intuitive enough for the math-shy.

http://www.earlevel.com/main/tag/sampling-theory-series/?order=asc 


I’m not trying to be presumptuous with the series title, “the best explanation 
you’ve ever heard”, but I think it’s unique in that it separates sampling 
origins from the digital aspects, making the mathematical basis more obvious. 
I’ve had several arguments over the years about what lies between samples in 
the digital domain, an epic argument about why and how zero-stuffing works in 
sample rate conversion here more than a decade ago, etc. I think if people 
understand exactly what sampling means, and what PCM means, it would be a 
benefit. And, basically, I couldn’t think of a way to titled it that didn’t 
sound like “yet another introduction to digital sampling”.___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

[Nigel Redmon]

Even cheaper—no need to get fancy with TPDF, since the level can be -300 dB or 
so :-D (I’ve done things as simply as toggle sign on 1e-15 once per block)

But watch out for highpass filters and add back in ;-)

> On Mar 10, 2017, at 1:10 AM, Richard Dobson  wrote:
> 
> This might not be possible if one is implementing e.g. a plugin to run in a 
> third-party host - where one does not have full control over the host, nor 
> indeed of fellow plugins. Whereas adding some ~very~ low level TPDF dither to 
> a signal should be close to minimum cost.
> 
> Richard Dobson
> 
> On 10/03/2017 08:29, Stefan Stenzel wrote:
>> That document is from 2002 - today all these suggestions make little
>> sense unless you want your code to run explicitly on a CPU without
>> SSE. The best strategy for avoiding denormals is to enforce the
>> compiler to use SSE and avoid the FPU, then set the
>> Denormals-Are-Zero (DAZ) and Flush-To-Zero (FTZ) flag in the SSE
>> status register.
>> 
>> Stefan
>> 

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

Re: [music-dsp] Recognizing Frequency Components

[Nigel Redmon]

> Always fun to extrapolate into the blue, huh ? Not so much

I think people participate because they enjoy discussing audio DSP topics, so 
things often diverge from the original question—this isn’t simply an answer 
forum.

> I read only a part fo the RBJ "From zero to first order principal component 
> synthesis" article yet, but am aware that, just like some other 
> generalizations, drawing from general mathematics of the last century all too 
> enthusiastically


Published on only the second month of the current century, I’d expect Robert’s 
paper to draw enthusiastically on the last century ;-)

Having trouble parsing that last paragraph, please excuse me if I 
misinterpreted.


> On Jan 28, 2017, at 10:19 AM, Theo Verelst  wrote:
> 
> 
> Always fun to extrapolate into the blue, huh ? Not so much, while it's 
> interesting to look at FFTs and try to form an opinion on using some (maybe 
> readily available) form of it to analyze a frequency, and maybe even 
> interesting parallel/pipe-lined versions are FOS available, it's not just a 
> lot of computations (your DSP maybe doesn't have time for) for the purpose, 
> it's also not the best averaging function for determining precise 
> frequencies. Apart from errors stemming from the fact that the FFT interval 
> often won't match the length of the waveform (like our sine wave)  being 
> measured, any further reasoning on the basis of the used FFT's main interval 
> will be biased in that it is assumed the actual waveform is being 
> transformed. This is not true, there is no inherent reconstruction of the 
> waveform going on in the FFT, and "averaging" batches or streaming 
> measurements doesn't accurately remedy this. The Hilbert transform of the 
> required integral of sinc functions isn't a constant, it can not be 
> ultimately accurate unless in this example we measure smarter, or perform 
> (costly and high latency) reconstruction computations.
> 
> Having used the correct hypothesis that our sampled sine has the form
> 
>  A*sin(f*x+p)
> 
> It should be possible to check samples across the proposed 10 seconds (e.g. 
> 44,100 * 10 samples) of "measurement" and arrive at pretty stunning accuracy! 
> Using various types of measurement might be interesting to prevent the 
> incircumventable additions of errors from getting a standard type of bias 
> that will make future audio computations on the basis of the results subject 
> to a character that is hard to remove, once it has entered. It (in know from 
> experience) is easy to add (and find) components in audio signals that come 
> up relatively clear in FFT type of computations, and can send that peak up 
> and down and a bin back and forth easily. Other filters have their own 
> character as well. Arriving at a overall as neutral as possible digital 
> signal path, for instance int the sense of sensibly taking care of errors 
> staying statistically independent and/or  not easily accumulate to sound of 
> certain modern audio products is a real challenge!
> 
> I read only a part fo the RBJ "From zero to first order principal component 
> synthesis" article yet, but am aware that, just like some other 
> generalizations, drawing from general mathematics of the last century all too 
> enthusiastically, making a number of possibly incorrect assumptions will not 
> necessarily create a strong or mathematically sound proof set of theorems.. 
> Wavelets, (semi-) orthogonal filter banks, and wonderful Gaussian summings 
> are no exception, even though it is an interesting and challenging subject.
> 
> T.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

Re: [music-dsp] Recognizing Frequency Components

[Nigel Redmon]

OK, I see the idea has been brought up—here’s a 15-minute video from the course 
that gets to the point (“peak detection” refers to frequency peaks/centers in 
the FFT data):

https://www.coursera.org/learn/audio-signal-processing/lecture/cJmOi/peak-detection


> On Jan 28, 2017, at 9:44 AM, Nigel Redmon  wrote:
> 
> I haven’t had time to follow, maybe don’t understand the request or have 
> missed similar replies…I took the debut session of this free course in 2015, 
> excellent:
> 
> https://www.coursera.org/course/audio <https://www.coursera.org/course/audio>
> 
> The usual overlapping FFTs, the trick that I hadn’t thought of is fitting a 
> parabola (window shape) to find frequency centers between “bins”. The goal 
> being not just the fundamental, but harmonics (so you can operate notes out 
> of music, including tracking of pitch modulation, etc., for resynthesis). The 
> course includes the use of a Python toolkit, sms-tools, which you can work 
> with without taking the course:
> 
> https://github.com/MTG/sms-tools <https://github.com/MTG/sms-tools>
> 
> 
>> On Jan 28, 2017, at 3:09 AM, Andrew Simper > <mailto:a...@cytomic.com>> wrote:
>> 
>> I thought the common way to do it was to take two FFTs really close to each 
>> other, one or more samples depending on which frequencies you want the best 
>> resolution for, and do phase differencing to work out the frequency. Seems 
>> to work pretty well in the little test I just did, and is robust in the 
>> presence of additive gaussian noise. Also long as you have at least four 
>> cycles of your sine wave in the FFT block you can get to around a cent 
>> accuracy, more if you have more cycles.
>> 
>> Cheers,
>> 
>> Andy
>> 
>> On 27 January 2017 at 19:32, STEFFAN DIEDRICHSEN > <mailto:sdiedrich...@me.com>> wrote:
>> Here it is from our nuclear friends at CERN:
>> 
>> https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf 
>> <https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf>
>> 
>> 
>> Steffan
>> 
>> 
>> 
>>> On 26.01.2017|KW4, at 20:01, robert bristow-johnson 
>>> mailto:r...@audioimagination.com>> wrote:
>>> 
>>> i thought Steffan mentioned something about using a Gaussian window.  he 
>>> mentioned a paper he found but did not identify it.  i am a little curious.
>>> 
>>> 
>> 
>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>> https://lists.columbia.edu/mailman/listinfo/music-dsp 
>> <https://lists.columbia.edu/mailman/listinfo/music-dsp>
>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu <mailto: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

[Nigel Redmon]

I haven’t had time to follow, maybe don’t understand the request or have missed 
similar replies…I took the debut session of this free course in 2015, excellent:

https://www.coursera.org/course/audio 

The usual overlapping FFTs, the trick that I hadn’t thought of is fitting a 
parabola (window shape) to find frequency centers between “bins”. The goal 
being not just the fundamental, but harmonics (so you can operate notes out of 
music, including tracking of pitch modulation, etc., for resynthesis). The 
course includes the use of a Python toolkit, sms-tools, which you can work with 
without taking the course:

https://github.com/MTG/sms-tools


> On Jan 28, 2017, at 3:09 AM, Andrew Simper  wrote:
> 
> I thought the common way to do it was to take two FFTs really close to each 
> other, one or more samples depending on which frequencies you want the best 
> resolution for, and do phase differencing to work out the frequency. Seems to 
> work pretty well in the little test I just did, and is robust in the presence 
> of additive gaussian noise. Also long as you have at least four cycles of 
> your sine wave in the FFT block you can get to around a cent accuracy, more 
> if you have more cycles.
> 
> Cheers,
> 
> Andy
> 
> On 27 January 2017 at 19:32, STEFFAN DIEDRICHSEN  > wrote:
> Here it is from our nuclear friends at CERN:
> 
> https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf 
> 
> 
> 
> Steffan
> 
> 
> 
>> On 26.01.2017|KW4, at 20:01, robert bristow-johnson 
>> mailto:r...@audioimagination.com>> wrote:
>> 
>> i thought Steffan mentioned something about using a Gaussian window.  he 
>> mentioned a paper he found but did not identify it.  i am a little curious.
>> 
>> 
> 
> 
> ___
> 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] New session of the MOOC on Audio Signal Processing for Music Applications

[Nigel Redmon]

Thanks, Xavier

List: I took the initial session of this course a couple of years ago 
(already?), and highly recommend it.

(If I can spare the time, I’ll monitor this session and see what’s new.)


> On Sep 23, 2016, at 12:41 AM, Serra Xavier  wrote:
> 
> A new session of the MOOC on Audio Signal Processing for Music Applications 
> is starting in Coursera on September 26th. To enrol go to 
> https://www.coursera.org/learn/audio-signal-processing
> 
> This is a 10 week long course that focuses on the spectral processing 
> techniques of relevance for the description and transformation of sounds, 
> developing the basic theoretical and practical knowledge with which to 
> analyze, synthesize, transform and describe audio signals in the context of 
> music applications.
> 
> The course is free and based on open software and content. The demonstrations 
> and programming exercises are done using Python under Ubuntu, and the 
> references and materials for the course come from open online repositories. 
> The software and materials developed for the course are also distributed with 
> open licenses.
> 
> The course assumes some basic background in mathematics and signal 
> processing. Also, since the assignments are done with the programming 
> language Python, some software programming skills in any language are most 
> helpful. 
> 
> 
> ---
> Xavier Serra
> Music Technology Group
> Universitat Pompeu Fabra, Barcelona
> http://www.dtic.upf.edu/~xserra/

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

Re: [music-dsp] Anyone think about using FPGA for Midi/audio sync ?

[Nigel Redmon]

nce of 32-sample double buffering (and that added to ADC and DAC 
> delays) which is a little more than 1 ms.
> 
> but i can't, for the life of me, understand why any hardware product would 
> need a latency of 17 or 20 ms.  that's a factor of 10 longer than the minimum 
> delay i can account for.
> 
>  
> r b-j
> 
> 
>  Original Message 
> Subject: Re: [music-dsp] Anyone think about using FPGA for Midi/audio sync ?
> From: "Nigel Redmon" 
> Date: Sun, August 14, 2016 1:58 pm
> To: "robert bristow-johnson" 
> music-dsp@music.columbia.edu
> --
> 
> >> assuming no jitter in receiving the very first MIDI Status Byte (dunno 
> >> about this with Running Status), would a constant delay of 2 ms be better 
> >> than a jittery delay of 1 to 2 ms? which is better? which is more 
> >> "realistic" sounding? i confess that i really do not know.
> >>
> > Just a reminder that we’re pretty used to large jitter in hardware synths. 
> > I can’t speak to the latest synths, but a Roland D50 was a staple of my 
> > keyboard rack for years, and I would only play pads with it—I found the 
> > jitter too distracting to play percussive, piano-like sounds. I can 
> > withstand crazy latency if I have too—I used to play a pipe organ with pipe 
> > located high and wide in an auditorium, and my fingers would be easily 
> > three or four notes ahead of what I was hearing when playing Bach. But the 
> > D50 latency was highly variable, probably dependent on where a service loop 
> > was relative to the keypress, out to at least the 20 ms range I’m pretty 
> > sure.
> >
> > The OB8 round trip was about 17 ms when the DSX sequencer was attached (it 
> > connected directly to the cpu bus, and extended the loop time).
> >
> > I replaced my D50 with a Korg Trinity, which gave me great relief on the 
> > latency issue. However, it became too spongy for me when switch to Combo 
> > mode, so I avoided it. It was in turn replaced by a Korg Trinton Extreme 
> > after a burglary, which was better on the Combos. That was my last synth 
> > with a keyboard.
> >
> > A piano has latency, but it’s less the faster you play. I can’t think of an 
> > acoustic instrument that jitters, offhand. But there’s still a lot of 
> > jitter between exactly when you’d like to play a note, ideally, and when 
> > you pluck bow or blow it.
> >
> > Anyway, if you’ve played synths over the years, you’re used to substantial 
> > latency and jitter. You’ll still get it playing back from MIDI. Typically, 
> > they poll the incoming notes in a processing loop.
> >
> > So, other than the potential phase issues of coincident sounds in certain 
> > circumstances, I don’t think it matters in your question—2 ms delay or 1-2 
> > ms jitter.
> >
> >
> >> On Aug 13, 2016, at 8:10 PM, robert bristow-johnson 
> >>  wrote:
> >>
> >>
> >> so agreeing pretty much with everyone else, here are my $0.02 :
> >>
> >>
> >>
> >>  Original Message 
> >> Subject: Re: [music-dsp] Anyone think about using FPGA for Midi/audio sync 
> >> ?
> >>
> From: "David Olofson" 
> >> Date: Sat, August 13, 2016 6:16 pm
> >> To: "A discussion list for music-related DSP" 
> >> 
> >> --
> >>
> >> >
> >> > As to MIDI, my instinctive reaction is just, why even bother? 31250
> >> > bps. (Unless we're talking "high speed" MIDI-over-USB or something.)
> >> > No timestamps. You're not going to get better than ms level accuracy
> >> > with that, no matter what. All you can hope to there, even with custom
> >> > hardware, is avoid to make it even worse.
> >> >
> >> > BTW, I believe there already are MIDI interfaces with hardware
> >> > timestamping. MOTU Timepiece...?
> >> >
> >> > Finally, how accurate timing does one really need?
> >> >
> >>
> >> first of all, the time required for 3 MIDI bytes (1 Status Byte and 2 Data 
> >> Bytes) is about 1 millisecond. at least for MIDI 1.0 (5-pin DIN MIDI, i 
> >> dunno what it is for USB MIDI). so there is that minimum delay to start 
> >> with.
> >>
> >> and, say for a NoteOn (or other "Channel

Re: [music-dsp] Anyone think about using FPGA for Midi/audio sync ?

[Nigel Redmon]

> assuming no jitter in receiving the very first MIDI Status Byte (dunno about 
> this with Running Status), would a constant delay of 2 ms be better than a 
> jittery delay of 1 to 2 ms?  which is better?  which is more "realistic" 
> sounding?  i confess that i really do not know.
> 
Just a reminder that we’re pretty used to large jitter in hardware synths. I 
can’t speak to the latest synths, but a Roland D50 was a staple of my keyboard 
rack for years, and I would only play pads with it—I found the jitter too 
distracting to play percussive, piano-like sounds. I can withstand crazy 
latency if I have too—I used to play a pipe organ with pipe located high and 
wide in an auditorium, and my fingers would be easily three or four notes ahead 
of what I was hearing when playing Bach. But the D50 latency was highly 
variable, probably dependent on where a service loop was relative to the 
keypress, out to at least the 20 ms range I’m pretty sure.

The OB8 round trip was about 17 ms when the DSX sequencer was attached (it 
connected directly to the cpu bus, and extended the loop time).

I replaced my D50 with a Korg Trinity, which gave me great relief on the 
latency issue. However, it became too spongy for me when switch to Combo mode, 
so I avoided it. It was in turn replaced by a Korg Trinton Extreme after a 
burglary, which was better on the Combos. That was my last synth with a 
keyboard.

A piano has latency, but it’s less the faster you play. I can’t think of an 
acoustic instrument that jitters, offhand. But there’s still a lot of jitter 
between exactly when you’d like to play a note, ideally, and when you pluck bow 
or blow it.

Anyway, if you’ve played synths over the years, you’re used to substantial 
latency and jitter. You’ll still get it playing back from MIDI. Typically, they 
poll the incoming notes in a processing loop.

So, other than the potential phase issues of coincident sounds in certain 
circumstances, I don’t think it matters in your question—2 ms delay or 1-2 ms 
jitter.


> On Aug 13, 2016, at 8:10 PM, robert bristow-johnson 
>  wrote:
> 
>  
> so agreeing pretty much with everyone else, here are my $0.02 :
> 
> 
> 
>  Original Message 
> Subject: Re: [music-dsp] Anyone think about using FPGA for Midi/audio sync ?
> From: "David Olofson" 
> Date: Sat, August 13, 2016 6:16 pm
> To: "A discussion list for music-related DSP" 
> --
> 
> >
> > As to MIDI, my instinctive reaction is just, why even bother? 31250
> > bps. (Unless we're talking "high speed" MIDI-over-USB or something.)
> > No timestamps. You're not going to get better than ms level accuracy
> > with that, no matter what. All you can hope to there, even with custom
> > hardware, is avoid to make it even worse.
> >
> > BTW, I believe there already are MIDI interfaces with hardware
> > timestamping. MOTU Timepiece...?
> >
> > Finally, how accurate timing does one really need?
> >
> 
> first of all, the time required for 3 MIDI bytes (1 Status Byte and 2 Data 
> Bytes) is about 1 millisecond.  at least for MIDI 1.0 (5-pin DIN MIDI, i 
> dunno what it is for USB MIDI).  so there is that minimum delay to start with.
> 
> and, say for a NoteOn (or other "Channel Voice Message" in the MIDI 
> standard), when do you want to calculate the future time stamp? based on the 
> time of arrival of the MIDI Status Byte (the first UART byte)? or based on 
> the arrival of the final byte of the completed MIDI message? what if you base 
> it on the former (which should lead to the most constant key-down to 
> note-onset delay) and, for some reason, the latter MIDI Data Bytes don't 
> arrive during that constant delay period?  then you will have to put off the 
> note onset anyway, because you don't have all of the information you need to 
> define the note onset.
> 
> so i agree with everyone else that a future time stamp is not needed, even if 
> the approximate millisecond delay from key-down to note-onset is not nailed 
> down.
> 
> the way i see it, there are 3 or 4 stages to dealing with these MIDI Channel 
> Voice Messages:
> 
> 1. MIDI status byte received, but the MIDI message is not yet complete.  this 
> is a your MIDI parser working like a state machine.  email me if you want C 
> code to demonstrate this.
> 
> 2. MIDI message is complete.  now you have all of the information about the 
> MIDI NoteOn (or Control message) and you have to take that information (the 
> MIDI note number and key velocity) and from that information and other 
> settings or states of your synth, you have to create (or change an existing 
> "idle" struct to "active") a new "Note Control Struct" which is a struct (or 
> object, if you're C++) that contains all of the parameters and states of your 
> note while it proceeds or evolves in time (ya know, that ADSR thing).  once 
> the Note Control Struct is all filled out, then your not

Re: [music-dsp] looking for tutorials

[Nigel Redmon]

> Ty seems to be planning to re-implement just about everything:
> 
> https://www.google.com.au/?q=ty+armour+looking+for+tutorials+write 
> 
Hm, the list has a troll:

I want tutorials on every part of writing darwin and custom kernels and custom 
bios…
I am looking for tutorials on developing any and every aspect of OpenBSD, from 
bootloaders to device drivers to writing a raspberry pi image of OpenBSD…
I am looking for tutorials on how to basically rewrite perl…
I am looking for tutorials on how to basically write every aspect of 
libreoffice…
I am just looking for tutorials on developing a computer language…
I could use some tutorials on how to develop the backend of openssh...
etc…

Can we can this thread now?

> On Jun 13, 2016, at 5:42 PM, Ross Bencina  wrote:
> 
> >>Do everything in the recording studio
> 
> Here's my first attempt at a tutorial on seekable lock-free audio 
> record/playback:
> 
> http://www.rossbencina.com/code/interfacing-real-time-audio-and-file-io
> 
> 
>> Passion is a good thing
> 
> Ty seems to be planning to re-implement just about everything:
> 
> https://www.google.com.au/?q=ty+armour+looking+for+tutorials+write
> 
> They were asking about how to re-implement PortAudio a while back...
> 
> It would be great if every piece of software came with a tutorial about how 
> to re-write it. I remember reading about NASA having a documentation folder 
> for every source code file for the space shuttle software.
> 
> Cheers,
> 
> Ross.

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

Re: [music-dsp] Anyone using unums?

[Nigel Redmon]

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  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

Re: [music-dsp] Generating pink noise in Python

[Nigel Redmon]

> ...I hadn’t seen it before.

I take that back—I did read your blog article on it when it was new—thought the 
part about the FIR on top sounded familiar. But very nice to see it in code, 
thanks!


> On Jan 20, 2016, at 6:38 PM, Nigel Redmon  wrote:
> 
> Very nice, Stefan!
> 
> Thanks for bring it up, I hadn’t seen it before.
> 
> Nigel
> 
> 
>> On Jan 20, 2016, at 2:59 PM, Stefan Stenzel  
>> wrote:
>> 
>> Allen,
>> 
>> Did you consider the recipe for pink noise I published recently?
>> It performs better in terms of precision and performance than all others.
>> 
>> https://github.com/Stenzel/newshadeofpink
>> 
>> Regards,
>> Stefan
>> 
>> 
>> 
>>> On 20 Jan 2016, at 21:41 , Allen Downey  wrote:
>>> 
>>> Hi Music-DSP,
>>> 
>>> Short version: I've got a new blog post about generating pink noise in 
>>> Python:
>>> 
>>> http://www.dsprelated.com/showarticle/908.php
>>> 
>>> Longer version:
>>> 
>>> If you set the WABAC machine for 1978, you might remember Martin Gardner's 
>>> column in Scientific American about pink noise and fractal music.  It 
>>> presented material from a paper by Voss and Clarke that included an 
>>> algorithm for generating pink noise.
>>> 
>>> Then in 1999 there was a discussion on this very mailing list about the 
>>> Voss algorithm, which included a message from James McCartney that 
>>> suggested an improvement to the algorithm.  This page explains the details: 
>>> http://www.firstpr.com.au/dsp/pink-noise/
>>> 
>>> And in 2006 there was another discussion on this very mailing list, where 
>>> Larry Trammell suggested a stochastic version of the algorithm.  This page 
>>> has the details:  http://home.earthlink.net/~ltrammell/tech/pinkalg.htm
>>> 
>>> As an exercise in my book, Think DSP, I challenge the reader to implement 
>>> one of these algorithms in Python, using NumPy for reasonable performance.  
>>> I present my implementation in a new blog post at
>>> 
>>> http://www.dsprelated.com/showarticle/908.php
>>> 
>>> From there, there's a link to the IPython notebook with all the details.
>>> 
>>> Hope you find it interesting!
>>> 
>>> Allen
>>> 
>>> ___
>>> 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] Generating pink noise in Python

[Nigel Redmon]

Very nice, Stefan!

Thanks for bring it up, I hadn’t seen it before.

Nigel


> On Jan 20, 2016, at 2:59 PM, Stefan Stenzel  
> wrote:
> 
> Allen,
> 
> Did you consider the recipe for pink noise I published recently?
> It performs better in terms of precision and performance than all others.
> 
> https://github.com/Stenzel/newshadeofpink
> 
> Regards,
> Stefan
> 
> 
> 
>> On 20 Jan 2016, at 21:41 , Allen Downey  wrote:
>> 
>> Hi Music-DSP,
>> 
>> Short version: I've got a new blog post about generating pink noise in 
>> Python:
>> 
>> http://www.dsprelated.com/showarticle/908.php
>> 
>> Longer version:
>> 
>> If you set the WABAC machine for 1978, you might remember Martin Gardner's 
>> column in Scientific American about pink noise and fractal music.  It 
>> presented material from a paper by Voss and Clarke that included an 
>> algorithm for generating pink noise.
>> 
>> Then in 1999 there was a discussion on this very mailing list about the Voss 
>> algorithm, which included a message from James McCartney that suggested an 
>> improvement to the algorithm.  This page explains the details: 
>> http://www.firstpr.com.au/dsp/pink-noise/
>> 
>> And in 2006 there was another discussion on this very mailing list, where 
>> Larry Trammell suggested a stochastic version of the algorithm.  This page 
>> has the details:  http://home.earthlink.net/~ltrammell/tech/pinkalg.htm
>> 
>> As an exercise in my book, Think DSP, I challenge the reader to implement 
>> one of these algorithms in Python, using NumPy for reasonable performance.  
>> I present my implementation in a new blog post at
>> 
>> http://www.dsprelated.com/showarticle/908.php
>> 
>> From there, there's a link to the IPython notebook with all the details.
>> 
>> Hope you find it interesting!
>> 
>> Allen
>> 
>> ___
>> 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] NAMM Meetup?

[Nigel Redmon]

Nice blog, Christian, good job.

Gee, I think I may have been to them all (Anaheim Winter NAMM)…anyway, too busy 
to make a weekday, but I plan to go Saturday.

> On Jan 18, 2016, at 2:42 AM, Christian Luther  wrote:
> 
> Hey everyone!
> 
> who’ll be there and who’s in for a little music-dsp meetup?
> 
> Cheers
> Christian
> 
> P.S.: I just started a new blog, might be interesting for you guys. Have a 
> look:
> http://science-of-sound.net

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

Re: [music-dsp] automation of parametric EQ .

[Nigel Redmon]

Hi Robert,

I gave detailed reply yesterday, from the other side of the world, on my iPad. 
It had a sending failure, which also, apparently, left it as a completely empty 
message. Trying again from  scratch via iPhone...

There is no standard 3-knob parametric. Consider that the classic analog 
parametrics have different parameter interactions that audio engineers prefer 
(Tangent, for example—in general the interaction is how increasing gain affects 
Q). Some plug-ins give you a choice of classic behaviors.

Now, you want to automate the gain of one of these. Now you want to transfer 
that over to another 3-para with a different behavior. So, you need to 
translate that into gain automation and Q automation. Hmmm...

Tl;dr: You can't reasonably expect parameters from 3-paras to be 
interchangeable any more that you can with equally-ubiquitous compressors and 
reverbs. 

Second item: Parameter automation and MIDI automation are different things. The 
former tracks changes in a control over its range (often a knob that ranges 
(0-1). It may be a gain knob, it may be a Q knob. What is the value of the knob 
at 3-o'clock (the host may want to display it for an automation point)? It's 
whatever that plug-in tells the host it is. (The host queries the pluggie for a 
value string for control value 0.8, for instance. "+12 dB", might be the reply.)

A midi track might be attached to a control—whatever midi message you mated 
with it—and therefore you'll get that exported to a midi file but don't expect 
a host's automation track to get saved in a midi file, any more than you'd 
expect to save an audio/sequencer project in Cuebase and import it into Pro 
Tools and carry on there.

Hope this helps,

Nigel

> On Dec 20, 2015, at 11:16 AM, robert bristow-johnson 
>  wrote:
> 
>  
> 
>  
> 
> can anyone point me where to find the technical information regarding how 
> automation regarding control settings might be defined, particularly 
> regarding the 3-knob parametric EQ.
> 
>  
> 
> first, other than MIDI, with automation data stored as a MIDI files, how else 
> is this information stored?  like how does Pro Tools store the data?  
> essentially, i am curious exactly how a Pro Tools session (or whatever they 
> call the file) stores the automation data for a 3-knob parametric EQ.  like 
> exactly how is the Q or bandwidth defined.
> 
>  
> 
> second, specifically, how is this data defined in a MIDI file?  specifically 
> which MIDI controls (the control numbers) are, by default, assigned to 
> parametric EQ?  how many can a single MIDI channel have?
> 
>  
> 
> and then how is the scaling defined?  presumably 0x40 would represent the 
> middle of the knob range.  where does that go for f0?  and for Q?  i presume 
> 0x40 would correspond to a dB gain of 0.
> 
>  
> 
> has anyone used the same MIDI file for automatic control of EQ and translated 
> that MIDI file from one machine (or plugin) to another?  what did the two 
> products do with the settings?  did they go to the same f0?  the same Q?
> 
>  
> 
> just trying to find out what the practice is.  i know more about the theory, 
> but do not know what the emergent "standards" are.
> 
>  
> 
> thanks.
> 
> 
> --
> 
>  
> 
>  
> 
>  
> 
> 
> 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] Inlined functions

[Nigel Redmon]

This is a topic discussed ad museum on stackoverflow.com, and is better suited 
to that venue. Google ;-)

"Inline" is more a suggestion, compiler dependent, etc., so other than saying 
the obvious—that small, often called functions benefit (where the overhead of 
the call is significant relative to function body)—the discuss quickly drills 
down to minutia (versus #define macro, blah blah).

> On Oct 12, 2015, at 8:27 AM, Aran Mulholland  wrote:
> 
> I'm just wondering how people decide which functions should be inlined? What 
> are the rules that you follow when choosing to inline a function? Are you 
> concerned with function size or the number of inlined functions through the 
> code base? What other considerations do you factor in whilst making the 
> decision to inline?
> 
> Thanks
> 
> Aran


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

Re: [music-dsp] FFT, zero padding and magnitude response

[Nigel Redmon]

Andreas, the reason I suggested that it was a typo is that it’s *almost* a 
direct quote from the link he provided, notably with the exception of that one 
word (“linear" vs “ideal”):

>>> Another way to look at this is that zero padding is identical to
>>> linear interpolation in the frequency domain

The link: "This theorem shows that zero padding in the time domain corresponds 
to ideal interpolation in the frequency domain"


> On Sep 23, 2015, at 12:02 PM, Andreas Tell  wrote:
> 
> 
> On 23 Sep 2015, at 18:39, Nigel Redmon  wrote:
> 
>> Russell, a little typo:
>> 
>>> Another way to look at this is that zero padding is identical to
>>> linear interpolation in the frequency domain
>> 
>> “ideal interpolation in the frequency domain”
> 
> 
> I don’t think this was a typo. Russell probably wrote linear as in
> “linear map” not a triangular (i.e. “linear”) interpolation kernel.
> Even higher order interpolation schemes are linear as a mapping,
> and this is what Russell’s argument corretcly builds upon.
> 
> Just my 2c,
> 
> Andreas



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

Re: [music-dsp] sinc interp, higher orders

[Nigel Redmon]

> On Sep 21, 2015, at 1:59 PM, robert bristow-johnson 
>  wrote:
> On 9/21/15 1:26 PM, Nigel Redmon wrote:
>> And to elaborate on your comment that two tables per octave gets you over 
>> 19k, I believe that requires an asterisk (doesn’t it? had to do this 
>> quickly...): Whereas one table per octave works out symmetrically, where the 
>> top harmonics would be at 14700 and fold back to 14700 when shifted up an 
>> octave, two-per is not so convenient. The aliasing is limited to 19153 IF 
>> the highest harmonic is limited to 17640 (F_top for num_tables_per_octave = 
>> 2). Now that’s not much of a limitation, because “good luck hearing 
>> harmonics over 17640”, and aliasing would be a bigger concern, so it’s a 
>> good tradeoff—just noting it’s not 19/19 (highest allowed harmonic in table 
>> / lowest alias). I wanted to add that because you wrote of a band above 19k 
>> "in which you *do* allow foldover and aliasing.  or, on the other hand, 
>> missing harmonics”, but you really don’t get both.
> 
> well, you don't get both with the very same note.

To be clear, I meant on the same table (not note), over the pitch shift range 
of the table. In other words, for a single table per octave (and therefore one 
octave shift range), at 48k, a table that has it’s highest harmonic at 16 kHz 
unshifted, will have its lowest alias at 16 kHz at max frequency shift. Anyway, 
the important part of that had to do with your comment about 44.1k getting you 
over 19k, and that’s no longer a point, as you amended that to say at 48k.

And yes, I get 19882 Hz for 48k also.

> other than the practicalities of the brick-wall filter, what am i doing wrong?

Nothing—looks good to me!


> On Sep 21, 2015, at 1:59 PM, robert bristow-johnson 
>  wrote:
> 
> On 9/21/15 1:26 PM, Nigel Redmon wrote:
>> Hi Robert,
>> 
>> Yes, my answer was strictly for the special case of one table per octave. In 
>> that case, the start of the highest table (which would also be highest 
>> harmonic per table), such that transposing up by the maximum amount (in this 
>> case, one octave) is SR/3. But the general case is:
>> 
>>   F_top = SR / (2 + 1 / num_tables_per_octave)
>> 
>> And, whereas in the one-octave case the frequency base of the next higher 
>> table is twice the current table, the general case is higher by a factor of:
>> 
>>   2^(1 / num_table_per_octave)
>> 
>> The general case for the number of harmonics per table is:
>> 
>>   floor(F_top / current_table_base_freq)
>> 
>> And to elaborate on your comment that two tables per octave gets you over 
>> 19k, I believe that requires an asterisk (doesn’t it? had to do this 
>> quickly...): Whereas one table per octave works out symmetrically, where the 
>> top harmonics would be at 14700 and fold back to 14700 when shifted up an 
>> octave, two-per is not so convenient. The aliasing is limited to 19153 IF 
>> the highest harmonic is limited to 17640 (F_top for num_tables_per_octave = 
>> 2). Now that’s not much of a limitation, because “good luck hearing 
>> harmonics over 17640”, and aliasing would be a bigger concern, so it’s a 
>> good tradeoff—just noting it’s not 19/19 (highest allowed harmonic in table 
>> / lowest alias). I wanted to add that because you wrote of a band above 19k 
>> "in which you *do* allow foldover and aliasing.  or, on the other hand, 
>> missing harmonics”, but you really don’t get both.
> 
> 
> well, you don't get both with the very same note.
> 
> lemme see how i crunch the formulae:
> 
> your lowest fundamental (at the bottom of the split) is f0 (what you're 
> labeling as "current_table_base_freq"), your sample rate is SR, and the upper 
> limit to the bandwidth is F_top where F_top < SR/2.
> 
> a the bottom of the split, the highest harmonic number is
> 
>   N = floor(F_top/f0)
> 
> the highest non-zero harmonic is at N*f0 < F_top < SR/2 and the lowest image 
> is SR - N*f0 > SR - F_top > SR/2.  so that image is not an alias.
> 
> now you're gonna play notes in the same split and the highest note (r = 
> "num_table_per_octave" which is what i would call the "number of splits per 
> octave") is at
> 
>   2^(1/r)*f0
> 
> and the highest harmonic before foldover is
> 
>  N * 2^(1/r)*f0
> 
> 
> folded over that harmonic becomes an alias at
> 
>  SR - N * 2^(1/r)*f0
> 
> 
> and we're gonna make sure that this alias stays above F_top
> 
>  SR - N * 2^(1/r)*f0 > F_top
> 
> 
> in the worst case N*f0 is within a millismidgen of F_top (but just below it) 
> so
> 
>   SR - 2^(1/r) 

Re: [music-dsp] FFT, zero padding and magnitude response

[Nigel Redmon]

Russell, a little typo:

> Another way to look at this is that zero padding is identical to
> linear interpolation in the frequency domain

“ideal interpolation in the frequency domain"

> On Sep 23, 2015, at 6:20 AM, Russell McClellan  
> wrote:
> 
> Another way to look at this is that zero padding is identical to
> linear interpolation in the frequency domain
> (https://ccrma.stanford.edu/~jos/dft/Zero_Padding_Theorem_Spectral.html).
> In general, linear interpolation won't preserve magnitudes between
> pairs of points with the same magnitude if the phase differs in the
> way you are describing.
> 
> For example, imagine at bin 2 of X is 2, bin 3 of X is 3, fully real.
> Now bin 2 of Y is 2i, bin 3 of Y is 3.  Say you zero pad by a factor
> or two, linear interpolating by 2.  Then at the new bin 5, halfway
> between the old 2 and 3,  X is obviously 2.5, where Y is 1i + 1.5,
> which obviously has a different magnitude than 2.5.
> 
> Thanks,
> -Russell
>> 
>> 
>> On Tue, Sep 22, 2015 at 6:21 AM, Tobias Münzer  wrote:
>>> 
>>> Hi
>>> 
>>> I have two signals X and Y with equal length, a power of two (e.g. 128).
>>> If I take the fft of these signals their magnitude responses are identical, 
>>> their phase responses are different.
>>> abs(fft(X)) = abs(fft(Y)), angle(fft(X)) != angle(fft(Y))
>>> 
>>> If I now zero pad both signals (to e.g. 256)  the magnitude responses 
>>> become different.
>>> abs(fft(Xp)) != abs(fft(Yp))
>>> And this is not just rounding noise, but a significant difference.
>>> 
>>> I am having a hard time understanding this behaviour, can someone explain?
>>> 
>>> Thanks a lot!
>>> ___
>>> 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] sinc interp, higher orders

[Nigel Redmon]

Hi Robert,

Yes, my answer was strictly for the special case of one table per octave. In 
that case, the start of the highest table (which would also be highest harmonic 
per table), such that transposing up by the maximum amount (in this case, one 
octave) is SR/3. But the general case is:

  F_top = SR / (2 + 1 / num_tables_per_octave)

And, whereas in the one-octave case the frequency base of the next higher table 
is twice the current table, the general case is higher by a factor of:

  2^(1 / num_table_per_octave)

The general case for the number of harmonics per table is:

  floor(F_top / current_table_base_freq)

And to elaborate on your comment that two tables per octave gets you over 19k, 
I believe that requires an asterisk (doesn’t it? had to do this quickly...): 
Whereas one table per octave works out symmetrically, where the top harmonics 
would be at 14700 and fold back to 14700 when shifted up an octave, two-per is 
not so convenient. The aliasing is limited to 19153 IF the highest harmonic is 
limited to 17640 (F_top for num_tables_per_octave = 2). Now that’s not much of 
a limitation, because “good luck hearing harmonics over 17640”, and aliasing 
would be a bigger concern, so it’s a good tradeoff—just noting it’s not 19/19 
(highest allowed harmonic in table / lowest alias). I wanted to add that 
because you wrote of a band above 19k "in which you *do* allow foldover and 
aliasing.  or, on the other hand, missing harmonics”, but you really don’t get 
both.

Nigel



> On Sep 20, 2015, at 6:57 PM, robert bristow-johnson 
>  wrote:
> 
> On 9/11/15 3:25 PM, Nigel Redmon wrote:
>> Great—glad to hear the articles were helpful, Nuno. (Website back up.)
>> 
>>> To build the oscillators tables I’m using that multi table technic you 
>>> describe on your waveforms series posts where maxHarms is: int maxHarms = 
>>> 44100.f / (3.0 * BASE_FREQ) + 0.5; Is this an heuristic?
>> 
>> This equation is specific to my goal of showing the minimum number of 
>> wavetables for a high-quality oscillator at 44.1 kHz sample rate. That is, 
>> one wavetable per octave. The oscillator I demonstrated does alias in the 
>> audio band, but those components are confined to being above one-third of 
>> the sample rate (in this case 44100.0 / 3.0). I think the rest of the 
>> equation is obvious—dividing by the base frequency (20 Hz, for instance), 
>> because the lower the lowest (base) frequency that you want to represent, 
>> the more harmonics are needed to fill the audio band. And the 0.5 is to 
>> round up.
>> 
>> So, back to the SR/3 part: Again, we’re allowing one wavetable per octave. 
>> If you wanted no aliasing at all, you’d need to limit the highest harmonic 
>> to 22050 Hz (half SR) when that table is shift ed up an octave. But the 
>> highest harmonic, for such a table, would only be at 11025 when not shifted 
>> up an octave. That’s not very good. Instead, we say that we’ll allow 
>> aliasing, but limit it to staying very high in the audio band where we can’t 
>> hear it, or at least it’s unnoticed.
> 
> the way i would quantify the problem is to define a frequency band from 
> somewhere below Nyquist (like 19 kHz) up to Nyquist (22.05 kHz) in which you 
> *do* allow foldover and aliasing.  or, on the other hand, missing harmonics.  
> if you don't mind crap above 19 kHz (put a brick-wall LPF on it, if you do 
> mind), you can get away with 2 wavetables per octave with Fs = 44.1 kHz, with 
> non-zero harmonics up to 19 kHz and no aliases below 19 kHz.  some harmonics 
> will fold back and become non-harmonic, but they'll stay above 19.
> 
> i thought i tossed out the equations before, but i don't remember.  i can do 
> it again, i s'pose.
> 
>> Well, if we allow 1k of aliasing, when shifted up, it would alias at 21050, 
>> and at the low end it would be 12025. The aliasing would be acceptable (not 
>> only unhearable, but this is for a synth—higher harmonics are typically 
>> lower amplitude than lower harmonics, AND we usually run through a lowpass 
>> filter), but there’s not much improvement for the start of the octave’s 
>> highest frequency component. Optimal is probably where the highest component 
>> of the bottom of the octave meets the worst-case aliasing from the top—and 
>> that is the half-way point of the top octave of the audio band (that is, 
>> 11025 to 22050 Hz). The half-way point of the top octave is 22050/1.5, or 
>> 44100/3—14700 Hz.
>> 
>> So, the equation just determines how many harmonics should be in the table 
>> for a given octave—the highest harmonic for a given octave table should be 
>> limited to 14700 Hz to allow for shifting up an octav

Re: [music-dsp] sinc interp, higher orders

[Nigel Redmon]

Great—glad to hear the articles were helpful, Nuno. (Website back up.)

> To build the oscillators tables I’m using that multi table technic you 
> describe on your waveforms series posts where maxHarms is: int maxHarms = 
> 44100.f / (3.0 * BASE_FREQ) + 0.5; Is this an heuristic? 

This equation is specific to my goal of showing the minimum number of 
wavetables for a high-quality oscillator at 44.1 kHz sample rate. That is, one 
wavetable per octave. The oscillator I demonstrated does alias in the audio 
band, but those components are confined to being above one-third of the sample 
rate (in this case 44100.0 / 3.0). I think the rest of the equation is 
obvious—dividing by the base frequency (20 Hz, for instance), because the lower 
the lowest (base) frequency that you want to represent, the more harmonics are 
needed to fill the audio band. And the 0.5 is to round up.

So, back to the SR/3 part: Again, we’re allowing one wavetable per octave. If 
you wanted no aliasing at all, you’d need to limit the highest harmonic to 
22050 Hz (half SR) when that table is shift ed up an octave. But the highest 
harmonic, for such a table, would only be at 11025 when not shifted up an 
octave. That’s not very good. Instead, we say that we’ll allow aliasing, but 
limit it to staying very high in the audio band where we can’t hear it, or at 
least it’s unnoticed. Well, if we allow 1k of aliasing, when shifted up, it 
would alias at 21050, and at the low end it would be 12025. The aliasing would 
be acceptable (not only unhearable, but this is for a synth—higher harmonics 
are typically lower amplitude than lower harmonics, AND we usually run through 
a lowpass filter), but there’s not much improvement for the start of the 
octave’s highest frequency component. Optimal is probably where the highest 
component of the bottom of the octave meets the worst-case aliasing from the 
top—and that is the half-way point of the top octave of the audio band (that 
is, 11025 to 22050 Hz). The half-way point of the top octave is 22050/1.5, or 
44100/3—14700 Hz.

So, the equation just determines how many harmonics should be in the table for 
a given octave—the highest harmonic for a given octave table should be limited 
to 14700 Hz to allow for shifting up an octave.

Of course, you could use more tables and limit the shifting to a fraction of an 
octave, and do better, but good luck hearing the difference ;-) It’s simply a 
good tradeoff.


> On Sep 11, 2015, at 10:18 AM, Nuno Santos  wrote:
> 
> Nigel,
> 
> You wordpress blog was crucial to understand how to implement a band limited 
> oscillator. I confess there were some small details I couldn’t figure out by 
> that time and then moved on. 
> 
> Right now I have a really complete synthesiser engine and I haven’t changed 
> or improved the oscillators section since then.
> 
> Question: How should I calculate the minimum table length size to have no 
> artefacts on a LFO? 
> 
> To build the oscillators tables I’m using that multi table technic you 
> describe on your waveforms series posts where maxHarms is: int maxHarms = 
> 44100.f / (3.0 * BASE_FREQ) + 0.5; Is this an heuristic? 
> 
> For the LFO tables I have only one table and the maxHarms is SAMPLE_RATE/2
> 
> And YES Alan, I’m using a interpolation algorithm but currently only on core 
> Delay unit. No interpolation on the oscillators unit right now. I’m using the 
> cubic hermit and it definitely contributes for a better sound.
> 
> Nuno Santos
> Founder / CEO / CTO
> www.imaginando.pt <http://www.imaginando.pt/>
> +351 91 621 69 62
> 
>> On 11 Sep 2015, at 17:39, Nigel Redmon > <mailto:earle...@earlevel.com>> wrote:
>> 
>> Hi Nuno,
>> 
>> First, can I suggest that you take a look at my series on wavetable 
>> oscillators? It covers some of the questions you have, and in particular 
>> goes into detail about table length.
>> 
>> Well, this is annoying, I think an automated WordPress update killed my 
>> site, I need to look into it. But normally, go to earlevel.com 
>> <http://earlevel.com/> and click the right-column topics for oscillators and 
>> the series will come up. But you can get the gist of it from my video:
>> 
>> https://youtu.be/k81hoZODOP0 <https://youtu.be/k81hoZODOP0>
>> 
>> Note that linear interpolation would help your low frequency oscillator 
>> issue, and help your oscillator at high frequencies too. 2048 is a good 
>> minimum table length for 20 Hz and up, so you’re in the right ballpark. 
>> (Longer if you aren’t using interpolation between samples, and longer to get 
>> sharp edges for LFO—for instance, a low frequency sawtooth won’t have a 
>> crisp “tick tick tick”, but a more muffled one, at 1 Hz if your table is 
>> only 2048.)
>> 
>

Re: [music-dsp] sinc interp, higher orders

[Nigel Redmon]

BTW, Ross, I should have made it clear that while I quoted your reply, I was 
commenting for the benefit of Nuno (and others)—hope that didn’t sound like I 
was correcting you. ;-)

> On Sep 11, 2015, at 9:40 AM, Ross Bencina  wrote:
> 
> > sinc(x) := sin(x)/x
> 
> On 12/09/2015 2:20 AM, Nigel Redmon wrote:
>> I’m also aware that some people would look at me like I’m a nut to even 
>> bring up that distinction.
> 
> I considered making the distinction, but it is discussed at the first link 
> that I provided:
> 
> > https://en.wikipedia.org/wiki/Sinc_function
> 
> Mathworld also says: "There are two definitions in common use."
> 
> http://mathworld.wolfram.com/SincFunction.html
> 
> 
> With hindsight, given the audience and intended use, I should have quoted the 
> "DSP and information theory" definition.
> 
> R.


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

Re: [music-dsp] sinc interp, higher orders

[Nigel Redmon]

Hi Nuno,

First, can I suggest that you take a look at my series on wavetable 
oscillators? It covers some of the questions you have, and in particular goes 
into detail about table length.

Well, this is annoying, I think an automated WordPress update killed my site, I 
need to look into it. But normally, go to earlevel.com and click the 
right-column topics for oscillators and the series will come up. But you can 
get the gist of it from my video:

https://youtu.be/k81hoZODOP0 

Note that linear interpolation would help your low frequency oscillator issue, 
and help your oscillator at high frequencies too. 2048 is a good minimum table 
length for 20 Hz and up, so you’re in the right ballpark. (Longer if you aren’t 
using interpolation between samples, and longer to get sharp edges for LFO—for 
instance, a low frequency sawtooth won’t have a crisp “tick tick tick”, but a 
more muffled one, at 1 Hz if your table is only 2048.)

Nigel


> On Sep 11, 2015, at 8:13 AM, Nuno Santos  wrote:
> 
> Hi,
> 
> Curiosity, by sinc do you mean sin function?
> 
> Before anything: I’m a newbie. If I say something stupid don’t throw fire at 
> me, please! :)
> 
> During this last year I have been developing a synthesizer. My lookup table 
> hadn’t more than 2048 samples. The sounds coming out from the oscillators was 
> alright.
> 
> When I got to develop a chorus, I was using the very same table for the lfo 
> oscillators. The modulation was causing artifacts. It took me a while to 
> understand that the problem was being caused by the lack of resolution of my 
> tables. I ended up with a table 441000 length, for a 44100 sample rate. The 
> artifacts were gone! My conclusion was that the raw steps were causing 
> audible artifacts and increasing the resolution was the solution.
> 
> I haven’t tried to find the lowest point of resolution that doesn’t cause 
> artifacts. I was so tired of trying to solve the artifacts that I have only 
> remember this problem when I saw this question from Victor.
> 
> For the oscillators table I have simply doubled the initial value and now i’m 
> using 4096.
> 
> What do you guys think of this? 
> 
> Thanks,
> 
> Regards,
> 
> Nuno
> 
>> On 10/09/2015, at 20:15, Victor Lazzarini  wrote:
>> 
>> Is there much to gain in going above a 1024 window, when doing sinc 
>> interpolation (for table lookup applications)?
>> 
>> (simple question; no intention of starting flame wars; not asking about any 
>> other method, either ;) )
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> ___
>> 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] sinc interp, higher orders

[Nigel Redmon]

Mind if I add—Normalized sinc function:

sinc(x) := sin(pi*x)/(pi*x)

This is the one we typically use. Sorry if some think that’s picky, but I 
worked with Rob Bracewell at Stanford in the late ‘80s on a project, and I was 
showing him that some Z80 code implemented a half-zinc table and SRC, and he 
looked up and said something like, “You know, some would say that sinc is sine 
x over x, but it’s sine pi x over pi x.” I immediately realized how profound 
that simple statement was. I’m also aware that some people would look at me 
like I’m a nut to even bring up that distinction. ;-)

> On Sep 11, 2015, at 8:43 AM, Ross Bencina  wrote:
> 
> On 12/09/2015 1:13 AM, Nuno Santos wrote:
>> Curiosity, by sinc do you mean sin function?
> 
> sinc(x) := sin(x)/x
> 
> https://en.wikipedia.org/wiki/Sinc_function
> 
> https://ccrma.stanford.edu/~jos/pasp/Windowed_Sinc_Interpolation.html
> 
> Cheers,
> 
> Ross.



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

Re: [music-dsp] Compensate for interpolation high frequency signal loss

[Nigel Redmon]

OK, I looked back at Robert’s post, and see that the fact his reply was broken 
up into segments (as he replied to segments of Peter’s comment) made me miss 
his point. At first he was talking general (pitch shifting), but at that point 
he was talking about strictly sliding into halfway between samples in the 
interpolation. Never mind.


> On Aug 18, 2015, at 1:50 PM, Nigel Redmon  wrote:
> 
> I’m sorry, I’m missing your point here, Peter (and perhaps I missed Roberts, 
> hence the “No?” in my reply to him).
> 
> The frequency response of linear interpolation is (sin(pi*x)/(pi*x))^2, -7.8 
> dB at 0.5 of the sample rate...
> 
> 
>> On Aug 18, 2015, at 1:40 AM, Peter S  wrote:
>> 
>> On 18/08/2015, Nigel Redmon  wrote:
>>>> 
>>>> well, if it's linear interpolation and your fractional delay slowly sweeps
>>>> from 0 to 1/2 sample, i think you may very well hear a LPF start to kick
>>>> in.  something like -7.8 dB at Nyquist.  no, that's not right.  it's -inf
>>>> dB at Nyquist.  pretty serious LPF to just slide into.
>>> 
>>> Right the first time, -7.8 dB at the Nyquist frequency, -inf at the sampling
>>> frequency. No?
>> 
>> -Inf at Nyquist when you're halfway between two samples.
>> 
>> Assume you have a Nyquist frequency square wave: 1, -1, 1, -1, 1, -1, 1, 
>> -1...
>> After interpolating with fraction=0.5, it becomes a constant signal
>> 0,0,0,0,0,0,0...
>> (because (-1+1)/2 = 0)
>> __


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

Re: [music-dsp] Compensate for interpolation high frequency signal loss

[Nigel Redmon]

I’m sorry, I’m missing your point here, Peter (and perhaps I missed Roberts, 
hence the “No?” in my reply to him).

The frequency response of linear interpolation is (sin(pi*x)/(pi*x))^2, -7.8 dB 
at 0.5 of the sample rate...


> On Aug 18, 2015, at 1:40 AM, Peter S  wrote:
> 
> On 18/08/2015, Nigel Redmon  wrote:
>>> 
>>> well, if it's linear interpolation and your fractional delay slowly sweeps
>>> from 0 to 1/2 sample, i think you may very well hear a LPF start to kick
>>> in.  something like -7.8 dB at Nyquist.  no, that's not right.  it's -inf
>>> dB at Nyquist.  pretty serious LPF to just slide into.
>> 
>> Right the first time, -7.8 dB at the Nyquist frequency, -inf at the sampling
>> frequency. No?
> 
> -Inf at Nyquist when you're halfway between two samples.
> 
> Assume you have a Nyquist frequency square wave: 1, -1, 1, -1, 1, -1, 1, -1...
> After interpolating with fraction=0.5, it becomes a constant signal
> 0,0,0,0,0,0,0...
> (because (-1+1)/2 = 0)
> __


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

Re: [music-dsp] Compensate for interpolation high frequency signal loss

[Nigel Redmon]

> On Aug 17, 2015, at 7:23 PM, robert bristow-johnson 
>  wrote:
> 
> On 8/17/15 7:29 PM, Sampo Syreeni wrote:
>> 
>>> to me, it really depends on if you're doing a slowly-varying precision 
>>> delay in which the pre-emphasis might also be slowly varying.
>> 
>> In slowly varying delay it ought to work no matter what.
> 
> well, if it's linear interpolation and your fractional delay slowly sweeps 
> from 0 to 1/2 sample, i think you may very well hear a LPF start to kick in.  
> something like -7.8 dB at Nyquist.  no, that's not right.  it's -inf dB at 
> Nyquist.  pretty serious LPF to just slide into.

Right the first time, -7.8 dB at the Nyquist frequency, -inf at the sampling 
frequency. No?


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

Re: [music-dsp] Compensate for interpolation high frequency signal loss

[Nigel Redmon]

And to add to what Robert said about “write code and sell it”, sometimes it’s 
more comfortable to make general but helpful comments here, and stop short of 
detailing the code that someone paid you a bunch of money for and might not 
want to be generally known.

And before people assume that I mean strictly “keep the secret sauce secret”, 
there’s also the fact that marketing might not want it known that every detail 
of their expensive plug-in is not 256x oversampled, 128-bit floating point data 
path throughout, dithered every stage. :-D

> On Aug 17, 2015, at 1:46 PM, robert bristow-johnson 
>  wrote:
> 
> On 8/17/15 12:07 PM, STEFFAN DIEDRICHSEN wrote:
>> I could write a few lines over the topic as well, since I made such a 
>> compensation filter about 17 years ago.
>> So, there are people, that do care about that topic, but there are only 
>> some, that do find time to write up something.
>> 
>> ;-)
>> 
>> Steffan
>> 
>> 
>>> On 17.08.2015|KW34, at 17:50, Theo Verelst >> > wrote:
>>> 
>>> However, no one here besides RBJ and a few brave souls seems to even care 
>>> much about real subjects.
> 
> Theo, there are a lotta heavyweights here (like Steffan).  if you want a 
> 3-letter acronym to toss around, try "JOS".   i think there are plenty on 
> this list that care deeply about reality because they write code and sell it. 
>  my soul is chicken-shit in the context.
> 
> -- 
> 
> r b-j  r...@audioimagination.com
> 
> "Imagination is more important than knowledge."


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

Re: [music-dsp] Compensate for interpolation high frequency signal loss

[Nigel Redmon]

OK, Robert, I did consider the slow versus fast issue. But there have been few 
caveats posted in this thread, so I thought it might be misleading to some to 
not be specific about context. The worst case would be a precision delay of an 
arbitrary constant. (For example, at 44.1 kHz SR, there would be a significant 
frequency response difference between 250 ms and 250.01 ms, despite no 
perceptible difference in time. Of course, in some cases, even when using 
interpolated delays, you can quantize the delay time to a sample boundary—say 
if modulation is transient and the steady state is the main concern.)

So, yes, the context means a lot, so we should be clear. (And can you tell I’m 
doing something with delays right now?)

Personally, I’m a fan of upsampling, when needed.


> On Aug 17, 2015, at 1:55 PM, robert bristow-johnson 
>  wrote:
> 
> On 8/17/15 2:39 PM, Nigel Redmon wrote:
>> Since compensation filtering has been mentioned by a few, can I ask if 
>> someone could get specific on an implementation (including a description of 
>> constraints under which it operates)? I’d prefer keeping it simple by 
>> restricting to linear interpolation, where it’s most needed, and perhaps 
>> these comments will make clearer what I’m after:
>> 
>> As I noted in the first reply to this thread, while it’s temping to look at 
>> the sinc^2 rolloff of a linear interpolator, for example, and think that 
>> compensation would be to boost the highs to undo the rolloff, that won’t 
>> work in the general case. Even in Olli Niemitalo’s most excellent paper on 
>> interpolation methods 
>> (http://yehar.com/blog/wp-content/uploads/2009/08/deip.pdf), he seems to 
>> suggest doing this with pre-emphasis, which seems to be a mistake, unless I 
>> misunderstood his intentions.
>> 
>> In Olli’s case, he specifically recommended pre-emphasis (which I believe 
>> will not work except for special cases of resampling at fixed fractions 
>> between real samples) over post, as post becomes more complicated. (It seems 
>> that you could do it post, taking into account the fractional part of a 
>> particular lookup and avoiding the use of recursive filters—personally I’d 
>> just upsample to begin with.)
> 
> to me, it really depends on if you're doing a slowly-varying precision delay 
> in which the pre-emphasis might also be slowly varying.
> 
> but if the application is sample-rate conversion or similar (like pitch 
> shifting) where the fractional delay is varying all over the place, i think a 
> fixed compensation for sinc^2 might be a good idea.  i don't see how it would 
> hurt.  especially for the over-sampled case.
> 
> i like Olli's "pink-elephant" paper, too.  and i think (since he was picking 
> up on Duane's and my old and incomplete paper) it was more about the 
> fast-varying fractional delay.  and i think that the Zölzer/Bolze paper 
> suggested the same thing (since it was even "worse" than linear interp).
> 
> 
> -- 
> 
> r b-j  r...@audioimagination.com
> 
> "Imagination is more important than knowledge."


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

Re: [music-dsp] Compensate for interpolation high frequency signal loss

[Nigel Redmon]

Since compensation filtering has been mentioned by a few, can I ask if someone 
could get specific on an implementation (including a description of constraints 
under which it operates)? I’d prefer keeping it simple by restricting to linear 
interpolation, where it’s most needed, and perhaps these comments will make 
clearer what I’m after:

As I noted in the first reply to this thread, while it’s temping to look at the 
sinc^2 rolloff of a linear interpolator, for example, and think that 
compensation would be to boost the highs to undo the rolloff, that won’t work 
in the general case. Even in Olli Niemitalo’s most excellent paper on 
interpolation methods 
(http://yehar.com/blog/wp-content/uploads/2009/08/deip.pdf), he seems to 
suggest doing this with pre-emphasis, which seems to be a mistake, unless I 
misunderstood his intentions.

In Olli’s case, he specifically recommended pre-emphasis (which I believe will 
not work except for special cases of resampling at fixed fractions between real 
samples) over post, as post becomes more complicated. (It seems that you could 
do it post, taking into account the fractional part of a particular lookup and 
avoiding the use of recursive filters—personally I’d just upsample to begin 
with.)

It just occurred to me that perhaps one possible implementation is to 
cross-fade between a pre-emphasized and normal delay line, depending on the 
fractional position (0.5 gets all pre-emph, 0.0 gets all normal). This sort of 
thing didn’t seem to be what Olli was getting at, since he only gave the 
worst-case rolloff curve and didn’t discuss it further.

I also think about the possibility of crossfading between emphasis and none, 
depending on the fractional position (full emphasis for 

I’m not asking because I need to do this—I’m asking for the sake of the thread, 
where people are talking about compensation, but not explaining the 
implementation they have in mind, and not necessarily explaining the conditions 
under which it works.


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

[music-dsp] Change in reply-to?

[Nigel Redmon]

I noticed that, as of the past three weeks, the reply-to for messages to the 
list has change from the list to the sender. Intentional? It seems to make it 
easy to reply to the sender and miss the list.
___
music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Compensate for interpolation high frequency signal loss

[Nigel Redmon]

As far as compensation: Taking linear as an example, we know that the response 
rolls off (“sinc^2"). Would you compensate by boosting the highs? Consider that 
for a linearly interpolated delay line, a delay of an integer number of 
samples, i, has no high frequency loss at all. But that the error is max it you 
need a delay of i + 0.5 samples. More difficult to compensate for, would be 
such a delay line where the delay time is modulated.

A well-published way of getting around the fractional problem is allpass 
compensation. But a lot of people seem to miss that this method doesn’t lend 
itself to modulation—it’s ideally suited for a fixed fractional delay. Here’s a 
paper that shows one possible solution, crossfading two allpass filters:

http://scandalis.com/jarrah/Documents/DelayLine.pdf

Obviously, the most straight-forward way to avoid the problem is to convert to 
a higher sample rate going into the delay line (using windowed sinc, etc.), 
then use linear, hermite, etc.


> On Aug 16, 2015, at 1:09 AM, Sham Beam  wrote:
> 
> Hi,
> 
> Is it possible to use a filter to compensate for high frequency signal loss 
> due to interpolation? For example linear or hermite interpolation.
> 
> Are there any papers that detail what such a filter might look like?
> 
> 
> Thanks
> Shannon
> ___
> music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp


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

Re: [music-dsp] A little frivolous diversion on the effect of using a delay

[Nigel Redmon]

> On Jul 20, 2015, at 11:12 PM, robert bristow-johnson 
>  wrote:
> 
> On 7/20/15 7:49 PM, Nigel Redmon wrote:
>> To add to Robert’s comment on discrete-time analog…
>> 
>> The only thing special about digital sampling is that it’s stable (those 
>> digital numbers can be pretty durable—the analog samples don’t hold up so 
>> well) and convenient for computation. But the digital audio samples are just 
>> a representation of the analog audio that’s been pulse amplitude modulated. 
>> (I never worked with BBDs or CCDs, and suspect there’s some zero-order hold 
>> involved in practical implementations,
> 
> there's gotta be *some* voltage at the output at all times.  doubt that it's 
> return to zero, so ZOH makes the most sense.

RIght. What I meant to imply is that the (mathematical) ideal is an impulse 
(return to zero), but for practical reasons it’s basically ZOH and you make 
adjustments.

>>  but it doesn’t matter as long as that’s compensated for—digital to analog 
>> converters have also dealt with the same sort of issue. Still, the basis is 
>> that those samples in the BBD/CCD represent impulses, momentary snapshots.) 
>> Just as with the digital versions, in the analog versions you have a lowpass 
>> filter to ensure the input spectrum remains below half the sample rate, and 
>> on the output you have a filter to get rid of the aliased images, created by 
>> the modulation process.
>> 
>> In the early days of digital delays, the analog delays had some advantages 
>> that are probably not obvious to someone coming from today’s knowledge. For 
>> instance, today we’d make a delay with a constant sample rate, and use a 
>> software LFO and an interpolated delay line to make a flanger. But back 
>> then, computation was difficult and costly, so it was done the same way that 
>> the analog delays did it: variable sample rate and vary the clock frequency 
>> with a hardware LFO. The advantage of digital was better fidelity, but the 
>> analog delays could sweep over a much wider range. Digital memory wasn’t so 
>> fast back then, and super-fast A/Ds were huge bucks (I worked for a group in 
>> a company in the late ‘70s that made a 40 MHz 8-bit A/D chip that was $800 
>> in low quantities, and they sold ‘em as fast as they could make ‘em).
> 
> geepers.  that's fast.  around 1979-80, i did a DSP project with a MC6809 and 
> a 12-bit DAC that i double-up and used with a comparator to be a successive 
> approximation ADC.  in those days the DAC was $40 and we didn't wanna spend 
> money getting an ADC.  the sampling rate was something like 10 Hz (it was a 
> medical application and the signal was very slow.)

These 8-bit ADCs were “flash" converters (a string of resistors with 
comparators feeding a MUX), usually used in video applications. They dropped to 
$500 in quantities…or, you could buy ones with a missing code or two cheaper, 
and correct for it in software, as some people on a budget did. They also made 
those popular 16x16 multipliers and MACs (MPY-16 and MAC-16) that people would 
make hardware FFT butterflies with. It runs in my mind that the Bell Labs 
(Alles) synth used a bunch of the multipliers. Now imagine a board full of 
these things, dissipating 5W each (the Mac-16s anyway—the MPY-16s were a bit 
less as I recall)…LOL.

One cool thing about the 6809 (because a multiply) was that they did all memory 
access on a half-cycle, so you could put two of them on the same memory out of 
phase to do more crunching.

--
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 little frivolous diversion on the effect of using a delay

[Nigel Redmon]

OK, this tune shows off a wide range of Marshall Time Modulator effects; I did 
in in 1979 in the EM lab at USC, very sparse Moog modular plus vocal:

http://earlevel.com/temp/Finally.mp3

The vocal shows off the MTM best. I put my roommate out on the roof of the 
fourth floor of the USC music building with a mic and headphones for isolation 
(had to pause for airplanes). His mic is going from pre-amp to MTM to tape. I’m 
inside twiddling the knobs on the MTM as he sings, taking it through flanging 
(1:56, for example), automatic triple-tracking (two independent delays with 
slow random modulation), etc. The vocal is printed in one take with effects, no 
overdubs, no editing, one guy singing. (The very first half-speed words are 
just taped and played back at half speed.)

The main string-machine-like sound is one sawtooth oscillator per voice, for 
the three-note chords. No filter, no modulation besides the MTM and the 
amplitude modulation that makes it sound like I’m playing the chords to a beat 
(I’m just holding them out per measure, as in the beginning, then turn up the 
amplitude of the LFO to the VCA). The sound is thin as heck without the MTM. 
Monophonic keyboard, so I used the Moog sequencer, 8x3, to set up four 3-note 
chords (as heard in the beginning) and select a chord by stepping to the 
appropriate sequencer position manually, then doing the same after turning up 
the LFO, but also transposing with the keyboard with my other hand.


> On Jul 20, 2015, at 2:24 PM, Nigel Redmon  wrote:
> 
> Here’s an interesting interview:
> 
> http://www.studioelectronics.biz/Documents/SSC.DEVICE.pdf 
> <http://www.studioelectronics.biz/Documents/SSC.DEVICE.pdf>
> 
> I first heard about it at AES (’75 in LA), from Stephen St. Croix himself. It 
> was a brand new product, and Steve was trying to convince anyone who would 
> listen. He was giving away cool t-shirts too, and my buddy and I wanted one. 
> He was a little ticked, I think, because he could tell we were more 
> interested in the t-shirts and were just waiting for him to finish and get 
> the shirts, but he gave his passionate speech and I was listening more than 
> he probably thought. He was basically selling against the new delta-encoded 
> digital competition, telling us why it sucked, and why the wimpy clocking 
> range (compared to his analog device) meant their flanging sucked, etc. He 
> handed us our shirts and we were gone to see what other cool stuff was at the 
> show.
> 
> But not too long after, the electronic music lab at USC got one, and I made 
> good use of it. At the end of summer, it was stolen. I was a lab rat and was 
> the last booking before then shut down for a couple of weeks ahead of the 
> fall semester—and when they opened the lab next, it was gone. They got a new 
> one, and identical circumstances—again, I was the last guy to book the lab 
> int he summer session, and when they re-opened the new one was gone as well. 
> It’s not like they cleaned out the lab—someone really like those Marshall 
> Time Modulators.
> 
> So, interesting history with them. St. Croix was plagued by problems 
> obtaining parts (the dvx modules, the CCDs), so I don’t think a large number 
> were built, and they cost too much for me at the time. I sure loved the 
> sound, though.
> 
> 
>> On Jul 20, 2015, at 1:45 PM, pdowling  wrote:
>> 
>>> Marshall Time Modulator
>> 
>> got some good links?
>> 
>> 
>> On 20 Jul 2015, at 21:40, Nigel Redmon  wrote:
>> 
>>> Most of the old delays were BBD, but the king of discrete-time analog was 
>>> the Marshall Time Modulator, which used CCDs. Between the dbx companding 
>>> for increased s/n and the wide clock-sweeping range, it had awesome 
>>> flanging (-80dB notches claimed)—great double/triple tracking too.
>>> 
>>> 
>>>> On Jul 20, 2015, at 12:16 PM, robert bristow-johnson 
>>>>  wrote:
>>>> 
>>>> On 7/20/15 2:44 PM, padawa...@obiwannabe.co.uk wrote:
>>>>> Whenever vintage delays come to my mind, I hear the sound of the bucket 
>>>>> brigade
>>>>> delay lines
>>>>> that were made from a chain of capacitors and switches. In the early 80s 
>>>>> there
>>>>> were many
>>>>> electronic magazine articles and kits to build them. The SAD chips had a 
>>>>> maximum
>>>>> delay time
>>>>> of about 200ms. Were they digital? Kind of.
>>>> 
>>>> no, they weren't.  not really.
>>>> 
>>>> discrete-time is not the same as digital.
>>>> 
>>>> 
>>>>> Were they analogue? Kind of too.
>>>> 
>>>&

Re: [music-dsp] A little frivolous diversion on the effect of using a delay

[Nigel Redmon]

To add to Robert’s comment on discrete-time analog…

The only thing special about digital sampling is that it’s stable (those 
digital numbers can be pretty durable—the analog samples don’t hold up so well) 
and convenient for computation. But the digital audio samples are just a 
representation of the analog audio that’s been pulse amplitude modulated. (I 
never worked with BBDs or CCDs, and suspect there’s some zero-order hold 
involved in practical implementations, but it doesn’t matter as long as that’s 
compensated for—digital to analog converters have also dealt with the same sort 
of issue. Still, the basis is that those samples in the BBD/CCD represent 
impulses, momentary snapshots.) Just as with the digital versions, in the 
analog versions you have a lowpass filter to ensure the input spectrum remains 
below half the sample rate, and on the output you have a filter to get rid of 
the aliased images, created by the modulation process.

In the early days of digital delays, the analog delays had some advantages that 
are probably not obvious to someone coming from today’s knowledge. For 
instance, today we’d make a delay with a constant sample rate, and use a 
software LFO and an interpolated delay line to make a flanger. But back then, 
computation was difficult and costly, so it was done the same way that the 
analog delays did it: variable sample rate and vary the clock frequency with a 
hardware LFO. The advantage of digital was better fidelity, but the analog 
delays could sweep over a much wider range. Digital memory wasn’t so fast back 
then, and super-fast A/Ds were huge bucks (I worked for a group in a company in 
the late ‘70s that made a 40 MHz 8-bit A/D chip that was $800 in low 
quantities, and they sold ‘em as fast as they could make ‘em). But you probably 
sweep those CCD clocks from something like 20 Khz to over 1 MHz (kinda of 
guessing here, but the point is that you could get nowhere remotely close to 
that with a DDL).


> On Jul 20, 2015, at 12:16 PM, robert bristow-johnson 
>  wrote:
> 
> On 7/20/15 2:44 PM, padawa...@obiwannabe.co.uk wrote:
>> Whenever vintage delays come to my mind, I hear the sound of the bucket 
>> brigade
>> delay lines
>> that were made from a chain of capacitors and switches. In the early 80s 
>> there
>> were many
>> electronic magazine articles and kits to build them. The SAD chips had a 
>> maximum
>> delay time
>> of about 200ms. Were they digital? Kind of.
> 
> no, they weren't.  not really.
> 
> discrete-time is not the same as digital.
> 
> 
>>  Were they analogue? Kind of too.
> 
> they were fully analog[ue].
> 
>> A lost technology
>> from gap between analogue and digital, you can hear them on a surprising 
>> number
>> of records,
>> especially early electronic.  That odd "dub" effect where a sound converges 
>> on a
>> single low
>> frequency is often BBD set to maximum feedback I think, but is sometimes
>> mistaken for tape
>> echo or early DDL.
> 
> to the precision of the A/D and D/A converters (which is considerable), there 
> is no reason that a modern digital delay ling can't be made to sound like the 
> old CCD (or "BBD" or whatever you wanna call it) delay products.  like an 
> analog[ue] amplifier, you might have to model in analog non-linearities, 
> noise, buzz, hum, and interference to make it sound the same.  with the 
> exception of the non-linearities, i normally think that modeling the noise 
> and buzz leaking through is not desirable.  who knows?
> 
> one thing i think might be cool is to use different delay/echo effects on 
> each string of a hex-pickup gitfiddle.  just like you might have different 
> pitch shifting done on each string.
> 
> 
> -- 
> 
> 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 little frivolous diversion on the effect of using a delay

[Nigel Redmon]

Here’s an interesting interview:

http://www.studioelectronics.biz/Documents/SSC.DEVICE.pdf 
<http://www.studioelectronics.biz/Documents/SSC.DEVICE.pdf>

I first heard about it at AES (’75 in LA), from Stephen St. Croix himself. It 
was a brand new product, and Steve was trying to convince anyone who would 
listen. He was giving away cool t-shirts too, and my buddy and I wanted one. He 
was a little ticked, I think, because he could tell we were more interested in 
the t-shirts and were just waiting for him to finish and get the shirts, but he 
gave his passionate speech and I was listening more than he probably thought. 
He was basically selling against the new delta-encoded digital competition, 
telling us why it sucked, and why the wimpy clocking range (compared to his 
analog device) meant their flanging sucked, etc. He handed us our shirts and we 
were gone to see what other cool stuff was at the show.

But not too long after, the electronic music lab at USC got one, and I made 
good use of it. At the end of summer, it was stolen. I was a lab rat and was 
the last booking before then shut down for a couple of weeks ahead of the fall 
semester—and when they opened the lab next, it was gone. They got a new one, 
and identical circumstances—again, I was the last guy to book the lab int he 
summer session, and when they re-opened the new one was gone as well. It’s not 
like they cleaned out the lab—someone really like those Marshall Time 
Modulators.

So, interesting history with them. St. Croix was plagued by problems obtaining 
parts (the dvx modules, the CCDs), so I don’t think a large number were built, 
and they cost too much for me at the time. I sure loved the sound, though.


> On Jul 20, 2015, at 1:45 PM, pdowling  wrote:
> 
>> Marshall Time Modulator
> 
> got some good links?
> 
> 
> On 20 Jul 2015, at 21:40, Nigel Redmon  wrote:
> 
>> Most of the old delays were BBD, but the king of discrete-time analog was 
>> the Marshall Time Modulator, which used CCDs. Between the dbx companding for 
>> increased s/n and the wide clock-sweeping range, it had awesome flanging 
>> (-80dB notches claimed)—great double/triple tracking too.
>> 
>> 
>>> On Jul 20, 2015, at 12:16 PM, robert bristow-johnson 
>>>  wrote:
>>> 
>>> On 7/20/15 2:44 PM, padawa...@obiwannabe.co.uk wrote:
>>>> Whenever vintage delays come to my mind, I hear the sound of the bucket 
>>>> brigade
>>>> delay lines
>>>> that were made from a chain of capacitors and switches. In the early 80s 
>>>> there
>>>> were many
>>>> electronic magazine articles and kits to build them. The SAD chips had a 
>>>> maximum
>>>> delay time
>>>> of about 200ms. Were they digital? Kind of.
>>> 
>>> no, they weren't.  not really.
>>> 
>>> discrete-time is not the same as digital.
>>> 
>>> 
>>>> Were they analogue? Kind of too.
>>> 
>>> they were fully analog[ue].
>>> 
>>>> A lost technology
>>>> from gap between analogue and digital, you can hear them on a surprising 
>>>> number
>>>> of records,
>>>> especially early electronic.  That odd "dub" effect where a sound 
>>>> converges on a
>>>> single low
>>>> frequency is often BBD set to maximum feedback I think, but is sometimes
>>>> mistaken for tape
>>>> echo or early DDL.
>>> 
>>> to the precision of the A/D and D/A converters (which is considerable), 
>>> there is no reason that a modern digital delay ling can't be made to sound 
>>> like the old CCD (or "BBD" or whatever you wanna call it) delay products.  
>>> like an analog[ue] amplifier, you might have to model in analog 
>>> non-linearities, noise, buzz, hum, and interference to make it sound the 
>>> same.  with the exception of the non-linearities, i normally think that 
>>> modeling the noise and buzz leaking through is not desirable.  who knows?
>>> 
>>> one thing i think might be cool is to use different delay/echo effects on 
>>> each string of a hex-pickup gitfiddle.  just like you might have different 
>>> pitch shifting done on each string.
>>> 
>>> 
>>> -- 
>>> 
>>> 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 l

Re: [music-dsp] A little frivolous diversion on the effect of using a delay

[Nigel Redmon]

Most of the old delays were BBD, but the king of discrete-time analog was the 
Marshall Time Modulator, which used CCDs. Between the dbx companding for 
increased s/n and the wide clock-sweeping range, it had awesome flanging (-80dB 
notches claimed)—great double/triple tracking too.


> On Jul 20, 2015, at 12:16 PM, robert bristow-johnson 
>  wrote:
> 
> On 7/20/15 2:44 PM, padawa...@obiwannabe.co.uk wrote:
>> Whenever vintage delays come to my mind, I hear the sound of the bucket 
>> brigade
>> delay lines
>> that were made from a chain of capacitors and switches. In the early 80s 
>> there
>> were many
>> electronic magazine articles and kits to build them. The SAD chips had a 
>> maximum
>> delay time
>> of about 200ms. Were they digital? Kind of.
> 
> no, they weren't.  not really.
> 
> discrete-time is not the same as digital.
> 
> 
>>  Were they analogue? Kind of too.
> 
> they were fully analog[ue].
> 
>> A lost technology
>> from gap between analogue and digital, you can hear them on a surprising 
>> number
>> of records,
>> especially early electronic.  That odd "dub" effect where a sound converges 
>> on a
>> single low
>> frequency is often BBD set to maximum feedback I think, but is sometimes
>> mistaken for tape
>> echo or early DDL.
> 
> to the precision of the A/D and D/A converters (which is considerable), there 
> is no reason that a modern digital delay ling can't be made to sound like the 
> old CCD (or "BBD" or whatever you wanna call it) delay products.  like an 
> analog[ue] amplifier, you might have to model in analog non-linearities, 
> noise, buzz, hum, and interference to make it sound the same.  with the 
> exception of the non-linearities, i normally think that modeling the noise 
> and buzz leaking through is not desirable.  who knows?
> 
> one thing i think might be cool is to use different delay/echo effects on 
> each string of a hex-pickup gitfiddle.  just like you might have different 
> pitch shifting done on each string.
> 
> 
> -- 
> 
> 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 little frivolous diversion on the effect of using a delay

[Nigel Redmon]

Er, minor correction, the effect I was talking about on the tune (where the 
echo is more part of the sound than perceived as a repeat) is the bass and the 
textural chordal change thing most easily heard in the sparse section starting 
at 1:37; my buddy added all the mallet things with echo (still cool, just 
differentiating what in my mind are two completely different uses of echo).


> On Jul 20, 2015, at 11:29 AM, Nigel Redmon  wrote:
> 
> Being a long-time fan of delays (and author of Echo farm PT plug-in and DL4 
> delay modeler stompbox), starting with tape delay (first a Univox tape delay, 
> graduated to Roland Space Echo (the space echo emulation in Echo Farm is 
> based on my aged RE-101)…when the digital first came in, it was neat at 
> first, but exact (near exact) delay is so boring after a bit, and your 
> realize that the rapid drop-off of frequencies in analog delays is a feature, 
> not a fault, and certainly the pitch consistency of tape echoes. My old prog 
> band recorded an album in 1979, and the engineer/producer wanted to use his 
> shiny new MXR rack delay. I completely regret not demand that we use the 
> space echo—my modular synth sounded so tiny.
> 
> Anyway, I was having a conversation with my old bandmate some time back, over 
> the phone; he’s a recording engineer producer theses days, and he mentioned 
> something about delays, saying that he never quite latched onto their use 
> (the way I had). I mentioned a fun way to use them that I had always liked (I 
> guess similar to the Alan Parson’s I Robot), then after getting off the call 
> whipped up some simple changes to show him what I meant. Being the guy he is, 
> he couldn’t help but add drums and finish it out. I made a little video for 
> it (he added the echoey sparse vibraphone/marimba melodic part, not really 
> what I’m talking about; I’m referring to the baseline and the textural 
> chordal change parts, also a mallet-ish sound by constant, where the echo is 
> integral to the sound):
> 
> https://youtu.be/BsNchxCglVk
> 
> 
> 
>> On Jul 20, 2015, at 9:43 AM, Theo Verelst  wrote:
>> 
>> Hi all,
>> 
>> No theoretical dumbfounding or deep searching incantations from me this 
>> Monday, but just something I've through about and that somehow has since 
>> long been a part of music and analog and digital productions.
>> 
>> I recall when I was doing some computer audio experiments say in the early 
>> 80s that there was this tantalizing effect that outside of special tape 
>> based machines hadn't really existed as an effect for using with random 
>> audio sources: the digital delay. I recall I was happy when I'd used (low 
>> fidelity) AD and DA converters and a early home computer with 64 kilobytes 
>> of memory to achieve an echo effect. It was fun. For musical purposes, a bit 
>> later I used various digital effect units that optionally could act as a 
>> delay line, and with a feedback control, as an echo unit.
>> 
>> It seems however that with time, the charm of the effect wore off. Just like 
>> nowadays some people occupy themselves with (arguably desirable) reverb 
>> reduction, it seems that using a delay isn't very cool anymore, doesn't 
>> necessarily make your audio workstation output prettier waves when playing a 
>> nice solo, and even it makes samples sound uglier when a digital delay 
>> effect is used on them, now that everybody with a computer and a sound card 
>> can do some audio processing, in a way that's a shame.
>> 
>> Some of the early charm must have been that the effect was featured in 
>> popular music, and wasn't easy enough to get for a hobbyist in the 70s, and 
>> possibly that the grungy and loose feel of the low bit depth and the jittery 
>> or modulated AD/DA converter clock signals was only fun while it lasted. 
>> Maybe instruments aren't designed to sound good with a delay effect either, 
>> or there's a conflict with audio system's internal processing, and as last 
>> suggestion, the studio "delay" effect does a little bit more than just 
>> delaying that makes it so addictive...
>> 
>> T.
>> —
> 
> 
> --
> 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 little frivolous diversion on the effect of using a delay

[Nigel Redmon]

Being a long-time fan of delays (and author of Echo farm PT plug-in and DL4 
delay modeler stompbox), starting with tape delay (first a Univox tape delay, 
graduated to Roland Space Echo (the space echo emulation in Echo Farm is based 
on my aged RE-101)…when the digital first came in, it was neat at first, but 
exact (near exact) delay is so boring after a bit, and your realize that the 
rapid drop-off of frequencies in analog delays is a feature, not a fault, and 
certainly the pitch consistency of tape echoes. My old prog band recorded an 
album in 1979, and the engineer/producer wanted to use his shiny new MXR rack 
delay. I completely regret not demand that we use the space echo—my modular 
synth sounded so tiny.

Anyway, I was having a conversation with my old bandmate some time back, over 
the phone; he’s a recording engineer producer theses days, and he mentioned 
something about delays, saying that he never quite latched onto their use (the 
way I had). I mentioned a fun way to use them that I had always liked (I guess 
similar to the Alan Parson’s I Robot), then after getting off the call whipped 
up some simple changes to show him what I meant. Being the guy he is, he 
couldn’t help but add drums and finish it out. I made a little video for it (he 
added the echoey sparse vibraphone/marimba melodic part, not really what I’m 
talking about; I’m referring to the baseline and the textural chordal change 
parts, also a mallet-ish sound by constant, where the echo is integral to the 
sound):

https://youtu.be/BsNchxCglVk



> On Jul 20, 2015, at 9:43 AM, Theo Verelst  wrote:
> 
> Hi all,
> 
> No theoretical dumbfounding or deep searching incantations from me this 
> Monday, but just something I've through about and that somehow has since long 
> been a part of music and analog and digital productions.
> 
> I recall when I was doing some computer audio experiments say in the early 
> 80s that there was this tantalizing effect that outside of special tape based 
> machines hadn't really existed as an effect for using with random audio 
> sources: the digital delay. I recall I was happy when I'd used (low fidelity) 
> AD and DA converters and a early home computer with 64 kilobytes of memory to 
> achieve an echo effect. It was fun. For musical purposes, a bit later I used 
> various digital effect units that optionally could act as a delay line, and 
> with a feedback control, as an echo unit.
> 
> It seems however that with time, the charm of the effect wore off. Just like 
> nowadays some people occupy themselves with (arguably desirable) reverb 
> reduction, it seems that using a delay isn't very cool anymore, doesn't 
> necessarily make your audio workstation output prettier waves when playing a 
> nice solo, and even it makes samples sound uglier when a digital delay effect 
> is used on them, now that everybody with a computer and a sound card can do 
> some audio processing, in a way that's a shame.
> 
> Some of the early charm must have been that the effect was featured in 
> popular music, and wasn't easy enough to get for a hobbyist in the 70s, and 
> possibly that the grungy and loose feel of the low bit depth and the jittery 
> or modulated AD/DA converter clock signals was only fun while it lasted. 
> Maybe instruments aren't designed to sound good with a delay effect either, 
> or there's a conflict with audio system's internal processing, and as last 
> suggestion, the studio "delay" effect does a little bit more than just 
> delaying that makes it so addictive...
> 
> T.
> —


--
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] oversampled Fourier Transform

[Nigel Redmon]

I think the basics have been hit by others (just had time to skim), but a 
couple of points:

As other have pointed out, zero padding increases the sample rate 
(oversampling) in the frequency domain; add: if you care about the absolute 
phase being correct, you need to make sure you’re zero-phase zero padding 
(padding the middle of the fft buffer—this assumes you used zero-phase 
windowing also).

You can use parabolic interpolation to increase peak detection accuracy between 
“bins”; I didn’t read this page but it looks like it covers the general idea: 
https://ccrma.stanford.edu/~jos/parshl/Peak_Detection_Steps_3.html


> On Mar 31, 2015, at 3:12 PM, MF  wrote:
> 
> given a N-point window h(n), how do I create an oversampled Fourier
> transform H out of h(n)? I need to have very high resolution of the H so
> that I can find out the magnitude of arbitrary frequency with little
> frequency error.
> 
> 
> This is what I did: to oversample h(n) with factor 2, I first sampled the
> window h with N * 2 points, and then simply FFT the 'new h' with N*2-point.
> But the H with N*2 points looks very different from H with N points. What
> am I doing wrong?
> 
> 
> Here is detailed description with some sample output of the original and
> oversampled fft
> 
> 
> This is my windowing function:
> 
> *function blackman(N)*
> 
>  a0 = 0.42659;
> 
>  a1 = 0.49656;
> 
>  a2 = 0.076849;
> 
>  w = zeros(N);
> 
> 
>  for n = 1:N
> 
>w[n] = a0 - a1 * cos(2*pi*n/(N-1)) + a2 * cos(4*pi*n/(N-1));
> 
>  end
> 
>  return w;
> 
> end
> 
> 
> I assume an oversampled fft of the window function by a factor of 2 would
> be *fft(blackman(N*2))*
> 
> 
> However, the fft values of the original and the oversampled value aren't
> increasing/decreasing in a similar way (I expect the oversampled version to
> takes twice as much samples to increase and decrease, in case the
> over-sample factor is 2).
> 
> 
> Here are some the fft sample values from 1 - 10. the original is
> FFT(blackman(512)), the oversampled is FFT(blackman(512 * 2))
> 
> 
> k = 1
> 
>   original: 217.9943833003818 + 0.0im
> 
>   oversampled: 873.2366098911153 + 0.0im
> 
> k = 2
> 
>   original: -127.11893711697411 - 2.340240508514901im
> 
>   oversampled: -508.4935935475258 - 2.3400747304536136im
> 
> k = 3
> 
>   original: 19.845020222085132 + 0.7309352010595286im
> 
>   oversampled: 78.87486492124337 + 0.7259756614936985im
> 
> k = 4
> 
>   original: 0.00044320678301414774 + 2.423663020980352e-5im
> 
>   oversampled: 0.0005516543659794568 + 7.61242746175689e-6im
> 
> k = 5
> 
>   original: 0.007485288714345478 + 0.0005517961643643162im
> 
>   oversampled: 0.00748836292444639 + 0.00013785416101184825im
> 
> k = 6
> 
>   original: 0.0060558634779024605 + 0.000558513387226844im
> 
>   oversampled: 0.00605535370050697 + 0.00013934970191932598im
> 
> k = 7
> 
>   original: 0.004581346143077173 + 0.0005075321354533686im
> 
>   oversampled: 0.004584081103264545 + 0.0001265980340830028im
> 
> k = 8
> 
>   original: 0.0035101418651299794 + 0.0004541979779443242im
> 
>   oversampled: 0.003516027383715841 + 0.0001132935089731223im
> 
> k = 9
> 
>   original: 0.0027517589243924367 + 0.00040747551324277084im
> 
>   oversampled: 0.0027600729094881945 + 0.00010164856218561597im
> 
> k = 10
> 
>   original: 0.002205670972923391 + 0.0003679932983093956im
> 
>   oversampled: 0.0022158009449307643 + 9.181309340287595e-5im
> 
> 
> What's wrong with my approach?
> 
> 
> Thanks in advance!
> --
> 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] Array indexing in Matlab finally corrected after 30 years!

[Nigel Redmon]

> On Apr 1, 2015, at 7:19 AM, robert bristow-johnson 
>  wrote:
> 
> On 4/0/15 6:24 AM, Max wrote:

Well Played.

--
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] Glitch/Alias free modulated delay

[Nigel Redmon]

Suggestion:

Make it work with linear interpolation first.

The implementation is extremely simple—it won’t take much of your time to try 
it—and you’ll eliminate most of the problems (buffer wrap, etc.) without 
getting confused about whether your interpolation scheme is the fault.

Plus, you’ll have a baseline to compare higher-order improvements with. Linear 
interpolation sounds better than most people would guess, with typical musical 
input (musical interments usually have weaker upper harmonics), so you’ll have 
a better idea of whether you’re getting your money’s worth with more elaborate 
methods.



> On Mar 20, 2015, at 2:10 PM, Nuno Santos  wrote:
> 
> 
>> On 20 Mar 2015, at 18:58, Alan Wolfe  wrote:
>> 
>> One thing to watch out for is to make sure you are not looking
>> backwards AND forwards in time, but only looking BACK in time.
> 
> This is how I calculate the read index:
> 
> float t=_writeIndex-_time-_modulation*_modulationRange;
> 
> if(t<0)
>t+=_size;
> 
>> 
>> When you say you have an LFO going from -1 to 1 that makes me think
>> you might be going FORWARD in the buffer as well as backwards, which
>> would definitely cause audible problems.
> 
> I have tried to rescale the LFO to fit between 0 and 1 and it doing the same 
> artefacts:
> 
> 
> // this where delay gets updated with lfo
> float lfo = (_lfo.step()-1.f)/2.f;
> 
> delay.setModulation(lfo);
> 
>> 
>> your LFO really should go between -1 and 0, you then multiply that
>> value by the number of samples in your buffer (minus 1 if needed,
>> depending on your design and timing in your code), and then subtract
>> that value from your "write index" into the buffer, making sure to
>> handle the case of going negative, where your subtracted offset is
>> greater than your current write index.
> 
> I even tried to change from 
> 
> _time+_modulation*_modulationRange
> 
> to 
> 
> _time-_modulation*_modulationRange 
> 
> Exactly the same issues….
> 
> :/

--
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] Geographical visualization of music-dsp list participants

[Nigel Redmon]

That marker at Torrance (usa-west) is me ;-)


> On Feb 11, 2015, at 3:46 AM, Peter S  wrote:
> 
> On 11/02/2015, Peter P.  wrote:
>> Thank you! This is a nice visualization. If I may correct a tiny little
>> bit, I see it more as a representation of the people who clicked your
>> link, which might not be synonymous with people reading the list (but
>> you are sure aware of this difference). What link were people supposed
>> to click on by the way?
> 
> Exactly - it only visualizes people who clicked on this link I posted
> here earlier:
> http://morpheus.spectralhead.com/demos/
> 
> The number of people who clicked on my biquad filter transfer curves,
> was about the same  (~125 hits), so I just assumed it's mostly the
> same people, and did not bother to analyze that separately. So yes,
> it's only partial data, but still interesting.
> 
>>> Close-up of San Francisco - Los Angeles area:
>>> http://morpheus.spectralhead.com/img/musicdsp/usa-west.png
>> I am just curious who the lucky girl/guy is that accessed your link from
>> the Channel Island National Park. ;)
> 
> There's also a visitor from the Canary Islands :)
> 
>> Do you know how many accesses are from web spiders/crawlers?
> 
> One of them is BingBot from Redmond, that I forgot to remove.
> Bots/crawlers usually have a distinct signature in the log, but I do
> not see any other bots in the list.
> 
>> thanks again for your nice visualizations!
> 
> You're welcome :) It's always interesting to see visualized data.
> 
> - Peter
> --
> 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] Dither video and articles

[Nigel Redmon]

Maybe you missed the original kickstarter video (it’s still there)…snake oil 
sales is when famous musicians, who have spent countless hours in the finest, 
quietest studios, with the finest and costliest equipment available, step out 
of a CAR, with a pocket-player system, and say it’s the best sounding digital 
audio they’ve ever heard. :-)


> On Feb 10, 2015, at 1:25 PM, Tom Duffy  wrote:
> 
> So you like the bar being raised, but not the way that Neil Young has
> attempted?
> 
> Whether the higher resolution actually degrades the quality is a
> topic up for future debate.
> 
> From the ponomusic webpage:
> "...and now, with the PonoPlayer, you can finally feel the master in all its 
> glory, in its native resolution, CD quality or higher, the way the artist 
> made it, exactly"
> 
> Even they are not saying it has to be higher than CD quality, just
> that it has to have been made well in the first place.
> 
> I don't get why so many people are trying to paint this as
> a snake oil pitch.
> 
> ---
> Tom.
> 
> On 2/10/2015 1:13 PM, Ethan Duni wrote:
> I'm all for releasing stuff from improved masters. There's a trend in my
> favorite genre (heavy metal) to rerelease a lot of classics in "full
> dynamic range" editions lately. While I'm not sure that all of these
> releases really sound much better (how much dynamic range was there in an
> underground death metal recording from 1991 anyway?) I like the trend.
> These are regular CD releases, no weird formats (demonstrating that such is
> not required to sell the improved master releases).
> 
> But the thing is that you often *can* hear the extra sampling frequency -
> in the form of additional distortion. It sounds, if anything, *worse* than
> a release with an appropriate sample rate! Trying to sell people on better
> audio, and then giving them a bunch of additional intermodulation
> distortion is not a justified marketing ploy, it's outright deceptive and
> abusive. This is working from the assumption that your customers are
> idiots, and that you should exploit that to make money, irrespective of
> whether audio quality is harmed or not. The fact the Neil Young is himself
> one of the suckers renders this less objectionable, but only slightly.
> Anyway Pono is already a byword for "audiophile snake oil" so hopefully the
> damage will mostly be limited to the bank accounts of Mr. Young and his
> various financial backers in this idiocy. Sounds like the product is a real
> dog in industrial design terms anyway (no hold button, awkward shape,
> etc.). Good riddance...
> 
> E
> --
> 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
> 
> 
> NOTICE: This electronic mail message and its contents, including any 
> attachments hereto (collectively, "this e-mail"), is hereby designated as 
> "confidential and proprietary." This e-mail may be viewed and used only by 
> the person to whom it has been sent and his/her employer solely for the 
> express purpose for which it has been disclosed and only in accordance with 
> any confidentiality or non-disclosure (or similar) agreement between TEAC 
> Corporation or its affiliates and said employer, and may not be disclosed to 
> any other person or entity.
> 
> 
> 
> --
> 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] Dither video and articles

[Nigel Redmon]

>An audio engineer doesn't work for himself, so I don't see your point.

Well, I think that you probably do, but if you really don’t, set about chatting 
individually with such people to convince them that they can’t hear and don’t 
need dither at 16-bit, and you’ll get the point soon enough ;-)

But I don’t want to give you the impression I’m arguing, just discussing. I 
don’t feel we’re that far apart, in general.


> On Feb 9, 2015, at 10:12 PM, Didier Dambrin  wrote:
> 
> Well if it's 1 in 100, then dither using whatever is available & forget it. 
> But if it's 50 in 100, then I'd say it's still worth getting interested in 
> the best dithering algo's, or developping them further.
> In fact, if it happens to be 50 in 100, then I'd even go as far as saying 
> that delivering music to the world in 24bit format is NOT stupid and that 
> Neil Young's music player isn't just a lame marketing ploy.
> 
> 
> An audio engineer doesn't work for himself, so I don't see your point. An 
> audio engineer's most important job is also mastering, which generally 
> involves heavy compression & other rather destructive processes.
> To me, if an audio engineer dithers, it's more related to that compulsive 
> obsession about well-rounded things, that us programmers "suffer" from as 
> well. I bet many programmers here, when having to decide about parameter 
> values, will go for 1. no decimals if that works, 2. even numbers if that 
> works, 3. powers of 2 if that works. For no other reason than imaginary 
> perfection, so it's a form of superstition.
> 
> But yes, you're right that dithering has a selling point, if the goal is to 
> sell it to engineers. But then it's a debate more about marketing than 
> "science". Hey, it doesn't even need to do anything to be sellable.
> 
> 
> Personally, I think it'd be way more interesting to know more about this side 
> of perception. There's no mystery about the humanly audible frequency range, 
> and how it varies with age. Looks like there still is about levels?
> Afterall, my ears aren't in perfect shape, I happen to have hyperacusis of 
> bass (that, or the rest of the world doesn't hear bass loud enough).
> 
> It would also be interesting in other domains of DSP, because it's, for ex, 
> quite common to use waveshaping tables to save computation - the precision of 
> those tables then doesn't depend on our own perception, but the accepted one. 
> We use a lot of expensive trigonometry functions, and it has become quite 
> common to use low-precision algos to spare CPU. I've always done this 
> according to my ears, not according to charts.
> 
> 
> 
> 
> -Message d'origine- From: Nigel Redmon
> Sent: Tuesday, February 10, 2015 4:19 AM
> To: A discussion list for music-related DSP
> Subject: Re: [music-dsp] Dither video and articles
> 
>> But it matters, because the whole point of dithering to 16bit depends on how 
>> common that ability is.
> 
> Depends on how common? I’m not sure what qualifies for common, but if it’s 1 
> in 100, or 5 in 100, it’s still a no-brainer because it costs nothing, 
> effectively.
> 
> But more importantly, I don’t think you’re impressed by my point that it’s 
> the audio engineers, the folks making the music, that are in the best 
> position to hear it, and to do something about it. There are the ones 
> listening carefully, in studios built to be quiet and lack reflections and 
> resonances that might mask things, on revealing monitors and with ample 
> power. I don’t think that you understand that it’s these guys who are not 
> going to let their work go out the door with grit on it, even if it’s below 
> -90 dB. You wouldn’t get many sympathetic ears among them if you advocated 
> that they cease this dithering nonsense :-) I get enough grief about telling 
> them that dither at 24-bit is useless.
> 
> How common it is for for the average listener is immaterial. It’s not done 
> for the average listener.
> 
> 
>> On Feb 9, 2015, at 6:56 PM, Didier Dambrin  wrote:
>> 
>> I'm having a hard time finding anyone who could hear past the -72dB noise, 
>> here around.
>> 
>> Really, either you have super-ears, or the cause is (technically) somewhere 
>> else. But it matters, because the whole point of dithering to 16bit depends 
>> on how common that ability is.
>> 
>> 
>> 
>> 
>> -Message d'origine- From: Andrew Simper
>> Sent: Saturday, February 07, 2015 2:08 PM
>> To: A discussion list for music-related DSP
>> Subject: Re: [music-dsp] Dither video and articles
&

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

>But it matters, because the whole point of dithering to 16bit depends on how 
>common that ability is.

Depends on how common? I’m not sure what qualifies for common, but if it’s 1 in 
100, or 5 in 100, it’s still a no-brainer because it costs nothing, effectively.

But more importantly, I don’t think you’re impressed by my point that it’s the 
audio engineers, the folks making the music, that are in the best position to 
hear it, and to do something about it. There are the ones listening carefully, 
in studios built to be quiet and lack reflections and resonances that might 
mask things, on revealing monitors and with ample power. I don’t think that you 
understand that it’s these guys who are not going to let their work go out the 
door with grit on it, even if it’s below -90 dB. You wouldn’t get many 
sympathetic ears among them if you advocated that they cease this dithering 
nonsense :-) I get enough grief about telling them that dither at 24-bit is 
useless.

How common it is for for the average listener is immaterial. It’s not done for 
the average listener.


> On Feb 9, 2015, at 6:56 PM, Didier Dambrin  wrote:
> 
> I'm having a hard time finding anyone who could hear past the -72dB noise, 
> here around.
> 
> Really, either you have super-ears, or the cause is (technically) somewhere 
> else. But it matters, because the whole point of dithering to 16bit depends 
> on how common that ability is.
> 
> 
> 
> 
> -Message d'origine- From: Andrew Simper
> Sent: Saturday, February 07, 2015 2:08 PM
> To: A discussion list for music-related DSP
> Subject: Re: [music-dsp] Dither video and articles
> 
> On 7 February 2015 at 03:52, Didier Dambrin  wrote:
>> It was just several times the same fading in/out noise at different levels,
>> just to see if you hear quieter things than I do, I thought you'd have
>> guessed that.
>> https://drive.google.com/file/d/0B6Cr7wjQ2EPub2I1aGExVmJCNzA/view?usp=sharing
>> (0dB, -36dB, -54dB, -66dB, -72dB, -78dB)
>> 
>> Here if I make the starting noise annoying, then I hear the first 4 parts,
>> until 18:00. Thus, if 0dB is my threshold of annoyance, I can't hear -72dB.
>> 
>> So you hear it at -78dB? Would be interesting to know how many can, and if
>> it's subjective or a matter of testing environment (the variable already
>> being the 0dB "annoyance" starting point)
> 
> Yep, I could hear all of them, and the time I couldn't hear the hiss
> any more as at the 28.7 second mark, just before the end of the file.
> For reference this noise blast sounded much louder than the bass tone
> that Nigel posted when both were normalised, I had my headphones amp
> at -18 dB so the first noise peak was loud but not uncomfortable.
> 
> I thought it was an odd test since the test file just stopped before I
> couldn't hear the LFO amplitude modulation cycles, so I wasn't sure
> what you were trying to prove!
> 
> All the best,
> 
> Andy
> 
> 
> 
> 
>> -Message d'origine- From: Andrew Simper
>> Sent: Friday, February 06, 2015 3:21 PM
>> To: A discussion list for music-related DSP
>> Subject: Re: [music-dsp] Dither video and articles
>> 
>> Sorry, you said until, which is even more confusing. There are
>> multiple points when I hear the noise until since it sounds like the
>> noise is modulated in amplitude by a sine like LFO for the entire
>> file, so the volume of the noise ramps up and down in a cyclic manner.
>> The last ramping I hear fades out at around the 28.7 second mark when
>> it is hard to tell if it just ramps out at that point or is just on
>> the verge of ramping up again and then the file ends at 28.93 seconds.
>> I have not tried to measure the LFO wavelength or any other such
>> things, this is just going on listening alone.
>> 
>> All the best,
>> 
>> Andrew Simper
>> 
>> 
>> 
>> On 6 February 2015 at 22:01, Andrew Simper  wrote:
>>> 
>>> On 6 February 2015 at 17:32, Didier Dambrin  wrote:
 
 Just out of curiosity, until which point do you hear the noise in this
 little test (a 32bit float wav), starting from a bearable first part?
 
 
 https://drive.google.com/file/d/0B6Cr7wjQ2EPucjFCSUhGNkVRaUE/view?usp=sharing
>>> 
>>> 
>>> I hear noise immediately in that recording, it's hard to tell exactly
>>> the time I can first hear it since there is some latency from when I
>>> press play to when the sound starts, but as far as I can tell it is
>>> straight away. Why do you ask such silly questions?
>>> 
>>> All the best,
>>> 
>>> Andrew Simper
>> 
>> --
>> 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
>> 
>> 
>> -
>> Aucun virus trouve dans ce message.
>> Analyse effectuee par AVG - www.avg.fr
>> Version: 2015.0.5645 / Base de donnees virale: 4281/9068 - Date: 06/02/2015
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subsc

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

I’m thankful for Andy posting that clear explanation too. Sometimes I 
understate things—when I said that it would be “pretty hard to avoid” having 
ample gaussian noise to self-dither in the A/D process, I was thinking 
cryogenics (LOL).


> On Feb 9, 2015, at 7:54 AM, Vicki Melchior  wrote:
> 
> That's a clear explanation of the self-dither assumed in A/D conversion, 
> thanks for posting it. 
> 
> Vicki
> 
> On Feb 8, 2015, at 9:11 PM, Andrew Simper wrote:
> 
>> Vicki,
>> 
>> If you look at the limits of what is possible in a real world ADC
>> there is a certain amount of noise in any electrical system due to
>> gaussian thermal noise:
>> http://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise
>> 
>> For example if you look at an instrument / measurement grade ADC like
>> this: 
>> http://www.prismsound.com/test_measure/products_subs/dscope/dscope_spec.php
>> They publish figures of a residual noise floor of 1.4 uV, which they
>> say is -115 dBu. So if you digitise a 1 V peak (2 V peak to peak) sine
>> wave with a 24-bit ADC then you will have hiss (which includes a large
>> portion of gaussian noise) at around the 20 bit mark, so you will have
>> 4-bits of hiss to self dither. This has nothing to do with microphones
>> or noise in air, this is in the near perfect case of transmission via
>> a well shielded differential cable transferring the voltage directly
>> to the ADC.
>> 
>> All the best,
>> 
>> Andy
>> -- cytomic -- sound music software --
>> 
>> 
>> On 9 February 2015 at 00:09, Vicki Melchior  wrote:
>>> I have no argument at all with the cheap high-pass TPDF dither; whenever it 
>>> was published the original authors undoubtedly verified that the moment 
>>> decoupling occurred, as you say.  And that's what is needed for dither 
>>> effectiveness.   If you're creating noise for dither, you have the option 
>>> to verify its properties.  But in the situation of an analog signal with 
>>> added, independent instrument noise, you do need to verify that the 
>>> composite noise source actually satisfies the criteria for dither.  1/f 
>>> noise in particular has been questioned, which is why I raised the spectrum 
>>> issue.
>>> 
>>> Beyond that, Nigel raises this issue in the context of "self-dither".  In 
>>> situations where there is a clear external noise source present, whether 
>>> the situation is analog to digital conversion or digital to digital bit 
>>> depth change, the external noise may, or may not, be satisfactory as dither 
>>> but at least it's properties can be measured.  If the 'self-dithering' 
>>> instead refers to analog noise captured into the digitized signal with the 
>>> idea that this noise is going to be preserved and available at later 
>>> truncation steps to 'self dither' it is a very very hazy argument.   I'm 
>>> aware of the various caveats that are often postulated, i.e. signal is 
>>> captured at double precision, no truncation, very selected processing.  But 
>>> even in minimalist recording such as live to two track, it's not clear to 
>>> me that the signal can get through the digital stages of the A/D and still 
>>> retain an unaltered noise distribution.  It certainly won't do so after 
>>> considerable processing.  So the sho
> r
>> t
>>> answer is, dither!  At the 24th bit or at the 16th bit, whatever your 
>>> output is.  If you (Nigel or RBJ) have references to the contrary, please 
>>> say so.
>>> 
>>> Vicki
>>> 
>>> On Feb 8, 2015, at 10:11 AM, robert bristow-johnson wrote:
>>> 
 On 2/7/15 8:54 AM, Vicki Melchior wrote:
> Well, the point of dither is to reduce correlation between the signal and 
> quantization noise.  Its effectiveness requires that the error signal has 
> given properties; the mean error should be zero and the RMS error should 
> be independent of the signal.  The best known examples satisfying those 
> conditions are white Gaussian noise at ~ 6dB above the RMS quantization 
> level and white TPDF noise  at ~3dB above the same, with Gaussian noise 
> eliminating correlation entirely and TPDF dither eliminating correlation 
> with the first two moments of the error distribution.   That's all 
> textbook stuff.  There are certainly noise shaping algorithms that shape 
> either the sum of white dither and quantization noise or the white dither 
> and quantization noise independently, and even (to my knowledge) a few 
> completely non-white dithers that are known to work, but determining the 
> effectiveness of noise at dithering still requires examining the 
> statistical properties of the error signal and showi
> n
>> g
>>> 
 th
> at the mean is 0 and the second moment is signal independent.  (I think 
> Stanley Lipschitz showed that the higher moments don't matter to 
> audibility.)
 
 but my question was not about the p.d.f. of the dither (to decouple both 
 the mean and the variance of the quantization error, you need triangular 
 p.d.f. dith

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

OK, I don’t want to diverge too much from the practical to the theoretical, so 
I’m going to run down what is usual, not what is possible, because it narrows 
the field of discussion.

Most people I know are using recording systems that bussing audio at 32-bit 
float, minimum, and use 64-bit float calculations in plug-ins and significant 
processing. They may still be using 24-bit audio tracks on disk, but for the 
most part they are recorded and are dithered one way or another (primarily 
gaussian noise in the recording process). They may bounce things to tracks to 
free processor cycles. I think in large majority of cases, these are 
self-dithered, but even if it doesn’t happen for some, I don’t think it will 
impact the audio. And if people are worried about it, I don’t understand why 
they aren’t using 32-bit float files, as I think most people have that choices 
these days.

Some of the more hard core will send audio out to a convertor (therefore 
truncated at 24-bit), and back in. Again, I think the vast majority of cases, 
these will self dither, but then there’s the fact error is at a very low level, 
will get buried in the thermal noise of the electronics, etc.

Maybe I left out some other good ones, but to cut it short, yes, I’m mainly 
talking about final mixes. At 24-bit, that often goes to someone else to 
master. The funny thing is that some mastering engineers say “only dither 
once!”, and they want to be the one doing it. Others point out that they may 
want to mess with the dynamic range and boost frequencies, and any error from 
not dithering 24-bit will show up in…you know, the stereo imaging, depth, etc. 
I think it would be exceptional to actually have truncation distortion of 
significant duration, except for potential situations with unusual fades, so 
I’m not worried about saying don’t dither 24-bit, even heading to a mastering 
engineer (but again, do it if you want, it’s just no big deal for final 
outputs–in contrast to the pain in the rear it is to do it at every point for 
the items I mentioned in previous paragraphs).

Down the more theoretical paths, I’ve had people argue that this is a big deal 
because things like ProTools 56k plug-ins need to be dithered internally…but 
why argue legacy stuff that “is what it is”, and secondly, these people usually 
don’t think through how many 24-bit truncations occur in a 56k algorithm, and 
you only have so many cycles. The other thing I sometimes get is the specter of 
the cumulative effect (but what if you have so many tracks, and feedback, 
and…)—but it seems to me that the more of this you get going on, to approach a 
meaningful error magnitude, the more it’s jumbled up in chaos and the less easy 
it is for your ear to recognize it as “bad”.



> On Feb 9, 2015, at 7:54 AM, Vicki Melchior  wrote:
> 
> Nigel, I looked at your video again and it seems to me it's confusing as to 
> whether you mean 'don't dither the 24b final output' or 'don't ever dither at 
> 24b'.  You make statements several times that imply the former, but in your 
> discussion about 24b on all digital interfaces, sends and receives etc, you 
> clearly say to never dither at 24b.  Several people in this thread have 
> pointed out the difference between intermediate stage truncation and final 
> stage truncation, and the fact that if truncation is done repeatedly, any 
> distortion spectra will continue to build.   It is not noise-like, the peaks 
> are coherent peaks and correlated to the signal.  
> 
> You don't say in the video what the processing history is for the files you 
> are using.  If they are simple captures with no processing, they probably 
> reflect the additive gaussian noise present at  the 20th bit in the A/D, 
> based on Andy's post, and are properly dithered for 24b truncation.   My 
> point is that at the digital capture stage you have (S+N) and the amplitude 
> distribution of the S+N signal might be fine for 24b truncation if N is 
> dither-like.  After various stages of digital processing including non-linear 
> steps, the (S+N) intermediate signal may no longer have an adequate amplitude 
> distribution to be truncated without 24b dither.  
> 
> I think the whole subject of self dither might be better approached through 
> FFT measurement than by listening.   Bob Katz shows an FFT of truncation 
> spectra at 24b in his book on 'Itunes Music, Mastering for High Resolution 
> Audio Delivery'  but he uses a generated, dithered pure tone that doesn't 
> start with added gaussian noise.  Haven't thought about it but I can imagine 
> extending his approach into a research effort.  
> 
> Offhand I don't know anything that would go wrong in your difference file (" 
> ...if the error doesn't sound wrong).  It's a common method for looking at 
> residuals.
> 
&g

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

>Beyond that, Nigel raises this issue in the context of "self-dither”...

First, remember that I’m the guy who recommended “always” dithering 16-bit (no 
“always” as in “alway necessary”, but as in “do it always, unless you know that 
it gives no improvement”), and to not bother dithering 24-bit. So, I’m only 
interested in this discussion for 24-bit. That said:

>...In situations where there is a clear external noise source present, whether 
>the situation is analog to digital conversion or digital to digital bit depth 
>change, the external noise may, or may not, be satisfactory as dither but at 
>least it's properties can be measured.

For 24-bit audio, could you give an example of when it’s likely to not be 
satisfactory (maybe you’ve already given a reference to determining 
“satisfactory")? Offhand, I’d say one case might be with extremely low noise, 
then digitally faded such that you fade the noise level below the dithering 
threshold while you still have enough signal to exhibit truncation distortion, 
and the fade characteristics allow it to last long enough to matter to your 
ears—if we weren’t talking about this distortion being down near -140 dB in the 
first place. I’d think that, typically, you’d have gaussian noise at a much 
higher level that is needed to dither 24-bit; that could change with digital 
processing, but I think that in the usual recording chain, it seems pretty hard 
to avoid for your "analog to digital conversion” case.

I’m still interested in what you have to say about my post yesterday (“...if 
the error doesn’t sound wrong to the ear, can it still sound wrong added to the 
music?”). Care to comment?


> On Feb 8, 2015, at 8:09 AM, Vicki Melchior  wrote:
> 
> I have no argument at all with the cheap high-pass TPDF dither; whenever it 
> was published the original authors undoubtedly verified that the moment 
> decoupling occurred, as you say.  And that's what is needed for dither 
> effectiveness.   If you're creating noise for dither, you have the option to 
> verify its properties.  But in the situation of an analog signal with added, 
> independent instrument noise, you do need to verify that the composite noise 
> source actually satisfies the criteria for dither.  1/f noise in particular 
> has been questioned, which is why I raised the spectrum issue.  
> 
> Beyond that, Nigel raises this issue in the context of "self-dither".  In 
> situations where there is a clear external noise source present, whether the 
> situation is analog to digital conversion or digital to digital bit depth 
> change, the external noise may, or may not, be satisfactory as dither but at 
> least it's properties can be measured.  If the 'self-dithering' instead 
> refers to analog noise captured into the digitized signal with the idea that 
> this noise is going to be preserved and available at later truncation steps 
> to 'self dither' it is a very very hazy argument.   I'm aware of the various 
> caveats that are often postulated, i.e. signal is captured at double 
> precision, no truncation, very selected processing.  But even in minimalist 
> recording such as live to two track, it's not clear to me that the signal can 
> get through the digital stages of the A/D and still retain an unaltered noise 
> distribution.  It certainly won't do so after considerable processing.  So 
> the short 
> answer is, dither!  At the 24th bit or at the 16th bit, whatever your output 
> is.  If you (Nigel or RBJ) have references to the contrary, please say so.
> 
> Vicki
> 
> On Feb 8, 2015, at 10:11 AM, robert bristow-johnson wrote:
> 
>> On 2/7/15 8:54 AM, Vicki Melchior wrote:
>>> Well, the point of dither is to reduce correlation between the signal and 
>>> quantization noise.  Its effectiveness requires that the error signal has 
>>> given properties; the mean error should be zero and the RMS error should be 
>>> independent of the signal.  The best known examples satisfying those 
>>> conditions are white Gaussian noise at ~ 6dB above the RMS quantization 
>>> level and white TPDF noise  at ~3dB above the same, with Gaussian noise 
>>> eliminating correlation entirely and TPDF dither eliminating correlation 
>>> with the first two moments of the error distribution.   That's all textbook 
>>> stuff.  There are certainly noise shaping algorithms that shape either the 
>>> sum of white dither and quantization noise or the white dither and 
>>> quantization noise independently, and even (to my knowledge) a few 
>>> completely non-white dithers that are known to work, but determining the 
>>> effectiveness of noise at dithering still requires examining the 
>>> statistical properties of the error signal and showing
> 
>> th
>>> at the mean is 0 and the second moment is signal independent.  (I think 
>>> Stanley Lipschitz showed that the higher moments don't matter to 
>>> audibility.)
>> 
>> but my question was not about the p.d.f. of the dither (to decouple both the 
>> mean and the variance of the qua

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

Sorry for the delay…I’ve updated the linked files with an additional 16-bit 
dither with mono TPDF dither noise. I also uploaded the correct 32-bit float 
source audio, without the unintentional 6 dB gain, so that the field are at the 
same level.

http://earlevel.com/temp/music-dsp


> On Feb 5, 2015, at 11:32 PM, Andrew Simper  wrote:
> 
> Hi Nigel,
> 
> You're welcome! Thanks for spending the time and effort preparing
> examples so I could make some observations on. Yeah, with headphones
> my ears easily picked up the stereo-ness of the hiss as soon as I
> switched sources. If I was listening to an entire CD and all tracks
> had the same hiss I would have just assumed it would be part of the
> recording chain in making the CD, which I suppose in a sense it is,
> but the hiss definitely sounded quieter in headphones when it was
> mono.
> 
> Now I'm just being lazy with the plugin, I can do it myself as a
> command line thing / plugin, but I just figured if you had recently
> compiled the plugin it would be an interesting addition to have!
> 
> All the best,
> 
> Andy
> 
> -- cytomic -- sound music software --
> 
> 
> On 6 February 2015 at 14:47, Nigel Redmon  wrote:
>> Funny, Andy, I was thinking about the merits of mono versus stereo dither a 
>> couple of nights ago while having dinner…while independent dither makes 
>> sense, in that your equipment’s background noise should be uncorrelated, 
>> there is the issue with headphones (maybe making it more obvious, more 
>> spacious?)…I didn’t think it through very far, just a thought to try out, 
>> but it’s interesting that you should bring it up...
>> 
>> But actually, those files aren’t using my plug-in. Since the test didn’t 
>> require a constant residual level at various truncation levels (which is the 
>> best part of the plug-in—nothing like juggling a couple of gain plug-ins to 
>> manually compensate the gain in a null test, and blasting your ears off when 
>> a stray index finger mouse-scrolls bit-depth down to one or two bits with a 
>> high gain setting in place), I went with the off-the-shelf stuff, and not 
>> have a chance that someone would question whether my plug-in was doing 
>> something misleading. DP’s Quan Jr plug-in is supplying the dither.
>> 
>> I can mod my plug-in for mono dither, though, and supply a version of that. 
>> You make an interesting observation, thanks.
>> 
>> 
>>> On Feb 5, 2015, at 6:31 PM, Andrew Simper  wrote:
>>> 
>>> Hi Nigel,
>>> 
>>> Can I please ask a favour? Can you please add a "mono noise" button to
>>> your dither plugin? In headphones the sudden onset of stereo hiss of
>>> the dither is pretty obvious and a little distracting in this example.
>>> I had a listen with a "make mono" plugin and the results were much
>>> less obvious between the 16-bit with dither and the float file.  It
>>> would be interesting to hear a stereo source (eg the same Diva sounds
>>> but in unison) put through mono noise dithering.
>>> 
>>> The differences are pretty clear to me, thanks for posting the files! My 
>>> setup:
>>> 
>>> (*) Switching between files randomly the three files randomly playing
>>> them back with unity gain (the float file padded -6 dB to have the
>>> same volume as the others)
>>> (*) FireFace UCX with headphone output set to -12 dB, all other gains at 
>>> unity
>>> (*) Senheisser Amperior HD25 headphones
>>> 
>>> My results
>>> 
>>> (*) the float file is easy to spot, because of the differences when
>>> compared to the other two
>>> (*) the dithered one sounds hissy straight away when I switch to it,
>>> it is obvious that the hiss is stereo, my ears immediately hear that
>>> stereo difference, but otherwise it sounds like the original float
>>> file
>>> (*) the undithered one, right from the start, sounds like a harsher
>>> version of the float one with just a hint of noise as well, an
>>> aggressive subtle edge to the tone which just isn't in the original.
>>> When the fadeout comes then it becomes more obvious aliasing
>>> distortion that everyone is used to hearing.
>>> 
>>> I also tried boosting the float version of the bass tone to -1 dB (so
>>> another 18 dB up from with the same test setup), it was loud, but not
>>> anywhere near the threshold of pain for me. I then boosted it another
>>> 12 dB on the headphone control (so 0 dB gain), so now 30 dB gain in
>>> total and my headphones were really shaki

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

Hi Vicki,

My intuitive view of dither is this (I think you can get this point from my 
video):

After truncation, the error introduced is the truncated signal minus the 
original high resolution signal. We could analyze it statistically, but our 
ears and brain do a real good job of that. And after all, the object here is to 
satisfy our ears and brain.

Listening to the original, high-resolution signal, plus this error signal, is 
equivalent to listening to the truncated signal.

So, my question would be, given such an error signal that sounds smooth, 
pleasant, and unmodulated (hiss-like, not grating, whining, or sputtering, for 
instance): Under what circumstances would the result of adding this error 
signal to the original signal result in an unnecessarily distracting or 
unpleasant degradation of the source material? (And of course, we’re talking 
about 16-bit audio, so not an error of overpowering amplitude.)

I’m not asking this rhetorically, I’d like to know. Measurable statistical 
purity aside, if the error doesn’t sound wrong to the ear, can it still sound 
wrong added to the music? I’ve tried a bit, but so far I haven’t been able to 
convince myself that it can, so I’d appreciate it if someone else could.

Nigel


> On Feb 7, 2015, at 5:54 AM, Vicki Melchior  wrote:
> 
> Hi RBJ,
> 
> Well, the point of dither is to reduce correlation between the signal and 
> quantization noise.  Its effectiveness requires that the error signal has 
> given properties; the mean error should be zero and the RMS error should be 
> independent of the signal.  The best known examples satisfying those 
> conditions are white Gaussian noise at ~ 6dB above the RMS quantization level 
> and white TPDF noise  at ~3dB above the same, with Gaussian noise eliminating 
> correlation entirely and TPDF dither eliminating correlation with the first 
> two moments of the error distribution.   That's all textbook stuff.  There 
> are certainly noise shaping algorithms that shape either the sum of white 
> dither and quantization noise or the white dither and quantization noise 
> independently, and even (to my knowledge) a few completely non-white dithers 
> that are known to work, but determining the effectiveness of noise at 
> dithering still requires examining the statistical properties of the error 
> signal and showing th
> at the mean is 0 and the second moment is signal independent.  (I think 
> Stanley Lipschitz showed that the higher moments don't matter to audibility.)
> 
> Probably there are papers around looking at analog noise in typical music 
> signals and how well it works as self dither (because self dither is assumed 
> in some A/D conversion) but I don't know them and would be very happy to see 
> them.  The one case I know involving some degree of modeling was a tutorial 
> on dither given last year in Berlin that advised against depending on self 
> dither in signal processing unless the noise source was checked out 
> thoroughly before hand.  Variability of amplitude, PDF and time coherence 
> were discussed if I recall.
> 
> Best,
> Vicki 
> 
> On Feb 6, 2015, at 9:27 PM, robert bristow-johnson wrote:
> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  Original Message 
>> 
>> Subject: Re: [music-dsp] Dither video and articles
>> 
>> From: "Vicki Melchior" 
>> 
>> Date: Fri, February 6, 2015 2:23 pm
>> 
>> To: "A discussion list for music-related DSP" 
>> 
>> --
>> 
>> 
>> 
>>> The self dither argument is not as obvious as it may appear. To be 
>>> effective at dithering, the noise has to be at the right level of course 
>>> but also should be white and temporally constant.
>> 
>> why does it have to be white?  or why "should" it?
>> 
>> 
>> 
>> 
>> 
>> --
>> 
>> 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

--
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] Dither video and articles

[Nigel Redmon]

>why does it have to be white?  or why "should" it?

A common and trivial dither signal for non-shaped dither is rectangular PDF 
noise through a one-pole highpass filter. In other words, instead of generating 
two random numbers and adding them together for the dither signal at each 
sample, one random number is generated, and the random number for the previous 
sample is subtracted. The idea is that it biases the noise toward the highs, 
less in the body of the music, and is a little faster computationally (which 
typically doesn’t mean a thing).


> On Feb 6, 2015, at 6:27 PM, robert bristow-johnson 
>  wrote:
> 
> 
>  Original Message 
> 
> Subject: Re: [music-dsp] Dither video and articles
> 
> From: "Vicki Melchior" 
> 
> Date: Fri, February 6, 2015 2:23 pm
> 
> To: "A discussion list for music-related DSP" 
> 
> --
> 
> 
>> The self dither argument is not as obvious as it may appear. To be effective 
>> at dithering, the noise has to be at the right level of course but also 
>> should be white and temporally constant.
>  
> why does it have to be white?  or why "should" it?
> 
> 
> --
>  
> 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

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

Funny…you made me think of the event below, late last night, but I couldn’t 
recall what I was thinking of when I got up this morning. Oh well, it will come 
to me later maybe, I think...I take a little 
break and pick up Tape Op magazine, which I had rescued form the trunk of my 
car, from AES, flip it open to a quote from Brian Eno…oh yeah, now I remember 
my thought:

Years ago, a friend invited me to a colloquy with Brian Eno. Eno talked about 
his first experience with CDs in some sort of show or presentation, where he 
had music on CD player over the sound system. It didn’t sound “right” to him, 
so he hooked up a cassette deck with a blank tape and mixed hiss into the sound 
system to improve the listening experience.

Maybe it’s that “air” that people like to hear ;-)


> On Feb 5, 2015, at 11:32 PM, Andrew Simper  wrote:
> 
> Hi Nigel,
> 
> You're welcome! Thanks for spending the time and effort preparing
> examples so I could make some observations on. Yeah, with headphones
> my ears easily picked up the stereo-ness of the hiss as soon as I
> switched sources. If I was listening to an entire CD and all tracks
> had the same hiss I would have just assumed it would be part of the
> recording chain in making the CD, which I suppose in a sense it is,
> but the hiss definitely sounded quieter in headphones when it was
> mono.
> 
> Now I'm just being lazy with the plugin, I can do it myself as a
> command line thing / plugin, but I just figured if you had recently
> compiled the plugin it would be an interesting addition to have!
> 
> All the best,
> 
> Andy
> 
> -- cytomic -- sound music software --
> 
> 
> On 6 February 2015 at 14:47, Nigel Redmon  wrote:
>> Funny, Andy, I was thinking about the merits of mono versus stereo dither a 
>> couple of nights ago while having dinner…while independent dither makes 
>> sense, in that your equipment’s background noise should be uncorrelated, 
>> there is the issue with headphones (maybe making it more obvious, more 
>> spacious?)…I didn’t think it through very far, just a thought to try out, 
>> but it’s interesting that you should bring it up...
>> 
>> But actually, those files aren’t using my plug-in. Since the test didn’t 
>> require a constant residual level at various truncation levels (which is the 
>> best part of the plug-in—nothing like juggling a couple of gain plug-ins to 
>> manually compensate the gain in a null test, and blasting your ears off when 
>> a stray index finger mouse-scrolls bit-depth down to one or two bits with a 
>> high gain setting in place), I went with the off-the-shelf stuff, and not 
>> have a chance that someone would question whether my plug-in was doing 
>> something misleading. DP’s Quan Jr plug-in is supplying the dither.
>> 
>> I can mod my plug-in for mono dither, though, and supply a version of that. 
>> You make an interesting observation, thanks.
>> 
>> 
>>> On Feb 5, 2015, at 6:31 PM, Andrew Simper  wrote:
>>> 
>>> Hi Nigel,
>>> 
>>> Can I please ask a favour? Can you please add a "mono noise" button to
>>> your dither plugin? In headphones the sudden onset of stereo hiss of
>>> the dither is pretty obvious and a little distracting in this example.
>>> I had a listen with a "make mono" plugin and the results were much
>>> less obvious between the 16-bit with dither and the float file.  It
>>> would be interesting to hear a stereo source (eg the same Diva sounds
>>> but in unison) put through mono noise dithering.
>>> 
>>> The differences are pretty clear to me, thanks for posting the files! My 
>>> setup:
>>> 
>>> (*) Switching between files randomly the three files randomly playing
>>> them back with unity gain (the float file padded -6 dB to have the
>>> same volume as the others)
>>> (*) FireFace UCX with headphone output set to -12 dB, all other gains at 
>>> unity
>>> (*) Senheisser Amperior HD25 headphones
>>> 
>>> My results
>>> 
>>> (*) the float file is easy to spot, because of the differences when
>>> compared to the other two
>>> (*) the dithered one sounds hissy straight away when I switch to it,
>>> it is obvious that the hiss is stereo, my ears immediately hear that
>>> stereo difference, but otherwise it sounds like the original float
>>> file
>>> (*) the undithered one, right from the start, sounds like a harsher
>>> version of the float one with just a hint of noise as well, an
>>> aggressive subtle edge to the tone which just isn't in the original.
>>> When the fadeout 

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

Hi Michael,

I know that you already understand this, and comment that this is for internal 
calculations, but for the sake of anyone who might misinterpret your 32-bit vs 
64-bit comment, I’ll point out that this is a situation of error feedback—the 
resulting error is much greater than the sample sizes you’re talking about, and 
can result in differences far above the 24-bit level. A simple example is the 
ubiquitous direct form I biquad, which goes all to hell in lower audio 
frequencies with 24-bit storage (unless you noise shape or increase resolution).

Nigel


> On Feb 6, 2015, at 10:24 AM, Michael Gogins  wrote:
> 
> Do not believe anything that is not confirmed to a high degree of
> statistical signifance (say, 5 standard deviations) by a double-blind
> test using an ABX comparator.
> 
> That said, the AES study did use double-blind testing. I did not read
> the article, only the abstract, so cannot say more about the study.
> 
> In my own work, I have verified with a double-blind ABX comparator at
> a high degree of statistical significance that I can hear the
> differences in certain selected portions of the same Csound piece
> rendered with 32 bit floating point samples versus 64 bit floating
> point samples. These are sample words used in internal calculations,
> not for output soundfiles. What I heard was differences in the sound
> of the same filter algorithm. These differences were not at all hard
> to hear, but they occurred in only one or two places in the piece.
> 
> I have not myself been able to hear differences in audio output
> quality between CD audio and high-resolution audio, but when I get the
> time I may try again, now that I have a better idea what to listen
> for.
> 
> Regards,
> Mike
> 
> 
> 
> -
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Fri, Feb 6, 2015 at 1:13 PM, Nigel Redmon  wrote:
>>> Mastering engineers can hear truncation error at the 24th bit but say it is 
>>> subtle and may require experience or training to pick up.
>> 
>> Quick observations:
>> 
>> 1) The output step size of the lsb is full-scale / 2^24. If full-scale is 
>> 1V, then step is 0.000596046447753906V, or 0.0596 microvolt (millionths 
>> of a volt). Hearing capabilities aside, the converter must be able to 
>> resolve this, and it must make it through the thermal (and other) noise of 
>> their equipment and move a speaker. If you’re not an electrical engineer, it 
>> may be difficult to grasp the problem that this poses.
>> 
>> 2) I happened on a discussion in an audio forum, where a highly-acclaimed 
>> mastering engineer and voice on dither mentioned that he could hear the 
>> dither kick in when he pressed a certain button in the GUI of some beta 
>> software. The maker of the software had to inform him that he was mistaken 
>> on the function of the button, and in fact it didn’t affect the audio 
>> whatsoever. (I’ll leave his name out, because it’s immaterial—the guy is a 
>> great source of info to people and is clearly excellent at what he does, and 
>> everyone who works with audio runs into this at some point.) The mastering 
>> engineer graciously accepted his goof.
>> 
>> 3) Mastering engineers invariably describe the differences in very 
>> subjective term. While this may be a necessity, it sure makes it difficult 
>> to pursue any kind of validation. From a mastering engineer to me, 
>> yesterday: 'To me the truncated version sounds colder, more glassy, with 
>> less richness in the bass and harmonics, and less "front to back" depth in 
>> the stereo field.’
>> 
>> 4) 24-bit audio will almost always have a far greater random noise floor 
>> than is necessary to dither, so they will be self-dithered. By “almost”, I 
>> mean that very near 100% of the time. Sure, you can create exceptions, such 
>> as synthetically generated simple tones, but it’s hard to imagine them 
>> happening in the course of normal music making. There is nothing magic about 
>> dither noise—it’s just mimicking the sort of noise that your electronics 
>> generates thermally. And when mastering engineers say they can hear 
>> truncation distortion at 24-bit, they don’t say “on this particular brief 
>> moment, this particular recording”—they seems to say it in general. It’s 
>> extremely unlikely that non-randomized truncation distortion even exists for 
>> most material at 24-bit.
>> 
>> My point is simply that I’m not going to accept that mastering engineers can 
>> hear the 24th bit truncatio

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

>Isn't it generally agreed that truncation noise is correlated with the signal?

“Is correlated”? No, but it can be.

First, if there is enough noise in the signal before truncation, then it’s 
dithered by default—no correlation.

Second, if the signal is sufficiently complex, it seems, then there is no 
apparent correlation. See my video (https://www.youtube.com/watch?v=KCyA6LlB3As 
<https://www.youtube.com/watch?v=KCyA6LlB3As>) where I show a 32-bit float mix, 
truncated to 8-bit, nulled, and boosted +24 dB. There is no apparent 
correlation till the very end, even though the noise floor is not sufficient to 
self-dither.


> On Feb 6, 2015, at 10:42 AM, Tom Duffy  wrote:
> 
> Isn't it generally agreed that truncation noise is correlated with the
> signal?
> The human ear is excellent at picking up on correlation, so a system
> that introduces multiple correlated (noise) signals may reach a point
> where it is perceptual, even if the starting point is a 24 bit signal.
> 
> I would believe this to be an explanation for why ProTools early hardware 
> mixers were regarded as having problems - they used 24bit
> fixed point DSPs, coupled with fixed bit headroom management may
> have introduced truncation noise at a level higher than the 24 bit
> noise floor.
> 
> Also, the dither noise source itself needs to be investigated.
> Studies have shown that a fixed repeated buffer of pre-generated white
> noise is immediately obvious (and non-pleasing) to the listener up to
> several hundred ms long - if that kind of source was used as a dither
> signal, the self correlation becomes even more problematic.
> Calculated a new PRDG value for each sample is expensive, which
> is why a pre-generated buffer is attractive to the implementor.
> 
> ---
> Tom.
> 
> On 2/6/2015 10:32 AM, Victor Lazzarini wrote:
> Quite. This conversation is veering down the vintage wine tasting alley.
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
> On 6 Feb 2015, at 18:13, Nigel Redmon  wrote:
> 
> Mastering engineers can hear truncation error at the 24th bit but say it is 
> subtle and may require experience or training to pick up.
> 
> Quick observations:
> 
> 1) The output step size of the lsb is full-scale / 2^24. If full-scale is 1V, 
> then step is 0.000596046447753906V, or 0.0596 microvolt (millionths of a 
> volt). Hearing capabilities aside, the converter must be able to resolve 
> this, and it must make it through the thermal (and other) noise of their 
> equipment and move a speaker. If you’re not an electrical engineer, it may be 
> difficult to grasp the problem that this poses.
> 
> 2) I happened on a discussion in an audio forum, where a highly-acclaimed 
> mastering engineer and voice on dither mentioned that he could hear the 
> dither kick in when he pressed a certain button in the GUI of some beta 
> software. The maker of the software had to inform him that he was mistaken on 
> the function of the button, and in fact it didn’t affect the audio 
> whatsoever. (I’ll leave his name out, because it’s immaterial—the guy is a 
> great source of info to people and is clearly excellent at what he does, and 
> everyone who works with audio runs into this at some point.) The mastering 
> engineer graciously accepted his goof.
> 
> 3) Mastering engineers invariably describe the differences in very subjective 
> term. While this may be a necessity, it sure makes it difficult to pursue any 
> kind of validation. From a mastering engineer to me, yesterday: 'To me the 
> truncated version sounds colder, more glassy, with less richness in the bass 
> and harmonics, and less "front to back" depth in the stereo field.’
> 
> 4) 24-bit audio will almost always have a far greater random noise floor than 
> is necessary to dither, so they will be self-dithered. By “almost”, I mean 
> that very near 100% of the time. Sure, you can create exceptions, such as 
> synthetically generated simple tones, but it’s hard to imagine them happening 
> in the course of normal music making. There is nothing magic about dither 
> noise—it’s just mimicking the sort of noise that your electronics generates 
> thermally. And when mastering engineers say they can hear truncation 
> distortion at 24-bit, they don’t say “on this particular brief moment, this 
> particular recording”—they seems to say it in general. It’s extremely 
> unlikely that non-randomized truncation distortion even exists for most 
> material at 24-bit.
> 
> My point is simply that I’m not going to accept that mastering engineers can 
> hear the 24th bit truncation just because they say they can.
> 
> 
> On Feb 6, 2015, at 5:21 AM, Vicki Melchior  wrote:
&g

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

>Mastering engineers can hear truncation error at the 24th bit but say it is 
>subtle and may require experience or training to pick up.

Quick observations:

1) The output step size of the lsb is full-scale / 2^24. If full-scale is 1V, 
then step is 0.000596046447753906V, or 0.0596 microvolt (millionths of a 
volt). Hearing capabilities aside, the converter must be able to resolve this, 
and it must make it through the thermal (and other) noise of their equipment 
and move a speaker. If you’re not an electrical engineer, it may be difficult 
to grasp the problem that this poses.

2) I happened on a discussion in an audio forum, where a highly-acclaimed 
mastering engineer and voice on dither mentioned that he could hear the dither 
kick in when he pressed a certain button in the GUI of some beta software. The 
maker of the software had to inform him that he was mistaken on the function of 
the button, and in fact it didn’t affect the audio whatsoever. (I’ll leave his 
name out, because it’s immaterial—the guy is a great source of info to people 
and is clearly excellent at what he does, and everyone who works with audio 
runs into this at some point.) The mastering engineer graciously accepted his 
goof.

3) Mastering engineers invariably describe the differences in very subjective 
term. While this may be a necessity, it sure makes it difficult to pursue any 
kind of validation. From a mastering engineer to me, yesterday: 'To me the 
truncated version sounds colder, more glassy, with less richness in the bass 
and harmonics, and less "front to back" depth in the stereo field.’

4) 24-bit audio will almost always have a far greater random noise floor than 
is necessary to dither, so they will be self-dithered. By “almost”, I mean that 
very near 100% of the time. Sure, you can create exceptions, such as 
synthetically generated simple tones, but it’s hard to imagine them happening 
in the course of normal music making. There is nothing magic about dither 
noise—it’s just mimicking the sort of noise that your electronics generates 
thermally. And when mastering engineers say they can hear truncation distortion 
at 24-bit, they don’t say “on this particular brief moment, this particular 
recording”—they seems to say it in general. It’s extremely unlikely that 
non-randomized truncation distortion even exists for most material at 24-bit.

My point is simply that I’m not going to accept that mastering engineers can 
hear the 24th bit truncation just because they say they can.


> On Feb 6, 2015, at 5:21 AM, Vicki Melchior  wrote:
> 
> The following published double blind test contradicts the results of the old 
> Moran/Meyer publication in showing (a) that the differences between CD and 
> higher resolution sources is audible and (b) that failure to dither at the 
> 16th bit is also audible.  
> 
> http://www.aes.org/e-lib/browse.cfm?elib=17497
> 
> The Moran/Meyer tests had numerous technical problems that have long been 
> discussed, some are enumerated in the above.  
> 
> As far as dithering at the 24th bit, I can't disagree more with a conclusion 
> that says it's unnecessary in data handling.  Mastering engineers can hear 
> truncation error at the 24th bit but say it is subtle and may require 
> experience or training to pick up.  What they are hearing is not noise or 
> peaks sitting at the 24th bit but rather the distortion that goes with 
> truncation at 24b, and it is said to have a characteristic coloration effect 
> on sound.  I'm aware of an effort to show this with AB/X tests, hopefully it 
> will be published.  The problem with failing to dither at 24b is that many 
> such truncation steps would be done routinely in mastering, and thus the 
> truncation distortion products continue to build up.  Whether you personally 
> hear it is likely to depend both on how extensive your data flow pathway is 
> and how good your playback equipment is.  
> 
> Vicki Melchior
> 
> On Feb 5, 2015, at 10:01 PM, Ross Bencina wrote:
> 
>> On 6/02/2015 1:50 PM, Tom Duffy wrote:
>>> The AES report is highly controversial.
>>> 
>>> Plenty of sources dispute the findings.
>> 
>> Can you name some?
>> 
>> Ross.
>> --

--
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] Dither video and articles

[Nigel Redmon]

Funny, Andy, I was thinking about the merits of mono versus stereo dither a 
couple of nights ago while having dinner…while independent dither makes sense, 
in that your equipment’s background noise should be uncorrelated, there is the 
issue with headphones (maybe making it more obvious, more spacious?)…I didn’t 
think it through very far, just a thought to try out, but it’s interesting that 
you should bring it up...

But actually, those files aren’t using my plug-in. Since the test didn’t 
require a constant residual level at various truncation levels (which is the 
best part of the plug-in—nothing like juggling a couple of gain plug-ins to 
manually compensate the gain in a null test, and blasting your ears off when a 
stray index finger mouse-scrolls bit-depth down to one or two bits with a high 
gain setting in place), I went with the off-the-shelf stuff, and not have a 
chance that someone would question whether my plug-in was doing something 
misleading. DP’s Quan Jr plug-in is supplying the dither.

I can mod my plug-in for mono dither, though, and supply a version of that. You 
make an interesting observation, thanks.


> On Feb 5, 2015, at 6:31 PM, Andrew Simper  wrote:
> 
> Hi Nigel,
> 
> Can I please ask a favour? Can you please add a "mono noise" button to
> your dither plugin? In headphones the sudden onset of stereo hiss of
> the dither is pretty obvious and a little distracting in this example.
> I had a listen with a "make mono" plugin and the results were much
> less obvious between the 16-bit with dither and the float file.  It
> would be interesting to hear a stereo source (eg the same Diva sounds
> but in unison) put through mono noise dithering.
> 
> The differences are pretty clear to me, thanks for posting the files! My 
> setup:
> 
> (*) Switching between files randomly the three files randomly playing
> them back with unity gain (the float file padded -6 dB to have the
> same volume as the others)
> (*) FireFace UCX with headphone output set to -12 dB, all other gains at unity
> (*) Senheisser Amperior HD25 headphones
> 
> My results
> 
> (*) the float file is easy to spot, because of the differences when
> compared to the other two
> (*) the dithered one sounds hissy straight away when I switch to it,
> it is obvious that the hiss is stereo, my ears immediately hear that
> stereo difference, but otherwise it sounds like the original float
> file
> (*) the undithered one, right from the start, sounds like a harsher
> version of the float one with just a hint of noise as well, an
> aggressive subtle edge to the tone which just isn't in the original.
> When the fadeout comes then it becomes more obvious aliasing
> distortion that everyone is used to hearing.
> 
> I also tried boosting the float version of the bass tone to -1 dB (so
> another 18 dB up from with the same test setup), it was loud, but not
> anywhere near the threshold of pain for me. I then boosted it another
> 12 dB on the headphone control (so 0 dB gain), so now 30 dB gain in
> total and my headphones were really shaking, this was a bit silly a
> level, but still definitely not painful to listen to. My point being
> that this is a very reasonable test signal to listen to, and it is
> clear to hear the differences even at low levels of gain.
> 
> If I had to choose, between the two 16-bit ones I would prefer the one
> with dither but put through a "make mono" plugin, as this sounded the
> closest to the float version.
> 
> All the best,
> 
> Andy
> 
> -- cytomic -- sound music software --
> 
> 
> On 5 February 2015 at 16:46, Nigel Redmon  wrote:
>> Hmm, I thought that would let you save the page source (wave file)…Safari 
>> creates the file of the appropriate name and type, but it stays at 0 
>> bytes…OK, I put up and index page—do the usual right-click to save the field 
>> to disk if you need to access the files directly:
>> 
>> http://earlevel.com/temp/music-dsp/
>> 
>> 
>>> On Feb 5, 2015, at 12:13 AM, Nigel Redmon  wrote:
>>> 
>>> OK, here’s my new piece, I call it Diva bass—to satisfy your request for me 
>>> to make something with truncation distortion apparent. (If it bother you 
>>> that my piece is one note, imagine that this is just the last note of a 
>>> longer piece.)
>>> 
>>> I spent maybe 30 seconds getting the sound—opened Diva (default “minimoog” 
>>> modules), turn the mixer knobs down except for VCO 1, set range to 32’, 
>>> waveform to triangle, max release on the VCA envelope.
>>> 
>>> In 32-bit float glory:
>>> 
>>> http://earlevel.com/temp/music-dsp/Diva%20bass%2032-bit%20float.wav
>>> 
>>> Truncated to 

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

>Yes, because that's the only thing 16bit audio applies to, the end listener.

??? They have absolutely no control over it. The decision to dither or not was 
made before they hear it. My advice is not to them. I get asked questions about 
dither from the people who do the reduction to 16-bit, not your average music 
listener. I have another video that explains what dither is and how it works, 
for the curious, but I get asked for my opinion, so I made this video. (Often, 
the people who ask already have their own opinion, and want to see if I’m on 
their side. And often, what follows is a spirited debate about 24-bit dither, 
not 16-bit.)

>Talking about this, in a world where the end listener almost always listens in 
>lossy encoded formats, the 16bit quantization problem isn't even a shrimp in 
>the whole universe.

Sure, or FM radio in a car on a cheap system. But a mastering engineer isn’t 
going to factor in the lowest common denominator, any more than a photographer 
is going to assume that his photo will end up in black and white newsprint, or 
a movie director will assume that his work is going to be cropped to fit an old 
tube set and broadcast for pickup on rabbit ears. :-) If you tell a recording 
or mastering engineer that nobody can hear this stuff, they’ll crank the 
monitors and say, “you can’t hear THAT crap?” End of story.

Of course, they’ll often “hear” it when it isn’t really there too, which is why 
I showed a more objective way of listening for it. Several people have told me 
that they can hear it, consistently, on 24-bit truncations. I don’t think so. I 
read in a forum, where an expert was using some beta software and mentioned the 
audible difference with engaging 24-bit dither and not via a button on the GUI, 
and the developer had to tell him that he was mistaken on the function of that 
button, and that it did not impact audio at all. (I’m not making fun of the 
guy, and I admire his work, it’s just that anyone who does serious audio work 
fools themselves into thinking they hear something that is not, 
occasionally—fact of life.) But at 16-bit, it’s just not that hard to hear 
it—an edge case, for sure, but it’s there, so they will want to act on it, and 
I don’t think that’s unreasonable.


> On Feb 5, 2015, at 3:15 PM, Didier Dambrin  wrote:
> 
> But the key here is *bits*. If you're listening at normal levels, those parts 
> in music that "don't use all 16bits" (which is obvious, you can find parts of 
> all levels in a song) will be quieter, & thus the noise will be less audible.
> 
> Put a sine wave in the lowest 1 or 2 bits of a 16bit piece of audio, it 
> should be horrible noise, right? If you crank up your volume until you hear 
> that sinewave, obviously it will. But at normal listening level, are you 
> really gonna hear that sinewave or worse, its horrible noise? My bet would be 
> *maybe*, in an anechoic room, after a couple of hours of getting used to 
> silence.
> 
> 
>>> he cost is virtual nothing
> 
> I will certainly not disagree with that, it doesn't hurt & costs (almost) 
> nothing. But it's still snake oil.
> 
> 
> 
>>> Our biggest difference is that you are looking at this from the 
>>> end-listener point of view.
> 
> Yes, because that's the only thing 16bit audio applies to, the end listener. 
> Ok, apparently some still need to publish 16bit audio files for pro's because 
> not every tool out there (I guess) supports 24 (& I would still advise 
> against storing in integer format at all) or 32bit formats - this is most 
> likely not gonna last very long.
> Talking about this, in a world where the end listener almost always listens 
> in lossy encoded formats, the 16bit quantization problem isn't even a shrimp 
> in the whole universe.
> 
> 
> 
> 
> 
> 
> 
> -Message d'origine- From: Nigel Redmon
> Sent: Thursday, February 05, 2015 7:13 PM
> To: A discussion list for music-related DSP
> Subject: Re: [music-dsp] Dither video and articles
> 
> Music is not typically full scale. My level was arbitrary—where the mixer 
> knob happened to be sitting—but the note is relatively loud in a musical 
> setting.
> 
> You don’t get to use all 16 bits, all the time in music. So, to complain that 
> it might as well be 13-bit…well, if we had 13-bit converters and sample size, 
> we’d be having this discussion about 10-bit. The bass note is LOUD, compared 
> to similar bits in actual music, as I’m playing from iTunes right now.
> 
> OK, I’m not trying to convince you—it was obvious that we’d have to agree to 
> disagree on this. And, as you know, I’m not overstating the importance of 
> dithering 16-bit audio, as many others do. I’m simply saying that it’s worth 
> it—the cost is virtual not

Re: [music-dsp] Thoughts on DSP books and neural networks

[Nigel Redmon]

The cookbook filters put the zeros at -1, the Nyquist frequency, for the low 
pass filter. So it’s true that the filters can’t be made the same for the 
cookbook formula, just not true that a two-zero filter can’t have the same 
transfer function as a one-zero.


> On Feb 5, 2015, at 11:25 AM, Ethan Duni  wrote:
> 
>> 'z=infinity' mean it's at the origin? I'm not 100% sure of the
>> terminology used here.
> 
> Sorry, I should have written "at z=0", not infinity. Typing too fast at the
> end of the day.
> 
>> Well, I think that would be rather a semantic distinction or an
>> 'implied' zero at the origin - in practice, no one would actually
>> calculate 0*x in an algorithm (as that would be pointless), though
>> you're right that during calculation and analyis of the filter, you
>> can treat the whole thing as a 2 pole / 2 zero filter with one or both
>> zeros at the origin, as a special case of the general 2 pole biquad
>> filter.
> 
> Right. So can the cookbook filters be made to put one of the zeros at the
> origin, or do they always produce responses with two non-trivial zeros?
> 
> E
> 
> On Thu, Feb 5, 2015 at 11:00 AM, Peter S 
> wrote:
> 
>> On 05/02/2015, Nigel Redmon  wrote:
>>> To your first comment—well, of course. But maybe you’ve lost site of the
>>> context—here’s your comment:
>>> 
>>>> My filter has 2 poles and 1 zero. Unlike the Cookbook filter, which
>>>> has 2 poles and 2 zeros.
>>>> I think that automatically assumes, the transfer function cannot be
>>>> equivalent.
>>> 
>>> Ethan pointed out that they can be, because one-zero is equivalent to a
>>> special case of two-zero. (Some would argue that if it’s a second-order
>>> filter, with two poles, then it always has matching zeros, even if one or
>>> both at at the origin. .)
>> 
>> Well, I think that would be rather a semantic distinction or an
>> 'implied' zero at the origin - in practice, no one would actually
>> calculate 0*x in an algorithm (as that would be pointless), though
>> you're right that during calculation and analyis of the filter, you
>> can treat the whole thing as a 2 pole / 2 zero filter with one or both
>> zeros at the origin, as a special case of the general 2 pole biquad
>> filter.
>> 
>> On 05/02/2015, Ethan Duni  wrote:
>>> You just stick the extra zero(s) off at z=infinity.
>> 
>> Does 'z=infinity' mean it's at the origin? I'm not 100% sure of the
>> terminology used here.
>> 
>> - Peter
>> --
>> 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] Thoughts on DSP books and neural networks

[Nigel Redmon]

To your first comment—well, of course. But maybe you’ve lost site of the 
context—here’s your comment:

> My filter has 2 poles and 1 zero. Unlike the Cookbook filter, which
> has 2 poles and 2 zeros.
> I think that automatically assumes, the transfer function cannot be 
> equivalent.

Ethan pointed out that they can be, because one-zero is equivalent to a special 
case of two-zero. (Some would argue that if it’s a second-order filter, with 
two poles, then it always has matching zeros, even if one or both at at the 
origin. .) You disagreed, and I clarified. I’m not making a case that a 
two-zero is superior if you don’t need both zeros, just that the transfer 
functions can be equivalent.


> On Feb 5, 2015, at 10:24 AM, Peter S  wrote:
> 
> On 05/02/2015, Nigel Redmon  wrote:
>> A two-zero filter with one fixed at the origin of the z plane is the same as
>> a one-zero filter. It should be obvious that in the transfer function, a
>> coefficient of 0 for a term is equivalent to that term no being there.
> 
> Well, that is true, you can add as many 0-coefficient terms to the
> 1-zero filter as you want, since 0*x = 0. So yes, that is trivially
> true, you can add even a hundred more zeros at the origin that do
> nothing. But why would you do that, instead of simply removing all
> 0-coefficient terms that effectively do nothing?
> 
> Realistically, anyone who uses two zeros in a filter, uses nonzero
> coefficients for both zeros, otherwise it's just wasted computation.
> At least I've seen no design which always gives a biquad coefficient
> of zero for one of the zeros; in the lowpass case, both zeros are
> always at Nyquist.
> 
>> Your stuff sounds good, I’m impressed. But you are posting to a group of
>> technical people, few of which are likely to buy your designs. So, I think
>> the value of you showing how good your stuff sounds, then not saying why or
>> how, is somewhat limited on this mailing list. I understand that the point
>> was to say that you are worth being listened to, but that will only get you
>> so far—once stated, people either decide that’s sufficient, or not, and
>> there’s not much point in arguing it.
> 
> Fair enough, that was the only purpose. I'm not trying to "sell" these
> algorithms here (places like KVR Audio etc. are more suited to that).
> And maybe later I'll reveal some of my designs and/or write a few
> papers, but currently I don't have enough time nor incentive to do
> that.
> 
> - Peter
> --
> 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] Dither video and articles

[Nigel Redmon]

"Bob Ohlsson"—not sure if I really typed it that way or if it got 
autocorrected...

> On Feb 5, 2015, at 10:13 AM, Nigel Redmon  wrote:
> 
> Music is not typically full scale. My level was arbitrary—where the mixer 
> knob happened to be sitting—but the note is relatively loud in a musical 
> setting.
> 
> You don’t get to use all 16 bits, all the time in music. So, to complain that 
> it might as well be 13-bit…well, if we had 13-bit converters and sample size, 
> we’d be having this discussion about 10-bit. The bass note is LOUD, compared 
> to similar bits in actual music, as I’m playing from iTunes right now.
> 
> OK, I’m not trying to convince you—it was obvious that we’d have to agree to 
> disagree on this. And, as you know, I’m not overstating the importance of 
> dithering 16-bit audio, as many others do. I’m simply saying that it’s worth 
> it—the cost is virtual nothing (it’s not even don’t in real time, but just 
> for the final bounce to disk), doing it doesn’t harm the music in any way (if 
> you can hear the distortion, I don’t think you’ll hear 16-bit flat dither).
> 
> Our biggest difference is that you are looking at this from the end-listener 
> point of view. But why would I be giving advice to the listener? They aren’t 
> the ones making the choice to dither or not. The advice is for people in the 
> position of dithering. And these people do hear it. If my advice were “Don’t 
> bother—you can’t hear it anyway”, these people would think I’m an idiot—of 
> course they can hear it. Their business is to look for junk and grunge and 
> get rid of it. I can envision Bob Katz, Bob Olson, and Bruce Swedien knocking 
> at my door, wanting to beat me with a microphone stand and pop screens for 
> telling them that they can’t hear this stuff. (Just kidding, they seem like 
> really nice guys.)
> 
> The funny thing is that I’m arguing in favor of 16-bit dither with you, and 
> having a similar exchange with a mastering engineer, who is sending me 
> examples of why we really must dither at 24-bit ...
> 
> 
>> On Feb 5, 2015, at 9:49 AM, Didier Dambrin  wrote:
>> 
>>>> If you mean that the peak loudness of the synth isn’t hitting full scale
>> 
>> Yeah I mean that, since, to compensate, you crank your volume up, making it 
>> 13bit worth (from 14bit, after your extra -6dB gain)
>> 
>> I mean it's always the same debate with dithering, one could demonstrate 
>> exactly the same with 8bit worth of audio in a 16bit file. To me a 16bit 
>> file is 16bit worth of audio, for the whole project, thus with the loudest 
>> parts of the project designed to be listened to. If the entire project peaks 
>> at -18dB, then it's not designed to be listened to at the same level as 
>> other 16bit files, and thus it's not 16bit worth of audio. One could go 
>> further & store 1 bit worth of audio in a 16bit file and point out how 
>> degraded it is.
>> Quantization & loss is everywhere in a computer (obviously) and magnifying 
>> it doesn't make a point, because you always can bring the imperceptible back 
>> to perception. To me it's all about what's perceptible when the project is 
>> used as intended, otherwise, even 64bit float audio should be marked as 
>> "lossy".
>> 
>> 
>>>> I could have had a louder sound with a similar tail that would have 
>>>> produced the same distortion.
>> 
>> yeah, except that louder sound would have killed your ears, so you would 
>> have cranked your listening level down, and not heard the noise anymore
>> 
>> 
>> 
>> 
>> 
>> -Message d'origine- From: Nigel Redmon
>> Sent: Thursday, February 05, 2015 6:22 PM
>> To: A discussion list for music-related DSP
>> Subject: Re: [music-dsp] Dither video and articles
>> 
>> Oh, sorry about the 6 dB. I made the 16- and 32-bit versions, then noticed I 
>> had the gain slider on the DP mixer pushed up. I pulled it back to 0 dB and 
>> made new bounces, plus the residual and dithered version subsequently, but 
>> must have grabbed the wrong 32-bit version for upload.
>> 
>> I have no idea what you’re implying about "IMHO this is 13bit worth of audio 
>> inside a 16bit file”. I took care to have no gain after the truncation 
>> (except the accidental 6 dB on the 32-bit file). If you mean that the peak 
>> loudness of the synth isn’t hitting full scale, then, A) welcome to music, 
>> and B) it’s immaterial—I could have had a louder sound with a similar tail 
>> that would have produced the same distortion.
>> 
>> I’m not surprised you couldn’t hear it, as I s