Re: [music-dsp] Fourier and its negative exponent

[robert bristow-johnson]

On 10/7/15 3:02 PM, Theo Verelst wrote:

Stijn Frishert wrote:

Hey all,

In trying to get to grips with the discrete Fourier transform,


Depending on how deep you want to study/understand the subject, get a 
good textbook on the subject, like "The Fourier Transform and its 
Applications" from the Stanford "see" courses, or this one which 
caught my eye because it quotes a book from  a course I did (Circuits 
and Systems, Papoulis) :



https://books.google.nl/books?id=Sp7O4bocjPAC=PA53=PA53=the+DFT+is+a+special+case+of+the+sampled+DTFT=bl=dqfZLS8G9N=rWuIFQikiPPr_f3snYb0FHYZpFI=en=X=0CCsQ6AEwAmoVChMI3vKC4oKxyAIVy2sUCh178gpd#v=onepage=the%20DFT%20is%20a%20special%20case%20of%20the%20sampled%20DTFT=false 



which contains a good quote at the top of page 53

"the DFT is a special case of the sampled DTFT"



the quote is "good" and it's salient, but it only one way to look at it.

the other is "the DFT is synonymous with the DFS which bijectively maps 
a discrete-time sequence of period N to a discrete-frequency sequence 
with the same period N."


(besides the commonly-considered zero-padded x[n] that goes into the 
DTFT and is sampled for the DFT, there are many other aliases of x[n] 
that can be DTFT and sampled to get the very same DFT.)



--

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] Fourier and its negative exponent

[robert bristow-johnson]

On 10/5/15 9:28 AM, Stijn Frishert wrote:

In trying to get to grips with the discrete Fourier transform, I have a 
question about the minus sign in the exponent of the complex sinusoids you 
correlate with doing the transform.

The inverse transform doesn’t contain this negation and a quick search on the 
internet tells me Fourier analysis and synthesis work as long as one of the 
formulas contains that minus and the other one doesn’t.

So: why? If the bins in the resulting spectrum represent how much of a sinusoid 
was present in the original signal (cross-correlation), I would expect 
synthesis to use these exact same sinusoids to get back to the original signal. 
Instead it uses their inverse! How can the resulting signal not be 180 phase 
shifted?

This may be text-book dsp theory, but I’ve looked and searched and everywhere 
seems to skip over it as if it’s self-evident.



hi Stijn,

so just to confuse things further, i'll add my 2 cents that i had always 
thought made it less confusing.  (but people have disabused me of that 
notion.)


first of all, it's a question oft asked in DSP circles, like the USENET 
comp.dsp or, more recently at Stack Exchange (not a bad thing to sign up 
and participate in):


 
http://dsp.stackexchange.com/questions/19004/why-is-a-negative-exponent-present-in-fourier-and-laplace-transform



in my opinion, the answer to your question is one word: "convention".

the reason why it's merely convention is that if the minus sign was 
swapped between the forward and inverse Fourier transform in all of the 
literature and practice, all of the theorems would work the same as they 
do now.


the reason for that is that the two imaginary numbers +j and -j are, 
qualitatively, *exactly* the same even though they are negatives of each 
other and are not zero.  (the same cannot be said for +1 and -1, which 
are qualitatively different.) both +j and -j are purely imaginary and 
have equal claim to squaring to become -1.


so, by convention, they chose +j in the inverse Fourier Transform and -j 
had to come out in the forward Fourier transform.  they could have 
chosen -j for the inverse F.T., but then they would need +j in the 
forward F.T.


so why did they do that?  in signal processing, where we are as 
comfortable with negative frequency as we are with positive frequency 
it's because if you want to represent a single (complex) sinusoid at an 
angular frequency of omega_0 with an amplitude of 1 and phase offset of 
zero, it is:



   e^(j*omega_0*t)

so, when we represent a periodic signal with fundamental frequency of 
omega_0>0 (that is, the period is 2*pi/omega_0), it is:


 +inf
   x(t)  =   SUMX[k] * e^(j*k*omega_0*t)
k=-inf


each frequency component is at frequency k*omega_0.  for positive 
frequencies, k>0, for negative, k<0.



to extract the coefficient X[m], we must multiply x(t) by 
e^(-j*m*omega_0*t) to cancel the factor e^(j*m*omega_0*t) in that term 
(when k=m) in that summation, and then we average.  the m-th term is now 
DC and averaging will get X[m].  all of the other terms are AC and 
averaging will eventually make those terms go to zero.  so only X[m] is 
left.


that is conceptually the basic way in which Fourier series or Fourier 
transform works.  (discrete or continuous.)



but, we could do the same thing all over again, this time replace every 
occurrence of +j with -j and every -j with +j, and the same results will 
come out.  the choice of +j in the above two expressions is one of 
convention.




--

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] Fourier and its negative exponent

[robert bristow-johnson]

On 10/5/15 5:40 PM, robert bristow-johnson wrote:


about an hour ago i posted to this list and it hasn't shown up on my end.



okay, something got lost in the aether. i am reposting this:


On 10/5/15 9:28 AM, Stijn Frishert wrote:
In trying to get to grips with the discrete Fourier transform, I have 
a question about the minus sign in the exponent of the complex 
sinusoids you correlate with doing the transform.


The inverse transform doesn’t contain this negation and a quick search 
on the internet tells me Fourier analysis and synthesis work as long 
as one of the formulas contains that minus and the other one doesn’t.


So: why? If the bins in the resulting spectrum represent how much of a 
sinusoid was present in the original signal (cross-correlation), I 
would expect synthesis to use these exact same sinusoids to get back 
to the original signal. Instead it uses their inverse! How can the 
resulting signal not be 180 phase shifted?


This may be text-book dsp theory, but I’ve looked and searched and 
everywhere seems to skip over it as if it’s self-evident.



hi Stijn,

so just to confuse things further, i'll add my 2 cents that i had always 
thought made it less confusing. (but people have disabused me of that 
notion.)


first of all, it's a question oft asked in DSP circles, like the USENET 
comp.dsp or, more recently at Stack Exchange (not a bad thing to sign up 
and participate in):


http://dsp.stackexchange.com/questions/19004/why-is-a-negative-exponent-present-in-fourier-and-laplace-transform 





in my opinion, the answer to your question is one word: "convention".

the reason why it's merely convention is that if the minus sign was 
swapped between the forward and inverse Fourier transform in all of the 
literature and practice, all of the theorems would work the same as they 
do now.


the reason for that is that the two imaginary numbers +j and -j are, 
qualitatively, *exactly* the same even though they are negatives of each 
other and are not zero. (the same cannot be said for +1 and -1, which 
are qualitatively different.) both +j and -j are purely imaginary and 
have equal claim to squaring to become -1.


so, by convention, they chose +j in the inverse Fourier Transform and -j 
had to come out in the forward Fourier transform. they could have chosen 
-j for the inverse F.T., but then they would need +j in the forward F.T.


so why did they do that? in signal processing, where we are as 
comfortable with negative frequency as we are with positive frequency 
it's because if you want to represent a single (complex) sinusoid at an 
angular frequency of omega_0 with an amplitude of 1 and phase offset of 
zero, it is:



e^(j*omega_0*t)

so, when we represent a periodic signal with fundamental frequency of 
omega_0>0 (that is, the period is 2*pi/omega_0), it is:


+inf
x(t) = SUM X[k] * e^(j*k*omega_0*t)
k=-inf


each frequency component is at frequency k*omega_0. for positive 
frequencies, k>0, for negative, k<0.



to extract the coefficient X[m], we must multiply x(t) by 
e^(-j*m*omega_0*t) to cancel the factor e^(j*m*omega_0*t) in that term 
(when k=m) in that summation, and then we average. the m-th term is now 
DC and averaging will get X[m]. all of the other terms are AC and 
averaging will eventually make those terms go to zero. so only X[m] is 
left.


that is conceptually the basic way in which Fourier series or Fourier 
transform works. (discrete or continuous.)



but, we could do the same thing all over again, this time replace every 
occurrence of +j with -j and every -j with +j, and the same results will 
come out. the choice of +j in the above two expressions is one of 
convention.






--

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

[music-dsp] test (sorry)

[robert bristow-johnson]

about an hour ago i posted to this list and it hasn't shown up on my end.


--

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] test (sorry)

[robert bristow-johnson]

On 10/5/15 5:58 PM, Stijn Frishert wrote:
> Your mail (the first copy) was well received and is still ringing through my 
> mind. Especially the part about -j and +j having equal claim to square to -1 
> is an eye opener.
check out "Imaginary unit" at Wikipedia.

>  I'm still thinking about the consequences and need to write some stuff out 
> on paper, but I'll get back to it. That's why it's taking some time to react 
> ;)

i wasn't worried about your (or anyone else's) reaction. you get what
you pay for. but it did *not* show up on my email, so i thought the
internet somehow ate it.


-- 

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

"Imagination is more important than knowledge."



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

Re: [music-dsp] Fast convolution with synthesis window

[robert bristow-johnson]

On 10/4/15 12:36 PM, Earl Vickers wrote:

rbj wrote:


why would you *want* to use a synthesis window if you're doing OLA
fast-convolution?

Good question.


[ ] it might be a very nice way to have a changing filter kernel and
have it sound nice in the transitions.

Good answer!

Yes, I’m doing time-varying filtering. Just wondering if there were
any tricks I’m missing.


dunno.  just make sure that N >= B + L - 1

where N = FFT length
  B = length of the non-zero values of the window
  L = FIR length


Thanks for the suggestions,


here is another.  i presume your filter kernels are computed in advance 
(and you select one or another for each fast-convolution frame)?  maybe 
it doesn't matter, but whatever they are (they are the DFT of the 
zero-padded h[n]), you must make sure that they are the DFT of an h[n] 
that is no longer than N-B+1.


earlier i wrote here about (and i have a pdf document that spells it 
out) what the optimal size of N (where N is a power of 2) given what the 
FIR length L is.  it was done for a rectangular window (with no overlap 
of the windows, even though there is always overlap of the frames), but 
i think the results are similar for 50% overlapped windows.  it would be 
half as efficient, but i think the optimal N would be the same.


just FYI.



--

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] Fast convolution with synthesis window

[robert bristow-johnson]

On 10/3/15 1:06 PM, Earl Vickers wrote:

Is there any way to do STFT-based fast convolution using a (non-rectangular) 
synthesis window?

do you mean analysis window instead of synthesis window?

No, I mean using a synthesis window, as with WOLA or Griffin/Lim (in addition 
to an analysis window).

Julius Smith says:

"Output windows are _not_ used in simple FFT convolution processors 
because the input frames
are _supposed_ to be expanded by the convolution, and an output window 
would 'pinch off' the
'filter ringing' from each block, yielding incorrect results…. In other 
words, WOLA is good
for 'instantaneous nonlinear spectral processing'."

Just wondering if there's a way around that.


why would you *want* to use a synthesis window if you're doing OLA 
fast-convolution?


i remember, in the context of a phase-vocoder, Jean Laroche telling us 
about using a Hann window as an analysis window and another identical 
one as an additional synthesis window and using that with 75% overlap.  
maybe Millar Puckette first had the idea.  somehow they add up to 1, if 
i remember correctly.


but with 50% overlapping Hann windows (or some other complementary 
windows) and some zero-padding on top of that (so the FFT length is 
longer than the window width by the length of the FIR), you can do fast 
convolution just like you would with a rectangular window.  but your hop 
length would be 1/2 of the hop length with the rect() window.  so you 
would get half the number of new output samples out of each frame.  so 
it's half as efficient.


but it might be a very nice way to have a changing filter kernel and 
have it sound nice in the transitions.  (this is with no window applied 
to the overlapping output frames.  since the frames are longer than the 
window, your overall overlap is longer than 50%.)


--

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] Fast convolution with synthesis window

[robert bristow-johnson]

On 10/2/15 11:29 AM, Earl Vickers wrote:

Is there any way to do STFT-based fast convolution using a (non-rectangular) 
synthesis window?



do you mean analysis window instead of synthesis window?

sure, but the rules of overlap-add fast convolution still have to be 
followed.


the length of the non-zero window plus the length of the impulse 
response of the FIR must not exceed the length of the FFT (plus one).


it's just that with 50% overlap with complementary windows (like Hann), 
that your hop length will be half of what it was with a rectangular 
window.  so you'll get half of the number of output samples per frame as 
you would with a rectangular window.


--

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] sinc interp, higher orders

[robert bristow-johnson]

if, by a 1024 window that means you are looking at your original samples 
from x[n-512] up to x[n+512], i would say that it's overkill.


sometimes, when doing interpolation there is an upsampling factor 
implied.  if there is an upsampling factor of, say, 32 in there, and 
you're really only considering samples from x[n-8] to x[n+8], then i 
would say it's not enough.


bestest,

r b-j


On 9/11/15 10:20 AM, Victor Lazzarini wrote:

Excellent, thanks.

Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952


On 11 Sep 2015, at 09:16, Stefan Stenzel  wrote:

No.


On 10 Sep 2015, at 21:15 , Victor Lazzarini  wrote:

Is there much to gain in going above a 1024 window, when doing sinc 
interpolation (for table lookup applications)?

(simple question; no intention of starting flame wars; not asking about any 
other method, either ;) )

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp


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


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





--

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] warts in JUCE

[robert bristow-johnson]

On 9/6/15 8:52 AM, Chris Cannam wrote:

On Sat, Sep 5, 2015, at 11:37 PM, Daniel Varela wrote:

Robert is right, sample rate is part of the audio information

Robert is certainly right -- an encapsulation of an audio buffer in
isolation must include the sample rate. I don't expect anyone in this
thread disagrees with that.


now, why not do that since the "proper size" of the AudioSampleBuffer is 
normally much larger than the word used to assign to sampleRate.

All the same, a lot of software breaks down the abstraction differently
and associates the sample rate with a processing context (or graph)
instead of with individual buffers. You could say the buffers then are
incomplete, just series of values rather than self-contained
representations of audio. As I understood it, Robert was wondering why
anyone would do that (assuming some reason other than "programmer is
just stupid" or "programmer hasn't learned the first thing about sampled
audio")


no.  my complaint is about modularity and utility.  AudioSampleBuffer is 
eventually going out loudspeakers for someone to hear.  it is, lacking a 
single 4-byte float, nearly a complete physical description of the very 
thing we're trying to do with the audio.



  and I was trying to articulate an answer. It makes no sense to
represent that as a question of right or wrong.

(Perhaps Jules's mistake was to name the class AudioSampleBuffer in the
first place.)



i think he actually told me that in one of the emails.  i disagree.  it 
is what it almost is.



On 9/6/15 9:03 AM, Chris Cannam wrote:

On Sun, Sep 6, 2015, at 01:50 PM, robert bristow-johnson wrote:

otherwise, you're always going to be passing sampleRate
along with every AudioSampleBuffer.

This bit here -- this is the part that doesn't match real practice. You
would typically pass the sample rate when you construct a specific
processing object (i.e. literally when you call its constructor, in C++
terms).


sure.  i understand that what you're saying that sampleRate would be 
established once in the driver setup.  fine.  then ignore the contents 
of myAudioSampleBuffer.sampleRate().


one might consider putting in a sanity check where the sample rate set 
at construction is compared to sampleRate and turning on an LED or 
something about the audio source changing.  and, of course, nothing 
stops you from accepting differing sample rates and interpolating on the 
fly.


but it's not the point (having a robust sample rate output device).  the 
point is a natural use of modularization of a thing.  a sorta important 
thing in audio, like how we unambiguously define a piece of it and send 
it around to different processes and devices.



  It's not global, it's not hardcoded, but you still don't need to
pass it to every processing call.


is that such a big expense?  especially if passed-by-reference.  i don't 
understand what the problem is.



  It's just fixed for a particular
instance of a processor. Say you have a filter object, you construct
that to run at a particular sample rate, and then you just feed it the
sample values each time.


the filter object needs to know the sample rate in order to compute 
filter coefficients.  you can still do it the old way and set the sample 
rate at instantiation time.  you can ignore the value.  or you can 
compare the value to the sample rate set at instantiation time to see if 
it's different and flag an error to something or 'nother.


but you can design filter objects can handle varying coefficients.  we 
do that for all kinds of things.  making the filter be able to apply 
different sample rates makes this thing *more* modular and has *more* 
utility.


i still just cannot understand how anyone values it of higher utility to 
leave this necessary component of information out of the object, 
considering what the object is.



You mentioned channel count as well -- same thing applies.


well, no, numChannels is included, as it should be, and sampleRate is not.

you wouldn't expect numChannels to change after instantiation.  neither 
need to change, but both need to be known and both are fundamental in 
the definition of the "thing", this description of a piece of audio that 
will eventually go out to loudspeakers.



I imagine (as
Ethan suggested earlier) that channel count is only included in the
buffer object because it wouldn't be possible to unpick the raw C++
object without it. Arguably that's a limitation of C/C++ (pointer-based
arrays don't know their size) rather than by design.


so you're saying the sole purpose of having numChannels is because they 
need it to define a the array and C++ doesn't know the dimensions?




--

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] warts in JUCE

[robert bristow-johnson]

On 9/6/15 12:59 AM, Ross Bencina wrote:

On 6/09/2015 8:37 AM, Daniel Varela wrote:

sample rate is part of the audio information so any related message
  ( AudioSampleBuffer ) should provide it, no need to extend the 
discursion.


There's more than one concept at play here:


i very much agree.



(1) If you consider the AudioSampleBuffer as a stand-alone entity, 
then it should carry it's own sample rate. Further, if the object is 
fully in control of its own buffer allocations then you can argue for 
all kind of extensions (e.g. zero-padding, power-of-two size, etc.).


(2) On the other hand, if the system has a fixed sample rate, then the 
sample rate is a (global) property of the system, not of the buffers. 
By definition, all buffers have the same sample rate -- the system 
sample rate. Further, if the buffers are allocated externally (e.g. by 
a plug-in host) then the role of AudioSampleBuffer is purely a wrapper 
(smart pointer) and there is no way for it to provide a mechanism for 
zero-padding or any other buffer allocation related features.


how is this different than the system having a fixed number of 
channels.  everything is 2 channels.  why bother to put numChannels into 
the object?




This discussion seems to be about whether AudioSampleBuffer is (1), 
(2), or both.


i was rooting for both.



There is no one-true-answer, but if the object is modeling (2), adding 
a field for sample rate not only violates the zero-overhead principle


dunno how it does that.

but also opens the door to violating a system invariant (i.e. that all 
buffers have the same sample rate).


so forcing a restriction that they're all the same is better.

let's just have a system global called "sampleRate".  why not hard code 
it?  because otherwise, you're always going to be passing sampleRate 
along with every AudioSampleBuffer.  or you may into trouble receiving 
an AudioSampleBuffer and you may have to guess what sample rate to 
associate with it.



As far as I know, case (2) addresses the main use-case for JUCE.

Personally, I think AudioSampleBuffer is (a) trying to do too much 
(there should be two objects: a Buffer and a BufferRef);


oh dear.  the opposite of modularization.  an outpouring of object classes.


and (b) it's abstraction overkill for the plug-in use-case.



i do not think that sample rate is particularly overly abstracted from a 
buffer of audio.  i think it is central.


--

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] warts in JUCE

[robert bristow-johnson]

On 9/4/15 8:58 AM, mdsp wrote:

On 04/09/15 02:44, robert bristow-johnson wrote:
In both cases the sampling rate is already available before the 
processing starts using prepareToPlay(int samplesPerBlockExpected, 
double sampleRate). Having it stored on AudioSampleBuffer while 
handy would be redundant, and more importantly it would require all 
calling code to be modified to initialize it properly,


no.  it would not.
would you trust a class where the sampling rate is an optional feature 
or can default to 0?


first of all, needing to define a sample rate is not an optional 
feature.  one way or another you need to do that (with the exception of 
the memory-less processes of gain change or mixing streams).  the way 
AudioSampleBuffer is now, there is *more* of a danger of some code down 
the pike being passed an AudioSampleBuffer and not knowing what the 
sample rate is.


defaulting the private sampleRate member variable to 0 offers a hint to 
some code down the pike that they may have a problem (if they hadn't 
determined the sample rate from some other means, like it was explicitly 
passed to them).  it's not compile time, it's run time but it's not a 
bad idea.


i have more experience in embedded DSP but i have, in contexts other 
than JUCE, have done native DSP processing, both real-time and not.  
this case was not real time.  there was one programmer there that had 
the reputation of "No-Null-Check McGee" (regarding pointers to sample 
buffers) and his code was always in need of fixing by other people.  
very low-quality code but he was a principal of sorts.  last i heard 
he's now the VP of R  perhaps a run-time check that the sampleRate is 
a positive value before using it might be a useful thing.  the other 
contexts i have worked, it was guaranteed, but the overall structure of 
the system that there really was audio at where the pointer was pointing 
and that the sample rate really was meaningful.


but the issue you bring up is not really directly related.  whether the 
sample rate is embedded in the class or not, if it's a block of audio 
samples, you better know what the sampling rate is (unless it's a 
memory-less process of gain change or mixing streams or perhaps a 
memory-less nonlinear process).  and it's in the *existing* model where 
there is more danger of the sampling rate being "optional".





What I was saying was that in order to be able to trust the class, a 
non-backward compatible change would be necessary to go from:


AudioSampleBuffer (int numChannels, int numSamples);
AudioSampleBuffer (float *const *dataToReferTo, int numChannels, int 
numSamples);
AudioSampleBuffer (float *const *dataToReferTo, int numChannels, int 
startSample, int numSamples);


to

AudioSampleBuffer (int numChannels, int numSamples, double samplingRate);
AudioSampleBuffer (float *const *dataToReferTo, int numChannels, int 
numSamples, double samplingRate);
AudioSampleBuffer (float *const *dataToReferTo, int numChannels, int 
startSample, int numSamples, double samplingRate);


In order to *force* a compile-time error to make it clear to all 
client code of this class that the responsibilities have changed.


Of course you can add a variable like samplingRate silently and 
initialise it to 0 (or a potentially wrong sampling rate).
Then will come the time, long after that change where somebody will 
try to use the sampling rate as something that can be trusted.


but you have that problem NOW.  i don't get it.  it's the *present* 
state of affairs where someone is writing code, they get some 
AudioSampleBuffer from somewhere, and they are forced to assume a value 
for the sampling rate (this is where i've seen hard-coded numbers like 
"44100.0" in the code, which is just inexcusable).  or they have to look 
around in the lineage of that AudioSampleBuffer to find out where it 
came from and what the sample rate was when the audio was first input, 
whether from a device like a codec or from a sound file reader.


