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?  more general

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_source=link_campaign=sig-email_content=emailclient>
>>>Virus-free. www.avg.com 
>>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_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_source=link_campaign=sig-email_content=emailclient>
>> Virus-free. www.avg.com 
>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_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] 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 

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

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 

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 <renato.fab...@gmail.com> 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 <earle...@earlevel.com 
> <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 <renato.fab...@gmail.com 
>> <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 

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]

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 
> <r...@audioimagination.com> wrote:
> 
> 
> 
>  Original Message 
> Subject: Re: [music-dsp] Sampling theory "best" explanation
> From: "Nigel Redmon" <earle...@earlevel.com>
> 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 <ethan.d...@gmail.com> 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 <earle...@earlevel.com> 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 make it a 
>> resampler is

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

[Nigel Redmon]

 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 <et...@polyspectral.com 
> <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 <ethan.d...@gmail.com 
> <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 <earle...@earlevel.com 
> <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 <ethan.d...@gmail.com 
>> <mailto:ethan.d...@gmail.com>> wrote:
>> 
>> Ethan F wrote:
>> >I see your nitpick and raise you. :o) Surely there are uncountab

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 <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 <earle...@earlevel.com 
> <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 <ethan.d...@gmail.com 
>> <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 

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

[Nigel Redmon]

te number of bandlimited functions 
> that interpolate 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 <et...@polyspectral.com 
> <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 <earle...@earlevel.com 
> <mailto:earle...@earlevel.com>> wrote:
> Hi Remy,
> 
>> On Aug 28, 2017, at 2:16 AM, Remy Muller <muller.r...@gmail.com 
>> <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 abou

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 <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 <earle...@earlevel.com 
> <mailto:earle...@earlevel.com>> wrote:
> Hi Remy,
> 
>> On Aug 28, 2017, at 2:16 AM, Remy Muller <muller.r...@gmail.com 
>> <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. Ho

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

[Nigel Redmon]

Hi Remy,

> On Aug 28, 2017, at 2:16 AM, Remy Muller <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 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 
> <r...@audioimagination.com> 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=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" <de...@iki.fi>
> Date: Sun, August 27, 2017 2:20 am
> To: "A discussion list for music-related DSP" <music-dsp@music.columbia.edu>
> --
> 
> > 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 <de...@iki.fi> 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 <earle...@earlevel.com> 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 <a...@cytomic.com 
>> <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 <sdiedrich...@me.com 
>> <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 
>>> <r...@audioimagination.com <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 
>> > 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]

f 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" <earle...@earlevel.com>
> Date: Sun, August 14, 2016 1:58 pm
> To: "robert bristow-johnson" <r...@audioimagination.com>
> 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 
> >> <r...@audioimagination.com> 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" <da...@olofson.net>
> >> Date: Sat, August 13, 2016 6:16 pm
> >> To: "A discussion list for music-related DSP" 
> >> <music-dsp@music.columbia.edu>
> >> --
> >>
> >> >
> >> > 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 th

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 

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]

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

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]

> On Sep 21, 2015, at 1:59 PM, robert bristow-johnson 
> <r...@audioimagination.com> 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 
> <r...@audioimagination.com> 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 i

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 <li...@brainstream-audio.de> wrote:
> 
> 
> On 23 Sep 2015, at 18:39, Nigel Redmon <earle...@earlevel.com> 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]

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 <nunosan...@imaginando.pt> 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 <earle...@earlevel.com 
>> <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

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 <rossb-li...@audiomulch.com> 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] 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 peter.schoffhau...@gmail.com wrote:
 
 On 18/08/2015, Nigel Redmon earle...@earlevel.com 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]

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 earle...@earlevel.com 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 peter.schoffhau...@gmail.com wrote:
 
 On 18/08/2015, Nigel Redmon earle...@earlevel.com 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]

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 
 r...@audioimagination.com 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 theo...@theover.org 
 mailto:theo...@theover.org 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 
 r...@audioimagination.com 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]

 On Aug 17, 2015, at 7:23 PM, robert bristow-johnson 
 r...@audioimagination.com 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]

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

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 sham.b...@gmail.com 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

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