that information is necessary as part of the physical definition of the 
audio, just as the number of channels and the number of samples (both of 
which are embedded in the AudioSampleBuffer class) are.  you can't just 
pass an AudioSampleBuffer to an output device or a sound file writer 
without also passing the associated sample rate.  in addition, you can't 
just pass an AudioSampleBuffer to a processing routine that is a filter 
or delay or an audio effect without also passing the correct sample rate 
along with it.  or an audio-to-MIDI converter.


That kind of bugs are so easy to introduce and to forget about, but 
not so easy to track afterward.


you're not arguing a case for leaving it out, you're making my case for me.



That's the reason why most of the time I prefer a 
non-backward-compatible change that force you to update your client 
code and let the compiler show you where you need to take action over 
a silent modification that breaks assum

Re: [music-dsp] Announcement: libsoundio 1.0.0 released

[robert bristow-johnson]

On 9/4/15 1:31 PM, Andrew Kelley wrote:
On Fri, Sep 4, 2015 at 10:30 AM Alexandre Pages 
> wrote:


Yes, why re-invent the wheel over and over again?


I prefer round wheels :-)



woot!

i guess i'm gonna have to check this out.

--

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] warts in JUCE

[robert bristow-johnson]

On 9/4/15 12:27 PM, mdsp wrote:
I've tried to make my point but I think there's still quite a lot of 
misunderstanding.


sometimes it's misunderstanding.

again, i'm not a C++ expert (i said this on my old email to Jules that i 
posted here), but *am* an expert in nearly all particulars in C and also 
know what to expect as it is compiled into machine code.  i know about 
processing in real time and in non-real time.


i originally offered the suggestion in the effort to serve the purposes 
of modular programming, of which the principles, as i understand it are:


  https://en.wikipedia.org/wiki/Single_responsibility_principle

  https://en.wikipedia.org/wiki/Separation_of_concerns


i find it odd that it seems to all inherent to a parcel of sound 
represented in a computer are the number of samples and the number of 
channels (and both are in an AudioSampleBuffer in addition to the audio 
samples themselves) yet the sample rate is considered "ancillary".  i 
know for a fact that the sample rate is *not* ancillary, but primary or 
inherent.  you do not have a complete description of that chunk of audio 
without.  and *with* the sample rate (as well as what is already 
contained in the AudioSampleBuffer and aforementioned) you *do* have a 
complete description of that chunk of audio.  (i am assuming that the 
samples are uniformly sampled in time. i think that assumption is 
totally reasonable.)  it is *natural* that these all are contained in a 
common object.


and, as a raw description of the audio, it is *unnatural* for anything 
else to be contained in it, but i can see putting in metadata like the 
date/time of recording, some information regarding the equipment, 
perhaps a voltage or SPL reference for the full-scale (which i think is 
floating-point 1.0).  such fields could be left empty or not, or we 
wouldn't need to put them into the definition at all.  a sample-playback 
synthesizer needs the required: the samples themselves, the number of 
channels, the number of samples per channel, and the sample rate.  now 
JUCE's AudioSampleBuffer *does* contain some private metadata that JUCE 
uses to manage memory.  the same kinda data any operation system with a 
heap uses to manage memory, allocate and move blocks of data around and 
to combine fragmented unused space into contiguous unused space.  that's 
fine because it's private variables and it is not necessary for a 
sample-playback synth to do what it must do with the AudioSampleBuffer.


if AudioSampleBuffer did *not* contain the numChannels or numSamples, 
and you had to pass that data around all the time along with the 
AudioSampleBuffer, just so you could do something with it, i think you 
would conclude that something is missing and should be included in the 
object definition.  i don't grok why anyone would not come to the same 
conclusion regarding sampleRate.



I don't post often here and I don't want to pollute this mailing-list 
too much, so that will be my last post on this subject.




understood.


On 04/09/15 17:27, robert bristow-johnson wrote:
oh, that's interesting.  so Jules also prefers 
non-backward-compatible changes in JUCE.  i didn't know that.


doesn't make that much sense to me.
iif the change is a disruptive one that could have important 
side-effects on existing code.




but the change will *not* have *any* salient side-effects on *existing* 
code.  that's why it's backward compatible.


it *may*, if people use the enhancement, have effects on *future* code 
and if some old code is updated where parts of it make use of the 
change, then other parts may also need to be updated to keep it clean.  
but *old* code will work fine because the old data structure is still 
there and unchanged.  the numChannels and numSamples and pointers to the 
channel audio samples are all still there, just as they were before.  
nothing breaks.


cf item #14 in C++ coding Standards by Herb Sutter and Alexey 
Alexandrescu: "Prefer compile- and link-time errors to run-time errors"


http://www.gotw.ca/publications/c++cs.htm
what if the host changes the sampling rate now?  you have the same 
problem.  but worse.  now you have the additional danger of having 
set it up for, say, 48 kHz and then the host changes it to 96 kHz and 
your code merrily goes along ignorant of the change.
The host is required to stop processing and inform you about sampling 
rate and maxBlockSize changes in all plugin formats I know about. 
that's what prepareToPlay is meant for in JUCE. Once this is done, I 
don't see the need to transmit that information all the time.


well, it's only one (or two, if you include zeroPad) extra word that 
gets passed around.  just like in the present case, you can choose to 
ignore any change at real time betting on the fact that some coherent 
programmer isn't gonna change the numChannels on the fly on you.  it 
*does* appear that the numSamples might change between frames and that 
the called method need

Re: [music-dsp] warts in JUCE

[robert bristow-johnson]

On 9/4/15 4:35 PM, Chris Cannam wrote:

(I have never used JUCE, don't know its interfaces, and have no side to
take)

On Fri, Sep 4, 2015, at 08:38 PM, robert bristow-johnson wrote:

i find it odd that it seems to all inherent to a parcel of sound
represented in a computer are the number of samples and the number of
channels (and both are in an AudioSampleBuffer in addition to the audio
samples themselves) yet the sample rate is considered "ancillary".

If your sample buffer has the sample rate attached, then any library
function that consumes a sample buffer cannot be correct until its
author has made a decision about what to do if the sample rate changes
between calls.


same problem (if that *is* a problem) if you pass sampleRate alongside 
the AudioSampleBuffer rather than inside of it.


if the sampleRate changes, whatever code that gets this audio passed to 
it has to deal with the new sample rate however.


suppose you have a real-time audio playback function that takes 
AudioSampleBuffers, concatenates them chronologically and plays them out 
to some outside device.  now, suppose the *hardware* sample rate is 
fixed and some nice high value, like 192 kHz.  but this thing is 
designed so that you can pass audio at any lower audio rate.  of course, 
if you pass audio at a lower rate (say 44.1 kHz), this function will 
have to do some kinda interpolation on the fly to create samples at the 
192 rate to go out. fine, we know how to do that.  the function only 
knows how to do this interpolation because it knows the sample rate 
going out to the hardware and it knows the sample rate coming in with 
the AudioSampleBuffer.


now suppose the source of audio changed (like a different file or 
different internal buffer is now gonna be sent out) and it's a different 
sample rate attached to it.  now the function sees that it's a different 
input rate and the interpolation step-size must change and it's 
recalculated.  the function can still handle that.  there might be a 
glitch at the boundary, but there would be anyway if you switched from 
one source to another.


a sample-rate-conversion function that operates on an AudioSampleBuffer 
will be changing the associated sampleRate parameter, whether it's 
explicitly attached to the AudioSampleBuffer or sent alongside of it.  
this is normal.  i don't see a problem here.



In most cases the library won't be able to handle this, and in normal
processing use it won't anyway, so the obvious thing would be to fail,
or else to ignore the changed rate. Few developers would actually write
(correctly) the code necessary to support a change in sample rate
between process calls.


well, what's the point of knowing the sample rate in the first place, then?


If the sample rate can't change between calls, then the right thing is
to enforce that in the API.


if the sample rate can't change, but you draw the audio from different 
sources and the sources didn't have the same rate, whether you embed it 
into AudioSampleBuffer or not, the premise of your condition is not 
satisfied.



  In an object-oriented world, that means that
unchanging properties like sample rate and channel count are given when
the object is constructed, rather than when its methods are called.


but the methods are aware of the numChannels with the existing 
AudioSampleBuffer.  if you're writing a simple filter effect, you have 
to know how many channels there are (and how many samples there are) to 
do your task.  but guess what?  you also have to know the sample rate, 
too, otherwise you cannot compute the filter coefficients correctly.  
this is the case whether the property is changing or unchanging.



  So
they're passed in to the constructor instead of to the methods that
accept audio buffers.


no, numChannels is in the AudioSampleBuffer.  and sampleRate is not (at 
present).



That changes the conception of what the function does -- it no longer
accepts an audio buffer at a particular sample rate and works on that;
instead it has already been constructed to work at a particular sample
rate -- it produces a function that processes audio at a particular
sample rate -- and it accepts all audio buffers on the assumption that
they match it.


bad assumption.


  That's much simpler to deal with and probably also simpler to call.


no, it's the opposite.  i gotta filter method and you send me an 
AudioSampleBuffer and some parameters for the filter such as type (LPF, 
etc), Q, and cutoff frequency (in units of physical frequency).  i 
cannot do the job until i know what the sample rate is.  the best thing 
is if i look at the AudioSampleBuffer itself, which came from a 
recording device or from a sound file and has this sample rate naturally 
attached to it.



The way you propose things is also very sound in outline, I think, but
it's more like a functional-programming paradigm. In an object-oriented
world you would bind the context as soon as you construct the obje

Re: [music-dsp] warts in JUCE

[robert bristow-johnson]

On 9/3/15 5:57 AM, mdsp wrote:
As a long-time JUCE user and observer let me give you my opinion 
regarding AudioSampleBuffer.


thank you.  i hope it's okay if i respond (and disagree, respectfully).

now, i want us to be clear about the definition of "backward 
compatible".  Google defines it simply as:


"(of computer hardware or software) able to be used with an older piece 
of hardware or software without special adaptation or modification."


i am interpreting it as, in the current context, that code that was 
written and uses JUCE, specifically AudioSampleBuffer, and (of course) 
does not fiddle with any private variables (i.e. only accesses them via 
member functions), and that functions correctly before the change (or 
"enhancement"), will also function identically after the change.  with 
the MATLAB origin-generalization enhancement i have been advocating for 
20 years, i would add the extra condition that the backward-compatible 
enhancement functions identically save for a possible extremely small 
loss of execution efficiency from one or two extra instructions.  but 
this is not the case with what i am advocating regarding 
AudioSampleBuffer.  it might take a teeny-weeny bit more memory (unless 
you go crazy with the amount of zero padding), but it will *not* cost a 
dime in extra computational burden.  (and even if it did cost an extra 
instruction or two, i would still call it "backward compatible" if it 
doesn't break any existing code.)


While I totally understand why you're suggesting that kind of 
enhancement, it's important to consider where AudioSampleBuffer is 
mostly used (i.e. in AudioProcessor and AudioSource) and why it was 
created. It may seem simple and not harmful at first but that's not so 
simple:


In both cases the sampling rate is already available before the 
processing starts using prepareToPlay(int samplesPerBlockExpected, 
double sampleRate). Having it stored on AudioSampleBuffer while handy 
would be redundant, and more importantly it would require all calling 
code to be modified to initialize it properly,


no.  it would not.

not only in JUCE codebase but in all JUCE's users code too if they 
want to be able to use it reliably.


nope.

In order to enforce that new contract, the constructor should be 
changed to force a compile-time error in all places making use of it 
so not a backward-compatible change in the end.


   prepareToPlay(samplesPerBlockExpected, sampleRate)

would ignore the value of sampleRate embedded in the AudioSampleBuffer 
(i will confess that i do not know exactly how an AudioSampleBuffer gets 
connected to an AudioSource, but i don't think that detail matters).  
old code would still work the same way.


perhaps, after sampleRate is added to AudioSampleBuffer, in time someone 
will make a backward compatible version of prepareToPlay() that is


prepareToPlay(samplesPerBlockExpected);

a call to prepareToPlay() like that would use the sampleRate embedded in 
the AudioSampleBuffer.


old code would still work, without modification, just like it had before.

and new code *could* choose to take advantage of the new feature that 
greatly simplifies the calling conventions.




Moreover it is most often used to convey small blocks of audio (64 - 
4096) so zero-padding could be a significant overhead over existing data,


in memory.  memory is cheap.

also the zeroPad parameter can be 0.  no reason it can't.  i would 
suggest a default initial value of more than zero, but perhaps i am 
wrong and the default should be 0.  in that case it doesn't cost a 
single extra word in the sample array data.


but more importantly AudioSampleBuffer doesn't necessarily own its 
memory (cf the second constructor that is meant to reference external 
data) it is meant as a lightweight wrapper around existing API like 
VST that gives you float** buffers.


doesn't matter.  if zeroPad>0 it just means more memory in that other 
memory space, wherever it is.  if memory is super-expensive in that 
space or if there is any other reason you don't want to waste any words 
on zero-padding, set it to 0.  so i guess i have to concede that the 
default value should be 0.


Having zero-padding would break this and require allocating an array 
(potentially in a real-time thread), and copying the external data.


nothing is broken if zeroPad=0. AudioSampleBuffer already has its means 
for allocating memory (Jules has his own malloc() and there is private 
data embedded in an AudioSampleBuffer that is used solely for that 
purpose).  want to increase the size of an AudioSampleBuffer?  just call 
setSize().


of course if zeroPad is increased, setSize() would have to be called.  
this can be done transparently to the user.  essentially there would be 
a new private function called "setZeroPad()" (or something like that) 
that would never be called by legacy code.  you cannot make a claim that 
future code that calls setZeroPad() and then breaks something is 
evidence of violation 

[music-dsp] warts in JUCE (was Re: Implementing GMM for voice diarization on iOS and Android)

[robert bristow-johnson]

On 9/2/15 7:13 AM, Jean-Baptiste Thiebaut wrote:
I'd recommend JUCE (juce.com ). There's already 
support for iOS and Android, and it's about to get better. And it's 
all cross platform C++, so you can do real-time applications.


(full disclosure: I'm the product manager for JUCE)


really?

i've corresponded with Jules about this multiple times back in 2013 when 
i was working on a project using JUCE: why doesn't JUCE include 
"sampleRate" (probably a float) in AudioSampleBuffer??  it's really dumb 
not to.


i really hate having to pass a sample rate along with a reference to an 
AudioSampleBuffer to processing routines.  i've even seen code where 
44100.0 was hardwired in it.  all this is just inexcusable.


although less salient, i would also include a "zeroPad" member parameter 
(and a member processes that can change it).


i also really hate having to either manually zero pad an 
AudioSampleBuffer myself or having to write special code to deal with 
frames that are on the edge.  either the first one or two frames and/or 
the final one or two frames.


it can all be done backward compatible with the existing AudioSampleBuffer.

--

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] warts in JUCE

[robert bristow-johnson]

On 9/2/15 5:14 PM, Tom Duffy wrote:



On 9/2/2015 1:48 PM, robert bristow-johnson wrote:


On 9/2/15 7:13 AM, Jean-Baptiste Thiebaut wrote:

I'd recommend JUCE (juce.com). There's already
support for iOS and Android, and it's about to get better. And it's
all cross platform C++, so you can do real-time applications.
(full disclosure: I'm the product manager for JUCE)

really?



Don't forget about the mirage of backwards compatibility - there's
little of it in reality.


that's because there is little careful and legitimate and modular coding 
done in reality.  too many hackers doing quickies and then "it's done" 
and they move on.


like the MATLAB index-origin thingie, i can explain how adding either of 
these two features can be perfectly backward compatible.


i'm gonna look up some of my old correspondence with Jules






I had a minor application written in JUCE that I needed to maintain,
grabbed the closest library source, but got a ton of compile errors.
The exact version that was in use when the application was written
was no longer available.
Welcome to Sh*t Creek, leave your paddle on the shore over there.

Eventually got an exact copy of the original version from someone
else who had previously compiled the program and still had it hanging
around.


it's because someone's not legit.

below is one of the things i said to Jules.  i have reviewed some of our 
back-and-forth and decided the discussion got a little testy (moreso on 
my part), so thought twice about publicly posting that.



L8r,

--

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

"Imagination is more important than knowledge."





On 1 November 2013 23:41, robert bristow-johnson 
<r...@audioimagination.com <mailto:r...@audioimagination.com>> wrote:


hello Jules,

we haven't been introduced, but i am a long-time audio DSP coder 
developer.  i don't have a website with my public work, but the 
music-dsp site has some of it.  many people have made use of the Audio 
EQ Cookbook (perhaps you have, too, i dunno).


recently i had done some work with a company that is making extensive 
use of JUCE, and while i have not explored all of the different 
utilities, i *have* made use of JUCE Array.h and 
AudioSampleBuffer.h|.cpp .  i am not an expert C++ programmer, but i 
have coded in it.  i *am* an expert C programmer, and it is true that 
the people who have the most trouble with C++ coding philosophies are 
old C programmers like me.  but i will try to set that aside.


since the AudioSamplebuffer class appears to be the primary class one 
would use to implement their own DSP code using the JUCE framework, i 
*did* use and study that class quite a bit recently.  i have a question 
regarding efficiency and also a proposal for you to extend the class 
slightly in a backward-compatible manner that would be quite welcome to 
future audio DSP coders using the class.


the question i have is why do you bother to have the array of: float** 
channels ?  since about the only use of that array is to get a pointer 
to the individual sample buffers in getSampleData() and since the 
channel float* pointers are simply computed from allocatedData and size 
in a straight-forward linear fashion, can't you just have 
getSampleData() return the pointer to the 0th sample of the channel 
requested with (allocatedData + channelNumber*size)?  why bother to make 
that array of pointers in the first place?  this is really just an 
academic question, and not the main reason i am writing.


the main reason for writing is to suggest that you include two new 
(private, i suppose) member variables:


float sampleRate;
int zeroPad;

and use these with the AudioSampleBuffer in a perfectly 
backward-compatible manner (so no existing code gets broken by this 
modification).


the reason for including sampleRate along with numChannels, size, and 
the pointer to the actual data (allocatedData), is that along with the 
actual audio samples, numChannels, size, and sampleRate are all 
necessary and sufficient to fully define the physical recorded sound. 
 in our code, we would retrieve the sampleRate from the .ogg file 
reader (i don't remember what it was called) and we had to send 
sampleRate along with the AudioSampleBuffer to every DSP function as an 
additional argument.  it should just be attached to the audio itself. 
 along with numChannels, size, and the actual audio sample data, this 
is sufficient to pass to a file I/O utility or to a sample-playback 
synthesizer.  and any audio sample input device (or file reader) should 
supply the sampleRate information along with the other necessary 
metadata (like numChannels and size) and the sample data itself.


the other, slightly more difficult (but certainly very doable) 
modification to AudioSampleBuffer that i would strongly encourage you to 
do in the next salient revision is to zero pad each channel of audio in 
AudioSampleBuffer with zeroPad (perhaps about 4096) samples

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

[robert bristow-johnson]

On 8/26/15 9:47 PM, Ethan Duni wrote:

15.6 dB  +  (12.04 dB) * log2( Fs/(2B) )

Oh I see, you're actually taking the details of the sinc^2 into account.


really, just the fact that the sinc^2 has nice deep zeros at every 
integer multiple of Fs (except 0).


What I had in mind was more of a worst-case analysis where we just 
call the sin() component 1 and then look at the 1/n^2 decay (which is 
12dB per octave). Which we see in the second term, but of course the 
sine's contribution also whacks away a certain portion of energy, 
hence the 15.6dB offset.


well, it's more just how the strengths of the images add up.



On the other hand if you're interested in something like the 
spurious-free dynamic range, then the simple 12dB/octave estimate is 
appropriate. The worst-case components aren't going to get attenuated 
at all by the sin(), just the 1/k^2. I tend to favor that in cases 
where we can't be confident that the noise floor in question is (at 
least approximately) flat.



but whether you're assuming a flat spectrum up to B or just a single 
sinusoidal component at the maximum frequency of B, it's the sin() (or 
the sin^4 in the power spectrum of the images resulting from linear 
interpolation) that is the mathematical force in reducing the image 
strength in the oversampled case where 2B  Fs.  so it's *both* the 
sin^4 *and* the 1/k^4 is used.  the 1/k^4 thing is needed for the power 
of all those images to add up to a decent finite number.  but it's the 
sin() that puts a stake in the heart of the image and that is 
quantitatively quite useful.


--

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] [admin] list etiquette

[robert bristow-johnson]

On 8/28/15 9:23 AM, Peter S wrote:

You're speaking about an event that happened in the past.


it appears to be ongoing.


Which has
nothing to do with the present, or the future, or the accessibility
of this mailing list.

You can learn from the mistakes or faults of others, can't you? For
example, if someone wants to construct a windowed sinc FIR filter with
20,000 coefficients, it can be useful to learn *why* that idea is not
the best. Without pointing out to *why* that idea may fail, you cannot
learn from it, can you?


Peter, we're not learning anything from you.  at least i'm not.

(and it isn't because i think you have *nothing* intellectually to 
offer, but because i think you have far less to offer than you 
ostensibly have been offering.)



we all have finite time and bandwidth (ergo, a finite time-bandwidth 
product).  i, for one, will not engage in a fruitless debate or 
dick-wagging exercises.  i don't even have any time for that, much less 
the rest of the guys here who actually work on this stuff.



--

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] Compensate for interpolation high frequency signal loss

[robert bristow-johnson]

On 8/25/15 7:08 PM, Ethan Duni wrote:
if you can, with optimal coefficients designed with the tool of your 
choice, so i am ignoring any images between B and Nyquist-B, upsample 
by 512x and then do linear interpolation between adjacent samples for 
continuous-time interpolation, you can show that it's something like 
12 dB S/N per octave of oversampling plus another 12 dB.  that's 120 
dB.  that's how i got to 512x.


Wait, where does the extra 12dB come from? Seems like it should just 
be 12dB per octave of oversampling. What am I missing?


okay, this is painful.  in our 2-decade old paper, Duane and i did this 
theoretical approximation analysis for drop-sample interpolation, and i 
did it myself for linear, but we did not put in the math for linear 
interpolation in the paper.


so, to satisfy Nyquist (or Shannon or Whittaker or the Russian guy) the 
sample rate Fs must exceed 2B which is twice the bandwidth.  the 
oversampling ratio is defined to be Fs/(2B).  and in octaves it is 
log2(Fs/(2B)).  all frequencies in your baseband satisfy |f|B and if 
it's highly oversampled, 2B  Fs.


now, i'm gonna assume that Fs is so much (like 512x) greater than 2B 
that i will assume the attenuation due to the sinc^2 for |f|B is 
negligible.  i will assume that the spectrum between -B and +B is 
uniformly flat (that's not quite worst case, but it's worser case than 
what music, in the bottom 5 or 6 octaves, is).  so given a unit height 
on that uniform power spectrum, the energy will be 2B.


so, the k-th image (where k is not 0) will have a zero of the sinc^2 
function going right through the heart of it.  that's what's gonna kill 
the son-of-a-bitch.  the energy of that image is:



   k*Fs+B
 integral{ (sinc(f/Fs))^4 df }
   k*Fs-B


since it's power spectrum it's sinc^4 for linear and sinc^2 for 
drop-sample interpolation.


changing the variable of integration


   +B
 integral{ (sinc((k*Fs+f)/Fs))^4 df }
   -B



   +B
 integral{ (sinc(k+f/Fs))^4 df }
   -B



 sinc(k+f/Fs) =  sin(pi*(k+f/Fs))/(pi*(k+f/Fs))

  =  (-1)^k * sin(pi*f/Fs)/(pi*(k+f/Fs))

  =approx  (-1)^k  *  (pi*f/Fs)/(pi*k)

  since  |f|  B  Fs

raising to the 4th power gets rid of the toggling polarity.  so now it's

+B
 1/(k*Fs)^4 * integral{ f^4 df }  =  (2/5)/(k*Fs)^4 * B^5
-B


now you have to sum up the energies of all of the bad images (we are 
assuming that *all* of those images, *after* they are beaten down, will 
somehow fall into the baseband during resampling and their energies will 
team up).  there are both negative and positive frequency images to add 
up.  (but we don't add up the energy from the image at the baseband, 
that's the good image.)


+inf   +inf
2 * SUM{ (2/5)/(k*Fs)^4 * B^5 }  =  B*(4/5)*(B/Fs)^4 * SUM{1/k^4}
k=1k=1


the summation on the right is (pi^4)/90

so the energy of all of the nasty images (after being beaten down due to 
the application of the sinc^2 that comes from linear interpolation 
between the subsamples) is


   B*(4/5)*(B/Fs)^4 * (pi^4)/90

and the  S/N ratio is 2B divided by that.

   (  (2/450) * (2B/Fs)^4 * (pi/2)^4  )^-1

in dB we use 3.01*log2() because this is an *energy* ratio, not a 
voltage ratio.


   -3.01*log2( (2/450) * (2B/Fs)^4 * (pi/2)^4 )

 =  3.01*log2(225) + 12.04*log2(2/pi)  +  12.04*log2( Fs/(2B) )

 =  15.6 dB  +  (12.04 dB) * log2( Fs/(2B) )


so, it seems to come out a little more than 12 dB.  i think Duane did a 
better empirical analysis and he got it slightly less.


but, using linear interpolation between subsamples, you should get about 
12 dB of S/N for every octave of oversampling plus 15 dB more.





but the difference in price in memory only, *not* in computational burden.

Well, you don't get the full cost in computational burden since you 
can skip computing most of the upsamples.


exactly and it's the same whether you upsample by 32x or 512x.  but 
upsampling by 512x will cost 8 times the memory to store coefficients.


But the complexity still goes up with increasing oversampling factor 
since the interpolation filter needs to get longer and longer, no?


no.  that deals with a different issue, in my opinion.  the oversampling 
ratio determines the number of discrete (and uniformly spaced) 
fractional delays.  there is one FIR filter for each fractional delay.  
the number of coefs in the FIR filter is a performance issue regarding 
how well you're gonna beat down them images in between baseband and the 
next *oversampled* image.  in the analysis above, i am assuming all of 
those in-between images are beaten down to zero.  it's a crude analysis 
and i just wanted to see what the linear interpolation (on the upsampled 
signal) does for us.


So there is some balancing of computational 

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

[robert bristow-johnson]

On 8/24/15 11:18 AM, Sampo Syreeni wrote:

On 2015-08-19, Ethan Duni wrote:

and it doesn't require a table of coefficients, like doing 
higher-order Lagrange or Hermite would.


Robert I think this is where you lost me. Wasn't the premise that memory
was cheap, so we can store a big prototype FIR for high quality 512x
oversampling?


that was my premise for using linear interpolation *between* adjacent 
oversampled (by 512x) samples.  if you can, with optimal coefficients 
designed with the tool of your choice, so i am ignoring any images 
between B and Nyquist-B, upsample by 512x and then do linear 
interpolation between adjacent samples for continuous-time 
interpolation, you can show that it's something like 12 dB S/N per 
octave of oversampling plus another 12 dB.  that's 120 dB.  that's how i 
got to 512x.  some apps where you might care less about inharmonic 
energy from images folding over (a.k.a. aliasing), you might not need 
to go that high of whatever-x.


but the difference in price in memory only, *not* in computational 
burden.  whether it's 64x or 512x, the computational cost is separating 
the index into integer and fractional parts, using the integer part to 
select the N samples to combine and the fractional part to tell you how 
to combine them.  if it's 512x, the fractional part is broken up into 
the top 9 bits to select your N coefficients (and the neighboring set of 
N coefficients) and the rest of the bits are for the linear 
interpolation.  with only the cost of a few K of words (i remember the 
days when 4K was a lotta memory :-), you can get to arbitrarily good 
with the cost of 2N+1 MAC instructions.


with drop-sample interpolation between fractional delays (6 dB per 
octave of oversampling), then you need another 10 octaves of 
oversampling, 512K*N words of memory, but only N MAC instructions per 
output sample.


when it's using Hermite or Lagrange then the S/N is 24 dB per octave of 
oversampling, i don't think it's worth it that you need only 16x or 32x 
oversampling (that saves only memory and the cost of computation becomes 
4 times worse or worser).  maybe in an ASIC or an FPGA, but in DSP code 
or regular-old software, i don't see the advantage of cubic or 
higher-order interpolation unless memory is *really* tight and you gotta 
lotta MIPs to burn.




In my (admittedly limited) experience these sorts of tradeoffs come 
when you need to resample generally, so not just downwards from the 
original sample rate but upwards as well, and you're doing it all on a 
dedicated DSP chip.


In that case, when your interpolator approaches and goes beyond the 
Nyquist frequency of the original sample, you need longer and longer 
approximations of the sinc(x) response,


you need that to get sharper and sharper brick-wall LPFs to whack those 
511 images in between the baseband and 512x.


then the sinc^2 function in the linear interpolation blasts the hell 
outa all them images that are at multiples of 512x (except the 0th 
multiple of course).  drop-sample interpolation would have only a sinc 
function doing it whereas and Mth-order B-spline would have a sinc^(M+1) 
function really blasting the hell outa them images.


with wonkier and wonkier recursion formulas for online calculation of 
the coefficients of the interpolating polynomial. Simply because of 
aliasing suppression, and because you'd like to calculate the 
coefficients on the fly to save on memory bandwidth.


However, if you suitably resample both in the output sampling 
frequency and in the incoming one, you're left with some margin as far 
as the interpolator goes, and it's always working downwards, so that 
it doesn't actually have to do aliasing suppression. An arbitrary low 
order polynomial is easier to calculate on the fly, then.


The crucial part on dedicated DSP chips is that they can generate 
radix-2 FFT coefficients basically for free, with no table lookup


yeah, but you get accumulated errors as you compute the twiddle factors 
on-the-fly.  either in linear or bit-reversed order.


and severely accelerated inline computation as well. That means that 
you can implement both the input and the output side 
anti-aliasing/anti-imaging filters via polyphase Fourier methods,


the way that Bob Adams did it, with a single side (the input side) was 
to step through the sinc-like LPF impulse response at smaller steps (and 
interpolate) to LPF the input further for down-sampling.


admittedly, i haven't worried about the natural foldover from 
downsampling and just assume there wasn't stuff below the original 
Nyquist that you had to worry about.  or maybe my optimal filter kernel 
started to whack stuff at a frequency below 20 kHz.  but i didn't change 
it for downsampling.  i guess i was lazy.


for much less effort than the intervening arbitrary interpolation step 
would ever require. When you do that right, the code is still rather 
complex since it needs to dynamically mipmap the input sample for 
larger 

Re: [music-dsp] [admin] list etiquette

[robert bristow-johnson]

On 8/23/15 7:32 AM, Peter S wrote:

Well, no thanks. I don't think that would work out well.
I'll rather keep my thoughts to myself.


hey Peter, why don't you come over to the USENET newsgroup comp.dsp and 
see how nice we are there.


one interesting Russian-American, Vlad, might engage you, but the sad 
thing is that he passed away very recently.


BTW, people who know me, both here and there (and within the Audio 
Engineering Society), know that i grind axes too.  don't think that i 
don't understand you even while i am selective in what i respond to.



--

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

[robert bristow-johnson]

On 8/19/15 1:43 PM, Peter S wrote:

On 19/08/2015, Ethan Duniethan.d...@gmail.com  wrote:

But why would you constrain yourself to use first-order linear
interpolation?

Because it's computationally very cheap?


and it doesn't require a table of coefficients, like doing higher-order 
Lagrange or Hermite would.



The oversampler itself is going to be a much higher order
linear interpolator. So it seems strange to pour resources into that

Linear interpolation needs very little computation, compared to most
other types of interpolation. So I do not consider the idea of using
linear interpolation for higher stages of oversampling strange at all.
The higher the oversampling, the more optimal it is to use linear in
the higher stages.



here, again, is where Peter and i are on the same page.


So heavy oversampling seems strange, unless there's some hard
constraint forcing you to use a first-order interpolator.

The hard constraint is CPU usage, which is higher in all other types
of interpolators.



for plugins or embedded systems with a CPU-like core, computation burden 
is more of a cost issue than memory used.  but there are other embedded 
DSP situations where we are counting every word used.  8 years ago, i 
was working with a chip that offered for each processing block 8 
instructions (there were multiple moves, 1 multiply, and 1 addition that 
could be done in a single instruction), 1 state (or 2 states, if you 
count the output as a state) and 4 scratch registers.  that's all i 
had.  ain't no table of coefficients to look up.  in that case memory is 
way more important than wasting a few instructions recomputing numbers 
that you might otherwise just look up.





--

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] Mails with images?

[robert bristow-johnson]

On 8/18/15 6:15 AM, STEFFAN DIEDRICHSEN wrote:

As it seems, it’s not a technical hurdle.



yay!!!

now let's see if we can get some LaTeX math markup going here and we'll 
have somethin... (other than Stack Exchange).


--

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

[robert bristow-johnson]

On 8/18/15 4:28 PM, Peter S wrote:


1, -1, 1, -1, 1, -1 ... is a proper bandlimited signal,
and contains no aliasing. That's the maximal allowed frequency without
any aliasing.


well Peter, here again is where you overreach.  assuming, without loss 
of generality that the sampling period is 1, the continuous-time signals



   x(t)  =  1/cos(theta) * cos(pi*t + theta)

are all aliases for the signal described above (and incorrectly as 
contain[ing] no aliasing).


--

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

[robert bristow-johnson]

On 8/18/15 4:50 PM, Nigel Redmon wrote:

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

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


i will try to spell out my point.

there are probably a zillion applications of fractional-sample 
interpolation.  Vesa Valimaki's IEEE article Splitting the Unit Delay 
from the 90s is sorta equivalently seminal as fred harris's classic 
windowing paper about this.


but, within the zillion of applications, i can think of two classes of 
application in which all applications will fall into one or the other:


  1.  slowly-varying (or constant) delay with a fractional component.   
this would be a precision delay we might use to time-align things (like 
speakers) or for effects like flanging or to compensate for the delay of 
some other component like a filter.


  2.  rapidly-varying delay (again with a fractional component).  this 
would be sample-rate-conversion (SRC), resampling sound files, pitch 
shifting (either the splicing thing a Harmonizer might do or the 
sample-playback and looping a sampler might do), and wild-assed delay 
effects.


it's only in the second class of application that i think the sinc^2 
frequency rolloff (assuming linear interpolation) is a valid model (or 
hand-wavy approximation of a model).


in the first class of application, i think the model should be what you 
get if the delay was constant.  for linear interpolation, if you are a 
delayed by 3.5 samples and you keep that delay constant, the transfer 
function is


   H(z)  =  (1/2)*(1 + z^-1)*z^-3

that filter goes to -inf dB as omega gets closer to pi.

--

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

[robert bristow-johnson]

On 8/18/15 5:01 PM, Emily Litella wrote:

... Never mind.



too late.

:-)

--

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

[robert bristow-johnson]

On 8/18/15 3:44 PM, Ethan Duni wrote:
Assume you have a Nyquist frequency square wave: 1, -1, 1, -1, 1, -1, 
1, -1...


The sampling theorem requires that all frequencies be *below* the 
Nyquist frequency. Sampling signals at exactly the Nyquist frequency 
is an edge case that sort-of works in some limited special cases, but 
there is no expectation that digital processing of such a signal is 
going to work properly in general.


But even given that, the interpolator outputting the zero signal in 
that case is exactly correct. That's what you would have gotten if 
you'd sampled the same sine wave (*not* square wave - that would imply 
frequencies above Nyquist) with a half-sample offset from the 1, -1, 
1, -1, ... case. The incorrect behavior arises when you try to go in 
the other direction (i.e., apply a second half-sample delay), and you 
still get only DC.


But, again, that doesn't really say anything about interpolation. It 
just says that you sampled the signal improperly in the first place, 
and so digital processing can't be relied upon to work appropriately.




as suprizing as it may first appear, i think Peter S and me are totally 
on the same page here.


regarding *linear* interpolation, *if* you use linear interpolation in a 
precision delay (an LTI thingie, or at least quasi-time-invariant) and 
you delay by some integer + 1/2 sample, the filter you get has 
coefficients and transfer function


   H(z) =  (1/2)*(1 + z^-1)*z^-N

(where N is the integer part of the delay).

the gain of that filter, as you approach Nyquist, approaches -inf dB.

*my* point is that as the delay slowly slides from a integer number of 
samples, where the transfer function is


   H(z) = z^-N

to the integer + 1/2 sample (with gain above), this linear but 
time-variant system is going to sound like there is a LPF getting segued in.


this, for me, is enough to decide never to use solely linear 
interpolation for a modulateable delay widget.  if i vary delay, i want 
only the delay to change.  and i would prefer if the delay was the same 
for all frequencies, which makes the APF fractional delay thingie 
problematic.


bestest,

r b-j



On Tue, Aug 18, 2015 at 1:40 AM, Peter S peter.schoffhau...@gmail.com 
mailto:peter.schoffhau...@gmail.com wrote:


On 18/08/2015, Nigel Redmon earle...@earlevel.com
mailto: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)



--

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

[robert bristow-johnson]

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

[robert bristow-johnson]

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

[robert bristow-johnson]

On 8/16/15 4:09 AM, Sham Beam wrote:

Hi,

Is it possible to use a filter to compensate for high frequency signal 
loss due to interpolation? For example linear or hermite interpolation.


Are there any papers that detail what such a filter might look like?



besides the well-known sinc^2 rolloff that comes with linear 
interpolation, this paper discussed interpolation using higher-order 
B-splines.


Udo Zölzer and Thomas Bolze, Interpolation Algorithms: Theory and 
Application, http://www.aes.org/e-lib/browse.cfm?elib=6334 .  i thought 
i had a copy of it, Duane Wise and i referenced the paper in our 
2-decade-old paper about different polynomial interpolation effects and 
which were better for what.  (you can have a .pdf of that paper if you 
want.)


but Zölzer and Bolze (they might be hanging out on this list, i was 
pleasantly surprized to see JOS post here recently) *do* discuss 
pre-compensation of high-frequency rolloff due to interpolation 
polynomials that cause such rolloff.  you just design a filter (using 
MATLAB or whatever) that has magnitude response that is, in the 
frequency band of interest, approximately the reciprocal of the rolloff 
effect from the interpolation.


Zölzer and Bolze suggested Nth-order B-spline without really justifying 
why that is better than other polynomial kernels such as Lagrange or 
Hermite.  the Nth-order B-spline (at least how it was shown in their 
paper), is what you get when you convolve N unit-rectangular functions 
with each other (or N zero-order holds).  the frequency response of a 
Nth-order B-spline is sinc^(N+1).  this puts really deep and wide 
notches at integer multiples of the original sampling frequency (other 
than the integer 0) which is where all those images are that you want to 
kill.  linear interpolation is all of a 1st-order Lagrange, a 1st-order 
Hermite, and a 1st-order B-spline (and the ZOH or drop-sample 
interpolation is a 0th-order realization of those three).


an Nth-order polynomial interpolator will have, somewhere in the 
frequency response, a H(f) = (sinc(f/Fs))^(N+1) in there, but if it's 
not the simple B-spline, there will be lower order terms of sinc() that 
will add to (contaminate) the highest order sinc^(N+1) and make those 
notches less wide.  any other polynomial interpolation (at higher order 
than 1), will have at least one sinc() term with lower order than N+1.


so the cool thing about interpolating with B-splines is that it kills 
the images (which become aliases when you resample) the most, but it 
also has wicked LPFing that needs to be compensated unless your sampling 
frequency is *much* higher than twice the bandwidth (oversampled 
big-time).  but if you *are* experiencing that LPFing, as you have 
suspected, you can design a filter to undo that for much of the 
baseband.  not all of it.


--

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] Non-linearity or filtering

[robert bristow-johnson]

On 8/10/15 10:02 AM, Peter S wrote:

On 10/08/2015, robert bristow-johnsonr...@audioimagination.com  wrote:

the thing that i *think* Peter is missing in this is the same as some of
the early manufacturers when they truncated the 30-bit words (or
whatever they had in the decimation filters) to 18 meaningful bits.
that simply adds one more source of quantization noise. and, especially
when our DSPs were 24 bits or more, we could make use of those bits.
i'd much rather have a 24-bit word, even if the dynamic range divided by
6.02 is only 18 or 20.

Are you *sure* truncating adds extra quantization noise?


  [sigma-delta modulator][decimation filter][quantizer]---

adds extra quantization noise to:

  [sigma-delta modulator][decimation filter]


  When the
lowest bits are already noise,


they're not completely noise.  they are signal buried in noise.

try this:  take a flute solo or some other monophonic lick and fade it 
down by a rate of, i dunno, 3 dB per second.  eventually it will hit 
your quantization floor.  do that and tell us you can't hear a 
difference.  there will be a point where the quantized output will be 
buzzing because your flute solo has become a square wave and then 
silence, but in the unquantized version, you can still hear it (but it's 
buried in noise of some spectral shape).


a way to *really* hear it is to compute the net error signal (output 
minus input) and listen to that.  and boost the error signal by 40 dB 
just so that you can scrutinize the difference.  i have some old .wav 
files and MATLAB code for you (and a powerpoint from 2008 that spells it 
out).


there is no reason to bother zeroing those bottom 4 or 6 or 8 bits (if 
your normal word width is 24 bits).  give the DSP whatever word width is 
natural for the DSP.  those bouncing bottom bits are actually useful for 
most audio DSP processing.  sometimes we have to *add* dither to the 
input so that non-linear breakpoints get to be a little rounded.  i 
would much rather have the *less* noisy input that also has the least 
significant bits bouncing around keeping them discontinuities (like 
internal clipping or quantization) in my algorithm in check.


another common experiment: reduce your amplitude by a factor of 
32767/32768, quantize to the word size, then bump it back up with the 
reciprocal factor.  and subtract the original and listen to the error 
signal boosted by 40 dB.



  I highly doubt that truncation would
add harmonic distortion or limit cycle oscillations. I tested the
difference, and if the noise floor is high enough, in blind ABX tests,
I personally hear no difference between the non-truncated and the
truncated signal (whatever bit depth).

Have you measured the difference? Do you actually hear the difference?
Can your ear distinguish between the two in blind listening tests?
Mine doesn't, and my analysis shows no difference in harmonic
distortion, so I believe that those lowest, discarded bits of noise
practically add nothing to the signal, and they can be discarded
without any loss of quality or any introduced artifacts.

That's my belief, and I base this on analysis and blind ABX listening
tests between the two.



i have a better idea (it's also what we should force the Monster Cable 
folks to do, or maybe the DSD folks):


AB testing.  the subject is asked to determine if A and B are the same 
or different.  have as many trials where A and B are identical as trials 
where they are different.  remove any bias from the subjects by 
subtracting the number of false positives from the number of times the 
subject correctly identifies a positive.  same for false negatives.  
then see if the subjects do better than random guessing.



there is *still* a part of your signal in those bottom 6 bits.  why
ditch them?

Because adding further bits of noise add no perceptional difference.


you didn't say anything about the audio level.  if you claim this for 
*any* level of audio, including audio that is going down into the noise 
floor, you're decidedly mistaken.




--

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] [ot] about entropy encoding

[robert bristow-johnson]

On 8/9/15 5:07 PM, Sampo Syreeni wrote:

On 2015-07-18, robert bristow-johnson wrote:

even so, Shannon information theory is sorta static. it does not deal 
with the kind of redundancy of a repeated symbol or string.


In fact it does so fully,


really?  like run-length encoding?

and i've always thunk that the data reduction that you get with LPC (to 
reduce the word size) that depends on the spectrum of the data was a 
different thing that Shannon information theory was looking at that 
might lead to Huffman coding.


and I believe Peter's problem is about not figuring out how it does 
this. (Sorry about arriving at this this late and reviving a heated 
thread.)


The basic Shannonian framework works on top of a single, structureless 
probability space.


yes, and you can model dependent probabilities, i s'pose.  so you can 
put together compound messages that have less information needed to 
represent them than you might have if they're separate.



Any message sent is a *single* word from that space with a given a 
priori probability, and the information it conveys is inversely 
related to the probability of the symbol. Thus, the basic framework is 
that we're computing the probabilities and the resulting information 
based on *entire* signals being the symbols that we send.