[Nigel Redmon]

 On Jul 20, 2015, at 11:12 PM, robert bristow-johnson 
 r...@audioimagination.com 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]

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 earle...@earlevel.com 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 theo...@theover.org 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 theo...@theover.org 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] 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 hello.pdowl...@gmail.com wrote:
 
 Marshall Time Modulator
 
 got some good links?
 
 
 On 20 Jul 2015, at 21:40, Nigel Redmon earle...@earlevel.com 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 
 r...@audioimagination.com 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
 
 --
 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]

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 
 r...@audioimagination.com 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]

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 
 r...@audioimagination.com 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] 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 ukel...@gmail.com 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] 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 nunosan...@imaginando.pt wrote:
 
 
 On 20 Mar 2015, at 18:58, Alan Wolfe alan.wo...@gmail.com 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(t0)
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 peter.schoffhau...@gmail.com wrote:
 
 On 11/02/2015, Peter P. peterpar...@fastmail.com 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]

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 di...@skynet.be 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 di...@skynet.be 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 a...@cytomic.com wrote:
 
 On 6 February 2015 at 17:32, Didier Dambrin di...@skynet.be 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:
 subscription info, FAQ, source code archive, list archive, book reviews, dsp
 links
 http://music.columbia.edu/cmc/music-dsp
 

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 vmelch...@earthlink.net 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.
 
 Vicki
 
 
 On Feb 8, 2015, at 6:11 PM, Nigel Redmon wrote:
 
 Beyond that, Nigel raises this issue in the context of self-dither”...
 
 First, remember that I’m the guy who recommended “always

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 vmelch...@earthlink.net 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 vmelch...@earthlink.net 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. dither of 2 LSBs width that is independent of the *signal*) but 
 about the spectrum of the dither.  and Nigel mentioned this already, but 
 you can cheaply make high-pass TPDF dither with a single (decent) uniform 
 p.d.f. random 

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 
 r...@audioimagination.com wrote:
 
 
  Original Message 
 
 Subject: Re: [music-dsp] Dither video and articles
 
 From: Vicki Melchior vmelch...@earthlink.net
 
 Date: Fri, February 6, 2015 2:23 pm
 
 To: A discussion list for music-related DSP music-dsp@music.columbia.edu
 
 --
 
 
 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]

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 vmelch...@earthlink.net 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 vmelch...@earthlink.net
 
 Date: Fri, February 6, 2015 2:23 pm
 
 To: A discussion list for music-related DSP music-dsp@music.columbia.edu
 
 --
 
 
 
 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]

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 michael.gog...@gmail.com 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 earle...@earlevel.com 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 vmelch...@earthlink.net 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

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 tdu...@tascam.com 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 earle...@earlevel.com 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 vmelch...@earthlink.net 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

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 a...@cytomic.com 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 earle...@earlevel.com 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 a...@cytomic.com 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

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 vmelch...@earthlink.net 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]

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 16-bit, no dither (Quan Jr plug-in, Digital Performer), saved to 
16-bit wave file:

http://earlevel.com/temp/music-dsp/Diva%20bass%2016-bit%20truncated.wav

You’ll have to turn your sound system up, not insanely loud, but loud. (I said 
that this would be the case before.) I can hear it, and I know engineers who 
monitor much louder, routinely, than I’m monitoring to hear this. My Equator 
Q10s are not terribly high powered, and I’m not adding any other gain ahead of 
them in order to boost the quiet part.

If you want to hear the residual easily (32-bit version inverted, summed with 
16-bit truncated, the result with +40 dB gain via Trim plug-in):

http://earlevel.com/temp/music-dsp/Diva%20bass%2016-bit%20truncated%20residual%20+40dB.wav

I don’t expect the 16-bit truncated version to bother you, but it does bother 
some audio engineers. Here's 16-bit dithered version, for completeness, so that 
you can decide if the added noise floor bothers you:

http://earlevel.com/temp/music-dsp/Diva%20bass%2016-bit%20dithered.wav



 On Feb 4, 2015, at 1:10 PM, Didier Dambrin di...@skynet.be wrote:
 
 Yes, I disagree with the always. Not always needed means it's sometimes 
 needed, my point is that it's never needed, until proven otherwise. Your 
 video proves that sometimes it's not needed, but not that sometimes it's 
 needed.
 
 
 
 -Message d'origine- From: Nigel Redmon
 Sent: Wednesday, February 04, 2015 6:51 PM
 To: A discussion list for music-related DSP
 Subject: Re: [music-dsp] Dither video and articles
 
 I totally understood the point of your video, that dithering to 16bit isn't 
 always needed - but that's what I disagree with.
 
 Sorry, Didier, I’m confused now. I took from your previous message that you 
 feel 16-bit doesn’t need to be dithered (dithering to 16bit will never make 
 any audible difference”). Here you say that you disagree with dithering to 
 16bit isn't always needed”. In fact, you are saying that it’s never 
 needed—you disagree because “isn’t always needed” implies that it is 
 sometimes needed—correct?
 
 
 On Feb 4, 2015, at 5:06 AM, Didier Dambrin di...@skynet.be wrote:
 
 Then, it’s no-win situation, because I could EASILY manufacture a bit of 
 music that had significant truncation distortion at 16-bit.
 
 Please do, I would really like to hear it.
 
 I have never heard truncation noise at 16bit, other than by playing with 
 levels in a such a way that the peaking parts of the rest of the sound would 
 destroy your ears or be very unpleasant at best. (you say 12dB, it's already 
 a lot)
 
 I totally understood the point of your video, that dithering to 16bit isn't 
 always needed - but that's what I disagree with.
 
 
 
 -Message d'origine- From: Nigel Redmon
 Sent: Wednesday, February 04, 2015 10:59 AM
 To: A discussion list for music-related DSP
 Subject: Re: [music-dsp] Dither video and articles
 
 Hi Didier—You seem to find contradictions in my choices because you are 
 making the wrong assumptions about what I’m showing and saying.
 
 First, I’m not steadfast that 16-bit dither is always needed—and in fact the 
 point of the video was that I was showing you (the viewers) how you can 
 judge it objectively for yourself (and decide whether you want to dither). 
 This is a much better way that the usual that I hear from people, who often 
 listen to the dithered and non-dithered results, and talk about the 
 soundstage collapsing without dither, “brittle” versus “transparent , etc.
 
 But if I’m to give you a rule of thumb, a practical bit of advice that you 
 can apply without concern that you might be doing something wrong in a given 
 circumstance, that advice is “always dither 16-bit reductions”. First, I 
 suspect that it’s below the existing noise floor of most music (even so, 
 things like slow fades of the master fader might override that, for that 
 point in time). Still, it’s not hard to manufacture something musical that 
 subject to bad truncation distortion—a naked, low frequency, 
 low-haromic-content sound (a synthetic bass or floor tom perhaps). Anyway, 
 at worst case, you’ve added white noise that you are unlikely to hear—and if 
 you do, so what? If broadband noise below -90 dB were a deal-breaker in 
 recorded music, there wouldn’t be any recorded music. Yeah, truncation 
 distortion at 16-bits is an edge case, but the cost to remove it is almost 
 nothing.
 
 You say that we can’t perceive

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 a...@cytomic.com 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 earle...@earlevel.com 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 earle...@earlevel.com 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 16-bit, no dither (Quan Jr plug-in, Digital Performer), saved 
 to 16-bit wave file:
 
 http://earlevel.com/temp/music-dsp/Diva%20bass%2016-bit%20truncated.wav
 
 You’ll have to turn your sound system up, not insanely loud, but loud. (I 
 said that this would be the case before.) I can hear it, and I know 
 engineers who monitor much louder, routinely, than I’m monitoring to hear 
 this. My Equator Q10s are not terribly high powered, and I’m not adding any

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

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 earle...@earlevel.com 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 16-bit, no dither (Quan Jr plug-in, Digital Performer), saved to 
 16-bit wave file:
 
 http://earlevel.com/temp/music-dsp/Diva%20bass%2016-bit%20truncated.wav
 
 You’ll have to turn your sound system up, not insanely loud, but loud. (I 
 said that this would be the case before.) I can hear it, and I know engineers 
 who monitor much louder, routinely, than I’m monitoring to hear this. My 
 Equator Q10s are not terribly high powered, and I’m not adding any other gain 
 ahead of them in order to boost the quiet part.
 
 If you want to hear the residual easily (32-bit version inverted, summed with 
 16-bit truncated, the result with +40 dB gain via Trim plug-in):
 
 http://earlevel.com/temp/music-dsp/Diva%20bass%2016-bit%20truncated%20residual%20+40dB.wav
 
 I don’t expect the 16-bit truncated version to bother you, but it does bother 
 some audio engineers. Here's 16-bit dithered version, for completeness, so 
 that you can decide if the added noise floor bothers you:
 
 http://earlevel.com/temp/music-dsp/Diva%20bass%2016-bit%20dithered.wav
 
 
 
 On Feb 4, 2015, at 1:10 PM, Didier Dambrin di...@skynet.be wrote:
 
 Yes, I disagree with the always. Not always needed means it's sometimes 
 needed, my point is that it's never needed, until proven otherwise. Your 
 video proves that sometimes it's not needed, but not that sometimes it's 
 needed.
 
 
 
 -Message d'origine- From: Nigel Redmon
 Sent: Wednesday, February 04, 2015 6:51 PM
 To: A discussion list for music-related DSP
 Subject: Re: [music-dsp] Dither video and articles
 
 I totally understood the point of your video, that dithering to 16bit isn't 
 always needed - but that's what I disagree with.
 
 Sorry, Didier, I’m confused now. I took from your previous message that you 
 feel 16-bit doesn’t need to be dithered (dithering to 16bit will never make 
 any audible difference”). Here you say that you disagree with dithering to 
 16bit isn't always needed”. In fact, you are saying that it’s never 
 needed—you disagree because “isn’t always needed” implies that it is 
 sometimes needed—correct?
 
 
 On Feb 4, 2015, at 5:06 AM, Didier Dambrin di...@skynet.be wrote:
 
 Then, it’s no-win situation, because I could EASILY manufacture a bit of 
 music that had significant truncation distortion at 16-bit.
 
 Please do, I would really like to hear it.
 
 I have never heard truncation noise at 16bit, other than by playing with 
 levels in a such a way that the peaking parts of the rest of the sound 
 would destroy your ears or be very unpleasant at best. (you say 12dB, it's 
 already a lot)
 
 I totally understood the point of your video, that dithering to 16bit isn't 
 always needed - but that's what I disagree with.
 
 
 
 -Message d'origine- From: Nigel Redmon
 Sent: Wednesday, February 04, 2015 10:59 AM
 To: A discussion list for music-related DSP
 Subject: Re: [music-dsp] Dither video and articles
 
 Hi Didier—You seem to find contradictions in my choices because you are 
 making the wrong assumptions about what I’m showing and saying.
 
 First, I’m not steadfast that 16-bit dither is always needed—and in fact 
 the point of the video was that I was showing you (the viewers) how you can 
 judge it objectively for yourself (and decide whether you want to dither). 
 This is a much better way that the usual that I hear from people, who often 
 listen to the dithered and non-dithered results, and talk about the 
 soundstage collapsing without dither, “brittle” versus “transparent , 
 etc.
 
 But if I’m to give you a rule of thumb, a practical bit of advice that you 
 can apply without concern that you might be doing something wrong in a 
 given circumstance, that advice is “always dither 16-bit reductions”. 
 First, I suspect that it’s below the existing noise floor of most music 
 (even so, things like slow fades of the master fader might override that, 
 for that point in time). Still, it’s not hard to manufacture something 
 musical that subject to bad truncation distortion—a naked, low frequency, 
 low

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 di...@skynet.be 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 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

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

[Nigel Redmon]

Fair enough, Peter. But remember that the question you posed was whether 
people, after hearing your algorithms, want to hear your ideas, or Robert’s. 
But in your reply to me, and several of your other messages to the list this 
morning, you explain why you won’t divulge your algorithms. That pretty much 
settles it that people will listen Robert then, no?

Don’t get me wrong—I don’t care that you don’t divulge your work, that is your 
choice and right. I admire people who give their time and knowledge, but I 
don’t look down upon people who don’t. I give away some of my knowledge via my 
website, but I don’t expect anything in return—I’m just trying to give a little 
toe-hold for some people who are otherwise overwhelmed by the technical nature 
of DSP. But beyond having a good grasp of filters that people before me figured 
out, I have no experience with making my own.

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.