Shannon entropy is then revolutionary because under certain conditions 
it allows us to decompose the space into smaller parts. If the entire 
signal can be broken down into Cartesian product of separate, 
*independent* part signals, the whole information content of the 
signal can be calculated from the partwise surprisals. That's how the 
uniqueness of the entropy measure is proven: if you want the 
information in the parts to sum to the information of the whole, and 
each part's information content is obviously related to the number of 
combinations of values they can take, then the only measure can be a 
logarithm of probabilities. At the bottom that's a simple homomorphism 
argument: there is no homomorphism from products to sums other than 
the logarithm.


But notice that there was an independence assumption there. If you 
plan to decompose your signal into smaller parts, Shannon's formula of 
additive entropy only holds if the parts don't affect each other. With 
periodic signals this assumption is violated maximally, by assumption: 
every period is the same, so that a single period correspond to the 
entire signal. For the purposes of talking about the entire signal and 
its entropy, you only ever need one period, and the underlying 
probability it varies within.


one thing that makes this encoding thing difficult is deciding how to 
communicate to the receiver the data that the signal is close to 
periodic and what the period is.  and when that changes, how to 
communicate something different.  it's the issue of how to define your 
codebook and whether the receiver knows about it in advance or not.  you 
could have a variety of different codebooks established in advance, and 
then send a single short word to tell the receiver which codebook to 
use.  maybe for non-white signals, the LPC coefs for that neighborhood 
of audio.




More generally, if there are any statistical correlations between the 
decomposed parts of any entire signal, they'll in a certain 
probabilistic sense mean that the entire symbol space is more limited 
than it would at first seem, and/or that its probability distribution 
clumps further away from being the flat, maximum entropy distribution 
Shannon's machinery first expects. The surprisal of the whole thing is 
lowered.


In limine you could have *any* signal *at all*, but always sent with 
100% certainty: when you saw it, its surprisal would be precisely 
zero. That's the trivial case of the underlying probability space for 
the entire signal being composed of a single message with probability 
1, *whatever* that one signal might be.


Peter's problem then seems to be that he doesn't specify that 
underlying probability space nor state his assumptions fully. He 
calculates on signals as though their successive part-symbols or 
periods were independent, as if Shannon's decomposition worked. But 
between the line he assumes that signals coming from an entirely 
different kind of, far more correlated-between-his-chosen-partition 
were an equal option.


Obviously that leads to teeth grinding and misery, because it isn't 
even mathematically coherent.


just with the probability of occurrence (which is measured from the 
relative frequency of occurrence) of messages. run-length coding 
isn't in there. maybe there is something in Shannon information 
theory about information measure with conditional probability (that 
might obviate what LPC can do to compress data).


In fact LPC and every other DSP transformation we use in codecs are 
well within Shannon's framework.


i didn't know that.  it appears to me to be different, almost orthogonal 
to the Shannon thing.


There, the basic message

Re: [music-dsp] Non-linearity or filtering

[robert bristow-johnson]

 was resting on top of a quantization level.  you're not 
decoupling the 2nd moment from the input.  even with subtractive 
dither.  maybe there's something i'm missing.


and at the same time has minimum power, amplitude, all of the dual 
measurables. ;)


5) dithering is usually placed inside the feedback loop of the noise 
shaping (One criticism of the 1 bit converter [...] is that because 
only 1 bit is used in both the signal and the feedback loop, adequate 
amounts of dither cannot be used in the feedback loop and distortion 
can be heard under some conditions.)


Yes, that's the Lipshitz and Vanderkooy critique which killed one bit 
converters and there by Sony's naïve DSP implemenation, already. Now 
they use multibit converters with a bit of headroom, which makes the 
dithered delta-sigma loop immune to the argument. Also to the early 
MASH-papers. Plus the Sony failing has lead to converters which 
optimize algebraically, with the theory then being applied to usual 
baseband oriented delta-sigma loops, with deterministic error bounds.


Failure to understand dithering will result in failure to understand 
noise shaping, since noise shaping is almost exclusively used 
together with dithering (= adding noise to the signal).


So it does, and you just forgot to make the distinction between dither 
introduced within the coding loop and in its input.


Now, what is *really* interesting and germane to your point about 
noise floors and converter depths is that you didn't make a proper 
distinction between input thermal noise floor and the noise induced by 
the delta-sigma coding loop. This is crucial, because only one of them 
is really noise: the input floor.


What the (undithered) loop does is completely different: it introduces 
all kinds of wild modulation phenomena which are only *modelled* as 
noise of certain power. If you do not suppress those over the utility 
band, you can get the funniest whines, or even free running limit 
cycle oscillations with enough power and harmonic content to be heard 
from -30dB below the noise floor. Especially you can get harmonics 
production from stuff similarly far down below the input noise floor.


That is then the reason you want to make your ADC and DAC much better 
than the prevailing noise floor: we can hear stuff there, to at least 
something like -20dB, and we don't want the modulator loop to fuck 
that stuff up. It will, unless its specs are down there as well.


Not to mention some of those wonky edge case signals, like the one 
Robert Bristow-Johnson mentioned just a couple of months ago, the 
DAC-designer's nightmare: ..., +1, -1, +1, +1, -1, +1, ... Even if 
you bury something like that well within noise, it's going to pop up 
upon proper reconstruction, and not pop up if you fucked up your 
modulator loop.


So, there are several reasons to engineer for below input noise floor 
purity. Don't neglect them.



...

Beyond that, Peter, I actually agree with you. 24 bits is beyond what 
we can dissolve.


the thing that i *think* Peter is missing in this is the same as some of 
the early manufacturers when they truncated the 30-bit words (or 
whatever they had in the decimation filters) to 18 meaningful bits.  
that simply adds one more source of quantization noise.  and, especially 
when our DSPs were 24 bits or more, we could make use of those bits.  
i'd much rather have a 24-bit word, even if the dynamic range divided by 
6.02 is only 18 or 20.


there is *still* a part of your signal in those bottom 6 bits.  why 
ditch them?


In fact I'd go with the Acoustic Renaissance for Audio paper which 
argues that a properly executed, noise shaped, 55kHz @~ 18bpS ought to 
be enough. 
https://www.meridian-audio.com/meridian-uploads/ara/araconta.htm#precision 
.


not much more than 44.1 16-bit.



But it then has to be proper as hell, and many practicalities come on 
the way. Even that paper I mentioned -- one of the most high minded 
I've *ever* seen in the field -- actually backs down to something 
besides the ideal. Because it's not just audio theory, it's about 
practicable solutions as well.


I think you ought to be thinking about the same for a change. ;)


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



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

Re: [music-dsp] Non-linearity or filtering

[robert bristow-johnson]

On 7/25/15 10:57 AM, Tom Duffy wrote:

You didn't change the bandwidth.

If the target signal is max 30Hz and you have a 192kHz sampler, you 
low pass

at 2x your max frequency (60Hz, but lets say 100Hz for convenience) using
a brick wall digital filter (processed at 192kHz).   Then you do a 
downsampling

of the signal from 192kHz to 100Hz.   Then you end up with lower noise
on the 30Hz signal,  but you need to play it back with a 100Hz DAC.



but you can virtually noiselessly upsample it back up to 192 kHz.

just the LPF (done at 192 kHz) is enough to lower the noise on the 30 Hz 
bandlimited signal.


and that's not counting noise-shaping.


On 7/25/15 3:25 AM, Peter S wrote:

Okay, a few more thoughts:

On 23/07/2015, robert bristow-johnsonr...@audioimagination.com  wrote:

okay, since there is no processing, just passing the signal from A/D to
D/A converter, there is only one quantization operation, at the A/D.

That's only true *if* it's a non-dithered converter (read: a converter
from the previous century).


if it's properly
dithered, the error will be well described as noise that's white with
DC=0 and AC power decoupled from the input value.

Seems the conceptual misunderstanding here is that dithering does not
mean that the error is described as noise.


oh dear.  that's the whole point of it.

do you understand what the difference between rectangular pdf dither and 
triangular pdf dither?  what it does to the quantization signal?  the 
whole purpose is to take whatever nasty non-linearity (which a staircase 
function is) and turn it into something that is white (or bandlimited 
white), and with it's first two moments decoupled from the value of the 
input signal.



  Rather, dithering means
that we deliberately *add* noise to the signal (because that has
advantages, see the literature).


sigh



--

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] The Art of VA Filter Design book revision 1.1.0

[robert bristow-johnson]

hey Vadim,

i love the rigor in your paper.  i'm still looking through it.

in the 2nd-order analog filters, i might suggest replacing 2R with 1/Q 
in all of your equations, text, and figures because Q is a notation and 
parameter much more commonly used and referred to in either the EE or 
audio/music-dsp contexts.


in section 3.2, i would replace n0-1 with n0 (which means replacing n0 
with n0+1 in the bottom limit of the summation).  let t0 correspond 
directly with n0.


now even though it is ostensibly obvious on page 40, somewhere (and 
maybe i just missed it) you should be explicit in identifying the 
trapezoidal integrator with the BLT integrator.  you intimate that 
such is the case, but i can't see where you say so directly.


section 3.9 is about pre-warping the cutoff frequency, which is of 
course oft treated in textbooks regarding the BLT.  it turns out that 
any *single* frequency (for each degree of freedom or knob) can be 
prewarped, not only or specifically the cutoff.  in 2nd-order system, 
you have two independent degrees of freedom that can, in a BPF, be 
expressed as two frequencies (both left and right bandedges).  you might 
want to consider pre-warping both, or alternatively, pre-warping the 
bandwidth defined by both bandedges.


lastly, i know this was a little bit of a sore point before (i can't 
remember if it was you also that was involved with the little tiff i had 
with Andrew Simper), but as depicted on Fig. 3-18, any purported 
zero-delay feedback using this trapezoidal or BLT integrator does get 
resolved (as you put it) into a form where there truly is no 
zero-delay feedback.  a resolved zero-delay feedback really isn't a 
zero-delay feedback at all.  the paths that actually feedback come from 
the output end of a delay element.  the structure in Fig 3-18 can be 
transposed into a simple 1st-order direct form that would be clear *not* 
having zero-delay feedback (but there is some zero-delay feedforward, 
which has never been a problem).


i'll be looking this over more closely, but these are my first 
impressions.  i hope you don't mind the review (that was not explicitly 
asked for).


L8r,

r b-j


On 7/24/15 6:58 AM, Vadim Zavalishin wrote:

Released the promised bugfix
http://www.native-instruments.com/fileadmin/ni_media/downloads/pdf/VAFilterDesign_1.1.1.pdf 



On 22-Jun-15 10:51, Vadim Zavalishin wrote:

Didn't realize I was answering a personal rather than a list email, so
I'm forwarding here the piece of information which was supposed to go to
the list:

While we are on the topic of the book, I have to mention that I found
the bug in the Hilbert transformer cutoff formulas 7.42 and 7.43. Tried
to merge odd and even orders into a more simple formula and introduced
several mistakes. The necessary corrections are (if I didn't do another
mistake again ;) )
- the sign in front of each occurence of sn must be flipped
- x=(4n+2+(-1)^N)*K(k)/N
- the stable poles are given by nN/2 for N even and n(N+1)/2 for N 
odd.


I plan to release a bugfix update, but want to wait for possibly more
bugs being discovered.

Regards,
Vadim







--

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] Non-linearity or filtering

[robert bristow-johnson]

On 7/23/15 4:38 PM, Peter S wrote:


...


 https://en.wikipedia.org/wiki/The_Paradox_of_Choice


You're welcome.


 http://www.imdb.com/title/tt1386011/


--

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] Non-linearity or filtering

[robert bristow-johnson]

On 7/23/15 1:12 AM, Peter S wrote:

On 23/07/2015, robert bristow-johnsonr...@audioimagination.com  wrote:

okay, since there is no processing, just passing the signal from A/D to
D/A converter, there is only one quantization operation, at the A/D. if
it's an old-fashioned conventional A/D, the quantization operation is,
essentially, a non-linear staircase operation and the error is a
measurable and then predictable function of the input. if it's properly
dithered, the error will be well described as noise that's white with
DC=0 and AC power decoupled from the input value. with noise-shaping,
the noise wouldn't have to be white, but the AC power level would
increase. sigma-delta (Σ-Δ or Δ-Σ) converters might have a similar
signal+noise model. that's N1.

Let me point out to some very important detail that you've just missed
- I was not talking about quantization noise at *all*. I implied that
in the clause among other noises, without giving any detail about
quantization noise _whatsover_.


well, then you're missing something.  that's the main noise.  if it 
ain't, then the hardware design is dirty.


and what i was missing is semiconductor noise or whatever crap we get 
from dirty power supplies and the like.  i am leaving that to the 
circuit designer and layout designer.


if one is trying to model the A/D and D/A as a wire, and trying to 
subtract the input from the output to see the error, while delay might 
be something to worry about, semiconductor noise is *not* what i would 
worry about.  if i had to worry about it, there is something else deeply 
wrong in the hardware circuit.



  I was talking about the noise _floor_,
which is a remarkably different type of noise.



sigh



If you have any converter and plug in some cable, without any actual
input/output,


you mean an open circuit on the other end of the cable?


  what you'll measure is *noise* (both on the ADC and the DAC).


well, there's hum and there's noise.  not the same thing.

if the hum, due to a floating open circuit, isn't bad then the major 
component of noise you should be seeing is the actual quantization noise 
of the A/D and if the D/A is also sigma delta, there is another noise 
source there.  and this noise has a numerical root.



  I was talking about _that_ (noise floor), not the noise from the
quantization.


better look up sigma-delta converters.


  Yes, there's *also* quantization noise, which I was not
even mentioning at all, so it's not in the formulas that I wrote,
which would be:

 S + N1 + Q1 + N2 + Q2

where Q1 and Q2 are the _quantization_ noise from the ADC and DAC, and
N1/N2 are the noise from the noise _floor_ of the ADC and DAC.


more of the noise _floor_ of A/D and D/A converters comes from numerical 
operation of these 1-bit converters that from noisy analog front end 
or back end.




there *is* error at the D/A, due to non-linearity, but i wouldn't call
that noise.

There is _definitely_ a noise floor. Which is, pretty much just noise.
If you record the input of your 24 bit sound card without plugging in
*anything*, you pretty much get just noise (whatever exact
distribution, possibly depending on the noise shaping of the converter
and other factors).


and it's a function of the input.

The noise floor is definitely NOT a function of the input.


the error due to non-linearity of the A/D is a function of the input.

the noise floor, due to an open circuit, might include hum, because your 
open circuit cable might be a little antenna.


if it's a quiet short-circuited input, if the noise from the analog 
front end exceeds the noise from the converters, some might say that the 
front end needs attention.



  Even if you
have no input at all (= you plug in _nothing_), you *will* get noise
in the lowest bits of a 24-bit converter. *Irregardless* of the input.


the last statement you made is inconsistent with the no input at all 
statement.



Even using the most high-end sound cards. The lowest 3-4 bits will
*always* be noise. Feel free to test this experimentally, if you doubt
my words If there's *no* noise floor, then why don't we have
32-bit converters with near 192 dB dynamic range?


one reason is that we cannot make parts with the tolerances necessary.


  According to what
you say, just apply some noise shaping, and voila! ~192 dB dynamic
range! Yet that doesn't happen.


if the required bandwidth of the input is low enough, yes you can.  if 
you want to measure DC (if you don't have a blocking cap and your A/D 
can handle DC), you can with averaging, get to very high S/N for just DC 
and the few Hz (or tenths of Hz) around 0.  since pure DC has a very low 
bandwidth, an arbitrarily low bandwidth, you can widen the window of 
averaging to as wide as necessary and get 192 dB S/N.




   In order to be able to fix that
noise, you'd need to be able to predict that noise.

or make use of the statistics of that noise (known in advance).

You cannot use the statistics of the noise floor to 

Re: [music-dsp] Non-linearity or filtering

[robert bristow-johnson]

On 7/23/15 3:36 AM, Peter S wrote:

Also if you fail to notice that the current year is 2015, and the
rules you learned 20 years ago for 8-bit and 16-bit converters do not
necessarily apply for today's typical 24-bit converters (that usually
have several bits of noise in the lowest bits),


Peter, do you know how a sigma-delta (or delta-sigma, people don't 
always agree on the semantics) converter works?


like how a sigma-delta modulator works?  oversampling?  possible 
dithering?  noise-shaping?  decimation (involving low-pass filtering and 
downsampling)?


do you have any idea what i am talking about (or writing about)?

it's you that are applying concepts of the old or conventional 
converters here.


the *major* component of audible noise is coming from the numerical 
processes inside the codec, unless it's a conventional A/D or D/A, which 
i highly doubt in audio (but there are some expensive audio gear that 
use conventional converters and oversampling).


also, even in the least-significant bits, there is signal embedded (or 
buried) in the noise.  it's not as if they appended 4 noisy bits to the 
right of a 20-bit word.  they didn't do that.



--

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] Non-linearity or filtering

[robert bristow-johnson]

i wrote:


the *major* component of audible noise is coming from the numerical processes 
inside the codec

On 7/23/15 12:43 PM, Peter S wrote:

Seriously, where do you get that from?



well, i take it that the answer to the question i asked is no.

so there are a few docs on the web like at 
http://www.analog.com/media/en/training-seminars/tutorials/MT-022.pdf , 
but they're not necessarily all that good.


i s'pose i should be more precise.  the *major* component of audible 
noise is coming from the severe quantization that occurs at the 1-bit 
converter in the sigma-delta modulator.  but the digital processing that 
follows to filter and decimate (which also increases the word width from 
1 bit to something much wider) are the numerical processes that follow 
the 1-bit converter.  it is in this process that you start to see a 
recognizable waveform with a noisy component added to it.



Do you realize that 'dithering' basically means: adding noise?



to what end?  why do you think they would they be adding that noise?  
how would that help?



--

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

[robert bristow-johnson]

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.



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


--

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

[robert bristow-johnson]

On 7/20/15 3:00 PM, jpff wrote:

The first delay of which I was aware was in the piece Echo III played on the
viola by Tim Souster in Cambridge in the early 1970s.  Not an echo  or reverb
but a cannon.  Delay was via two reel-to-reel tape machines, with a carefully
measured distance between them.  I cannot remember if it was the band
Intermodulation or 0db, but I loved the piece.  Not heard it for decades



the first i remember was the Echoplex.  single tape loop, but one of 
the heads (i think the playback head) was on a mechanical slider.  i 
think there was a feedback gain knob.


i dunno what may have preceded that.  did Echo III precede the Echoplex?


--

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

[robert bristow-johnson]

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

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

[robert bristow-johnson]

On 7/20/15 4:52 PM, Theo Verelst wrote:

robert bristow-johnson wrote:

On 7/20/15 2:44 PM, padawa...@obiwannabe.co.uk wrote:

Whenever vintage delays come to my mind, I hear the sound of the
bucket brigade delay lines


just for the record, none of them content words were written by me.

And it's back, in the Prophet-6. I build one of those dual BBD effects 
with filters and electronics, with interesting options, with a sine 
wave LFO modulated clock to act as a Leslie effect, which was fun, 
though without noise suppression very hissy.


so it's delay modulation, which is supposed to be the Leslie?  you 
really should have a synchronous, but outa-phase, amplitude modulation 
along with the delay modulation, to emulate a Leslie.  and multiple 
reflection paths to an auditory scene (a wall or two with reflections) 
and a stereo output derived from that.


That sure is better even with a simple software delay and cheap 
built-in sound card now, even at 16 bit, a delay can work fine at CD 
quality.


My interest at some point, which got me thinking, is that certain 
synthesizers (in this case the Yamaha Motif line) have nice 
oscillators, but it isn't possible to get certain sampled waves to not 
overlay more than 1 sample, in certain cases probably the same 
waveform playing over two sample replay partial engines, with a delay 
in between. So it would be a nice idea to be able to record the signal 
of a single note, and somehow extract the one sample from the two or 
three that play at the same time, presuming they're just time shifted.


uhm, what do you mean?  do you mean that the samples for each voice are 
being played out at different sample rates and zero-order held and then 
the different voices overlay their samples coming out at different 
rates?  i might think that if you analog LPF each voice separately 
before adding them, the overlay more than 1 sample wouldn't be an issue.




I realize that's a bit tough and might involve inversions with linear 
algebra and some iterations even, but it's a fun subject. I mean so 
much going on, but simply extracting a signal in the presence of a 
delayed added version of the same signal isn't generally available!




you mean inverting the filter:

 H(s) =  1 + alpha*e^(-s*T)

where T is the delay and alpha is the relative gain of the delayed added 
version?  that can be generally done if you know T and alpha.




--

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] about entropy encoding

[robert bristow-johnson]

On 7/18/15 10:10 PM, Peter S wrote:

It follows from the above, that Shannon's entropy model is a
simplified, idealized model of information, that pretends that
algorithms have zero length and thus no entropy, and you can magically
share a codebook telepathically without actually transmitting it.



Shannon makes no issue of that.  if you need the codebook at the other 
end (because you don't already have it), you need to send it.  it's not 
so big and i have seen that in some compressed files and i am sure .zip 
files (at least the old ones, that were mostly Huffman coded but also 
had some run-length encoding in the model) have the codebook in the file 
preamble.


even so, Shannon information theory is sorta static.  it does not deal 
with the kind of redundancy of a repeated symbol or string.  just with 
the probability of occurrence (which is measured from the relative 
frequency of occurrence) of messages.  run-length coding isn't in 
there.  maybe there is something in Shannon information theory about 
information measure with conditional probability (that might obviate 
what LPC can do to compress data).


--

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] about entropy encoding

[robert bristow-johnson]

On 7/17/15 1:26 AM, Peter S wrote:

On 17/07/2015, robert bristow-johnsonr...@audioimagination.com  wrote:

in your model, is one sample (from the DSP semantic) the same as a
message (from the Information Theory semantic)?

A message can be anything - it can be a sample, a bit, a combination
of samples or bits, a set of parameters representing a square wave,
whatever.


doesn't answer my question.


is your measure the same as

  SUM{ prob(message) * -log2(prob(message)) }
 all messages

?

Yes. In this particular example, a message means a set of
parameters that describe a parametric square wave. To distinguish
between two or more messages, at least 1 bit is needed.


and this question doesn't get answered until the previous one does.

--

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] about entropy encoding

[robert bristow-johnson]

On 7/17/15 2:28 AM, Peter S wrote:

Dear Ethan,

You suggested me to be short and concise.
My kind recommendation to you:

1) Read A Mathematical Theory of Communication.
2) Try to understand Theorem 2.
3) Try to see, when p_i != 1, then H != 0.