Regards,

Nigel


 On Feb 5, 2015, at 3:10 AM, Peter S peter.schoffhau...@gmail.com wrote:
 
 On 05/02/2015, Nigel Redmon earle...@earlevel.com wrote:
 I would probably listen to both, if both were sharing information, and in a
 helpful way. I’m not implying that you aren’t (I don’t know—I’ve seen some
 of your posts here, but don’t have a lot of experience with you). I do know
 that Robert has published many helpful and thought-provoking papers, and has
 been doing the same in this forum and comp.dsp for many years. I’m always
 interested in what he has to say.
 
 My only problem is - when I say something that is not a traditional
 approach, why is the first response of some guys here No, you're an
 idiot! That's not how we do it! Crackpot! Idiot! Go home and read some
 beginner books! All your mail will be sent to thrash!
 
 Don't get me wrong, my point is not that Robert is not a smart guy - I
 certainly know that he has a lot of knowledge and insight, a have
 absolutely zero doubt about that. (And he certainly knows a lot more
 than me about certain topics.)
 
 My point is - why that arrogant responses? I believe, that is unfair.
 I think I *could* publish a lot of thought-provoking papers or
 information, things that you currently won't find in any book or
 paper, but if I face such arrogance, why would I even waste my time
 writing those papers?
 
 Let me make this clear - techically I am not an academic, that is, no
 one pays me a hourly rate to write papers and books, so if there's not
 much incentive for me to share any of my information, and I am also
 faced with such high levels of arrogance, then I don't feel like
 sharing any of that information at all. Then I'll say - okay, if
 you're so smart, then just go and figure it out on your own.
 
 Which would be a pity, as I'll die some day and those things that I
 invented and are in my head will go to the grave with me, and future
 generations will need to reinvent all that 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] Dither video and articles

[Nigel Redmon]

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 di...@skynet.be 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 said it required fairly high 
 listening levels and I don’t know what your equipment is. It can be heard on 
 a professional monitoring system. I’m monitoring off my TASCAM DM-3200, and 
 it does not have a loud headphone amp—I can’t hear it there. But it’s right 
 on the edge—if I boost it +6 dB I have no problem hearing it. But my 
 monitoring speakers get louder than the headphones, so I can hear it there. 
 And I know engineers who routinely monitor much louder than my gear can get.
 
 
 On Feb 5, 2015, at 4:55 AM, Didier Dambrin di...@skynet.be wrote:
 
 I couldn't hear any difference (through headphones), even after an insane 
 boost, and even though your 16bit truncated wav was 6dB(?) lower than the 
 32bit wav
 
 But even if I could hear it, IMHO this is 13bit worth of audio

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 earle...@earlevel.com 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 di...@skynet.be 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 said it required fairly high 
 listening levels and I don’t know what your equipment is. It can be heard on 
 a professional monitoring system. I’m monitoring off my TASCAM DM-3200, and 
 it does not have a loud headphone amp—I can’t hear it there. But it’s right 
 on the edge—if I boost it +6 dB I have no problem hearing it. But my 
 monitoring speakers get louder than the headphones, so I can hear it there. 
 And I know engineers who routinely monitor much louder than my gear can get.
 
 
 On Feb 5, 2015, at 4:55 AM, Didier Dambrin di...@skynet.be wrote:
 
 I couldn't hear any difference

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 ethan.d...@gmail.com 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 peter.schoffhau...@gmail.com
 wrote:
 
 On 05/02/2015, Nigel Redmon earle...@earlevel.com 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. shrug.)
 
 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 ethan.d...@gmail.com 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] Dither video and articles

[Nigel Redmon]

Great point, Steffan, and glad to hear that you did some experiments. I have 
not, but made an assumption (by considering the math involved in encoding) that 
encoding from a high resolution source is best. My current music partner is a 
long-time engineer and producer, and he has the habit of mixing 16-bit versions 
and going from there, and I’ve been badgering him to always mix to 32-float (or 
24-bit if he must—you know how habits go with engineers, the concept of float 
seems to bother him, and others I know), and make a 16-bit (*only* for CD) and 
all other versions (AAC, etc.).


 On Feb 4, 2015, at 2:45 AM, STEFFAN DIEDRICHSEN sdiedrich...@me.com wrote:
 
 Great video!
 
 Great explanation and nice demonstration. On the other hand, I’m tempted to 
 ask, if this discussion is still relevant due to the slight changes in music 
 distribution. CD is still a medium, many artist prefer for distribution, 
 mostly for the artwork and booklet, that’s delivered to the buyer. As a 
 consequence, in most cases, the 16 bit, dithered or noise shaped master is 
 used for the compressed versions as well. But the question is, if this 
 process is really the best way? I made some experiments and found out, that 
 AAC benefits from a 24 bit or floating point input, dither noise is rather 
 disturbing the encoding process. That said, CD final mastering should be done 
 in parallel  to the creation of compressed versions. 
 
 
 Steffan   
 
 
 On 24.01.2015|KW4, at 18:49, Nigel Redmon earle...@earlevel.com wrote:
 
 “In the coming weeks”, I said…OK, maybe 10 months…(I wasn’t *just* slow, 
 actually rethought and changed courses a couple of times)…
 
 Here’s my new “Dither—The Naked Truth” video, looking at isolated truncation 
 distortion in music:
 
 https://www.youtube.com/watch?v=KCyA6LlB3As 
 https://www.youtube.com/watch?v=KCyA6LlB3As
 
 
 --
 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]

I totally understood the point of your video, that dithering to 16bit isn't 
always needed - but that's what I disagree with.

Sorry, Didier, I’m confused now. I took from your previous message that you 
feel 16-bit doesn’t need to be dithered (dithering to 16bit will never make 
any audible difference”). Here you say that you disagree with dithering to 
16bit isn't always needed”. In fact, you are saying that it’s never needed—you 
disagree because “isn’t always needed” implies that it is sometimes 
needed—correct?


 On Feb 4, 2015, at 5:06 AM, Didier Dambrin di...@skynet.be wrote:
 
 Then, it’s no-win situation, because I could EASILY manufacture a bit of 
 music that had significant truncation distortion at 16-bit.
 
 Please do, I would really like to hear it.
 
 I have never heard truncation noise at 16bit, other than by playing with 
 levels in a such a way that the peaking parts of the rest of the sound would 
 destroy your ears or be very unpleasant at best. (you say 12dB, it's already 
 a lot)
 
 I totally understood the point of your video, that dithering to 16bit isn't 
 always needed - but that's what I disagree with.
 
 
 
 -Message d'origine- From: Nigel Redmon
 Sent: Wednesday, February 04, 2015 10:59 AM
 To: A discussion list for music-related DSP
 Subject: Re: [music-dsp] Dither video and articles
 
 Hi Didier—You seem to find contradictions in my choices because you are 
 making the wrong assumptions about what I’m showing and saying.
 
 First, I’m not steadfast that 16-bit dither is always needed—and in fact the 
 point of the video was that I was showing you (the viewers) how you can judge 
 it objectively for yourself (and decide whether you want to dither). This is 
 a much better way that the usual that I hear from people, who often listen to 
 the dithered and non-dithered results, and talk about the soundstage 
 collapsing without dither, “brittle” versus “transparent , etc.
 
 But if I’m to give you a rule of thumb, a practical bit of advice that you 
 can apply without concern that you might be doing something wrong in a given 
 circumstance, that advice is “always dither 16-bit reductions”. First, I 
 suspect that it’s below the existing noise floor of most music (even so, 
 things like slow fades of the master fader might override that, for that 
 point in time). Still, it’s not hard to manufacture something musical that 
 subject to bad truncation distortion—a naked, low frequency, 
 low-haromic-content sound (a synthetic bass or floor tom perhaps). Anyway, at 
 worst case, you’ve added white noise that you are unlikely to hear—and if you 
 do, so what? If broadband noise below -90 dB were a deal-breaker in recorded 
 music, there wouldn’t be any recorded music. Yeah, truncation distortion at 
 16-bits is an edge case, but the cost to remove it is almost nothing.
 
 You say that we can’t perceive quantization above 14-bit, but of course we 
 can. If you can perceive it at 14-bit in a given circumstance, and it’s an 
 extended low-level passage, you can easily raise the volume control another 
 12 dB and be in the same situation at 16-bit. Granted, it’s most likely that 
 the recording engineer hears it and not the end-listener, but who is this 
 video aimed at if not the recording engineer? He’s the one making the choice 
 of whether to dither.
 
 Specifically:
 ..then why not use a piece of audio that does prove the point, instead? I 
 know why, it's because you can’t...
 
 First, I would have to use my own music (because I don’t own 32-bit float 
 versions of other peoples’ music, even if I thought it was fair use to of 
 copyrighted material). Then, it’s no-win situation, because I could EASILY 
 manufacture a bit of music that had significant truncation distortion at 
 16-bit. I only need to fire up one of my soft synths, and ring out some dull 
 bell tones and bass sounds. Then people would accuse me of fitting the data 
 to the theory, and this isn’t typical music made in a typical high-end study 
 by a professional engineer. And my video would be 20 minutes long because I’m 
 not looking at a 40-second bit of music any more. Instead, I clearly 
 explained my choice, and it proved to be a pretty good one, and probably 
 fairly typical at 16-bit, wouldn’t you agree? As I mentioned at the end of 
 the video, the plan is to further examine some high-resolution music that a 
 Grammy award-winning engineer and producer friend of mine has said he will 
 provide.
 
 ...and dithering to 16bit will never make any audible difference.
 
 If you mean “never make any audible difference” in the sense that it won’t 
 matter one bit to sales or musical enjoyment, I agree. I imagine 
 photographers make fixes and color tweaks that will never be noticed in the 
 magazine or webpage that the photo will end up in either. But I guarantee 
 you, there are lots of audio engineers that will not let that practically 
 (using the word in the original “practical sense–don’t read

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

 post-edit 
 the sound. Yes it is, totally, but if you're gonna post-edit the sound, you 
 will rather keep it 32 or 24bit anyway - the argument about dithering to 
 16bit is for the final mix.
 
 To me, until proven otherwise, for normal-to-(not abnormally)-high dynamic 
 ranges, we can't perceive quantization above 14bit for audio, and 10bits for 
 images on a screen (debatable here because monitors aren't linear but that's 
 another story). Yet people seem to care less about images, and there's 
 gradient banding all over the place.
 
 
 
 
 
 
 -Message d'origine- From: Andrew Simper
 Sent: Wednesday, February 04, 2015 6:06 AM
 To: A discussion list for music-related DSP
 Subject: Re: [music-dsp] Dither video and articles
 
 Hi Nigel,
 
 Isn't the rule of thumb in IT estimates something like: Double the
 time you estimated, then move it up to the next time unit? So 2 weeks
 actually means 4 months, but since we're in Music IT I think we should
 be allowed 5 times instead of 2, so from my point of view you've
 actually delivered on time ;)
 
 Thanks very much for doing the video! I agree with your recommended
 workflows of 16 bit = always dither, and 24 bit = don't dither. I
 would probably go further and say just use triangular dither, since at
 some time in the future you may want to pitch the sound down (ie for a
 sample library of drums with a tom you want to tune downwards, or
 remixing a song) then any noise shaped dither will cause an issue
 since the noise will become audible.
 
 All the best,
 
 Andrew
 
 -- cytomic -- sound music software --
 
 
 On 25 January 2015 at 01:49, Nigel Redmon earle...@earlevel.com wrote:
 “In the coming weeks”, I said…OK, maybe 10 months…(I wasn’t *just* slow, 
 actually rethought and changed courses a couple of times)…
 
 Here’s my new “Dither—The Naked Truth” video, looking at isolated truncation 
 distortion in music:
 
 https://www.youtube.com/watch?v=KCyA6LlB3As
 
 
 On Mar 26, 2014, at 4:45 PM, Nigel Redmon earle...@earlevel.com wrote:
 
 Since it’s been quiet…
 
 Maybe this would be interesting to some list members? A basic and intuitive 
 explanation of audio dither:
 
 https://www.youtube.com/watch?v=zWpWIQw7HWU
 
 The video will be followed by a second part, in the coming weeks, that 
 covers details like when, and when not to use dither and noise shaping. 
 I’ll be putting up some additional test files in an article on ear 
 level.com in the next day or so.
 
 For these and other articles on dither:
 
 http://www.earlevel.com/main/category/digital-audio/dither-digital-audio/
 
 --
 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
 
 -
 Aucun virus trouvé dans ce message.
 Analyse effectuée par AVG - www.avg.fr
 Version: 2015.0.5645 / Base de données virale: 4281/9051 - Date: 03/02/2015 
 --
 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]