I hope this excercise will help you grasp this topic.


listen, one thing i have to remind myself here (because if i don't, i'm 
gonna get embarrassed) is to not underestimate either the level of 
scholarship nor the level of practical experience doing things related 
to music (or at least audio) and DSP.  just a friendly caution to 
consider the same.



On 7/17/15 3:27 PM, Peter S wrote:

A linear predictor[1] tries to predict the next sample as the linear
combination of previous samples as

 x'[n] = SUM [i=1..k] a_i * x[n-i]

where x'[n] is the predicted sample, and a_1, a_2 ... a_k are the
prediction coefficients (weights). This is often called linear
predictive coding (LPC),


listen, i understand LPC.  i also understand (i remember having multiple 
email exchanges with Claude Cellier about the topic in the '90s) how to 
use LPC to reduce the word size (if the LPC is effective, the LPC guess 
for the following sample is, statistically-speaking, usually close to 
the actual sample, so the word size is smaller and the probability on 
each of those reduced-width words is higher) followed by Huffman coding 
on those often used delta values.  if you have a non-flat spectrum, LPC 
will make it flat, and if you have a non-uniform p.d.f., Huffman coding 
will similarly take advantage of that.  you can combine the two and 
tweek it to the point that the losslessly compressed file can't get much 
more compressed without adding more to the model (like periodicity, so 
that the LPC doesn't just use the most current N samples to predict the 
future sample, but also uses a bunch of samples that are P samples 
prior, where P is the best-fit period for a quasi-periodic input).  i 
know how to do that (and done MATLAB implementations, but never anything 
that saw the commercial light-of-day).


i also know how i might do it for music that is the combination of a few 
sources, if i get good pitch-detection data from a source separation 
alg, which is another big, difficult problem.


i know how to do this stuff.  i know how to teach this stuff and in a 
previous lifetime have done it.  (i like to use a recurring character of 
George Carlin: Al Sleet, the Hippy-Dippy Weatherman, to illustrate 
Shannon's use of message probability, or frequency-of-occurance as a 
natural measure of the true information content a message has.)


so be careful, lest you lose people's interest, to restrain any 
patronizing tone.  we're not as dumb as you think.


On 7/17/15 1:38 PM, Peter S wrote:

On 17/07/2015, robert bristow-johnsonr...@audioimagination.com  wrote:

On 7/17/15 1:26 AM, Peter S wrote:

On 17/07/2015, robert bristow-johnsonr...@audioimagination.com   wrote:

in your model, is one sample (from the DSP semantic) the same as a
message (from the Information Theory semantic)?

A message can be anything - it can be a sample, a bit, a combination
of samples or bits, a set of parameters representing a square wave,
whatever.

doesn't answer my question.

It does, it just depends on the model.

In the 1-bit square wave duty cycle estimator, a message is a bit.
In the English text compression experiment, a message is a character.
In the white noise entropy estimation experiment, a message is a byte.
In the binary waveform entropy experiment, a message is a string of bits.
In the bitflip counter, a message is an event that two consecutive bits differ
In the parametric squarewave thought experiment, message is a set of
parameteres describing a square wave.

Whatever arbitrarily chosen thing I send to you over a channel,
becomes a message. There's no universal definition of what a
message is, depending on the particular model, it can be literally
anything.


so here's my question(s) ... please read carefully because i'm the guy 
who gets to decide if my question really got answered, and i am still 
pretty much clueless about it:


what is the atom of information that you are counting to create a histogram?

maybe it's sophisticated, first you count every 1-bit message and create 
a two-column histogram.


then rewind the soundfile and count every 2-bit message, grouped 
adjacently and add that to the histogram.


then rewind the soundfile again and count each 3-bit message, and add 
that to the histogram.


continue to some defined word-width limit.

i can sorta see a generic measure of entropy doing that, but it assumes 
messages that are adjacent bits.  you can add to that messages that are 
grouped together in any imagined fashion, not just adjacent bits.


there are virtually uncountable ways of grouping together the bits of a 
binary file to measure entropy.  i simply cannot believe you did it 
every-which-way.


so, because i am too lazy to look around at previous posts, 

Re: [music-dsp] about entropy encoding

[robert bristow-johnson]

On 7/17/15 12:08 AM, Peter S wrote:

On 17/07/2015, Peter Speter.schoffhau...@gmail.com  wrote:

Think of it as this - if your receiver can distinguish only two
different sets of parameters, then you need to send at least *one* bit
to distinguish between them - '0' meaning square wave A, and '1'
meaning square wave B. Without sending at least a *single* bit, your
receiver cannot distinguish between square waves A and B.

It also follows that when your receiver can distinguish between
precisely two sets of parameters of nonzero probability, then in
practice, the entropy of a square wave (= parameter set) will *always*
be 1 bit. Your transmitter will always need to send *exactly* one bit
to distinguish between square wave A and square wave B,
irregardless of whatever probabilities they have.

So you need to specify a distribution [...] in order to talk about
the entropy is false - if I know that the parameters set has a size
of two (meaning two different square waves), then in practice, the
entropy will *always* be 1 bit - your transmitter will send either 0
or 1, meaning square wave A or B, for _all_ possible combination of
probabilities. In this case, the probabilities are entirely irrelevant
- you always send exactly 1 bit.

Hence, if the parameter set has a size of at least two, then you must
always send _at least_ one bit, hence, nonzero entropy, irregardless
of probability distribution. Entropy is zero _only_ if the parameter
set has a size of 1 with probability p=1.



in your model, is one sample (from the DSP semantic) the same as a 
message (from the Information Theory semantic)?


is your measure the same as

SUM{ prob(message) * -log2(prob(message)) }
   all messages

?


--

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] about entropy encoding

[robert bristow-johnson]

On 7/15/15 11:39 AM, Peter S wrote:


So far my best entropy estimator algorithm using sophisticated
correlation analysis,


i've only been following this coarsely, but did you post, either in code 
or pseudo-code the entropy estimator algorithm?  i'd be curious.



  gave entropy rate of 1 for white noise, and
between 0.0002-0.02 for perodic square waves of varying frequencies.
Based on that, getting closer to zero for a fully periodic signal in a
practical entropy estimation algorithm has limits:

- Windowing artifacts: unless the analysis window length is an exact
multiple of the period length, the truncated edges of the analysis
window will give some artifacts, making the entropy estimate nonzero
(similar to DFT windowing artifacts).

- Quantization artifacts: unless the period cycle is an integer
number, each cycle will be slightly different due to various
quantization artifacts. Unless your algorithm models that, it will
make the entropy estimate nonzero.


what if the quantization was fully dithered (TPDF dither of 2 LSBs)?  
what does your estimator do with that?



- Computational limit: I can increase the estimate precision for
periodic square waves to around 0.01-0.001 (within 0.1% error),
but then the algorithm becomes really slow. An infinite long analysis
window would need infinite computation.

- Uncertainity: how do you know that the output of some black-box
process is truly deterministic? Answer: you can't know. You can only
measure 'observed' probabilities, so the 'measured' entropy never
reaches zero in a finite amount of time.

Of course you can cheat and simply hard-code a threshold in your
algorithm, below which it just assumes that the signal is fully
deterministic, and just output zero. Where you put that threshold of
'close enough' is entirely arbitrary. (Most real-world signals are
never fully periodic, so that may be of not much use.)

I wouldn't call an entropy estimator that gives a result within 2%
error a poor estimator, despite it doesn't give zero for (seemingly)
determinisitic signals. (It's just seemingly deterministic, you can
never fully know unless you make infinite observations.) A simpler
estimate will have a different error distribution with more error.

After several experiments, I conclude: yes, you can make fairly high
precision practical entropy estimators for arbitrary signals. Where
you put the limit of good enough depends on your application. (Do
you really need an infinite long sinc kernel to reconstruct your
digital samples? Typically there's a filter that is good enough and
computable.)



so, given that a salient difference between an arbitrary signal and a 
deterministic signal is just a matter of the number of parameters one 
needs to fully describe it (like three numbers fully describe a 
sinusoid), how does you estimator know how to measure the necessary 
information content of different simple deterministic waveforms?  once 
you establish that the waveform is a triangle wave, again it doesn't 
take more than three number to fully describe it.  but how much 
information is there in encoding the waveform shape (sine vs. triangle)?


seems to me that, if the input is a perfectly periodic input with no 
assumptions regarding the number of samples per period (could be 
fractional), that a good algorithm would be able to extract from that a 
measure of information that would be the fundamental frequency (in, say, 
radians per sample), the number of the highest harmonic, and then two 
numbers per harmonic (and 1 for DC).  as the size of the analysis window 
gets larger and larger, that information should be small, compared to 
the number of samples.



--

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] Sampling theorem extension

[robert bristow-johnson]

On 6/29/15 6:43 PM, Sampo Syreeni wrote:

On 2015-06-29, Emanuel Landeholm wrote:

But all waveforms can be antialiased by brick wall filtering, ie. 
sine cardinal interpolation.


The point is that you can't represent the continuous time waveforms in 
the usual sampled form, and then apply a sinc filter. Which you need 
to do in order to synthesize them via a normal D/A converter. Instead 
you need to perform the convolution with the sinc in implicit form, 
which lands at a nice, regular, equidistantly sampled form.


*and* that has no harmonics above Nyquist before sompling at nice, 
regular, equidistantly sampling instances (or extremely reduced 
amplitudes of those harmonics exceeding Nyquist).


What we're after here is one of those guaranteed to be bandlimited 
implicit forms, only somewhat more general than what the conventional 
BLIT/BLEP framework allows.


Certainly not all frameworks can do that, and not for all signals.


but wavetable synthesis *is* a framework that can do that for any 
periodic (or quasiperiodic) signal.  bandlimited saw, square, PWM, 
sync-saw, sync-square, plucked string, piano, sax, horn, FM (where the 
carrier or modulation frequencies are all integer multiples of a 
common fundamental), whatever.  if it's a tone, wavetable synthesis can 
do it.  bells, tom, tympani and the like are a problem because of 
non-harmonic components.  wavetable synthesis requires that all partials 
are harmonic or close enough to harmonic that you can model the detuning 
from harmonic as a change in phase of the specific harmonic.


notes can be conventionally sampled and wavetables can be extracted at 
prescribed times in the sample and phase aligned with each other.  note 
attacks can be mangled a little with wavetable synthesis unless multiple 
wavetables are used to represent the initial couple of milliseconds.


there is interpolation or cross-fading between phase-aligned wavetables 
to worry about, but there is no overlapping of bandlimited grains or 
wavelets or BLI's (or whatever you wanna call them) to worry about.


Closed form discrete summation formulae don't exist for every 
waveform. At least at the outset, the BLIT/BLEP-framework seemingly 
cannot handle sine-on-sine FM. Vadim's paper is the first I've seen 
which handles even arbitrary sync on a sine. And even if what we've 
been talking about above does go as far as I (following Vadim) 
suggested, exponential segments are still out of the picture for now. 
Then, when you fail, you get aliasing, which sounds really bad and 
behaves nastily under change of parameters.


So then isn't that the end of the discussion, in *musical* DSP? It 
sounds like crap, move along, nothing to hear here.


or, paraphrasing Duke Ellington, if it sounds like crap, it IS crap.

--

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] Sampling theorem extension

[robert bristow-johnson]

On 6/19/15 5:03 PM, Sampo Syreeni wrote:

On 2015-06-19, Ethan Duni wrote:

I guess what we lose is the model of sampling as multiplication by a 
stream of delta functions, but that is more of a pedagogical 
convenience than a basic requirement to begin with.


pedagogical convenience, schmedagogical convenience...

:-)

In fact even that survives fully. In the local integration framework 
that the tempered distributions carry with them, you can convolve a 
polynomial by a delta function or any finite derivative of it, and you 
can also apply a Dirac comb to it so as to sample it.


i thought that, because of my misuse of the Dirac delta (from a 
mathematician's POV, but not from an EE's POV), i didn't think that the 
model of sampling as multiplication by a stream of delta functions was 
a living organism in the first place.  i thought, from the 
mathematician's POV, we had to get around this by using the Poisson 
summation formula ( 
https://en.wikipedia.org/wiki/Poisson_summation_formula ) to properly 
understand uniform sampling and that any manipulation of the naked Dirac 
delta (like adding up a string of them to make a Dirac comb) outside of 
the superficial representation with the integral (the sampling 
property of the Dirac impulse) was illegit.  a naked Dirac delta 
unclothed by an integral is not legit (according to the priesthood of 
mathematicians) and, even when wearing the clothing of an integral, it's 
really just a functional that maps x(t) to x(0).


personally, i have no problem with the pedantic manner that EEs are used 
to using the Dirac impulse (a.k.a. the local integration framework).  
works for me.  and i can understand other issues (like the dimensional 
analysis of impulses and impulse responses) better, more directly, with 
the pedantic POV of the Dirac.


--

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] [ot] other than sampling theorem, Theo

[robert bristow-johnson]

On 6/11/15 1:20 PM, Sampo Syreeni wrote:

On 2015-06-11, Theo Verelst wrote:

[...] I don't recommend any of the guys I've read from here to 
presume they'll make it high up the mathematical pecking order by 
assuming all kinds of previous century generalities, while being even 
more imprecise about Hilbert Space related math than already at the 
undergrad EE sampling theory and standard signal analysis and 
differential equations solving.


Could you be any more condescending?



Theo, might i recommend that (using Google Groups or eternal september 
or the NNTP of your choice) you mosey on over to and check out comp.dsp 
and see how dumb those guys are.


glmrboy (a.k.a Douglas Repetto) runs a pretty nice and clean and high 
S/N ratio forum here.  we're grateful for that.  because of that we try 
to be very nice to each other even when there is controversy (e.g. when 
i had a little run-in with Andrew Simper over the necessity of recursive 
solving of non-linear equations in real-time and with the salient 
differences between trapezoidal integration vs. bilinear transform), we 
try (and succeed) at not underestimating the knowledge, both in the 
practical and in the theoretical, of the other folks on the list.


but check out comp.dsp and see if they're as polite as Sampo.

--

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] Sampling theorem extension

[robert bristow-johnson]

On 6/11/15 5:39 PM, Sampo Syreeni wrote:

On 2015-06-09, robert bristow-johnson wrote:


BTW, i am no longer much enamoured with BLIT and the descendents of 
BLIT. eventually it gets to an integrated (or twice or 3 times 
integrated) wavetable synthesis, and at that point, i'll just do 
bandlimited wavetable synthesis (perhaps interpolating between 
wavetables as we move up the keyboard).


How do you handle free-form PWM, sync and such in that case? Inquiring 
minds want to know.


if memory is cheap, lotsa wavetables (in 2 dimensions sorta like the 
Prophet VS having 2 dimensions but with a constellation of many more 
than 4 wavetables) with incremental differences between them and 
point-by-point interpolation between adjacent wavetables.


one dimension might be the pitch and, if your sampling rate is 48 kHz 
and you don't care what happens above 19 kHz (because you'll filter it 
all out), you can get away with 2 wavetables per octave (and you're only 
interpolating between tow adjacent wavetables).  for these analog 
waveform emulations, whatever harmonics that adjacent wavetables have in 
common would be phase aligned.  as you get higher in pitch, some of the 
harmonics will drop off in the wavetables used for those higher pitch, 
the other harmonics would remain at exactly the same amplitude and same 
phase, so for just those active harmonics, you would be crossfading 
(with complementary constant-voltage crossfade) from one sinusoid to 
another sinusoid that is exactly the same.  but, as you get higher up 
the keyboard, in the higher harmonics, you will be crossfading from an 
active harmonic to no harmonic.


along the other dimension that would be your sync-osc frequency ratio 
(or the PWM duty cycle), i am not sure how many wavetables you would 
need, but i think a couple dozen (where you're always interpolating 
between just two adjacent wavetables) should be way more than enough.  
the waveshapes won't look exactly correct in the interpolated and 
bandlimited wavetables, but you can define the wavetables so that all of 
the harmonics below, say 19 kHz, are exactly what you want them to be 
(they would be the same as the analog sync-osc).  the harmonics above 19 
kHz would either be zero, on its way to zero (as the pitch moves up), or 
possibly folded back but not folded back below 19 kHz.


interpolating between samples within the wavetable is another issue that 
depends on the interpolation method.  again, if memory is cheap, perhaps 
you might wanna put something like 2^12 samples per cycle with harmonics 
only going up to, say, the 300th or so (for very low notes).  then you 
can get away with linear interpolation between samples.


--

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] Sampling theorem extension

[robert bristow-johnson]

On 6/9/15 4:32 AM, Vadim Zavalishin wrote:

Creating a new thread, to avoid completely hijacking Theo's thread.


it's a good idea.


Previous message here:
http://music.columbia.edu/pipermail/music-dsp/2015-June/073769.html

On 08-Jun-15 18:29, Sampo Syreeni wrote:

On 2015-06-08,vadim.zavalishin wrote:


The sampling theorem applies only to the class signals which do
have Fourier transform, separating this class further into
bandlimited and non-bandlimited. However, it doesn't say anything
about the signals which do not have Fourier transform.


Correct. But the class of signals which do have a Fourier theory is
much, *much* larger than you appear to think. Usually continuous time
Fourier theory is set in the class of tempered distributions, which
does include such things as Dirac impulses, trains of them with
suitably regular supports, and of course shifts, sums, scalings and
derivatives of all finite orders, and so on. Not everything you could
possibly ever want -- products are iffy, for instance -- but
everything you need in order to bandlimit the things and get the
most usual forms of converence in norm we're interested in.


Oh, I didn't know there's a rigorous framework behind Dirac deltas.


i think they call 'em generalized distributions.

i remember the first time i had a conceptual problem with this about 38 
years ago when i took a course is Real Analysis (using the Royden text). 
 we were learning about Lebesgue integration and then had a theorem 
(dunno what it's named) that if f(x)=g(x) almost everywhere (that is 
everywhere except on a set of real numbers of measure zero or a 
countable number of discrete points of x) then the integral of f(x) 
equals the integral of g(x) over the same interval.  like if f(x) = 1 
for rational x and 0 for irrational x, the integral is zero.  but what 
immediately came to my mind (and to the math profs attention via my 
lips) was the Dirac impulse and the way we electrical engineers treat it 
(which does not conform to the above theorem).


so the way i resolve it in my head is say that (among other facts like 
there really aren't any signals, remaining non-zero, that go off to t = 
+/- infinity) i will model, in my imagination, the ideal impulse 
function in time as having area of 1 (and dimensionless, which means the 
dimension of delta(t) is 1/time) and a width of 1 Planck time.  that's 
close enough for me regarding the physical reality and should keep the 
mathematicians happy.  it's not rigorous, but it's good enough and then 
i can integrate it and say the integral is 1.



This can be further extrapolated to the polynomial signal case
(which are implicitly assumed bandlimited in the BLEP, BLAMP and
higher order derivative discontinuity approaches).


They are not implicitly assumed anything, but instead a) the part of
 them which lands outside of your bandlimit are carefully bounded to
 where aliasing is perceptually harmless, or b) they're used so that
 they're fed bandlimited signals, which via the theory of Chebyshev
polynomials and the usual properties of the full Fourier transform
lead to exactly as many fold band expansion as the order of the
polynomial used has. That stuff then works perfectly fine with
oversampling.


Could you give a little bit more of a clarification here? So the
finite-order polynomials are not bandlimited, except the DC? Any hints
to what their spectra look like? How a bandlimited polynomial would look
like?


a Nth order polynomial, f(x), driven by an x(t) that is bandlimited to B 
will be bandlimited to N*B.  if you oversample by a ratio of at least 
(N+1)/2, none of the folded images (which we call aliases) will reach 
the original passband and can be filtered out with an LPF (at the high 
sampling rate) before downsampling to the original rate.  with 4x 
oversampling, you can do a 7th-order polynomial and avoid non-harmonic 
aliased components.