LOL, yes on the time estimates…I headed down one path, and, no that wasn’t 
right, down another…and another…oh, and now I need to write a plug-in..#D 
buttons would be nice…and every time my videos double in length, it’s takes at 
least four times as long to complete…

I understood that lesson pretty well in software development. I worked for a 
company (not to be named) on an ambitious product (not to be named), and we had 
a big meeting at the long conference table to set the milestones…mid-summer, 
with initial targets in September, beta in December, show at NAMM, ship end of 
Q1…as each of these dates where announced, I’d add “of the FOLLOWING year…”, 
and every one at the table would turn and glare at me, probably uncertain 
whether I was serious or joking. Well, guess which December it reached beta, 
which NAMM it finally showed at, which end of Q1…yeah, the following year. I 
always did pretty well in consulting estimates when I envisioned a seemingly 
reasonable (but of course unreasonably optimistic) amount of time for each 
step, added a little slop, doubling that, for each major component, then 
summing up those components and doubling the result.

I agree with you on your point about shaped dither. My feeling is that it’s a 
popular thing for companies to come out with their own, perhaps proprietary 
noise shaping…almost like a status symbol. That really doesn’t do anything of 
practical value. OK, it’s of marginal value in a technical sense at 16-bit, but 
in practical terms, where is it ever going to improve the listening experience? 
At that point, I’d just as soon leave the entire added noise floor below -90 
dB, going with TPDF. And as you say, definitely flat if there will ever be post 
processing. At 8-bits, noise shaping sure makes the area of interest in music 
much clearer (it debatable whether it makes the overall listening experience 
better, but if you need to focus on musical details in the middle, it’s a win). 
But that’s not a typical use case. And at 24-bits…not worth dithering in the 
first place, but does no harm so I have no gripe with people who suggest to 
dither 24-bit, but why oh why would you used shaped dither in that case? I’m 
not saying shaped dither is worthless at 16-bit, just that it’s not my choice. 
But it’s funny to see very slightly different flavors of noise shaping being 
heavily touted as a remarkable improvement over last year’s shaped dither, even 
though the differences are so far below the music that you have to do 
artificial things like listen to dithered silence with the volume up (or dither 
to a small sample size) to rationalize your choice of shaped dither flavor.


 On Feb 3, 2015, at 9:06 PM, Andrew Simper a...@cytomic.com wrote:
 
 Hi Nigel,
 
 Isn't the rule of thumb in IT estimates something like: Double the
 time you estimated, then move it up to the next time unit? So 2 weeks
 actually means 4 months, but since we're in Music IT I think we should
 be allowed 5 times instead of 2, so from my point of view you've
 actually delivered on time ;)
 
 Thanks very much for doing the video! I agree with your recommended
 workflows of 16 bit = always dither, and 24 bit = don't dither. I
 would probably go further and say just use triangular dither, since at
 some time in the future you may want to pitch the sound down (ie for a
 sample library of drums with a tom you want to tune downwards, or
 remixing a song) then any noise shaped dither will cause an issue
 since the noise will become audible.
 
 All the best,
 
 Andrew
 
 -- cytomic -- sound music software --
 
 
 On 25 January 2015 at 01:49, Nigel Redmon earle...@earlevel.com wrote:
 “In the coming weeks”, I said…OK, maybe 10 months…(I wasn’t *just* slow, 
 actually rethought and changed courses a couple of times)…
 
 Here’s my new “Dither—The Naked Truth” video, looking at isolated truncation 
 distortion in music:
 
 https://www.youtube.com/watch?v=KCyA6LlB3As
 
 
 On Mar 26, 2014, at 4:45 PM, Nigel Redmon earle...@earlevel.com wrote:
 
 Since it’s been quiet…
 
 Maybe this would be interesting to some list members? A basic and intuitive 
 explanation of audio dither:
 
 https://www.youtube.com/watch?v=zWpWIQw7HWU
 
 The video will be followed by a second part, in the coming weeks, that 
 covers details like when, and when not to use dither and noise shaping. 
 I’ll be putting up some additional test files in an article on ear 
 level.com in the next day or so.
 
 For these and other articles on dither:
 
 http://www.earlevel.com/main/category/digital-audio/dither-digital-audio/
 
 --
 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