Other signals (such as exponential function, FM'ed sine etc) are
also interesting.


Sure. And all that is well understood. The exponential function is
easy because of its connection via the Euler equation to sinusoids,
and via the usual energy norm, to the second order theory of the
Gaussian.


I'm failing to see how Euler equation can relate exponentials of a real
argument to sinusoids of a real argument? Any hints here?



let f(x) be defined to be  f(x) = e^(j*x)/(cos(x) + j*sin(x))

where j^2 = -1.

what is the value of f(0)?  (it's 1.)

what is the derivative of f(x)?  (it's 0 for all x.)

that means the numerator and denominator must be equal.

there are several other derivations.  Euler's original derivation used 
Taylor or Maclauren series.  i always thought that one was more messy 
than necessary.


another good way to derive the relationship is with the 2nd-order diff eq:

   (d^2/dx^2) f(x)  +  f(x)  =  0

try the exponential f(x) = e^(alpha*x)

then try the sinusoidal  f(x)  =  A*cos(x)  +  B*sin(x)

check out your initial conditions for f(0) and 

Re: [music-dsp] R: Comb filter decay wrt. feedback

[robert bristow-johnson]

On 5/11/15 3:25 AM, Marco Lo Monaco wrote:



we should have a drink together (do you come to U.S. AES shows?) and all
you do is mention one of several political topics and the hyperbole coming
outa me will be worse than this.

Hey, I also wanna have a drink with RBJ and talk about life, politics, women
and DSP?!?!?!!



as if i know shit about any of those topics.

i've also never made it across the pond.  so you'll have to come to the 
U.S. (or maybe Montreal which is as close to Europe as i can get).



--

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] Comb filter decay wrt. feedback

[robert bristow-johnson]

On 5/10/15 3:42 PM, Matthias Puech wrote:

I have a recursive comb filter, implemented with a simple delay line of size N and feedback F in 
[0..1]. If feedback is high and I ping it, it decays exponentially as it should, to 
give the typical ringing effect. The decay time D is also proportional to N: if I double N, D is 
also doubled. My question: what is the value of F depending on N that will give a constant D. In 
other words, how can I play my comb filter on a scale à la Karplus-Strong and retain a 
constant decay time?



i forgot to consider the less trivial part of the question (it wasn't 
about the gains of the teeth).  repeating the setup:


instead of z^-1 or e^(-sT), it's e^(-s*T0) where T0 is the reciprocal of 
the precise fundamental frequency of the ping and is not necessarily an 
integer number of samples.  so designing your comb (both feedback and 
feedforward gains) is the same as designing an LPF and the comb teeth 
are spaced by 1/T0 (the specified fundamental frequency, f0) instead of 
1/T (which is the sampling frequency)  if


  H(s) =  (1 + b*e(-s*T0)) / (1 + a*e(-s*T0))  (feedback gain is -a)


so first consider the simple 1st-order digital LPF

  H(z) =  (1 + b*z^-1) / (1 + a*z^-1)

it has a discrete-time impulse response of

 +inf
  h[n] =  d[n] + (1 - b/a) * SUM (-a)^i d[i-n]
 i=1

where d[n] is the Kronecker delta

   d[n] = 1   when   n=0
= 0   otherwise


translating back to analog (where z^-1 -- e^(-sT) )

+inf
  h(t) =  d(t) + (1 - b/a) * SUM (-a)^i d(iT-t)
 i=1

now d(t) is a sorta bandlimited dirac delta

  d(t) =  (1/T)*sinc(t/T) where T=1/Fs  is the sampling period

but let's pretend it's a regular dirac delta, whatever the hell that is.

the decaying sum can be rewritten as (if the feedback gain is 0  -a  1)

+inf
SUM  e^(log(-a)*i) * d(t-iT)
i=0

so when t=iT the decay is down to e^(log(-a)*(t/T))

and the time constant is

   tau  =  -T/log(-a)

and the decay rate is the reciprocal  log(-a)/T

now for the comb filter, replace T with T0, the delay of your precision 
delay.


normally that T0 is the period of the note.

1/T0 = f0

where

f0 = (440 Hz) * 2^((p-69)/12)

   = (8.17579891564371 Hz) * 2^(p/12)

where p is the MIDI note number.  now, if you want your decay rate to be 
independent of the note, the feedback gain, -a, cannot be independent


  log(-a) = -T0/tau

  -a  =  e^(-T0/tau)  = e^(-1/(tau*f0))

  =  e^( -2^(-p/12)/(tau*(8.1758Hz) )

so, select a time constant, know which note you're playing (that will 
determine T0 and how you're doing interpolation in the precision delay 
line), and calculate your feedback coefficient from that.


so Peter, this (the answer to the OP's question) is trivial?  it's not 
string theory, but it's more than trivial.


--

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] Comb filter decay wrt. feedback

[robert bristow-johnson]

On 5/10/15 3:42 PM, Matthias Puech wrote:

This is my first post on this list, although I have been reading it for quite 
some time, with great interest.


welcum


  I am a CS researcher in an unrelated field, but fascinated for as long as I 
can remember by DSP and sound synthesis. Unfortunately my knowledge is still 
basic, and now is the first time that I face real technical difficulties (while 
implementing this: http://mqtthiqs.github.io/parasites/). Witness this question:

I have a recursive comb filter, implemented with a simple delay line of size N and feedback F in 
[0..1]. If feedback is high and I ping it, it decays exponentially as it should, to 
give the typical ringing effect. The decay time D is also proportional to N: if I double N, D is 
also doubled. My question: what is the value of F depending on N that will give a constant D. In 
other words, how can I play my comb filter on a scale à la Karplus-Strong and retain a 
constant decay time?

Sorry if this sounds too trivial or if it is not the right place to ask. Don’t 
hesitate to redirect me if needed or point me to references, I am eagerly 
looking for basic literature.


it's not trivial and it's not in the basic lit.

lemme find and review my own notes/equations regarding that (i think i 
titled it Fun with Comb Filters), and i'll get back on it.  but to 
tune your comb filters to arbitrary pitches, you will need a precision 
tap delay line.  maybe need to get familiar with the Nyquist/Shannon 
Sampling and Reconstruction Theorem and the good ol' sinc() function.



--

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] Comb filter decay wrt. feedback

[robert bristow-johnson]

On 5/10/15 8:00 PM, Peter S wrote:

On 10/05/2015, robert bristow-johnsonr...@audioimagination.com  wrote:

it's not trivial and it's not in the basic lit.

It's trivial, and it's in the 1961 Schroeder paper linked in the previous post.



apologies for the hyperbole.  if you consider both feedback and 
feedforward gain, getting the gain no more or less trivial than 
designing a quick, oneth-order digital LPF.  instead of z^-1 or e^(-sT), 
it's e^(-s*T0) where T0 is the reciprocal of the precise fundamental 
frequency of the ping and is not necessarily an integer number of 
samples.  so designing your comb (both feedback and feedforward gains) 
is the same as designing an LPF and the comb teeth are spaced by 1/T0 
(the specified fundamental frequency, f0) instead of 1/T (which is the 
sampling frequency)  if


  H(s) =  (1 + b*e(-s*T0)) / (1 + a*e(-s*T0))  (feedback gain is -a)

the gain at the top of the teeth (assuming it's an LPF prototype) is 
(1+b)/(1+a) and you can dB-ize that.  the gain at the valleys between 
teeth is (1-b)/(1-a).  i think the teeth are taller than the valleys if 
b  a.   now it doesn't have to be modeled after an LPF, you could 
design a first-order HPF (with z^-1) and translating that to the longer 
delay, you would get a comb with teeth spaced by 1/T0, but instead of 
starting at DC, your first tooth is at 1/(2*T0).  then the teeth gain is 
(1-b)/(1-a) and the valley gain is (1+b)/(1+a).


now my brain cells are dying (i dunno how many zillions per second) so 
when i am first faced with a problem called precision delay, i have to 
at least wonder if i'm gonna do it with an APF (single  z^-1 and 
negative feedback coef) or with the FIR polyphase method (where i get to 
use MATLAB to design an LPF).  or maybe it'll be blanch Linear 
Interpolation.  it's gonna be one or even some combination of two or 
these methods.  but when i consider that part of designing comb filters 
tuned to musical notes, i have to at least pause and wonder which 
interpolation would be better or sufficient for whatever application and 
that's why it didn't seem trivial to me.


what's really cool (and also makes this a teeny bit less trivial) is 
that you can use this extend z^-1 design to comb filter design 
philosophy to second or higher order filters  (more precision-delay taps 
offa the delay line) and *really* design the shape of the teeth of the 
comb.  like do a butterworth design and the teeth are really flat (and 
won't complain too much if some harmonic is slightly offa its harmonic 
value).


we should have a drink together (do you come to U.S. AES shows?) and all 
you do is mention one of several political topics and the hyperbole 
coming outa me will be worse than this.


--

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

[music-dsp] Wow!!! Andy Moorer on All Things Considered!!!!

[robert bristow-johnson]

not to late for you guys living on the left coast to hear it.  just 
ended two minutes ago (21:44 GMT).



--

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] Wow!!! Andy Moorer on All Things Considered!!!!

[robert bristow-johnson]

On 4/11/15 6:46 PM, Vicki Melchior wrote:

It should appear in their listings and archives but I don't see anything very 
obvious on the NPR-ATC website for Apr 11 :  
http://www.npr.org/programs/all-things-considered/

What was it about?


sorry, just now clicked your link, Vickie.  it's this: 
http://www.npr.org/2015/04/11/399034279/know-that-thx-sound-before-movies-thats-actually-20-000-lines-of-code 



--

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] Wow!!! Andy Moorer on All Things Considered!!!!

[robert bristow-johnson]

On 4/11/15 8:20 PM, Chad Wagner wrote:

Haha - see also: 
http://createdigitalmusic.com/2015/04/thx-deep-note-creator-remade-iconic-sound/

The original 30-year-old C program is 325 lines, and the “patch” file for the 
synthesizer was 298 more lines. I guess it just felt like 20,000 lines when I did 
it.

I know the feeling ;-)


i was wondering about that (20,000 sounded awful large).  i thought they 
might have meant *all* of the system and utility code that was called to 
do 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] Uses of Fourier Synthesis?

[robert bristow-johnson]

On 4/5/15 5:21 PM, Theo Verelst wrote:
In the context of synthesis, or intelligent multi sampling with 
complicated signal issues, you could try to make the FFT analysis and 
filtering a targeted part of the synthesis path, so that the playing 
back of samples contain variations and sample information that can be 
picked up and transformed by a FFT based signal path element. In some 
form (not exactly as I described in general terms) I believe this is 
the case with the Kurzweils.


uhm, i worked for Kurz from 2006 to 2008, specifically on the synthesis 
component of the chip they used in the PC3.  while in off-line note 
analysis, there might be all sorts of frequency-domain stuff going on, i 
can tell you for sure there is no FFT-based signal path element in the 
real-time synthesis process.  (and saying so might have been saying too 
much so i won't be any more specific.  but i'll say it might be simpler 
than a particular guess.)  there are real limits to what can be done in 
real time, specifically if you want 128-voice polyphony.


--

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] Uses of Fourier Synthesis?

[robert bristow-johnson]

On 4/5/15 10:15 PM, Didier Dambrin wrote:
That's not at all what I was saying. I only wrote that additive 
synthesis could be used for an identical result to a KS, with better 
control on the filtering.





please accept my apology.  i did not correctly grok what you were saying 
Didier.


of course additive synthesis can make an identical result to *any* other 
synthesis method as it can pretty much create an identical result to any 
sound, musical tone or otherwise.


i'm sorry for misunderstanding and misinterpreting what you wrote.

bestest,

r b-j



--
It can sound exactly the same, with the added benefit that you have 
full control on the filtering.


lemme understand the claim: Karplus-Strong can be made to be
perceptually identical to the straight sample playback of a particular
plucked-string instrument?

...

--

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] Uses of Fourier Synthesis?

[robert bristow-johnson]

On 4/5/15 5:02 PM, Didier Dambrin wrote:
All harmonics (thus, not that many to compute, especially as most fade 
out to inaudibility pretty quickly), and not evolving


you mean the phase (let's say relative to the oscillator with the 
fundamental) is not changing while the note evolves?  certainly the 
amplitudes of these oscillators are evolving according to some envelope.



(-just- like with karplus strong, which is pretty much a single-cycle 
self-filtering over time)


yup, BUT, with Karplus-Strong, there are two filters in the feedback 
loop (and they can be teamed-up and called a single filter, if you 
want).  one filter is to get a fractional-sample precision delay and the 
other is a low-pass filter so that higher overtones die away faster than 
the lower.  now we can do everything in a phase-linear way, so that the 
phase delay of either filter is independent of frequency (BTW, phase 
delay is what's salient in Karplus-Strong rather than group delay).  to 
keep it phase linear, you would have to use some kinda polyphase FIR 
interpolation to get the fractional sample delay and another FIR 
implementation of the LPF.  and Karplus and Strong depicted the latter 
in their original CMJ article.  if it's all phase-linear, the overtones 
are harmonic.


but, you *could* use an IIR LPF and an IIR APF for the fractional sample 
delay.  then the loop delay will be slightly different for the different 
overtones and the frequency of those overtones will not be precisely 
harmonic.  i would imagine for realistic strings, one would want the 
loop delay to be less for higher frequencies than for lower frequencies, 
thus tuning the higher overtones sharper than their precise harmonic value.


BTW, i've always considered waveguide synthesis to **be** the method of 
physical modeling.  maybe i'm missing something basic.


It can sound exactly the same, with the added benefit that you have 
full control on the filtering.


lemme understand the claim: Karplus-Strong can be made to be 
perceptually identical to the straight sample playback of a particular 
plucked-string instrument?


i have to think about that one.  it seems to me that every overtone 
decay would be strictly exponential, although different overtones can 
have different alphas and decay at different rates.  but you would 
have to modify K-S a bit more, like have *two* precision delay lines in 
series and two feedback paths in order to have an envelope that would 
increase in time before it begins to decay exponentially.  or maybe 
three precision delays with three feedback paths to have a natural 
tremelo on some harmonic as it decays.  i dunno.


r b-j


-Message d'origine- From: robert bristow-johnson
Sent: Sunday, April 05, 2015 9:23 PM
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] Uses of Fourier Synthesis?

On 4/5/15 3:11 PM, Didier Dambrin wrote:
I've created plucked strings using additive (not FFT), and it sounds 
the same as a Karplus Strong, but with more control. So it's 
definitely doable.


The key is: all oscillators have to be phase-unrelated, or it won't 
sound metallic.


are the oscillators harmonic?  or not quite harmonic?

if the former, do the relative phases change while the note evolves?




--

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] Uses of Fourier Synthesis?

[robert bristow-johnson]

On 4/5/15 2:45 PM, Alan Wolfe wrote:

Interesting, thanks for the info!

What is the usual technique for simulating plucked strings? (:


i dunno what is the most common (probably sample playback), but lately 
Physical Modeling seems to be the craze.  Karplus-Strong is another 
method that appears to me to be closely related.


in my opinion, if the overtones are decently close to harmonic, you can 
use wavetable synthesis for any musical tone.  the plucked attack can be 
a one-shot sample playback and an evolving wavetable synthesis for the 
entire note after the attack.  for harmonic synthesis, wavetable is 
cheap (i mean efficient) and just as good as additive.  there are even 
ways to slightly detune overtones from their harmonic frequencies and to 
morph from one tone to another.


--

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] Uses of Fourier Synthesis?

[robert bristow-johnson]

On 4/5/15 2:51 PM, Zhiguang Zhang wrote:

Plucked strings can be done using the Karplus Strong algorithm, which uses a 
noise excitation put through a comb filter, or something similar.


it's the kind of comb filter with feedback.  and you need 
fractional-sample precision delay before feedback.  and the noise 
excitation is done by preloading the entire delay with random numbers.


--

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] Uses of Fourier Synthesis?

[robert bristow-johnson]

On 4/5/15 3:11 PM, Didier Dambrin wrote:
I've created plucked strings using additive (not FFT), and it sounds 
the same as a Karplus Strong, but with more control. So it's 
definitely doable.


The key is: all oscillators have to be phase-unrelated, or it won't 
sound metallic.


are the oscillators harmonic?  or not quite harmonic?

if the former, do the relative phases change while the note evolves?

--

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] Real-time Polyphonic Pitch Detection

[robert bristow-johnson]

On 4/3/15 5:12 PM, Alex Cannon wrote:

Hi all,

I was wondering what the state-of-the-art was with regards to real-time
polyphonic pitch-detection. The best solution for the MIREX task
http://www.music-ir.org/mirex/wiki/2014:Multiple_Fundamental_Frequency_Estimation_%26_Tracking_Results#Task_1:_Multiple_Fundamental_Frequency_Estimation_.28MF0E.29
achieved an accuracy of 74% but doesn't appear to be in real-time.


well, if the computational burden is too high, it's not gonna be real-time.

but if there is sufficient computational horsepower and sufficient delay 
is allowed, you can do whatever method you want on overlapping frames of 
audio.  essentially treat each frame like a sound file and sic the MIREX 
winner on each frame (somehow connect pitch tracks between frames).  
might be a lot of delay.



  Might
anyone know what the statistic would be for real-time solutions, or even
where I might find an implementation? Most of what I've found points to
fiddle~, am I on the right track?



tough problem.  might have to reverse-engineer melodyne.

--

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] Real-time Polyphonic Pitch Detection

[robert bristow-johnson]

On Fri, April 3, 2015 6:32 pm Matt Jackson matt.jack...@ableton.com wrote:



 I wasn't aware ~fiddle works polyphonically.

 I'm not an expert on the subject, but according to a few AES papers I glazed 
 over, I think you find one pitch, remove it with notches and iterate.


polyphonic is really tough.� say a C3 and G4 are played simultaneously.� 
somehow we hear it as two distinct notes, unless maybe the G4 has much lower 
key velocity.� might be hard for a mindless computer to separate them.� maybe 
if the 3rd and 6th and 9th harmonics of
the C3 are, as a group, much louder than the spectral envelope ostensibly 
visible from the other harmonics.
bitchy problem.� especially for live application (live = real-time + 15 
or 20 ms delay).
missed notes, spurious notes.� horror
story.
still dunno how melodyne does 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] Fwd: Array indexing in Matlab finally corrected after 30 years!

[robert bristow-johnson]

On 4/2/15 12:20 PM, Phil Burk wrote:

Speaking of zero based indexing, my neighbor's street address is 0
Meadowood Drive. There was a 4 Meadowood Drive already existing. They
left room to build one more house at the end of the street. But instead of
building a house they built two cottages. So they had to number them 0 and
2.



what if they built 3 cottages?  would one address be -2?


My wife doesn't understand why I am so jealous of that street address. My
neighbor says he likes it but he keeps getting forms returned asking him to
correct his street address


it's like the perfect two-letter .com domain name.


--

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] Array indexing in Matlab finally corrected after 30 years!

[robert bristow-johnson]

On 4/1/15 12:56 PM, Nigel Redmon wrote:

On Apr 1, 2015, at 7:19 AM, robert bristow-johnsonr...@audioimagination.com  
wrote:

On 4/0/15 6:24 AM, Max wrote:

Well Played.

credit Dilip Sarwate at comp.dsp (who also hangs out at the 
dsp.stackexchange forum).


--

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

[robert bristow-johnson]

On 3/31/15 6:53 PM, Justin Salamon wrote:


To expand on what Ethan wrote, it sounds like what you're trying to do is
zero-pad the signal:
http://www.dsprelated.com/dspbooks/mdft/Zero_Padding.html

That said, whilst zero padding will give you an interpolated spectrum in
the frequency domain, you may still miss the true location of your peaks,


how so?  the only mechanism for missing the true location would be 
sidelobe interference from adjacent peaks, possibly including the 
peak(s) in negative frequency.



and it will also increase the computational cost.

Another thing to look at is re-estimating the exact location of the peaks
in your spectrum using parabolic interpolation:
http://www.dsprelated.com/dspbooks/sasp/Quadratic_Interpolation_Spectral_Peaks.html


quadratic interpolation of peaks (given the three discrete samples 
around the peak) is a good ol' standby.  i use it for autocorrelation to 
get the period to a fractional-sample precision.  but i don't see why it 
would be more accurate than zero-padding before the FFT.



Or, you could use the phase instead to compute the instantaneous frequency:
http://en.wikipedia.org/wiki/Instantaneous_phase#Instantaneous_frequency


needs a Hilbert transformer.  and you would also need to isolate the 
sinusoidal partial from the other partials.


i think so, anyway.


--

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

[robert bristow-johnson]

On 3/20/15 2:58 PM, Alan Wolfe wrote:

One thing to watch out for is to make sure you are not looking
backwards AND forwards in time, but only looking BACK in time.



right!!  pretty hard to cross into the future with a real-time alg 
(because there ain't no future, it's really wrapping around your delay 
buffer to the distant past).  you *can* cross into the future with a 
non-real-time alg (it's also not really the future since it was recorded 
long ago).



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.

your LFO really should go between -1 and 0,


maybe not quite to 0 since there will be other samples needed for the 
Hermite interpolation.  the delay must be more than 1 sample for 
4-sample, 3rd-order polynomial interpolation.


i wish the OP could check his Hermite alg to see if it's consistent with 
what i wrote in an earlier reply.  i just didn't want to blast it out, 
but i guess i could.  if the alg is implemented i incorrectly, who knows 
what that would sound like.


perhaps the OP should try it first with linear interpolation to see if 
there are glitches due to discontinuities.  then improve the interpolation.


--

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

[robert bristow-johnson]

On 3/20/15 10:20 AM, Bjorn Roche wrote:

Interpolating the sample value is not sufficient to eliminate artifacts.
You also need to eliminate glitches that occur when jumping from one time
value to another.


what do you mean?  do you mean the normal speed-up-the-tape effect 
when smoothly decreasing the amount of delay?  or do you mean when an 
integer sample index boundary is crossed?



  In other words: no matter how good your sample-value
interpolation is, you will still introduce artifacts when changing the
delay time


depending on your answer to the above, i am not sure i agree with this.


--

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

[robert bristow-johnson]

On 3/19/15 2:28 PM, Nuno Santos wrote:

Hi,

Thanks for your replies.

What I hear is definitely related with the modulation. The artefacts are 
audible every time the modulation is applied: manually or automatically (please 
not that I have an interpolator for manual parameter changes to avoid abrupt 
changes). I think I was already applying an Hermit interpolation. This is my 
delay read function.

void IDelay::read(IAudioSample *output)
{
 float t = _time+_modulation*_modulationRange;

 if (t(_size-1))
 t=_size-1;

 float sf;

 #if 0
 sf = _buffer[int(readIndex(t,0))];
 #else
 float const y_1= _buffer[int(readIndex(t,-1))];
 float const y0 = _buffer[int(readIndex(t,0))];
 float const y1 = _buffer[int(readIndex(t,1))];
 float const y2 = _buffer[int(readIndex(t,2))];
 float const x=readIndex(t,0)-int(readIndex(t,0));
 float const c0 = y0;
 float const c1 = 0.5f*(y1-y_1);
 float const c2 = y_1 - 2.5f*y0 + 2.0f*y1 - 0.5f*y2;
 float const c3 = 0.5f*(y2-y_1) + 1.5f*(y0-y1);

 sf=((c3*x+c2)*x+c1)*x+c0;
 #endif

 *output = sf;
}




can someone confirm if the above is the same as

  x2 = x*x;
  x3 = x2*x;
  sf = 0.5f*( (x3-x2)*y2
+ (  x + 4.0f*x2 - 3.0f*x3)*y1
+ (2.0f- 5.0f*x2 + 3.0f*x3)*y0
+ ( -x + 2.0f*x2 -  x3)*y_1
);




??

otherwise i dunno if your Hermite interpolation is correct.  (might be, 
i dunno.)


when delay is modulated radically, i dunno if better than 4-sample, 3rd-order 
interpolation sounds any worse than bandlimited interpolation using something 
like windowed sinc functions that are much longer (say using 16 or 32 samples).

if the 3rd-order Hermite is done correctly and you're getting crap, try an 
interpolation that uses more samples of the signal.  if memory is not 
expensive, you could have 64 or 128 different fractional delays or phases of a 
polyphase filter and linearly interpolate between adjacent phases.  (that would 
be like ideally upsampling by 64x or 128x and linearly interpolating between 
them up-samples.


r b-j



--

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] Approximating convolution reverb with multitap?

[robert bristow-johnson]

On 3/18/15 1:39 PM, STEFFAN DIEDRICHSEN wrote:


With most IRs, you don’t see discrete peaks, it’s a continuous signal. This is 
due to the response of the speaker and microphone being used. This causes some 
smear.


sure, so let's say we deconvolve that smear because we think it's a lot 
shorter than the time difference between the direct path (between 
speaker and microphone) and the first reflection.