Re: [music-dsp] Dither video and articles

[Nigel Redmon]

“In the coming weeks”, I said…OK, maybe 10 months…(I wasn’t *just* slow, 
actually rethought and changed courses a couple of times)…

Here’s my new “Dither—The Naked Truth” video, looking at isolated truncation 
distortion in music:

https://www.youtube.com/watch?v=KCyA6LlB3As


 On Mar 26, 2014, at 4:45 PM, Nigel Redmon earle...@earlevel.com wrote:
 
 Since it’s been quiet…
 
 Maybe this would be interesting to some list members? A basic and intuitive 
 explanation of audio dither:
 
 https://www.youtube.com/watch?v=zWpWIQw7HWU
 
 The video will be followed by a second part, in the coming weeks, that covers 
 details like when, and when not to use dither and noise shaping. I’ll be 
 putting up some additional test files in an article on ear level.com in the 
 next day or so.
 
 For these and other articles on dither:
 
 http://www.earlevel.com/main/category/digital-audio/dither-digital-audio/

--
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] R: Sallen Key with sin only coefficient computation

[Nigel Redmon]

Naw, mhos is a one-off. It's fun, pronounceable, and in common use (since 
1883!). Don't get carried away. Besides, it makes me think of The Three 
Stooges, and smile. Siemens makes me think of...er, um—oh yeah—a German 
multinational corporation headquartered in Berlin and Munich.

;-)

Sent from my iPhone

 On Dec 24, 2014, at 3:51 PM, Stefan Stenzel stefan.sten...@waldorfmusic.de 
 wrote:
 
 Time to stop this tragedy, let's also measure frequency in dnoces 
 
 
 On 24 Dec 2014, at 3:40 , Nigel Redmon earle...@earlevel.com wrote:
 
 On Dec 23, 2014, at 4:45 AM, r...@audioimagination.com wrote:
 
 in units of mhos (reciprocal of ohms)?
 
 Tragically, the formal name for the mho is Siemens, in keeping with naming 
 units after the principal scientists involved. (Also, it follows from the 
 Siemens mercury unit.) The tragedy is not only in having such a clever and 
 descriptive term replaced by a non-descriptive one, but also the problem 
 with the trailing s on the latter. 10 mhos = 10 Siemens; 1 mho = 1, er, 
 Siemens...
 --
 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] R: Sallen Key with sin only coefficient computation

[Nigel Redmon]

 On Dec 23, 2014, at 4:45 AM, r...@audioimagination.com wrote:
 
 in units of mhos (reciprocal of ohms)?

Tragically, the formal name for the mho is Siemens, in keeping with naming 
units after the principal scientists involved. (Also, it follows from the 
Siemens mercury unit.) The tragedy is not only in having such a clever and 
descriptive term replaced by a non-descriptive one, but also the problem with 
the trailing s on the latter. 10 mhos = 10 Siemens; 1 mho = 1, er, Siemens...
--
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] On the theoretical foundations of BLEP, BLAMP etc

[Nigel Redmon]

On Jul 2, 2014, at 7:37 PM, robert bristow-johnson r...@audioimagination.com 
wrote:

 On 7/2/14 7:54 PM, Nigel Redmon wrote:
 I wasn’t assuming anything at all—especially not that it’s a single sine 
 function”. I meant, simply, that it’s clear what will work (without 
 aliasing) and what won’t—I was stating the obvious, as a prelude to 
 contrasting it with the case of BLEP.
 
 
 i think i understand what you're saying.  BLIT is a form of granular 
 synthesis where the BLI is the grain.  to frequency-modulate a waveform 
 generated from launching these BLI grains, we are modulating the spacing of 
 the onset time for each grain.  the grains themselves are not scrunched or 
 stretched like the waveform that comes out of a wavetable by modulating the 
 phase-increment.
 
 have to think about this a little.  normally the overlap-addition of BLI's, 
 even at sorta random delays, should still be BL.  but the FM'd wavetable is 
 not necessarily BL.

To be clear, I’ll have to bring up the part you quoted:

White it’s pretty clear where the wavetable oscillator will fail in frequency 
modulation,

And the rest of my sentence:

BLEP has performance issues at high frequencies, no? So, it seems that 
“equally well” requires a footnote…
[and the remainder of my post] (By BLEP, I’m assuming the minBLEP scheme 
from Eli, but without the minimum phase wrinkle.)

That is, I was only addressing the fact that BLEP has performance 
considerations (increasing overlap of BLEPs) at high frequencies. And when 
Vadim cited “heavy” audio-rate modulation, to me that meant we might be driving 
the BELP oscillator to high frequencies. (And that does not imply that I agree 
that the BLEP oscillator is any better with FM in general—I haven’t had time to 
think about exactly what that might mean. Till I do, I’m a little skeptical...)

But I agree that FM in general is not so much a problem, perhaps, except that 
it boils down to doing it digitally is different than doing it analogy”, as 
you put it.