now, i always thought that the way the reverb guys sorta did it was to 
use a straight multitap with a countable number of arbitrary taps (and 
zero coefficients in between) to get the early reflections and then add 
to that the output of a Schroeder-like or Jot-like reverberator (with a 
pre-delay about as long as the last tap in the multitap) that has the 
impulse response getting denser (and lower in amplitude) samples at 
later times to implement the decaying tail.


i know that a few companies have had done it a little differently and 
more esoterically. (like that reverb in the style of [David] 
Griesinger that Dattorro published in AES a while ago.  i remember 
pairs of high-pass taps (with -1, +1 coefs), but don't remember much 
else.)


--

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] Audio Latency Test App for iOS and Android

[robert bristow-johnson]

On 3/2/15 4:29 PM, Patrick Vlaskovits wrote:

Hiya!

We've released a free app for Android and iOS developers that measures
roundtrip audio latency.

http://superpowered.com/latency/



and you're doing all of your bookkeeping accurately so that the app 
itself isn't adding delay that it includes in the measurement?  or, if 
it does, you're accounting for it?




Interestingly enough, the data suggest that older iOS devices have BETTER
latency than more recent ones. Ouch!


doesn't surprize me in my most cynical state.  life is like that.


iPhone 6 Plus comes in at 38 ms, while iPhone 4S comes in a healthy 8 ms.


too many independent threads running simultaneously, i'll bet.  big 
buffer needed to keep it from hiccuping.  but 800+ sample delay for both 
input and output is way more than i would ever expect for something that 
purports to be real-time live.  guitar stomp box at anything more than 
15 or 20 ms (and that's on the outside, some pitch shifters might be 
around there) would cause some rebellion among live musicians.


but

--

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] Linearity of compression algorithms on more than one sound component

[robert bristow-johnson]

On 2/12/15 3:02 PM, Theo Verelst wrote:

Hi all,
Just a thought I share, because of associations I won't bother you 
with, suppose you take some form of audio compression, say Fmp3(wav) 
which transforms wav to an mp3 form, with some encoding parameters. 
Now we consider the linearity of the transform, most people will know 
this:


  Fmp3(Lambda * wav) ^= Lambda * Fmp3(wav)

  Fmp3(wav1 + wav2) ^= Fmp3(wav1) + Fmp3(wav2)


i don't think mp3 encoding is linear.  i'm almost certain it is not.



--

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

[robert bristow-johnson]

On 2/10/15 8:49 AM, Didier Dambrin wrote:
What are you talking about - why would phase not matter? It's 
extremely important (well, phase relationship between neighboring 
partials).





well, it's unlikely you'll be able to hear the difference between this:

x(t) = cos(wt) - 1/3*cos(3wt) + 1/5*cos(5wt) - 1/7*cos(7wt)

and this:

x(t) = cos(wt) + 1/3*cos(3wt) + 1/5*cos(5wt) + 1/7*cos(7wt)

yet the waveshapes are much different.

so if you have MATLAB or Octave, try this file out and see what you can 
hear.  look at the waveforms and see how different they are.


%
%   square_phase.m
%
%   a test to see if we can really hear phase changes
%   in the harmonics of a Nyquist limited square wave.
%
%   (c) 2004 r...@audioimagination.com mailto:r...@audioimagination.com
%

if ~exist('Fs', 'var')
 Fs = 44100  % sample rate, Hz
end

if ~exist('f0', 'var')
 f0 = 110.25 % fundamental freq, Hz
end

if ~exist('tone_duration', 'var')
 tone_duration = 2.0 % seconds
end

if ~exist('change_rate', 'var')
 change_rate = 1.0   % Hz
end

if ~exist('max_harmonic', 'var')
 max_harmonic = floor((Fs/2)/f0) - 1
end

if ~exist('amplitude_factor', 'var')
 amplitude_factor = 0.25 % this just keeps things from 
clipping

end

if ~exist('outFile', 'var')
 outFile = 'square_phase.wav'
end


   % make sure we don't uber-Nyquist 
anything

max_harmonic = min(max_harmonic, floor((Fs/2)/f0)-1);

t = linspace((-1/4)/f0, tone_duration-(1/4)/f0, Fs*tone_duration+1);

detune = change_rate;

x = cos(2*pi*f0*t);  % start with 1st harmonic

n = 3;   % continue with 3rd harmonic while 
(n = max_harmonic)
 if ((n-1) == 4*floor((n-1)/4))   % lessee if it's an even or 
odd term

 x = x + (1/n)*cos(2*pi*n*f0*t);
  else
 x = x - (1/n)*cos(2*pi*(n*f0+detune)*t);
 detune = -detune;% comment this line in an see some
 end  % funky intermediate waveforms
 n = n + 2;   % continue with next odd harmonic
end

x = amplitude_factor*x;

% x = sin((pi/2)*x);   % toss in a little soft clipping

plot(t, x);  % see
sound(x, Fs);% hear
wavwrite(x, Fs, outFile);% remember






16 bits is just barely enough for high-quality audio.


So to you, that Pono player isn't snake oil?


well, Vicki is the high-res guru here.

i certainly don't think we need 24-bit and 192 kHz just for listening to 
music in our living room.  but for intermediate nodes (or intermediate 
files), 24-bit is not a bad idea.  and if you have space or bandwidth to 
burn, why not, say, 96 kHz.  then people can't complain about the 
scrunching of the bell curve near Nyquist they get with cookbook EQ.


for a high-quality audio and music signal processor, i think that 16-bit 
pre-emphasized files (for sampled sounds or waveforms) is the minimum i 
want, 16-bit or more ADC and DAC, and 24-bit internal nodes for 
processing is the minimum i would want to not feel cheap about it.  if 
i were to use an ADI Blackfin (i never have) to process music and 
better-than-voice audio, i would end up doing a lot of double-precision 
math.


BTW, at this: 
http://www.aes.org/events/125/tutorials/session.cfm?code=T19 i 
demonstrated how good 7-bit audio sounds in a variety of different 
formats, including fixed, float (with 3 exponent bits and 4 mantissa 
bits), and block floating point (actually that was 7.001 bits per 
sample), dithered and not, noise-shaped and not.  but i still wouldn't 
want to listen to 7-bit audio if i had CD.


well dithered and noise-shaped 16-bits at 44.1 kHz is good enough for 
me.  i might not be able to hear much wrong with 128 kbit/sec MP3, but i 
still like CD audio better.





Besides, if it had mattered so much, non-linear (mu/A-law) encoding 
could have applied to 16bit as well..




naw, then you get a sorta noise amplitude modulation with a signal of 
roughly constant amplitude.  and there are much better ways to do 
optimal bit reduction than companding.  companding is a quick and easy 
way they did it back in the old Bell System days.  and, even in 
companding, arcsinh() and sinh() would be smoother mapping than either 
mu or A-law.



--

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

[robert bristow-johnson]

On 2/9/15 10:19 PM, Nigel Redmon wrote:

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.


i have had a similar argument with Andrew Horner about tossing phase 
information outa the line spectrum of wavetables for wavetable 
synthesis.  why bother to do that?  why not just keep the phase 
information and the waveshape when it costs nothing to do it.


regarding dithering and quantization, if it were me, for 32-bit or 
24-bit fixed-point *intermediate* values (like multiple internal nodes 
of an algorithm), simply because of the cost of dithering, i would 
simply use fraction saving, which is 1st-order noise shaping with a 
zero at DC, and not dither.  or just simply round, but the fraction 
saving is better and just about as cheap in computational cost.


but for quantizing to 16 bits (like for mastering a CD or a 16-bit 
uncompressed .wav or .aif file), i would certainly dither and optimally 
noise-shape that.  it costs a little more, but like the wavetable phase, 
once you do it the ongoing costs are nothing.  and you have better data 
stored in your lower resolution format.  so why not?


16 bits is just barely enough for high-quality audio.  and it wouldn't 
have been if Stanley Lipshitz and John Vanderkooy and Robert Wanamaker 
didn't tell us in the 80's how to extract another few more dB outa the 
dynamic range of the 16-bit word.  they really rescued the 80 minute Red 
Book CD.


--

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

[robert bristow-johnson]

On 2/10/15 1:30 PM, Didier Dambrin wrote:
Of course 24bit isn't a bad idea for intermediate files, but 32bit 
float is a better idea, even just because you don't have to normalize 
 store gain information that pretty much no app will read from the 
file. And since the price of storage is negligible these days..


can't disagree with that.  now, even with float, you can dither and 
noise shape the quantization (from double to single-precision floats), 
but the code to do so is more difficult.  and i dunno *what* to do if 
adding your dither causes, for a single sample, the exponent to change.  
it's kinda messy.  i guess you just accept that this particular sample 
will not be perfectly dithered correctly and, whatever quantization 
error *does* result, use that in the noise-shaping feedback.


--

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

[robert bristow-johnson]

On 2/10/15 1:51 PM, Ethan Duni wrote:

So to you, that Pono player isn't snake oil?

It's more the 192kHz sampling rate that renders the Pono player into snake
oil territory. The extra bits probably aren't getting you much, but the
ridiculous sampling rate can only *hurt* audio quality, while consuming
that much more battery and storage.


that's interesting.  why does higher-than-needed sample rate hurt audio 
quality?  might not be necessary, but how does it make it worse 
(excluding the increased computational burden)?  i always think that 
analog (or continuous-time) is like having an infinite sample rate.



--

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

[robert bristow-johnson]

On 2/7/15 8:54 AM, Vicki Melchior wrote:
Well, the point of dither is to reduce correlation between the signal and quantization noise.  Its effectiveness requires that the error signal has given properties; the mean error should be zero and the RMS error should be independent of the signal.  The best known examples satisfying those conditions are white Gaussian noise at ~ 6dB above the RMS quantization level and white TPDF noise  at ~3dB above the same, with Gaussian noise eliminating correlation entirely and TPDF dither eliminating correlation with the first two moments of the error distribution.   That's all textbook stuff.  There are certainly noise shaping algorithms that shape either the sum of white dither and quantization noise or the white dither and quantization noise independently, and even (to my knowledge) a few completely non-white dithers that are known to work, but determining the effectiveness of noise at dithering still requires examining the statistical properties of the error signal and showing 

th

  at the mean is 0 and the second moment is signal independent.  (I think 
Stanley Lipschitz showed that the higher moments don't matter to audibility.)


but my question was not about the p.d.f. of the dither (to decouple both 
the mean and the variance of the 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 number per sample and running that through a 
simple 1st-order FIR which has +1 an -1 coefficients (i.e. subtract the 
previous UPDF from the current UPDF to get the high-pass TPDF).  also, i 
think Bart Locanthi (is he still on this planet?) and someone else did a 
simple paper back in the 90s about the possible benefits of high-pass 
dither.  wasn't a great paper or anything, but it was about the same point.


i remember mentioning this at an AES in the 90's, and Stanley *did* 
address it.  for straight dither it works okay, but for noise-shaping 
with feedback, to be perfectly legitimate, you want white TPDF dither 
(which requires adding or subtracting two independent UPDF random 
numbers).  and i agree with that.  it's just that if someone wanted to 
make a quick-and-clean high-pass dither with the necessary p.d.f., you 
can do that with the simple subtraction trick.  and the dither is not 
white but perfectly decouples the first two moments of the total 
quantization error.  it's just a simple trick that not good for too much.


--

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

[robert bristow-johnson]

 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] Thoughts on DSP books and neural networks

[robert bristow-johnson]

On 2/5/15 6:10 AM, Peter S wrote:


... as I'll die some day and those things that I
invented and are in my head will go to the grave with me,


welcome to the club.


  and future generations will need to reinvent all that knowledge.


i wouldn't assume that for me.  them future generations might not give a 
rat's ass what i think.


--

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] Thoughts on DSP books and neural networks

[robert bristow-johnson]

On 2/5/15 2:25 PM, Ethan Duni wrote:

'z=infinity' mean it's at the origin? I'm not 100% sure of the
terminology used here.

Sorry, I should have written at z=0, not infinity. Typing too fast at the
end of the day.


Well, I think that would be rather a semantic distinction or an
'implied' zero at the origin - in practice, no one would actually
calculate 0*x in an algorithm (as that would be pointless), though
you're right that during calculation and analyis of the filter, you
can treat the whole thing as a 2 pole / 2 zero filter with one or both
zeros at the origin, as a special case of the general 2 pole biquad
filter.

Right. So can the cookbook filters be made to put one of the zeros at the
origin, or do they always produce responses with two non-trivial zeros?


i don't think any of the cookbook filters have a zero at the origin.  
sometimes zeros at DC or Nyquist.  the cookbook EQ is not general.  even 
if you toss in an additional constant gain, it's 4 knobs.  Knud 
Christensen tossed in this additional symmetry parameter an that made 
it 5 knobs controlling independent things.  an Orfanidis parametric EQ 
is a subset of the Christensen model.  of course, the cookbook 
parametric (or the cookbook shelves) is a subset.


but just because of the 5 degree of freedom concept, i am pretty sure 
that the generalized biquad 
http://www.google.com/patents/WO2004054099A1?cl=en can have identical 
transfer function and frequency response of any LTI 2nd-order digital 
filter.  Knud's five parameters injectively map to five coefficients.


--

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] Thoughts on DSP books and neural networks

[robert bristow-johnson]

On 2/5/15 5:00 PM, Ethan Duni wrote:

P.S. Anyone who knows how to effectively turn ideas into money while
everyone can benefit, let me know. Patenting stuff doesn't sound like
a viable means to me.

Well, that's exactly what patents are for. I'm not sure why you don't
consider that viable. Is it to do with the costs and time required to file
a patent?

Absent a patent filing, you're stuck choosing between keeping your work
undisclosed as a trade secret, or publicizing it without any means of
collecting licensing or other revenues. That's why patents were introduced,
to cut through that knot and allow inventors to profit while still
disclosing their findings.

Note that if you decide to retain your work as a trade secret, there is no
legal barrier for others to reverse engineer it and use it without paying
you a dime. IANAL but someone could even come up with it independently and
patent it themselves.



patents are expensive.  getting a patent attorney to help costs 
something like $20K.  enforcing infringements of the patent is laborious 
(discovering the infringement) and costly (legal action).  publishing in 
the patent can teach a competitor how you do it and this competitor uses 
that information and adds his/her own twist to it and gets something 
better and different enough that you can't sue them for infringement.  i 
won't tell you how many patented IVL ideas i have made better after 
first learning them.  ('cuz it's a trade secret!)  some of those IVL 
ideas i had already had.  IVL *did* patent some obvious ideas and some 
prior art, IMHO.  i think their Vocalist patent has run out, i dunno.  
maybe even the independent tuning on pitch shift and formant shift, 
maybe that one has also run out.  maybe the turn the keyboard player's 
voice into a harmonizing background group of singers, maybe that patent 
has run out.  they try new patents as a way to extend the old ones.


--

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] R: Thoughts on DSP books and neural networks

[robert bristow-johnson]

On 2/5/15 6:48 PM, Marco Lo Monaco wrote:

I dont know very much about US IP laws but in Italy (EU), reverse
engineering in illegal unless for interoperability issues.



You can understand an algorithm only by measuring in-out relationships (very
difficult to understand the details of an algo by only doing this),


maybe, if it's LTI.


  but no
decompiling or modify-the-code-and-see-what-happens techniques.


how do they enforce that?  if someone is really good at it, and with a 
good logic-state analyzer and/or disassembler (remember MacNosy?), gets 
to look at the code after it's been decrypted, and figgers out what the 
math that gets done is, and then writes that math in his company 
notebook, how can they differentiate that from if the mathematical ideas 
didn't just pop into that someone's head and he or she wrote it down?


even if, in litigating the reverse engineering, they say the math is 
the same, he or she must have reverse engineered it, usually you can 
find something different (and often better) to do to it that ostensibly 
makes it not quite the same.


people don't volunteer evidence that is contrary to their own interest.


But actually you are also allowed to reverse engineer to fix some errors in
the code.


how about making something better in design?  not quite the same as 
fixing errors, even though both make the product better.


--

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] Thoughts on DSP books and neural networks

[robert bristow-johnson]

On 2/4/15 8:25 PM, Peter S wrote:

On 04/02/2015, robert bristow-johnsonr...@audioimagination.com  wrote:

i'm only saying that
with a 2nd-order filter, there are only 5 degrees of freedom.  only 5
knobs.  so when someone says they came up with a different or better
method of computing coefficients for *whatever* 2nd-order filter, my
first curiosity will be what is the transfer function and from that, we
usually find out it is equivalent to the Cookbook transfer function
except Q or bandwidth is defined differently.

My filter has 2 poles and 1 zero. Unlike the Cookbook filter, which
has 2 poles and 2 zeros.


your 2-pole 1-zero filter is equivalent to a 2-pole 2-zero filter with 
the possible difference of 1 sample delay (a zero at z=0).



I think that automatically assumes, the transfer function cannot be equivalent.


it *can* be made equivalent to the 5-parameter generalized biquad, 
essentially the standard peaking EQ with this tilt or symmetry parameter.


take a look at 
http://dsp.stackexchange.com/questions/19225/audio-eq-cookbook-without-frequency-warping/19253?s=1|0.1113#19253 





(And strictly speaking, the transfer curve of my filter is not
biquadratic, just BLT.)


it's biquadratic with b0 or b2 set to zero.

if it's second order in the denominator, even if b2 in the numerator is 
0, it still can be mapped to the Knud Christensen model with 5 knobs on 
it.  if that tilt or symmetry parameter that Knud introduces is 0, it's 
the old-fashioned peaking EQ that's a BPF in parallel to a wire, which 
is 3 knobs (one of which is the bandwidth knob) with possibly with a 
constant gain, a 4th knob.



That also means, that my filter is also faster to process.


4 coefficients is quicker than 5.

--

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

[music-dsp] 14-bit MIDI controls, how should we do Course and Fine?

[robert bristow-johnson]

this has probably been settled long ago, but i cannot from the standard, 
make perfect sense of it.


so the MIDI 1.0 Spec says:

___

...


STATUSDATA BYTESDESCRIPTION
...   ...   ...

1011  0ccc  Control Change
  0vvv  ccc: control # (0-121) (see notes 5-8)
vvv: control value

...

5.  ccc: control number

ccc Description

0   Continuous Controller 0 MSB
1   Continuous Controller 1 MSB (MODULATION BENDER)
2   Continuous Controller 2 MSB
3   Continuous Controller 3 MSB
4-31Continuous Controllers 4-31 MSB

32  Continuous Controller 0 LSB
33  Continuous Controller 1 LSB (MODULATION BENDER)
34  Continuous Controller 2 LSB
35  Continuous Controller 3 LSB
36-63   Continuous Controllers 4-31 LSB

...

7.  Continuous controllers are divided into Most Significant and Least
Significant Bytes.  If only seven bits of resolution are needed for any
particular controllers, only the MSB is sent.  It is not necessary 
to send the
LSB.  If more resolution is needed, then both are sent, first the 
MSB, then the

LSB.  If only the LSB has changed in value, the LSB may be sent without
re-sending the MSB.

...
___


it seems to me very unfortunate that, if they wanted the flexibility of 
optionally using Coarse control only (controls 0-31) *and* optionally 
Fine control, that they spec'd in Note 7: If more resolution is needed, 
then both are sent, first the MSB, then the LSB.  If only the LSB has 
changed in value, the LSB may be sent without re-sending the MSB.


if they were thinking clearly, they would have spec'd in Note 7: If 
more resolution is needed, then both are sent, first the LSB, then the 
MSB.  If only the LSB has changed in value, both the LSB must be sent 
followed by the MSB.  if they had done it this way, then the actual 
control update, that actually affects the synth, would happen only after 
receiving the MSB, whether the LSB was sent or not.  receiving the LSB 
would affect bits in a field, but they would be latched and have no 
effect until the MSB is also updated.


so, to keep with that spec, to be flexible about receiving either Course 
and/or Fine adjustments, *and* to avoid jaggies that happen when the 
actual control is changed after the MSB is changed, but the LSB has not 
yet been received, how do we best do it?


in the past, i had implemented this by simply masking and updating only 
bits 7-13 for an MSB control change, masking and updating only bits 0-6 
for an LSB change and when *either* changed, i have assembled the 14-bit 
value, scaled and offset it according to the Min and Max for that 
particular control, and output the value.  it's flexible enough to 
satisfy Note 7, but it has little glitches in the LSB.


like, let's say it's a slider (like Control #16) or the mod wheel 
(Control #1).  and let's say that we're going from one 14-bit value, 
0x207F (MSB=0x40, LSB=0x7F), to just a teeny bit higher: 0x2080 
(MSB=0x41, LSB=0x00).  if our MIDI receiver is flexible enough to react 
to only a change in the MSB, first the net control value will go from 
0x207F to 0x20FF, then to 0x2080.  so there will be a glitch nearly as 
big as one step of the Course control when the change intended was one 
teeny little step of Fine.


how best do we do this to both be compatible with the standard (either 
MSB or LSB can be received without the other), to update the value 
immediately upon reception of the MIDI message, and to avoid this kind 
of glitch?


it takes a little less than a millisecond to receive a 3-byte MIDI 
message. should we put in some kinda delay (like a sample-and-hold) on 
that which prevents updating the net control value until 1 or 2 
milliseconds after either the MSB or LSB is received?  or slewing the 
net control value (slewing smooths out thin little glitches)?  this is 
the only way to be totally flexible about receiving Course and Fine and 
(if we assume that MSB an LSB are received at adjacent times, about 1 ms 
apart) avoiding the glitch.  and the price to pay is a 1 or 2 ms delay 
in updating.


or, as folks in an unnamed synth company i have worked for did it: ditch 
(ignore) the LSB?  but 7 bits of resolution ain't always so good.


so how did you other folks deal with this?


oh, another question... for Control #5 Portamento time, does anyone 
know of hand how that time (in seconds or ms) is defined from the 14-bit 
control value?


and, since MIDI 1.0, are there definitions assigned to Controls 3, 9, 
14, and 15?  or Controls 20 to 31?  does anyone implement them?  if i 
cover all 16 Channels, i don't wanna carve out space for 16 undefined 
controls that are never used, or would 

[music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?

[robert bristow-johnson]

i'm resending this because of unexpected word wrapping and, as much as i 
intended to avoid it, a persistent misspelling.


so this may have been settled long ago, but i cannot from the standard, 
make perfect sense of it.


so the MIDI 1.0 Spec says:

___

...


STATUSDATA BYTESDESCRIPTION
...   ...   ...

1011  0ccc  Control Change
  0vvv  ccc: control # (0-121) (see notes 5-8)
vvv: control value

...

5.  ccc: control number

ccc Description

0   Continuous Controller 0 MSB
1   Continuous Controller 1 MSB (MODULATION BENDER)
2   Continuous Controller 2 MSB
3   Continuous Controller 3 MSB
4-31Continuous Controllers 4-31 MSB

32  Continuous Controller 0 LSB
33  Continuous Controller 1 LSB (MODULATION BENDER)
34  Continuous Controller 2 LSB
35  Continuous Controller 3 LSB
36-63   Continuous Controllers 4-31 LSB

...

7.  Continuous controllers are divided into Most Significant and Least
Significant Bytes.  If only seven bits of resolution are needed for
any particular controllers, only the MSB is sent.  It is not
necessary to send the LSB.  If more resolution is needed, then both
are sent, first the MSB, then the LSB.  If only the LSB has changed
in value, the LSB may be sent without re-sending the MSB.

...
___


it seems to me very unfortunate that, if they wanted the flexibility of 
optionally using Coarse control only (controls 0-31) *and* optionally 
Fine control, that they spec'd in Note 7: If more resolution is needed, 
then both are sent, first the MSB, then the LSB.  If only the LSB has 
changed in value, the LSB may be sent without re-sending the MSB.


if they were thinking clearly, they would have spec'd in Note 7: If 
more resolution is needed, then both are sent, first the LSB, then the 
MSB.  If only the LSB has changed in value, both the LSB must be sent 
followed by the MSB.  if they had done it this way, then the actual 
control update, that actually affects the synth, would happen only after 
receiving the MSB, whether the LSB was sent or not.  receiving the LSB 
would affect bits in a field, but they would be latched and have no 
effect until the MSB is also updated.


so, to keep with that spec, to be flexible about receiving either Coarse 
and/or Fine adjustments, *and* to avoid jaggies that happen when the 
actual control is changed after the MSB is changed, but the LSB has not 
yet been received, how do we best do it?


in the past, i had implemented this by simply masking and updating only 
bits 7-13 for an MSB control change, masking and updating only bits 0-6 
for an LSB change and when *either* changed, i have assembled the 14-bit 
value, scaled and offset it according to the Min and Max for that 
particular control, and output the value.  it's flexible enough to 
satisfy Note 7, but it has little glitches in the LSB.


like, let's say it's a slider (like Control #16) or the mod wheel 
(Control #1).  and let's say that we're going from one 14-bit value, 
0x207F (MSB=0x40, LSB=0x7F), to just a teeny bit higher: 0x2080 
(MSB=0x41, LSB=0x00).  if our MIDI receiver is flexible enough to react 
to only a change in the MSB, first the net control value will go from 
0x207F to 0x20FF, then to 0x2080.  so there will be a glitch nearly as 
big as one step of the Coarse control when the change intended was one 
teeny little step of Fine.


how best do we do this to both be compatible with the standard (either 
MSB or LSB can be received without the other), to update the value 
immediately upon reception of the MIDI message, and to avoid this kind 
of glitch?


it takes a little less than a millisecond to receive a 3-byte MIDI 
message. should we put in some kinda delay (like a sample-and-hold) on 
that which prevents updating the net control value until 1 or 2 
milliseconds after either the MSB or LSB is received?  or slewing the 
net control value (slewing smooths out thin little glitches)?  this is 
the only way to be totally flexible about receiving Coarse and Fine and 
(if we assume that MSB an LSB are received at adjacent times, about 1 ms 
apart) avoiding the glitch.  and the price to pay is a 1 or 2 ms delay 
in updating.


or, as folks in an unnamed synth company i have worked for did it: ditch 
(ignore) the LSB?  but 7 bits of resolution ain't always so good.


so how did you other folks deal with this?


oh, another question... for Control #5 Portamento time, does anyone 
know of hand how that time (in seconds or ms) is defined from the 14-bit 
control value?


and, since MIDI 1.0, are there definitions assigned to Controls 3, 9, 
14, and 15?  or Controls 20 to 31?  does anyone implement them?  if i 
cover all 16 

Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?

[robert bristow-johnson]

On 2/4/15 4:50 PM, STEFFAN DIEDRICHSEN wrote:

There's an easy trick to overcome this. Put the MSB into the upper and lower 7 
bits.


???


  If an LSB comes along, put it into the lower bits. This way, you reach with 
the MSB alone the maximum value of 0x3FFF. If a LSB comes along, it's welcome 
but its absence won't limit the range.

Hope this helps,



Steffan, i don't see how it helps.  the issue is not problems with 
range.  it's a problem of a glitch when one crosses the MSB boundary and 
both LSB and MSB are updated.


--

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] Efficiently modulate filter coefficients without artifacts?

[robert bristow-johnson]

i am mostly just listening here.  i'll get back to you Ross.  when 
filters blow up because of varying coefficients, don't they settle down 
some finite time after the coefs stop varying?


On 2/2/15 6:21 PM, Stefan Sullivan wrote:

I actually found by playing around with a particular biquad problem that
changing the topology of the filter had a greater impact on reducing
artifacts than proving bibo stability. In fact, any linearly interpolated
biquad coefficients between stable filters results in a stable filter,
including with nonzero initial conditions (
http://dsp.stackexchange.com/a/11267/5321).


i think so, too.  because the stability depends on the value of a2 and 
ramping from one stable value of a2 to another stable value shouldn't be 
romping through unstable territory.  but if there is vibrato connected 
to a filter's control parameters, i can see how a filter can go unstable 
an never settle down.



  The trick is that the bounds
may be different with nonzero initial conditions than with zero initial
conditions. In my case I was using direct form biquads with float
arithmetic. Switching to direct form II transposed (
https://ccrma.stanford.edu/~jos/fp/Transposed_Direct_Forms.html) did the
trick for my purposes. I got away with updating pretty infrequently without
hearing any clicks. Basically my theory is that the direct form II that I
was using was causing my states to be so high as to make the entire filter
just a lot more sensitive small changes.


i can't remember how Jean Laroche put it, but i thought it was something 
like showing, for a particular sample period, how the changed 
coefficients can be modeled as the previous unchanged coef but the 
states were made different so that coef times state comes out the same.  
but if you move a fader, and the fader slews, an you repeatedly 
recalculate coefficients for different slewed fader values, the 
different forms will behave differently during and immediately after the 
transition, but none of them should go purely unstable, just from moving 
a fader and stopping moving it.



  Essentially making the initial
conditions portion of the filter equation more dominant than the general
portion.




--

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] Efficiently modulate filter coefficients without artifacts?

[robert bristow-johnson]

On 2/3/15 7:07 PM, Ethan Duni wrote:

well, the output states, y[n-1] and y[n-2], will change if coefs change.

No, those have already been computed and (presumably) output at that point.
It's true that these states won't match what they would have been if you'd
been running the new coefficients from the beginning of time, but of course
they aren't supposed to in this context.


well, that's what i mean.  the Laroche point is that they might go crazy 
of coefficients are being continually modulated.



The point is that they retain their (pseudo)physical meaning ala the
difference equations in a Direct Form I filter - you're still simply taking
inputs and outputs and doing linear combinations with your coefficients,


i know, but y[n] could blow up, in some cases, if coefs are being 
continually modulated.



i think you can model the initial conditions of the states at time n=0 as

a function of x[n-1] and x[n-2].

The states are a function of *all* previous inputs, generally.



but, if in experiment A we have a stable BIBO DF1 filter with zero 
states, and in other experiment we have the same filter (with same 
coefficients), i can with only two samples x[0] and x[1], steer y[2] and 
y[3], to be whatever finite values you specify.  so that guy's question: 
*How do I check for stability of a filter with non-zero initial 
conditions?* is superfluous, in my opinion.

so, if the thing is stable for zero initial states, it's stable for

arbitrary finite initial states.  it's just super-position.

I think that what you intend to say here is essentially correct, but we
have to be careful how we define stable in this context. I.e., it is true
that a given BIBO-stable LTI filter with zero state is also stable for any
particular (finite) initial state you care to start it with (modulo
numerical effects). Which is not to say that it won't produce a really bad
transient artifact (i.e., much louder than the desired output signal).


oh, yeah.  and if these fictitious x[0] and x[1] required to get the 
feedback states set to arbitrary values are huge, one can expect a 
filtered click.



But if we think about doing this continuously, it's easy to see how those
huge switching transients could keep getting amplified and amplified on
each coefficient change.
yup.  i agree.  i thought that's what Jean Laroche was writing about.   
like what if you modulate your filter with some sinusoidal vibrato.  
that could send it to hell and different forms (like SVF or Ladder or 
DF-whatever) will behave differently.



  So the time-variant system isn't BIBO stable any
more. Although in my view even one such big switching transient is
unacceptable anyway, so stability is kind of beside the point.


BTW, i think the Normalized Ladder has states that are both have L2 norms

that are the same as the input L2 norm.

they preserve r.m.s amplitude (or energy).  no states blowing up once the

coefs stop changing.

Yeah IIRC the state update is basically a rotation?

yup.


  These stability
guarantees are what you get for the extra computational cost of normalized
ladder topology.


yup.  another advantage is that the resonant frequency is determined 
fully by the k1 coefficient.  same for lattice.  same for SVF.


L8r,

--

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

Imagination is more important than knowledge.



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

Re: [music-dsp] Efficiently modulate filter coefficients without artifacts?

[robert bristow-johnson]

On 2/1/15 6:32 AM, Ross Bencina wrote:

Hello Alan,

On 1/02/2015 4:51 AM, Alan O Cinneide wrote:
 Dear List,

 While filtering an audio stream, I'd like to change the filter's
 characteristics.

You didn't say what kind of filter, so I'll assume a bi-quad section.


 In order to do this without audible artifacts, I've been filtering a
 concurrent audio buffer (long enough so that the initial transient
 behaviour peeters out) and then crossfading.

 I can't believe that this is the most efficient design.  Can someone
 explain to me a better implementation or give me a reference which
 discusses such?

Cross-fading is not entirely unreasonable. Another option is to 
band-limit (smooth) the parameter change. For that you need a filter 
that is stable for audio-rate time-varying parameter change (not many 
are).


Giulio's suggestions are good ones. Here's a recent paper that surveys 
a range of approaches:


Wishnick, A. (2014) “Time-Varying Filters for Musical Applications” 
Proc. of the 17th Int. Conference on Digital Audio Effects (DAFx-14), 
Erlangen, Germany, September 1-5, 2014.


Available here:
http://www.dafx14.fau.de/papers/dafx14_aaron_wishnick_time_varying_filters_for_.pdf 



Here is a practical implementation of a time-variant stable filter:

http://www.cytomic.com/files/dsp/SvfLinearTrapezoidalSin.pdf
see also:
http://www.cytomic.com/technical-papers


also, i might add to the list, the good old-fashioned lattice (or 
ladder) filters.  the coefficients from a simple DF1 biquad can be 
mapped to lattice pretty directly.  and be mindful of the cosine 
problem when the resonant frequency is very low.  to fix the cosine 
problem, make use of this trig identity:


   cos(w0) = 1 - 2*(sin(w0/2))^2

replace all cos(w0) with the above and work out the lattice difference 
equations with cos() replaced.  that 1 will result in a wire in the 
structure, but the sin(w0/2) term will work well, even with 
single-precision floating point.  but cos(w0) does *not* work well with 
single-precision floats.  not when w0 is in the bottom couple of octaves.


--

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

[robert bristow-johnson]

On 12/24/14 4:32 AM, Nigel Redmon wrote:

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


Q:  so what's long and hard and full of Siemen?



  yeah—a German multinational corporation headquartered in Berlin and Munich.

;-)



--

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

Imagination is more important than knowledge.























A:   a submarine.


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

[robert bristow-johnson]

On 12/23/14 11:36 PM, Andrew Simper wrote:

On 24 December 2014 at 08:55, robert bristow-johnson
r...@audioimagination.com  wrote:

the OTAs are there for voltage-controlled gain or, really, a
voltage-controlled resistor to change the tuning of the VCF.  from the
datasheet

They are an idealised voltage controlled current source, it looks
neater to use an OTA symbol for them.


for the anal-retentive, it looks like a non-trivial resistance is hidden 
from view.




http://users.ece.gatech.edu/~lanterma/sdiy/datasheets/ota/lm13600.pdf

the LM13600 looks like the transconductance, g_m is

g_m = ( 20/volt ) * I_ABC

okay, i get that.  and it is this transconductance that algebraically goes
with the capacitance to get a time constant and a filter spec.  that's was
my original problem, because it's not an obvious property since the
resistor that *must* go with the cap is hidden inside the OTA and, in the
olden daze, i only messed around with op-amps or transistor circuits.

Yes the g term is your 1/R of your resistor, you can set c1, c2 to
whatever you want then set the g term to get where you want in
frequency, they form your RC 1 pole low pass filters, which should be
clear from a glance at the diagram.


when i glance at it, i see no R for the RC.  none at all.



It is the way that you can mix the inputs into a Sallen Key filter
that is new.


they're more like gates or switches (and nicely modeled as gains) and a
couple of summers.  also, again it show's my creaky old age, but this is not
what we used to call a Sallen-Key circuit (thems were much simpler).  but
it, with all of this voltage-controlled resistor stuff, can take up a
similar form for a SK, at least for the LPF.

They aren't switches, you can mix them at any level you want, as shown
later in the paper to form shelves etc.


listen, when it's a single input and multiple outputs, we don't call it 
a multiplexer, we call it a demultiplexer.


a mixer has multiple inputs and (for mono) a single output.  i know 
that m0, m1, m2 can be any values we want in the analysis, but they're 
gates or switches.  that's what they're being used for.



Anyway, please forget about it diagram if it confuses you.

legit circuit diagrams ain't confusing.  signal flow diagrams ain't
confusing.  mixed metaphors can be confusing.  wires are sorta physical
things that you can do Kirchoff's laws on, signal paths are more like
information pipes in which numbers flow.  when i see a line go into a
capacitor, i think it's a wire.  when i see a line go into an adder or a
gain block, i think it's a signal path.

There isn't much point putting in a bunch of matched resistors, it
just makes the diagram messier. Idealised components are all that is
needed and they are unambiguous. Re-draw the diagram yourself if you
prefer, but this was the most succinct way to express the idea.



well, as Marco pointed out to me, it might be useful to include a note 
that all the adders and gain blocks have infinite input impedance and 
zero output impedance.  and it might be useful to explicitly show the 
output current of the OTA to be g times the diff-amp input voltage.



in the BPF case, you might also want to compensate Q because the bandwidth
will get squished as w0 gets close to Nyquist.  maybe not, whether it's LPF
or HPF or BPF, the bilinear transform maps the peak heights exactly (just
maps the peaks to slightly different frequencies).  you might want to
preserve the peak height instead and then you don't want to pre-warp Q when
the resonant frequency gets high.

Look later on in the paper at the Bell section.




what page is that?  haven't found anything that appears so titled.  and 
i am not reverse engineering code, and other than plots, i don't see 
much else in the paper.  haven't seen anything regarding compensation of 
effects of bilinear transform.



2nd-order is 2nd-order.  2nd-order IIR filters, whether they be DF1 or 
DF2 or transposed DF1 or DF2 or Lattice or Normalized Lattice or Hal's 
SVF or Rader-Gold or whatever form might pop out of your simulation of 
whatever analog filter, there are, when you boil it down, exactly 5 
independent coefficients and 5 degrees of freedom.   this is why, 2 
decades ago, i made this observation regarding bell parametric eq:


 http://www.aes.org/e-lib/browse.cfm?elib=6326

of course, one degree of freedom: the gain at Nyquist, need not be fixed 
to 0 dB, which Orfanidis made use of and which Knud Christensen has 
generalized for the 2nd-order IIR filter.  so, because of that, i 
recognize that they ain't *all* equivalent.  but most are.  point is, if 
you're modeling your analog bell filter (which has gain out at infinity 
of 0 dB) using trapezoidal rule for the integration (which is the same 
as bilinear transform, so the analog frequency of infinity gets mapped 
to Nyquist) done by the two caps, it *is* one of those that is 
equivalent in the sense of that Equivalence paper.  the coefficient 
calculation is a done deal.  it's

Re: [music-dsp] Sallen Key with sin only coefficient computation

[robert bristow-johnson]

On 12/23/14 4:43 AM, Andrew Simper wrote:

Everyone on the synth diy list didn't even bat an eyelid at that
diagram, they just said stuff like Thanks and That's very
interesting, I have not seen it done that way before.


i'm not ashamed to point out what i don't know.  you can't spell 
analysis without anal and we anal-retentives like to see all of the 
t's dotted and i's crossed.  otherwise we can't make sense of it.


the OTAs are there for voltage-controlled gain or, really, a 
voltage-controlled resistor to change the tuning of the VCF.  from the 
datasheet


http://users.ece.gatech.edu/~lanterma/sdiy/datasheets/ota/lm13600.pdf

the LM13600 looks like the transconductance, g_m is

   g_m = ( 20/volt ) * I_ABC

okay, i get that.  and it is this transconductance that algebraically 
goes with the capacitance to get a time constant and a filter spec.  
that's was my original problem, because it's not an obvious property 
since the resistor that *must* go with the cap is hidden inside the 
OTA and, in the olden daze, i only messed around with op-amps or 
transistor circuits.



It is the way that you can mix the inputs into a Sallen Key filter
that is new.


they're more like gates or switches (and nicely modeled as gains) and a 
couple of summers.  also, again it show's my creaky old age, but this is 
not what we used to call a Sallen-Key circuit (thems were much 
simpler).  but it, with all of this voltage-controlled resistor stuff, 
can take up a similar form for a SK, at least for the LPF.



Anyway, please forget about it diagram if it confuses you.


legit circuit diagrams ain't confusing.  signal flow diagrams ain't 
confusing.  mixed metaphors can be confusing.  wires are sorta physical 
things that you can do Kirchoff's laws on, signal paths are more like 
information pipes in which numbers flow.  when i see a line go into a 
capacitor, i think it's a wire.  when i see a line go into an adder or a 
gain block, i think it's a signal path.


someone (either Andrew or Marcos) said that the input impedances to the 
adders and gain blocks are infinite and the output impedances are zero 
(but i know that the output impedance of the OTA is *not* zero, but is 
much higher).  only with that information can the mixed symbol circuit 
diagram make sense for the anal retentive (and then we anal retentives 
would draw it differently).



va1 == (m0 v0) - (m1 v0 + v1)
va2 == (m1 v0 + v1) - (v2)
v1 == (k v2 - m2 v0) + vc1  --  vc1 == (v1) - (k v2 - m2 v0)
v2 == m2 v0 + vc2  --   vc2 == (v2) - (m2 v0)

solve the simultaneous nodal circuit equations for v2/v0:
0 == g va1 - s vc1
0 == g va2 - s vc2


i was wondering where the values of c1 and c2 come into it.  i think it's

   0 == g va1 - s c1 vc1
   0 == g va2 - s c2 vc2

which, for me, would be simply stated

 g va1 = s c1 vc1
 g va2 = s c2 vc2

to get current, you gotta have what multiplies va1 and vc1 both have dimension 
of conductance or 1/impedance.

and we're assuming both g's are the same?  in the KLM-307 diagram, the I_ABC 
currents are just split from a single node, but how do they guarantee the 
current splits equally?  that solely depends on the mismatch of input 
characteristics of pins 1 or 16 of the LM13600.  if they're mismatched, more 
current will flow into one than the other and i wouldn't expect the two g's to 
be the same.



and the solution is:
  H(s) = (g^2 m0 + g m1 s + m2 s^2)/(g^2 - g (k - 2) s + s^2)


since, in the KLM diagram, c1 = c2 = C, then you can just team them up 
with s.  but if c1 and c2 are different, your solution has to be fixed.


   m0  +  m1 C/g s  +  m2 (C/g)^2 s^2
  H(s)  =  v2/v0  =   
   1  +  (2-k) C/g s  +  (C/g)^2 s^2

in all combinations of m0, m1, m2, the (angular) resonant frequency is at

w0 = g/C

and Q at

Q = 1/(2-k)

(k better be less than 2 because that term in the denominator needs to be 
positive.)


and for m0 = m1 = 0  and  m2 = 1, you get a legit two-pole HPF.

so, for the analog case, you want to set

   g = 2*pi*f0 * C

and

   k  =  2 - 1/Q .

now, if you are modeling each component individually and using the trapezoid 
rule to integrate the currents in c1 and c2, this will work just like bilinear 
transform with *no* compensation for frequency warping.  i might suggest 
bumping up the resonant frequency (and thus g) to compensate for that:

  w0--  2*Fs * tan(w0/(2*Fs))

or

  g  =  2*Fs*tan(pi*f0/Fs) * C

where Fs is the sample rate.  otherwise your trapezoidal rule modeling will get 
the resonant frequency off a little bit (it will come out flat) as you tune it 
closer to Nyquist.

in the BPF case, you might also want to compensate Q because the bandwidth will 
get squished as w0 gets close to Nyquist.  maybe not, whether it's LPF or HPF 
or BPF, the bilinear transform maps the peak heights exactly (just maps the 
peaks to slightly different frequencies).  you might want to 

Re: [music-dsp] Sallen Key with sin only coefficient computation

[robert bristow-johnson]

On 12/22/14 12:27 AM, Andrew Simper wrote:

I've seen in many Sallen Key circuits people stick the input signal into
various points to generate some different responses, but always the high
pass is only 1 pole.

i haven't seen that with the SK.  for HPF, i've only seen it with the the
R's and C's swapped.  like with
http://sim.okawa-denshi.jp/en/OPseikiHikeisan.htm .

I'm referring to the MS20 and Steiner Parker filters,



http://machines.hyperreal.org/manufacturers/Korg/MS-synths/schematics/KLM-307.GIF


...

http://www.cgs.synth.net/modules/cgs35_syntha_vcf.html .


okay, neither of those seem to be what you have at 
http://cytomic.com/files/dsp/SkfInputMixing.jpg .


these LM13600's are more than a simple transconductance amplifier. they 
are current-controlled transconductance amplifiers and that current 
going into pins 1 or 16 of the chip determine the transconductance gain 
g_m.  in your analysis in your paper, are you assuming g is constant 
(or set independently) and then using time-domain analysis (modeling 
with trapezoidal integration) for the rest of the circuit?  or are you 
modeling a varying g, because i don't see that explicitly in 
SkfInputMixing.jpg?



--

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