But back to Vadim’s comment:

On Jul 2, 2014, at 1:12 AM, Vadim Zavalishin 
vadim.zavalis...@native-instruments.de wrote:
 As for using the wavetables, BLIT, etc, they might provide superior 
 performance (wavetables), total absence of inharmonic aliasing (BLIT) etc., 
 but, AFAIK they tend to fail in extreme situations like heavy audio-rate FM, 
 ring modulation etc. BLEP, OTOH, should still perform equally good.


Ring modulation shouldn’t be part of that, because given an equivalent output 
of an oscillator by any method (say, sawtooth from a wavetable oscillator, and 
a saw from another method—in general, the same harmonic properties and output 
sample rate), if the ring modulation (which is “balanced”, or four-quadrant 
amplitude modulation) results in aliasing, it will result in aliasing for any 
of the oscillator types, because it only depends on the frequency content of 
the oscillator output, not how it got there.


--
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] On the theoretical foundations of BLEP, BLAMP etc

[Nigel Redmon]

On Jul 3, 2014, at 1:36 AM, Vadim Zavalishin 
vadim.zavalis...@native-instruments.de wrote:

 On 03-Jul-14 08:00, Nigel Redmon wrote:
 On Jul 2, 2014, at 1:12 AM, Vadim Zavalishin
 vadim.zavalis...@native-instruments.de wrote:
 As for using the wavetables, BLIT, etc, they might provide superior
 performance (wavetables), total absence of inharmonic aliasing
 (BLIT) etc., but, AFAIK they tend to fail in extreme situations
 like heavy audio-rate FM, ring modulation etc. BLEP, OTOH, should
 still perform equally good.
 
 
 Ring modulation shouldn’t be part of that, because given an
 equivalent output of an oscillator by any method (say, sawtooth from
 a wavetable oscillator, and a saw from another method—in general, the
 same harmonic properties and output sample rate), if the ring
 modulation (which is “balanced”, or four-quadrant amplitude
 modulation) results in aliasing, it will result in aliasing for any
 of the oscillator types, because it only depends on the frequency
 content of the oscillator output, not how it got there.
 
 Ring modulation is clearly a part of that. If the input waveforms of a ring 
 mod can be specified analytically (which is normally the case in a 
 fixed-layout synth) you can consider the ring mod as an oscillator itself. 
 That is, you analytically compute the non-bandlimited output of the ring mod 
 in the continuous-time domain and then apply BLEPs to the discontinuities in 
 the output waveform.
 
 Regards,
 Vadim

OK, but you could do the same with the wavetable oscillator, couldn’t you? 
Maybe I’m misunderstanding…anyway, I thought you meant in the most 
straight-forward case of implementing ring modulation, which is a multiply, 
since you didn’t give conditions.
--
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] On the theoretical foundations of BLEP, BLAMP etc

[Nigel Redmon]

On Jul 2, 2014, at 1:12 AM, Vadim Zavalishin 
vadim.zavalis...@native-instruments.de wrote:

 As for using the wavetables, BLIT, etc, they might provide superior 
 performance (wavetables), total absence of inharmonic aliasing (BLIT) etc., 
 but, AFAIK they tend to fail in extreme situations like heavy audio-rate FM, 
 ring modulation etc. BLEP, OTOH, should still perform equally good.

White it’s pretty clear where the wavetable oscillator will fail in frequency 
modulation, BLEP has performance issues at high frequencies, no? So, it seems 
that “equally well” requires a footnote…

(By BLEP, I’m assuming the minBLEP scheme from Eli, but without the minimum 
phase wrinkle.)

--
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] On the theoretical foundations of BLEP, BLAMP etc

[Nigel Redmon]

I wasn’t assuming anything at all—especially not that it’s a single sine 
function”. I meant, simply, that it’s clear what will work (without aliasing) 
and what won’t—I was stating the obvious, as a prelude to contrasting it with 
the case of BLEP.


On Jul 2, 2014, at 4:20 PM, robert bristow-johnson r...@audioimagination.com 
wrote:

 On 7/2/14 12:40 PM, Nigel Redmon wrote:
 On Jul 2, 2014, at 1:12 AM, Vadim 
 Zavalishinvadim.zavalis...@native-instruments.de  wrote:
 
 As for using the wavetables, BLIT, etc, they might provide superior 
 performance (wavetables), total absence of inharmonic aliasing (BLIT) etc., 
 but, AFAIK they tend to fail in extreme situations like heavy audio-rate 
 FM, ring modulation etc. BLEP, OTOH, should still perform equally good.
 While it’s pretty clear where the wavetable oscillator will fail in 
 frequency modulation,
 
 i don't get it.  what does a DX7 do for the modulating and carrier 
 oscillators?  if the wavetable is a single sine function, you modulate the 
 phase (by changing an offset) or frequency (by changing an increment) as you 
 would for the analog FM modulator.  of course, in any digital oscillator that 
 outputs something other than a sine, there are issues regarding aliased 
 components that fold over.  but if both \omega_M and \omega_C are integer 
 multiples of the same \omega_0, the aliases will coincide with non-aliased 
 frequencies and all components are harmonic.  same about ring modulation.  
 doing it digitally is different than doing it analogly.  wavetable is just 
 another digital method.
 
 i hope neither of you were assuming uninterpolated wavetable synthesis.  if 
 you're interpolation is good, it just produces the samples of a bandlimited 
 and periodic waveform.  and you can change that waveform dynamically.  what's 
 failing?
 
 
 -- 
 
 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