From douglas at music.columbia.edu  Tue Sep  1 07:00:00 2009
From: douglas at music.columbia.edu (douglas repetto)
Date: Tue,  1 Sep 2009 07:00:00 -0400 (EDT)
Subject: [music-dsp] [admin] music-dsp FAQ
Message-ID: <20090901110000.2A4E23EC7E8@music.columbia.edu>

Hi,

Just a reminder that if you are new to the list you should read the
music-dsp FAQ. It contains answers to both technical _and_
adminstrative questions that often come up on the list. If your question
appears in the FAQ it is safe to assume that it has been discussed on the
list many times in the past, and you should probably have a look through
the list archives before posting your question to the list.

http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html


Also of interest to new and not-so-new list members:

The music-dsp list archives
http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html

The music-dsp source code archive
http://www.musicdsp.org

music-dsp books and reviews
http://music.columbia.edu/cmc/music-dsp/dspbooks.html


All this and more at:
http://music.columbia.edu/cmc/music-dsp


Hasta la pasta,
douglas

(this is an automated message sent out on the 1st and 15th of each month)

From hannes_loeschke at yahoo.de  Tue Sep  1 10:18:39 2009
From: hannes_loeschke at yahoo.de (=?iso-8859-1?Q?Hannes_L=F6schke?=)
Date: Tue, 1 Sep 2009 14:18:39 +0000 (GMT)
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <4A9BF9D6.1090402@tascam.com>
References: <02ac01ca23ee$31e48950$0473a8c0@rossmacbook>
	<4A9BF9D6.1090402@tascam.com>
Message-ID: <569401.13300.qm@web23707.mail.ird.yahoo.com>

Isn't the general aim of compression to get a louder signal?

The naive approach would be to adjust the gain in a way that 0dB input comes out at 0dB output by apllying the maximum gain reduction. In that case all the attacks would be pushed over 0dB into your (hopefully existing) headroom an possibly cause clipping.

Applying half the maximum gain reduction sounds like an attemt to prevent attacks from clipping for a reasonable range of attack times and signals. I don't know any TASCAM compresors, but maintaining percveived loudness doesn't sound like a sensible goal for automatic gain adjustments in compressors to me.

Taking attack time into account depends on the signal you use. Send an impulse through the compressor and any setting apart from 0ms schould essentially pass the impulse unchanged. Any automatic gain makeup would cause clipping in for an impulse. 

 
Hannes



----- Urspr?ngliche Mail ----
Von: Tom Duffy <tduffy at tascam.com>
An: A discussion list for music-related DSP <music-dsp at music.columbia.edu>
Gesendet: Montag, den 31. August 2009, 18:27:02 Uhr
Betreff: Re: [music-dsp] computing compressor automatic makeup gain (?)

The way it is implemented in TASCAM products:

Calculate the amount of gain reduction would be applied to a 0dBFS
signal.
Halve that.
Add it.

e.g. At Threshold = -20dB, with 2:1 compression, a 0dB signal would
be reduced by 10dB. Therefore the auto makeup gain applied would be
5dB.
This method was found empirically to maintain perceived loudness
over a range of thresholds and ratios.
In your example, making up the entire gain to bring 0dB back to
where it was results in an overly "loud" signal.

There are more complicated things you could do by including the
attack and release times into the equation. A faster attack means
the loudness will be reduced more for the same threshold and
ratio settings, therefore more automatic gain is OK.
at Attack = 0ms, maybe a 100% makeup would sound OK.

Tom

-------- Original Message --------
Subject: [music-dsp] computing compressor automatic makeup gain (?)
From: Ross Bencina <rossb-lists at audiomulch.com>
To: A discussion list for music-related DSP <music-dsp at music.columbia.edu>
Date: 8/23/2009 5:35 AM

Hi Everyone

This question was asked here a few years back but without a clear answer.

I'm wondering whether there's a standard (or preferred) way to calculate 
the
amount of automatic makeup gain required in a compressor, given a 
particular
threshold/ratio/compression curve. I realise that the concept of automatic
makeup is problematic, but enough compressors offer the feature that there
must at least be known approaches to implementing it.

I assume that its done by calculating the amount of gain required to 
make an
input of  XdB have the same output level. I'm not sure what X should be
though, 0db?

E.g. With a hard-knee compressor, threshold at -10dB, ratio of 2:1,
compressing a 0dB input would give a -5dB output, and therefore the
automatic makeup gain should be +5dB. Does that sound correct/incorrect to
anyone?

I'd be interested to hear about alternative approaches or whether anyone
knows the actual reference levels for auto makeup gain in hardware
compressors.

Thanks!

Ross.

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


NOTICE: This electronic mail message and its contents, including any attachments hereto (collectively, "this e-mail"), is hereby designated as "confidential and proprietary." This e-mail may be viewed and used only by the person to whom it has been sent and his/her employer solely for the express purpose for which it has been disclosed and only in accordance with any confidentiality or non-disclosure (or similar) agreement between TEAC Corporation or its affiliates and said employer, and may not be disclosed to any other person or entity.  
 




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



      

From tduffy at tascam.com  Tue Sep  1 12:33:13 2009
From: tduffy at tascam.com (Tom Duffy)
Date: Tue, 01 Sep 2009 09:33:13 -0700
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <569401.13300.qm@web23707.mail.ird.yahoo.com>
References: <02ac01ca23ee$31e48950$0473a8c0@rossmacbook>	<4A9BF9D6.1090402@tascam.com>
	<569401.13300.qm@web23707.mail.ird.yahoo.com>
Message-ID: <4A9D4CC9.40502@tascam.com>

(sorry for top-post style, that's all I'm set up to do)

A compressor's role is to change (generally reduce) the dynamic range
of a signal.
Without any gain, setting the threshold low (e.g. -40dB) and setting
the compression ratio high, e.g. 1:100, the output signal will be mostly
40dB lower than the input signal.  That's not a louder signal.
Adding 40dB of gain now gives you peaks over the prior signal signal
level, depending on the attack speed.

"Mastering Loudness" is achieved by making the peaks meet 0dBFS,
after you've reduced the dynamic range; it's a simple gain stage
after a compressor.
"Loudness" in the last 10 years or so has been also achieved by
letting the peaks go above 0dBFS and simply chopping them off, which
is a high distortion (therefore non-musical) transformation.

There is no sense in sending impulses through a compressor, it is
by definition a non-linear system, that would tell you nothing about
it.

Compression as a tool for managing high dynamic range signals during
recording (e.g. TASCAM products) is different from compression as a
component in "making things louder".

In general, you don't want to have to adjust the gain every time you
change the compressor settings, so keeping the perceived level about
the same eliminates some of the "louder sounds better, quieter
sounds worse" psychoacoustic effect, and lets you concentrate on the
dynamics of the signal you are working on.

Tom.

-------- Original Message --------
Subject: Re: [music-dsp] computing compressor automatic makeup gain (?)
From: Hannes L?schke <hannes_loeschke at yahoo.de>
To: A discussion list for music-related DSP <music-dsp at music.columbia.edu>
Date: 9/1/2009 7:18 AM

Isn't the general aim of compression to get a louder signal?

The naive approach would be to adjust the gain in a way that 0dB input 
comes out at 0dB output by apllying the maximum gain reduction. In that 
case all the attacks would be pushed over 0dB into your (hopefully 
existing) headroom an possibly cause clipping.

Applying half the maximum gain reduction sounds like an attemt to 
prevent attacks from clipping for a reasonable range of attack times and 
signals. I don't know any TASCAM compresors, but maintaining percveived 
loudness doesn't sound like a sensible goal for automatic gain 
adjustments in compressors to me.

Taking attack time into account depends on the signal you use. Send an 
impulse through the compressor and any setting apart from 0ms schould 
essentially pass the impulse unchanged. Any automatic gain makeup would 
cause clipping in for an impulse.

 
Hannes



----- Urspr?ngliche Mail ----
Von: Tom Duffy <tduffy at tascam.com>
An: A discussion list for music-related DSP <music-dsp at music.columbia.edu>
Gesendet: Montag, den 31. August 2009, 18:27:02 Uhr
Betreff: Re: [music-dsp] computing compressor automatic makeup gain (?)

The way it is implemented in TASCAM products:

Calculate the amount of gain reduction would be applied to a 0dBFS
signal.
Halve that.
Add it.

e.g. At Threshold = -20dB, with 2:1 compression, a 0dB signal would
be reduced by 10dB. Therefore the auto makeup gain applied would be
5dB.
This method was found empirically to maintain perceived loudness
over a range of thresholds and ratios.
In your example, making up the entire gain to bring 0dB back to
where it was results in an overly "loud" signal.

There are more complicated things you could do by including the
attack and release times into the equation. A faster attack means
the loudness will be reduced more for the same threshold and
ratio settings, therefore more automatic gain is OK.
at Attack = 0ms, maybe a 100% makeup would sound OK.

Tom

-------- Original Message --------
Subject: [music-dsp] computing compressor automatic makeup gain (?)
From: Ross Bencina <rossb-lists at audiomulch.com>
To: A discussion list for music-related DSP <music-dsp at music.columbia.edu>
Date: 8/23/2009 5:35 AM

Hi Everyone

This question was asked here a few years back but without a clear answer.

I'm wondering whether there's a standard (or preferred) way to calculate
the
amount of automatic makeup gain required in a compressor, given a
particular
threshold/ratio/compression curve. I realise that the concept of automatic
makeup is problematic, but enough compressors offer the feature that there
must at least be known approaches to implementing it.

I assume that its done by calculating the amount of gain required to
make an
input of  XdB have the same output level. I'm not sure what X should be
though, 0db?

E.g. With a hard-knee compressor, threshold at -10dB, ratio of 2:1,
compressing a 0dB input would give a -5dB output, and therefore the
automatic makeup gain should be +5dB. Does that sound correct/incorrect to
anyone?

I'd be interested to hear about alternative approaches or whether anyone
knows the actual reference levels for auto makeup gain in hardware
compressors.

Thanks!

Ross.

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


NOTICE: This electronic mail message and its contents, including any 
attachments hereto (collectively, "this e-mail"), is hereby designated 
as "confidential and proprietary." This e-mail may be viewed and used 
only by the person to whom it has been sent and his/her employer solely 
for the express purpose for which it has been disclosed and only in 
accordance with any confidentiality or non-disclosure (or similar) 
agreement between TEAC Corporation or its affiliates and said employer, 
and may not be disclosed to any other person or entity.
 




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



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


NOTICE: This electronic mail message and its contents, including any attachments hereto (collectively, "this e-mail"), is hereby designated as "confidential and proprietary." This e-mail?may be viewed and used only by the person to whom it has been sent and his/her employer?solely for the express purpose for which it has been disclosed and only in?accordance with any confidentiality or non-disclosure (or similar) agreement between TEAC Corporation or its affiliates and said employer, and may not be disclosed to any other person or entity. ?
?

 


?

From joey.mckay at comp.dit.ie  Wed Sep  2 10:25:03 2009
From: joey.mckay at comp.dit.ie (Joey McKay)
Date: Wed, 2 Sep 2009 15:25:03 +0100 (IST)
Subject: [music-dsp] IPEM Toolbox original installer
Message-ID: <4872.147.252.228.107.1251901503.squirrel@fionn.comp.dit.ie>

Hello,

I'm wondering does anybody have the original closed-source release with
installer for the IPEM Toolbox? The link to the installer on the site is
broken: http://www.ipem.ugent.be/Toolbox/ The original release was for
Matlab 5.3.1 and 6.0.

If not, then any working copy of IPEM Toolbox would be great or advice on
how to get the matlab/C source files working together.

It would be a great help if anybody can assist.

Kindest regards,

Joey McKay,
Digital Audio Research Group,
Room 13,
DIT Kevin St.
www.audioresearchgroup.com
Phone: +353 1 402 2862


From kcdixon at mtu.edu  Thu Sep  3 01:25:17 2009
From: kcdixon at mtu.edu (Kevin Dixon)
Date: Wed, 02 Sep 2009 22:25:17 -0700
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <4A9D4CC9.40502@tascam.com>
References: <02ac01ca23ee$31e48950$0473a8c0@rossmacbook>	<4A9BF9D6.1090402@tascam.com>	<569401.13300.qm@web23707.mail.ird.yahoo.com>
	<4A9D4CC9.40502@tascam.com>
Message-ID: <4A9F533D.7050906@mtu.edu>

Thanks for the insight Tom, as a bassist and engineer, I would agree 
with your (and TASCAM's) assessment of how this should work

-Kevin

Tom Duffy wrote:
> (sorry for top-post style, that's all I'm set up to do)
>
> A compressor's role is to change (generally reduce) the dynamic range
> of a signal.
> Without any gain, setting the threshold low (e.g. -40dB) and setting
> the compression ratio high, e.g. 1:100, the output signal will be mostly
> 40dB lower than the input signal.  That's not a louder signal.
> Adding 40dB of gain now gives you peaks over the prior signal signal
> level, depending on the attack speed.
>
> "Mastering Loudness" is achieved by making the peaks meet 0dBFS,
> after you've reduced the dynamic range; it's a simple gain stage
> after a compressor.
> "Loudness" in the last 10 years or so has been also achieved by
> letting the peaks go above 0dBFS and simply chopping them off, which
> is a high distortion (therefore non-musical) transformation.
>
> There is no sense in sending impulses through a compressor, it is
> by definition a non-linear system, that would tell you nothing about
> it.
>
> Compression as a tool for managing high dynamic range signals during
> recording (e.g. TASCAM products) is different from compression as a
> component in "making things louder".
>
> In general, you don't want to have to adjust the gain every time you
> change the compressor settings, so keeping the perceived level about
> the same eliminates some of the "louder sounds better, quieter
> sounds worse" psychoacoustic effect, and lets you concentrate on the
> dynamics of the signal you are working on.
>
> Tom.
>
> -------- Original Message --------
> Subject: Re: [music-dsp] computing compressor automatic makeup gain (?)
> From: Hannes L?schke <hannes_loeschke at yahoo.de>
> To: A discussion list for music-related DSP <music-dsp at music.columbia.edu>
> Date: 9/1/2009 7:18 AM
>
> Isn't the general aim of compression to get a louder signal?
>
> The naive approach would be to adjust the gain in a way that 0dB input 
> comes out at 0dB output by apllying the maximum gain reduction. In that 
> case all the attacks would be pushed over 0dB into your (hopefully 
> existing) headroom an possibly cause clipping.
>
> Applying half the maximum gain reduction sounds like an attemt to 
> prevent attacks from clipping for a reasonable range of attack times and 
> signals. I don't know any TASCAM compresors, but maintaining percveived 
> loudness doesn't sound like a sensible goal for automatic gain 
> adjustments in compressors to me.
>
> Taking attack time into account depends on the signal you use. Send an 
> impulse through the compressor and any setting apart from 0ms schould 
> essentially pass the impulse unchanged. Any automatic gain makeup would 
> cause clipping in for an impulse.
>
>  
> Hannes
>
>
>
> ----- Urspr?ngliche Mail ----
> Von: Tom Duffy <tduffy at tascam.com>
> An: A discussion list for music-related DSP <music-dsp at music.columbia.edu>
> Gesendet: Montag, den 31. August 2009, 18:27:02 Uhr
> Betreff: Re: [music-dsp] computing compressor automatic makeup gain (?)
>
> The way it is implemented in TASCAM products:
>
> Calculate the amount of gain reduction would be applied to a 0dBFS
> signal.
> Halve that.
> Add it.
>
> e.g. At Threshold = -20dB, with 2:1 compression, a 0dB signal would
> be reduced by 10dB. Therefore the auto makeup gain applied would be
> 5dB.
> This method was found empirically to maintain perceived loudness
> over a range of thresholds and ratios.
> In your example, making up the entire gain to bring 0dB back to
> where it was results in an overly "loud" signal.
>
> There are more complicated things you could do by including the
> attack and release times into the equation. A faster attack means
> the loudness will be reduced more for the same threshold and
> ratio settings, therefore more automatic gain is OK.
> at Attack = 0ms, maybe a 100% makeup would sound OK.
>
> Tom
>
> -------- Original Message --------
> Subject: [music-dsp] computing compressor automatic makeup gain (?)
> From: Ross Bencina <rossb-lists at audiomulch.com>
> To: A discussion list for music-related DSP <music-dsp at music.columbia.edu>
> Date: 8/23/2009 5:35 AM
>
> Hi Everyone
>
> This question was asked here a few years back but without a clear answer.
>
> I'm wondering whether there's a standard (or preferred) way to calculate
> the
> amount of automatic makeup gain required in a compressor, given a
> particular
> threshold/ratio/compression curve. I realise that the concept of automatic
> makeup is problematic, but enough compressors offer the feature that there
> must at least be known approaches to implementing it.
>
> I assume that its done by calculating the amount of gain required to
> make an
> input of  XdB have the same output level. I'm not sure what X should be
> though, 0db?
>
> E.g. With a hard-knee compressor, threshold at -10dB, ratio of 2:1,
> compressing a 0dB input would give a -5dB output, and therefore the
> automatic makeup gain should be +5dB. Does that sound correct/incorrect to
> anyone?
>
> I'd be interested to hear about alternative approaches or whether anyone
> knows the actual reference levels for auto makeup gain in hardware
> compressors.
>
> Thanks!
>
> Ross.
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews,
> dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>
>
> NOTICE: This electronic mail message and its contents, including any 
> attachments hereto (collectively, "this e-mail"), is hereby designated 
> as "confidential and proprietary." This e-mail may be viewed and used 
> only by the person to whom it has been sent and his/her employer solely 
> for the express purpose for which it has been disclosed and only in 
> accordance with any confidentiality or non-disclosure (or similar) 
> agreement between TEAC Corporation or its affiliates and said employer, 
> and may not be disclosed to any other person or entity.
>  
>
>
>
>
>  
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, 
> dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>
>
>
>  
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, 
> dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>
>
> NOTICE: This electronic mail message and its contents, including any attachments hereto (collectively, "this e-mail"), is hereby designated as "confidential and proprietary." This e-mail may be viewed and used only by the person to whom it has been sent and his/her employer solely for the express purpose for which it has been disclosed and only in accordance with any confidentiality or non-disclosure (or similar) agreement between TEAC Corporation or its affiliates and said employer, and may not be disclosed to any other person or entity.  
>  
>
>  
>
>
>  
> --
> dupswapdrop -- the music-dsp mailing list and website: 
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
> http://music.columbia.edu/cmc/music-dsp 
> http://music.columbia.edu/mailman/listinfo/music-dsp
>   


From rbj at audioimagination.com  Thu Sep  3 11:03:15 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Thu, 3 Sep 2009 11:03:15 -0400
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <4A9F533D.7050906@mtu.edu>
References: <02ac01ca23ee$31e48950$0473a8c0@rossmacbook>	<4A9BF9D6.1090402@tascam.com>	<569401.13300.qm@web23707.mail.ird.yahoo.com>
	<4A9D4CC9.40502@tascam.com> <4A9F533D.7050906@mtu.edu>
Message-ID: <8516FFD1-E3C9-427F-9D7F-8576463444E4@audioimagination.com>


On Sep 3, 2009, at 1:25 AM, Kevin Dixon wrote:

> Thanks for the insight Tom, as a bassist and engineer, I would agree
> with your (and TASCAM's) assessment of how this should work
>
>
> Tom Duffy wrote:
>>
>> A compressor's role is to change (generally reduce) the dynamic range
>> of a signal.
>> Without any gain, setting the threshold low (e.g. -40dB) and setting
>> the compression ratio high, e.g. 1:100, the output signal will be  
>> mostly
>> 40dB lower than the input signal.  That's not a louder signal.
>> Adding 40dB of gain now gives you peaks over the prior signal signal
>> level, depending on the attack speed.
>>
>> "Mastering Loudness" is achieved by making the peaks meet 0dBFS,
>> after you've reduced the dynamic range; it's a simple gain stage
>> after a compressor.
>> "Loudness" in the last 10 years or so has been also achieved by
>> letting the peaks go above 0dBFS and simply chopping them off, which
>> is a high distortion (therefore non-musical) transformation.
>>
>> There is no sense in sending impulses through a compressor, it is
>> by definition a non-linear system, that would tell you nothing about
>> it.
>>

this last statement, i cannot agree with.  i look at compressors and  
limiters as being the same species of animal.

if your compressor or limiter is acting on peak amplitude rather than  
r.m.s., sending in impulses that exceed the threshold or knee will  
tell you much more than nothing about what the compressor is doing.

being a non-linear system means that the impulse response cannot tell  
you how the device will respond to all other inputs.  for a linear  
time-invariant system, the impulse response is sufficient to tell you  
how the system will behave for any general input.


>> Compression as a tool for managing high dynamic range signals during
>> recording (e.g. TASCAM products) is different from compression as a
>> component in "making things louder".

how are they different *qualitatively*?  different attack and release  
times, different mapping curve, different overall gain.

a multiband compressor is qualitatively different, but i might  
imagine such used in either situation.


>> In general, you don't want to have to adjust the gain every time you
>> change the compressor settings, so keeping the perceived level about
>> the same eliminates some of the "louder sounds better, quieter
>> sounds worse" psychoacoustic effect, and lets you concentrate on the
>> dynamics of the signal you are working on.

it seems to me that the issue is whether you want to tack down the  
knee or corner to a certain level, or if you want to tack down 0 dB  
FS, or somewhere in between.  but those are settings; i don't see the  
qualitative difference.


--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From didid at skynet.be  Thu Sep  3 11:21:30 2009
From: didid at skynet.be (Didier Dambrin)
Date: Thu, 3 Sep 2009 17:21:30 +0200
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <8516FFD1-E3C9-427F-9D7F-8576463444E4@audioimagination.com>
References: <02ac01ca23ee$31e48950$0473a8c0@rossmacbook>	<4A9BF9D6.1090402@tascam.com>	<569401.13300.qm@web23707.mail.ird.yahoo.com><4A9D4CC9.40502@tascam.com>
	<4A9F533D.7050906@mtu.edu>
	<8516FFD1-E3C9-427F-9D7F-8576463444E4@audioimagination.com>
Message-ID: <0B131DF30937480B94C0492E851D342F@GOLAMD>

IMHO the only difference between a compressor and a limiter is the 
lookahead/latency. A limiter absolutely requires one to do its job properly, 
a compressor can exist without (but will then start acting as an expander). 
A limiter must also work with peaks, not RMS. So I'd class a limiter as a 
compressor with more strict requirements.




>
> On Sep 3, 2009, at 1:25 AM, Kevin Dixon wrote:
>
>> Thanks for the insight Tom, as a bassist and engineer, I would agree
>> with your (and TASCAM's) assessment of how this should work
>>
>>
>> Tom Duffy wrote:
>>>
>>> A compressor's role is to change (generally reduce) the dynamic range
>>> of a signal.
>>> Without any gain, setting the threshold low (e.g. -40dB) and setting
>>> the compression ratio high, e.g. 1:100, the output signal will be
>>> mostly
>>> 40dB lower than the input signal.  That's not a louder signal.
>>> Adding 40dB of gain now gives you peaks over the prior signal signal
>>> level, depending on the attack speed.
>>>
>>> "Mastering Loudness" is achieved by making the peaks meet 0dBFS,
>>> after you've reduced the dynamic range; it's a simple gain stage
>>> after a compressor.
>>> "Loudness" in the last 10 years or so has been also achieved by
>>> letting the peaks go above 0dBFS and simply chopping them off, which
>>> is a high distortion (therefore non-musical) transformation.
>>>
>>> There is no sense in sending impulses through a compressor, it is
>>> by definition a non-linear system, that would tell you nothing about
>>> it.
>>>
>
> this last statement, i cannot agree with.  i look at compressors and
> limiters as being the same species of animal.
>
> if your compressor or limiter is acting on peak amplitude rather than
> r.m.s., sending in impulses that exceed the threshold or knee will
> tell you much more than nothing about what the compressor is doing.
>
> being a non-linear system means that the impulse response cannot tell
> you how the device will respond to all other inputs.  for a linear
> time-invariant system, the impulse response is sufficient to tell you
> how the system will behave for any general input.
>
>
>>> Compression as a tool for managing high dynamic range signals during
>>> recording (e.g. TASCAM products) is different from compression as a
>>> component in "making things louder".
>
> how are they different *qualitatively*?  different attack and release
> times, different mapping curve, different overall gain.
>
> a multiband compressor is qualitatively different, but i might
> imagine such used in either situation.
>
>
>>> In general, you don't want to have to adjust the gain every time you
>>> change the compressor settings, so keeping the perceived level about
>>> the same eliminates some of the "louder sounds better, quieter
>>> sounds worse" psychoacoustic effect, and lets you concentrate on the
>>> dynamics of the signal you are working on.
>
> it seems to me that the issue is whether you want to tack down the
> knee or corner to a certain level, or if you want to tack down 0 dB
> FS, or somewhere in between.  but those are settings; i don't see the
> qualitative difference.
>
>
> --
>
> r b-j                  rbj at 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


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.76/2343 - Release Date: 09/03/09 
05:50:00


From bogac at bteaudio.com  Thu Sep  3 16:34:51 2009
From: bogac at bteaudio.com (Bogac Topaktas)
Date: Thu, 3 Sep 2009 13:34:51 -0700
Subject: [music-dsp] computing compressor automatic makeup gain (?)
Message-ID: <508b1683$3eed50dc$37eab100$@com>


> On Sep 3, 2009, at 6:04 PM, robert bristow-johnson wrote:
>
> if your compressor or limiter is acting on peak amplitude rather than  
> r.m.s., sending in impulses that exceed the threshold or knee will  
> tell you much more than nothing about what the compressor is doing.

But it can not reveal any clue about program dependent behavior.

> being a non-linear system means that the impulse response cannot tell  
> you how the device will respond to all other inputs.

The key word here is "memory". Dynamic convolution can capture static
(i.e. memory-less) non-linear behavior but becomes totally useless when
it comes to dynamic non-linearities. 

> how are they different *qualitatively*?  different attack and release  
> times, different mapping curve, different overall gain.
 
All of them plus program dependent behavior, see the following articles for 
full details:

"Analysis of Dynamic Range Control (DRC) Devices"
http://www.uaudio.com/webzine/2006/september/index2.html

"What is it about the 1176LN and LA2A that makes them 
distinctive-sounding?
How can the distinctive properties of these compressors be captured in a 
digital emulation?"
http://www.uaudio.com/webzine/2004/february/index2.html





From rbj at audioimagination.com  Fri Sep  4 11:18:51 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Fri, 4 Sep 2009 11:18:51 -0400
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <508b1683$3eed50dc$37eab100$@com>
References: <508b1683$3eed50dc$37eab100$@com>
Message-ID: <63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>


On Sep 3, 2009, at 4:34 PM, Bogac Topaktas wrote:

>> On Sep 3, 2009, at 6:04 PM, robert bristow-johnson wrote:
>>
>> if your compressor or limiter is acting on peak amplitude rather than
>> r.m.s., sending in impulses that exceed the threshold or knee will
>> tell you much more than nothing about what the compressor is doing.
>
> But it can not reveal any clue about program dependent behavior.

no clue at all??

i am not saying (nor have ever said) that the complete system  
description can be obtained by driving the compressor/limiter with an  
impulse or even a string of impulses (perhaps with different  
heights).  but you *can* get a clue about where the knee might be and  
the compressor starts kicking in.

if you build a compressor/limiter (say, in software as a plug-in) you  
have to test it with signals to see, regarding those test signals, if  
the compressor does as it is expected to do.  many test signals are  
necessary, but if the compressor/limiter is supposed to prevent  
spikes from exceeding the rails and getting clipped, to test that  
behavior, what test signal do you suggest to try at first?


>> being a non-linear system means that the impulse response cannot tell
>> you how the device will respond to all other inputs.
>
> The key word here is "memory". Dynamic convolution can capture static
> (i.e. memory-less) non-linear behavior but becomes totally useless  
> when
> it comes to dynamic non-linearities.

saying "totally useless" is a very strong statement and hard to  
defend.  all i have to do is find a single use and it is refuted.


>> how are they different *qualitatively*?  different attack and release
>> times, different mapping curve, different overall gain.
>
> All of them plus program dependent behavior,

of course, there is program dependent behavior.  it's a compressor.   
i still do not get the point that the response of the compressor to a  
well-defined impulse tells you *nothing* about how the compressor is  
working.  if it is peak-level detecting, it should detect that  
impulse even if it is only one sample wide.  if the height of that  
impulse exceeds the knee threshold, what comes out should be  
predictably adjusted in height.  if you have a string of impulses of  
increasing amplitude that are spaced far enough apart that the  
compressor attack and release recover to their quiescent states, that  
string of impulses can at least give you a *clue* about what the dB- 
in vs. dB-out mapping function might be.

i think you may have reacted to something i never said (like an  
impulse response completely describes the input-output behavior of  
the box when it is not LTI), but i continue to maintain that claiming  
that the response to an impulse provides *no* clue at all is an  
overstatement.


--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From tduffy at tascam.com  Fri Sep  4 12:16:42 2009
From: tduffy at tascam.com (Tom Duffy)
Date: Fri, 04 Sep 2009 09:16:42 -0700
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
References: <508b1683$3eed50dc$37eab100$@com>
	<63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
Message-ID: <4AA13D6A.9020200@tascam.com>

Of course a series of impulses, properly calibrated and calculated, 
would start
to characterize a compressor/limiter.

But, a single impulse tells you nothing.
When I am developing, debugging or analyzing an existing dynamics processor,
impulse responses are the last tool I would use, after a tone generator 
and storage
scope, and probably a load of test wave files, .e.g. 1kHz tone at 
-10dBFS for 5 seconds,
then 5 seconds silence, repeated, then different levels and then 
different ramped
levels.

Tom.

robert bristow-johnson wrote:
> On Sep 3, 2009, at 4:34 PM, Bogac Topaktas wrote:
>
>   
>>> On Sep 3, 2009, at 6:04 PM, robert bristow-johnson wrote:
>>>
>>> if your compressor or limiter is acting on peak amplitude rather than
>>> r.m.s., sending in impulses that exceed the threshold or knee will
>>> tell you much more than nothing about what the compressor is doing.
>>>       
>> But it can not reveal any clue about program dependent behavior.
>>     
>
> no clue at all??
>
> i am not saying (nor have ever said) that the complete system  
> description can be obtained by driving the compressor/limiter with an  
> impulse or even a string of impulses (perhaps with different  
> heights).  but you *can* get a clue about where the knee might be and  
> the compressor starts kicking in.
>
> if you build a compressor/limiter (say, in software as a plug-in) you  
> have to test it with signals to see, regarding those test signals, if  
> the compressor does as it is expected to do.  many test signals are  
> necessary, but if the compressor/limiter is supposed to prevent  
> spikes from exceeding the rails and getting clipped, to test that  
> behavior, what test signal do you suggest to try at first?
>
>
>   
>>> being a non-linear system means that the impulse response cannot tell
>>> you how the device will respond to all other inputs.
>>>       
>> The key word here is "memory". Dynamic convolution can capture static
>> (i.e. memory-less) non-linear behavior but becomes totally useless  
>> when
>> it comes to dynamic non-linearities.
>>     
>
> saying "totally useless" is a very strong statement and hard to  
> defend.  all i have to do is find a single use and it is refuted.
>
>
>   
>>> how are they different *qualitatively*?  different attack and release
>>> times, different mapping curve, different overall gain.
>>>       
>> All of them plus program dependent behavior,
>>     
>
> of course, there is program dependent behavior.  it's a compressor.   
> i still do not get the point that the response of the compressor to a  
> well-defined impulse tells you *nothing* about how the compressor is  
> working.  if it is peak-level detecting, it should detect that  
> impulse even if it is only one sample wide.  if the height of that  
> impulse exceeds the knee threshold, what comes out should be  
> predictably adjusted in height.  if you have a string of impulses of  
> increasing amplitude that are spaced far enough apart that the  
> compressor attack and release recover to their quiescent states, that  
> string of impulses can at least give you a *clue* about what the dB- 
> in vs. dB-out mapping function might be.
>
> i think you may have reacted to something i never said (like an  
> impulse response completely describes the input-output behavior of  
> the box when it is not LTI), but i continue to maintain that claiming  
> that the response to an impulse provides *no* clue at all is an  
> overstatement.
>
>
> --
>
> r b-j                  rbj at 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
>
>   


From sdiedrichsen at mac.com  Fri Sep  4 16:18:44 2009
From: sdiedrichsen at mac.com (Steffan Diedrichsen)
Date: Fri, 04 Sep 2009 22:18:44 +0200
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
References: <508b1683$3eed50dc$37eab100$@com>
	<63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
Message-ID: <13324453-79C9-454F-9122-2E4F6D95AE34@mac.com>

Having developed some dynamic processors, I can say, that a response  
to an impulse is not more than a simple test case. As you said,  
Robert, it's great to check a Limiter. But it doesn't help to  
characterize the compressor. As Tom said, a sine  wave with variying  
amplitudes reveals more. A rectangular wave might have the advantage,  
that the level detection converts it to DC. Might be useful, too.  
'Nuff said. ;-)

Anyway, to get back to the automatic gain, Tom's approach is quite  
nice. But even a "fixed" automatic makeup (e.g. -12dB input level  
results in -12dB output level) makes live easy. Setting the fix point  
to 0dB causes the compressor to get louder, if you dive into the  
signal with the threshold control. At -12dB, it's seems to be a good  
compromise.

Best,

Steffan


Am 04.09.2009|KW36 um 17:18 schrieb robert bristow-johnson:

> but i continue to maintain that claiming
> that the response to an impulse provides *no* clue at all is an
> overstatement.


From Christian at SavioursofSoul.de  Fri Sep  4 19:12:43 2009
From: Christian at SavioursofSoul.de (Christian-W. Budde)
Date: Sat, 05 Sep 2009 01:12:43 +0200
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <mailman.735.1252077541.141.music-dsp@music.columbia.edu>
References: <mailman.735.1252077541.141.music-dsp@music.columbia.edu>
Message-ID: <4AA19EEB.7040501@SavioursofSoul.de>

Hi there,
> i am not saying (nor have ever said) that the complete system 
> description can be obtained by driving the compressor/limiter with an 
> impulse or even a string of impulses (perhaps with different 
> heights).  but you *can* get a clue about where the knee might be and 
> the compressor starts kicking in.

In case you have the algorithm in form of a VST plugin, you could use my 
VST plugin analyser. It allows you to measure the characteristic curve 
and other program related behaviour. (see 
http://www.savioursofsoul.de/Christian/?page_id=48 at the bottom for a 
Behringer compressor). Together with an ASIO-VST Plugin you can even 
measure real hardware (like the Behringer compressor in this case).

Kind regards,

    Christian

From rossb-lists at audiomulch.com  Sat Sep  5 00:19:49 2009
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sat, 5 Sep 2009 14:19:49 +1000
Subject: [music-dsp] computing compressor automatic makeup gain (?)
References: <508b1683$3eed50dc$37eab100$@com><63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
	<13324453-79C9-454F-9122-2E4F6D95AE34@mac.com>
Message-ID: <012c01ca2de0$1cbf6530$0473a8c0@rossmacbook>

That's interesting Steffan

I was playing with the Logic 5 Platinum compressor recently and it did seem 
that the automatic makeup gain had the fix point set lower than 0dBFS...

On the other hand I received a message off list from someone who had worked 
on some well-reputed mastering compression systems where the automatic 
makeup gain fix point was 0dBFS.

On the subject of automatic analysis of compressor characteristics, the 
following is one of the few papers I've found. It only presents preliminary 
results but has an interesting methodology:

IDENTIFYING AND ANALYZING RELEVANT CHARACTERISTICS
OF DYNAMIC RANGE COMPRESSION
Andr?s Cabrera
DAFx-06
http://www.dafx.ca/proceedings/papers/p_061.pdf

The UA web zine stuff that Bogac already posted is also good...


Bests

Ross.



----- Original Message ----- 
From: "Steffan Diedrichsen" <sdiedrichsen at mac.com>
To: "A discussion list for music-related DSP" <music-dsp at music.columbia.edu>
Sent: Saturday, September 05, 2009 6:18 AM
Subject: Re: [music-dsp] computing compressor automatic makeup gain (?)


> Having developed some dynamic processors, I can say, that a response
> to an impulse is not more than a simple test case. As you said,
> Robert, it's great to check a Limiter. But it doesn't help to
> characterize the compressor. As Tom said, a sine  wave with variying
> amplitudes reveals more. A rectangular wave might have the advantage,
> that the level detection converts it to DC. Might be useful, too.
> 'Nuff said. ;-)
>
> Anyway, to get back to the automatic gain, Tom's approach is quite
> nice. But even a "fixed" automatic makeup (e.g. -12dB input level
> results in -12dB output level) makes live easy. Setting the fix point
> to 0dB causes the compressor to get louder, if you dive into the
> signal with the threshold control. At -12dB, it's seems to be a good
> compromise.
>
> Best,
>
> Steffan
>
>
> Am 04.09.2009|KW36 um 17:18 schrieb robert bristow-johnson:
>
>> but i continue to maintain that claiming
>> that the response to an impulse provides *no* clue at all is an
>> overstatement.
>
> --
> 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 


From rbj at audioimagination.com  Sat Sep  5 02:33:19 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Sat, 5 Sep 2009 02:33:19 -0400
Subject: [music-dsp] computing compressor automatic makeup gain (?)
In-Reply-To: <012c01ca2de0$1cbf6530$0473a8c0@rossmacbook>
References: <508b1683$3eed50dc$37eab100$@com><63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
	<13324453-79C9-454F-9122-2E4F6D95AE34@mac.com>
	<012c01ca2de0$1cbf6530$0473a8c0@rossmacbook>
Message-ID: <CA195849-60AA-4F62-AA2F-30457899CF26@audioimagination.com>


On Sep 5, 2009, at 12:19 AM, Ross Bencina wrote:

> That's interesting Steffan

no shit.


> On Sep 4, 2009, at 4:18 PM, Steffan Diedrichsen wrote:
>>  A rectangular wave might have the advantage,
>> that the level detection converts it to DC. Might be useful, too.
>> 'Nuff said. ;-)

i get it.  thank you.

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From sdiedrichsen at mac.com  Tue Sep  8 12:24:36 2009
From: sdiedrichsen at mac.com (Steffan Diedrichsen)
Date: Tue, 08 Sep 2009 18:24:36 +0200
Subject: [music-dsp] computing 0xFFth AES convention?
In-Reply-To: <CA195849-60AA-4F62-AA2F-30457899CF26@audioimagination.com>
References: <508b1683$3eed50dc$37eab100$@com>
	<63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
	<13324453-79C9-454F-9122-2E4F6D95AE34@mac.com>
	<012c01ca2de0$1cbf6530$0473a8c0@rossmacbook>
	<CA195849-60AA-4F62-AA2F-30457899CF26@audioimagination.com>
Message-ID: <01B8ABC0-3086-4DFA-A203-48F8BF5E4169@mac.com>

So, you guys,

who'll be @ 0xffth AES convention? I know, that Robert will be there,  
won't you?
But who else?

Best,

Steffan


Am 05.09.2009|KW36 um 08:33 schrieb robert bristow-johnson:

>
> On Sep 5, 2009, at 12:19 AM, Ross Bencina wrote:
>
>> That's interesting Steffan
>
> no shit.
>
>
>> On Sep 4, 2009, at 4:18 PM, Steffan Diedrichsen wrote:
>>> A rectangular wave might have the advantage,
>>> that the level detection converts it to DC. Might be useful, too.
>>> 'Nuff said. ;-)
>
> i get it.  thank you.
>
> --
>
> r b-j                  rbj at 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


From bastian.schnuerle at silberstein.de  Tue Sep  8 12:30:17 2009
From: bastian.schnuerle at silberstein.de (bastian.schnuerle)
Date: Tue, 8 Sep 2009 18:30:17 +0200
Subject: [music-dsp] computing 0xFFth AES convention?
In-Reply-To: <01B8ABC0-3086-4DFA-A203-48F8BF5E4169@mac.com>
References: <508b1683$3eed50dc$37eab100$@com>
	<63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
	<13324453-79C9-454F-9122-2E4F6D95AE34@mac.com>
	<012c01ca2de0$1cbf6530$0473a8c0@rossmacbook>
	<CA195849-60AA-4F62-AA2F-30457899CF26@audioimagination.com>
	<01B8ABC0-3086-4DFA-A203-48F8BF5E4169@mac.com>
Message-ID: <269AF3AC-47FA-4FA4-8BE4-852BD4EBCE4F@silberstein.de>

we gonna get a logic9 nfr or a macbook off50% if we are there ?

Am 08.09.2009 um 18:24 schrieb Steffan Diedrichsen:

> So, you guys,
>
> who'll be @ 0xffth AES convention? I know, that Robert will be there,
> won't you?
> But who else?
>
> Best,
>
> Steffan
>
>
> Am 05.09.2009|KW36 um 08:33 schrieb robert bristow-johnson:
>
>>
>> On Sep 5, 2009, at 12:19 AM, Ross Bencina wrote:
>>
>>> That's interesting Steffan
>>
>> no shit.
>>
>>
>>> On Sep 4, 2009, at 4:18 PM, Steffan Diedrichsen wrote:
>>>> A rectangular wave might have the advantage,
>>>> that the level detection converts it to DC. Might be useful, too.
>>>> 'Nuff said. ;-)
>>
>> i get it.  thank you.
>>
>> --
>>
>> r b-j                  rbj at audioimagination.com
>>
>> "Imagination is more important than knowledge."
>>
>>
>>
>>
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book
>> reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp


From sdiedrichsen at mac.com  Tue Sep  8 12:37:37 2009
From: sdiedrichsen at mac.com (Steffan Diedrichsen)
Date: Tue, 08 Sep 2009 18:37:37 +0200
Subject: [music-dsp] computing 0xFFth AES convention?
In-Reply-To: <269AF3AC-47FA-4FA4-8BE4-852BD4EBCE4F@silberstein.de>
References: <508b1683$3eed50dc$37eab100$@com>
	<63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
	<13324453-79C9-454F-9122-2E4F6D95AE34@mac.com>
	<012c01ca2de0$1cbf6530$0473a8c0@rossmacbook>
	<CA195849-60AA-4F62-AA2F-30457899CF26@audioimagination.com>
	<01B8ABC0-3086-4DFA-A203-48F8BF5E4169@mac.com>
	<269AF3AC-47FA-4FA4-8BE4-852BD4EBCE4F@silberstein.de>
Message-ID: <317BF690-EBED-4D0C-9034-A740A484350C@mac.com>

Am I Santa Claus? ;-)

At least the US AES members can take advantage of a sale special.
http://www.aes.org/e-news/2009/Sep3.cfm#apple

Best,

Steffan




Am 08.09.2009|KW37 um 18:30 schrieb bastian.schnuerle:

> we gonna get a logic9 nfr or a macbook off50% if we are there ?
>
> Am 08.09.2009 um 18:24 schrieb Steffan Diedrichsen:
>
>> So, you guys,
>>
>> who'll be @ 0xffth AES convention? I know, that Robert will be there,
>> won't you?
>> But who else?
>>
>> Best,
>>
>> Steffan
>>
>>
>> Am 05.09.2009|KW36 um 08:33 schrieb robert bristow-johnson:
>>
>>>
>>> On Sep 5, 2009, at 12:19 AM, Ross Bencina wrote:
>>>
>>>> That's interesting Steffan
>>>
>>> no shit.
>>>
>>>
>>>> On Sep 4, 2009, at 4:18 PM, Steffan Diedrichsen wrote:
>>>>> A rectangular wave might have the advantage,
>>>>> that the level detection converts it to DC. Might be useful, too.
>>>>> 'Nuff said. ;-)
>>>
>>> i get it.  thank you.
>>>
>>> --
>>>
>>> r b-j                  rbj at audioimagination.com
>>>
>>> "Imagination is more important than knowledge."
>>>
>>>
>>>
>>>
>>> --
>>> dupswapdrop -- the music-dsp mailing list and website:
>>> subscription info, FAQ, source code archive, list archive, book
>>> reviews, dsp links
>>> http://music.columbia.edu/cmc/music-dsp
>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book
>> reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp


From bastian.schnuerle at silberstein.de  Tue Sep  8 12:59:00 2009
From: bastian.schnuerle at silberstein.de (bastian.schnuerle)
Date: Tue, 8 Sep 2009 18:59:00 +0200
Subject: [music-dsp] computing 0xFFth AES convention?
In-Reply-To: <317BF690-EBED-4D0C-9034-A740A484350C@mac.com>
References: <508b1683$3eed50dc$37eab100$@com>
	<63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>
	<13324453-79C9-454F-9122-2E4F6D95AE34@mac.com>
	<012c01ca2de0$1cbf6530$0473a8c0@rossmacbook>
	<CA195849-60AA-4F62-AA2F-30457899CF26@audioimagination.com>
	<01B8ABC0-3086-4DFA-A203-48F8BF5E4169@mac.com>
	<269AF3AC-47FA-4FA4-8BE4-852BD4EBCE4F@silberstein.de>
	<317BF690-EBED-4D0C-9034-A740A484350C@mac.com>
Message-ID: <099EB886-B2E4-4F1C-889D-E5067C2EE45E@silberstein.de>

hahaha
+
Am 08.09.2009 um 18:37 schrieb Steffan Diedrichsen:

> Am I Santa Claus? ;-)
>
> At least the US AES members can take advantage of a sale special.
> http://www.aes.org/e-news/2009/Sep3.cfm#apple
>
> Best,
>
> Steffan
>
>
>
>
> Am 08.09.2009|KW37 um 18:30 schrieb bastian.schnuerle:
>
>> we gonna get a logic9 nfr or a macbook off50% if we are there ?
>>
>> Am 08.09.2009 um 18:24 schrieb Steffan Diedrichsen:
>>
>>> So, you guys,
>>>
>>> who'll be @ 0xffth AES convention? I know, that Robert will be  
>>> there,
>>> won't you?
>>> But who else?
>>>
>>> Best,
>>>
>>> Steffan
>>>
>>>
>>> Am 05.09.2009|KW36 um 08:33 schrieb robert bristow-johnson:
>>>
>>>>
>>>> On Sep 5, 2009, at 12:19 AM, Ross Bencina wrote:
>>>>
>>>>> That's interesting Steffan
>>>>
>>>> no shit.
>>>>
>>>>
>>>>> On Sep 4, 2009, at 4:18 PM, Steffan Diedrichsen wrote:
>>>>>> A rectangular wave might have the advantage,
>>>>>> that the level detection converts it to DC. Might be useful, too.
>>>>>> 'Nuff said. ;-)
>>>>
>>>> i get it.  thank you.
>>>>
>>>> --
>>>>
>>>> r b-j                  rbj at audioimagination.com
>>>>
>>>> "Imagination is more important than knowledge."
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> dupswapdrop -- the music-dsp mailing list and website:
>>>> subscription info, FAQ, source code archive, list archive, book
>>>> reviews, dsp links
>>>> http://music.columbia.edu/cmc/music-dsp
>>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>
>>> --
>>> dupswapdrop -- the music-dsp mailing list and website:
>>> subscription info, FAQ, source code archive, list archive, book
>>> reviews, dsp links
>>> http://music.columbia.edu/cmc/music-dsp
>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book
>> reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp


From aclark at danvillesignal.com  Tue Sep  8 13:17:36 2009
From: aclark at danvillesignal.com (Al Clark)
Date: Tue, 08 Sep 2009 12:17:36 -0500
Subject: [music-dsp] computing 0xFFth AES convention?
In-Reply-To: <01B8ABC0-3086-4DFA-A203-48F8BF5E4169@mac.com>
References: <508b1683$3eed50dc$37eab100$@com>	<63410D4C-620B-4403-807B-334DAB956FB1@audioimagination.com>	<13324453-79C9-454F-9122-2E4F6D95AE34@mac.com>	<012c01ca2de0$1cbf6530$0473a8c0@rossmacbook>	<CA195849-60AA-4F62-AA2F-30457899CF26@audioimagination.com>
	<01B8ABC0-3086-4DFA-A203-48F8BF5E4169@mac.com>
Message-ID: <4AA691B0.2010204@danvillesignal.com>

Steffan Diedrichsen wrote:
> So, you guys,
>
> who'll be @ 0xffth AES convention? I know, that Robert will be there,  
> won't you?
> But who else?
>
> Best,
>
> Steffan
>   
Robert is giving a presentation on Monday. I think he is covering the 
cookbook stuff. (Robert, this might be a good time to clarify if I have 
it wrong)
I'll be there.

Al Clark
Danville Signal Processing










From rbj at audioimagination.com  Tue Sep  8 18:37:28 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 08 Sep 2009 18:37:28 -0400
Subject: [music-dsp] computing 0xFFth AES convention?
Message-ID: <20090908183728.1693@web001.roc2.bluetie.com>


-----Original Message-----
From: "Al Clark" [aclark at danvillesignal.com]
Date: 09/08/2009 13:17
To: "A discussion list for music-related DSP" <music-dsp at music.columbia.edu>
Subject: Re: [music-dsp] computing 0xFFth AES convention?

>
> Robert is giving a presentation on Monday. I think he is covering the 
> cookbook stuff. 

not exactly.  it's a tutorial, so it's about pretty basic stuff that i might have thought would be more commonly employed.

> (Robert, this might be a good time to clarify if I have it wrong)

it's about how (and why bother) to design finite order polynomial approximations to functions, as opposed to look-up table (LUT) (with or without linear interpolation) which appears to be much more commonly employed.  the use of these mappings could either be for the common "cook the coefficients" process between knob twists and what the DSP alg sees (like what is in the biquad filter cookbook), or it could be about memoryless non-linear functions that full-bandwidth audio signals are applied to.  we know that simple LUT (especially without any interpolation) has the advantage of speed when little other consideration is made (lot'sa memory, maybe some index quantization error).  but i would think that there it would be more common in hardware applications (where there might not be your trusty std C math lib or floating-point) for implementing functions with short finite power series.  and truncated Taylor series is not such a good way to derive it.

> I'll be there.

i guess i have to be, now.

--

r b-j                  rbj at 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



From richarddobson at blueyonder.co.uk  Tue Sep  8 18:51:21 2009
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Tue, 08 Sep 2009 23:51:21 +0100
Subject: [music-dsp] computing 0xFFth AES convention?
In-Reply-To: <20090908183728.1693@web001.roc2.bluetie.com>
References: <20090908183728.1693@web001.roc2.bluetie.com>
Message-ID: <4AA6DFE9.3080707@blueyonder.co.uk>

robert bristow-johnson wrote:
..
> 
> it's about how (and why bother) to design finite order polynomial
> approximations to functions, as opposed to look-up table (LUT) (with
> or without linear interpolation) which appears to be much more
> commonly employed. 
...

Will there be an associated paper, or is it strictly off the record?


Richard Dobson


From Cyrille.Damez at laposte.net  Tue Sep  8 20:30:59 2009
From: Cyrille.Damez at laposte.net (Cyrille.Damez at laposte.net)
Date: Wed, 9 Sep 2009 02:30:59 +0200
Subject: [music-dsp] computing 0xFFth AES convention?
In-Reply-To: <20090908183728.1693@web001.roc2.bluetie.com>
References: <20090908183728.1693@web001.roc2.bluetie.com>
Message-ID: <200909090231.00196.Cyrille.Damez@laposte.net>

On Wednesday 09 September 2009 00:37:28 robert bristow-johnson wrote:

> we know that simple LUT (especially without any interpolation)
> has the advantage of speed when little other consideration is made (lot'sa
> memory, maybe some index quantization error).

And even that is less and less true: converting floats to ints can be 
expensive, so is memory access, and one can't efficiently read a LUT with the 
most common SIMD instructions sets (SSE, altivec, ...). On the other hand, 
multiply-add instructions keep getting cheaper.


From rbj at audioimagination.com  Wed Sep  9 01:40:31 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Wed, 9 Sep 2009 01:40:31 -0400
Subject: [music-dsp] computing 0xFFth AES convention?
In-Reply-To: <200909090231.00196.Cyrille.Damez@laposte.net>
References: <20090908183728.1693@web001.roc2.bluetie.com>
	<200909090231.00196.Cyrille.Damez@laposte.net>
Message-ID: <A3F745DA-DEF8-4835-BAF8-CF0B1B799067@audioimagination.com>


On Sep 8, 2009, at 8:30 PM, Cyrille.Damez at laposte.net wrote:

> On Wednesday 09 September 2009 00:37:28 robert bristow-johnson wrote:
>
>> we know that simple LUT (especially without any interpolation)
>> has the advantage of speed when little other consideration is made  
>> (lot'sa
>> memory, maybe some index quantization error).
>
> And even that is less and less true: converting floats to ints can be
> expensive, so is memory access, and one can't efficiently read a  
> LUT with the
> most common SIMD instructions sets (SSE, altivec, ...). On the  
> other hand,
> multiply-add instructions keep getting cheaper.

i dunno about these CPUs with float and int operations.  i think the  
SHArC had a fix instruction that made the conversion in a single  
instruction cycle.  (then the rigamarole you had to go through to get  
the fractional part for linear interpolation was a pain-in-arse, i  
think just converting the integer back to a float and subtracting  
that out of the original float was the simplest in the SHArC to get  
the fractional part.)  with the 56K, it was just a matter of scaling  
with the right scaler, and the integer part was in register a1 (that  
would go to an index offset) with the fractional part in a0.  with  
the 56300, with sufficient pipelining, i can do table lookup with  
linear interpolation in 8 instruction cycles.  it's about 3  
instructions per polynomial coef + overhead.  a 6th-order polynomial  
might take 25 instruction cycles.

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From schnarf at optonline.net  Thu Sep 10 01:50:24 2009
From: schnarf at optonline.net (Aaron Wishnick)
Date: Thu, 10 Sep 2009 01:50:24 -0400
Subject: [music-dsp] Vacuum Tube Simulation?
Message-ID: <CF4842E7-49D8-4E16-A39A-E19B27A46028@optonline.net>

Hi all,
I'm interested in tube simulation, particularly in the context of  
guitar playing -- I'm a guitar player. I've seen lots of great papers  
by David Yeh (check his website) and I feel like I have a good handle  
on simulating a triode stage. I'm interested to hear what other  
methods people have found useful for this, though.

Now, I haven't seen any papers on simulating the power amp stage,  
which is a bit different because there's an extra port on each tube to  
worry about, and particularly because of the interaction with the  
transformer. Has anybody seen any papers, or does anybody have  
suggestions on where to start with this?

Aaron

From lemoine.pascal at gmail.com  Thu Sep 10 03:19:12 2009
From: lemoine.pascal at gmail.com (Pascal Lemoine)
Date: Thu, 10 Sep 2009 09:19:12 +0200
Subject: [music-dsp] Vacuum Tube Simulation?
In-Reply-To: <CF4842E7-49D8-4E16-A39A-E19B27A46028@optonline.net>
References: <CF4842E7-49D8-4E16-A39A-E19B27A46028@optonline.net>
Message-ID: <a36ad8860909100019o16efd556u67f3b4061d268ec1@mail.gmail.com>

Leonardo Di Carlo, someone on this list, has been into pspice modelling.
Check out his page: http://www.fuzone.it/pspice_model.htm

In addition, Bogac Topaktas has submitted this bibliography, including
web pointers, 18 months ago:

Jan Ogrodzki (Editor), "Circuit Simulation Methods and Algorithms",
CRC-Press, 1994.

A. Vladimirescu, "The Spice Book", Wiley, New York, 1994.

W. J. McCalla, "Fundamentals of Computer-Aided Circuit Simulation",
Kluwer Academic Publishers, Boston, 1987.

K.G. Nichols, T.J. Kazmierski, M. Zwolinski, and A.D. Brown, "Overview
of SPICE-like circuit simulation algorithms", IEEE Proceedings -
Circuits, Devices and Systems, August 1994, Volume 141, Issue 4, p.
242-250

P. Mole and H. Rokos, "Techniques for Nonlinear Circuit Simulation",
Editorial, IEEE Proc.?Circuits Devices Syst., vol. 141, p. 241 (1994).

Important web resources on both theory and practice of vacuum tube
circuit modeling and simulation:

W. M. Leach, Jr., "SPICE Models for Vacuum Tube Amplifiers", Journal
of the Audio Engineering Society, Vol. 43, No. 3, pp. 117-126, March
1995. http://users.ece.gatech.edu/~mleach/papers/tubeamp/tubeamp.pdf

Vacuum Tube Preamplifier Analysis and SPICE Simulation,
http://bear.cwru.edu/eecs_cad/tut_spice3_tube.html

A Generalized Algebraic Technique For Modeling Triodes,
http://www.lynx.bc.ca/~jc/model.html

Inside Fender and Marshall Tube Amps, http://www.lynx.bc.ca/~jc/ifmta.html

Circuit Analysis of a Legendary Tube Amplifier: The Fender Bassman
5F6-A, http://www.pentodepress.com/contents.html

Tubes Versus Transistors:
http://users.ece.gatech.edu/~mleach/papers/TubeVsTrans.pdf

Articles and publications at SimulAnalog.org: http://www.simulanalog.org/

David Yeh's Publications: http://ccrma.stanford.edu/~dtyeh/papers/pubs.html



Hope this helps for your specific concern about power amp stage,
Pascal.

From bogac at bteaudio.com  Thu Sep 10 07:25:27 2009
From: bogac at bteaudio.com (Bogac Topaktas)
Date: Thu, 10 Sep 2009 04:25:27 -0700
Subject: [music-dsp] Vacuum Tube Simulation?
Message-ID: <4c302ec$1b459171$64f93b86$@com>


Thanks Pascal! I forgot that post..

The most comprehensive (and widely unknown) resource of information on 
modeling and simulation of tube amplifiers is Eric K. Pritchard's Patents:

USpat# 4,809,336; 4,995,084; 5,133,014;
5,434,536; 5,636,284; 5,734,725; 5,761,316; 5,761,317; 5,802,182;
5,805,713; 5,848,165; 6,057,737; 6,411,720; and 6,631,195.
(all available online at www.uspto.gov )
 
In your particular case (power stage/output transformer/loudspeaker 
interaction), key information is contained in #4,809,336; 4,995,084 (the 
best); 5,133,014; 5,434,536; 5,636,284; 5,761,316; and 5,805,713.

In addition to the above, the following patents contain key information on 
simulating the power supply sag: #5,635,872 and #5,909,145.

-------- Original Message --------
> From: "Aaron Wishnick" <schnarf at optonline.net>
> Sent: Thursday, September 10, 2009 8:50 AM
> To: music-dsp at music.columbia.edu
> Subject: [music-dsp] Vacuum Tube Simulation?
> 
> Hi all,
> I'm interested in tube simulation, particularly in the context of  
> guitar playing -- I'm a guitar player. I've seen lots of great papers  
> by David Yeh (check his website) and I feel like I have a good handle  
> on simulating a triode stage. I'm interested to hear what other  
> methods people have found useful for this, though.
> 
> Now, I haven't seen any papers on simulating the power amp stage,  
> which is a bit different because there's an extra port on each tube to  
> worry about, and particularly because of the interaction with the  
> transformer. Has anybody seen any papers, or does anybody have  
> suggestions on where to start with this?
> 
> Aaron
> --
> 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 




From thomazchaves at gmail.com  Thu Sep 10 11:31:49 2009
From: thomazchaves at gmail.com (Thomaz Oliveira)
Date: Thu, 10 Sep 2009 12:31:49 -0300
Subject: [music-dsp] Vacuum Tube Simulation?
In-Reply-To: <CF4842E7-49D8-4E16-A39A-E19B27A46028@optonline.net>
References: <CF4842E7-49D8-4E16-A39A-E19B27A46028@optonline.net>
Message-ID: <e6b1ee840909100831l2516904du9161ecfd07246267@mail.gmail.com>

Hi
I'm doing som e research on a electrical engennering institute and I'm
working on the subeject of tube emulations..  we can exchange
materials if you like...

I have some papers here:
do you intend to develop anything?

we can be parterns
I can send you some papers...
I`m also a guitar player as well as a scietist here in brazil

http://www.youtube.com/watch?v=QqDZTQNnalk

cheers

Thomaz

From douglas at music.columbia.edu  Tue Sep 15 07:00:00 2009
From: douglas at music.columbia.edu (douglas repetto)
Date: Tue, 15 Sep 2009 07:00:00 -0400 (EDT)
Subject: [music-dsp] [admin] music-dsp FAQ
Message-ID: <20090915110000.72F05557853@music.columbia.edu>

Hi,

Just a reminder that if you are new to the list you should read the
music-dsp FAQ. It contains answers to both technical _and_
adminstrative questions that often come up on the list. If your question
appears in the FAQ it is safe to assume that it has been discussed on the
list many times in the past, and you should probably have a look through
the list archives before posting your question to the list.

http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html


Also of interest to new and not-so-new list members:

The music-dsp list archives
http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html

The music-dsp source code archive
http://www.musicdsp.org

music-dsp books and reviews
http://music.columbia.edu/cmc/music-dsp/dspbooks.html


All this and more at:
http://music.columbia.edu/cmc/music-dsp


Hasta la pasta,
douglas

(this is an automated message sent out on the 1st and 15th of each month)

From Danijel.Domazet at littleendian.com  Tue Sep 15 07:26:08 2009
From: Danijel.Domazet at littleendian.com (Danijel Domazet)
Date: Tue, 15 Sep 2009 13:26:08 +0200
Subject: [music-dsp] "mathematics of music" book?
Message-ID: <4AAF79D0.9010606@LittleEndian.com>

Hi music-dsp,
I'd like to learn about mathematics of music. Could someone please 
recommend a book on this? Focus should be on the math, not on the whole 
music theory, if possible...  

Cheers!
 

Danijel Domazet
CEO
www.LittleEndian.com


From Victor.Lazzarini at nuim.ie  Tue Sep 15 07:31:29 2009
From: Victor.Lazzarini at nuim.ie (Victor Lazzarini)
Date: Tue, 15 Sep 2009 12:31:29 +0100
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <4AAF79D0.9010606@LittleEndian.com>
References: <4AAF79D0.9010606@LittleEndian.com>
Message-ID: <79EE22ED-D479-48CF-B307-0C56B637E22C@nuim.ie>

I like this one:

http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html

Victor

On 15 Sep 2009, at 12:26, Danijel Domazet wrote:

> Hi music-dsp,
> I'd like to learn about mathematics of music. Could someone please
> recommend a book on this? Focus should be on the math, not on the  
> whole
> music theory, if possible...
>
> Cheers!
>
>
> Danijel Domazet
> CEO
> www.LittleEndian.com
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp


From jdec at mindspring.com  Tue Sep 15 07:33:50 2009
From: jdec at mindspring.com (BrightBoy)
Date: Tue, 15 Sep 2009 07:33:50 -0400 (EDT)
Subject: [music-dsp] "mathematics of music" book?
Message-ID: <8333556.1253014430745.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>

>I'd like to learn about mathematics of music. Could someone please 
>recommend a book on this? Focus should be on the math, not on the whole 
>music theory, if possible...  

This seems like one of the obvious choices:

http://www.musimathics.com/

Cheers,

Jeff




From padawan12 at obiwannabe.co.uk  Tue Sep 15 07:46:54 2009
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Tue, 15 Sep 2009 12:46:54 +0100
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <4AAF79D0.9010606@LittleEndian.com>
References: <4AAF79D0.9010606@LittleEndian.com>
Message-ID: <20090915124654.d9134b34.padawan12@obiwannabe.co.uk>


I found Dave Bensons book interesting. 

http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html

Of course if you're serious a classic like Moore is the thing

http://www.amazon.com/Elements-Computer-Music-Richard-Moore/dp/0132525526

For cheap and cheerful you can get oldies like Elmore and Heald or
Olson in Dover for pennies these days.

http://www.amazon.com/Music-Physics-Engineering-Harry-Olson/dp/0486217698

Bear in mind that if you really want to understand the 'math' of music
you will have to stray beyond 'math books' into the realms of physics
and psychology too.


On Tue, 15 Sep 2009 13:26:08 +0200
Danijel Domazet <Danijel.Domazet at littleendian.com> wrote:

> Hi music-dsp,
> I'd like to learn about mathematics of music. Could someone please 
> recommend a book on this? Focus should be on the math, not on the whole 
> music theory, if possible...  
> 
> Cheers!
>  
> 
> Danijel Domazet
> CEO
> www.LittleEndian.com
> 
> --
> dupswapdrop -- the music-dsp mailing list and website: 
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
> http://music.columbia.edu/cmc/music-dsp 
> http://music.columbia.edu/mailman/listinfo/music-dsp

From padawan12 at obiwannabe.co.uk  Tue Sep 15 07:48:57 2009
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Tue, 15 Sep 2009 12:48:57 +0100
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <8333556.1253014430745.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
References: <8333556.1253014430745.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
Message-ID: <20090915124857.319b0221.padawan12@obiwannabe.co.uk>



Yum, fresh ones... nice find!

On Tue, 15 Sep 2009 07:33:50 -0400 (EDT)
BrightBoy <jdec at mindspring.com> wrote:

> >I'd like to learn about mathematics of music. Could someone please 
> >recommend a book on this? Focus should be on the math, not on the whole 
> >music theory, if possible...  
> 
> This seems like one of the obvious choices:
> 
> http://www.musimathics.com/
> 
> Cheers,
> 
> Jeff
> 
> 
> 
> --
> 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

From Victor.Lazzarini at nuim.ie  Tue Sep 15 08:35:56 2009
From: Victor.Lazzarini at nuim.ie (Victor Lazzarini)
Date: Tue, 15 Sep 2009 13:35:56 +0100
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <20090915124654.d9134b34.padawan12@obiwannabe.co.uk>
References: <4AAF79D0.9010606@LittleEndian.com>
	<20090915124654.d9134b34.padawan12@obiwannabe.co.uk>
Message-ID: <41CEA91E-D4C3-4A5E-972F-36A7649C71EA@nuim.ie>

Olson... the first book in the area I ever set my eyes on! Thanks
for reminding me of it...

Victor
On 15 Sep 2009, at 12:46, Andy Farnell wrote:

>
> I found Dave Bensons book interesting.
>
> http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html
>
> Of course if you're serious a classic like Moore is the thing
>
> http://www.amazon.com/Elements-Computer-Music-Richard-Moore/dp/0132525526
>
> For cheap and cheerful you can get oldies like Elmore and Heald or
> Olson in Dover for pennies these days.
>
> http://www.amazon.com/Music-Physics-Engineering-Harry-Olson/dp/0486217698
>
> Bear in mind that if you really want to understand the 'math' of music
> you will have to stray beyond 'math books' into the realms of physics
> and psychology too.
>
>
> On Tue, 15 Sep 2009 13:26:08 +0200
> Danijel Domazet <Danijel.Domazet at littleendian.com> wrote:
>
>> Hi music-dsp,
>> I'd like to learn about mathematics of music. Could someone please
>> recommend a book on this? Focus should be on the math, not on the  
>> whole
>> music theory, if possible...
>>
>> Cheers!
>>
>>
>> Danijel Domazet
>> CEO
>> www.LittleEndian.com
>>
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book  
>> reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp


From michael.gogins at gmail.com  Tue Sep 15 08:38:26 2009
From: michael.gogins at gmail.com (Michael Gogins)
Date: Tue, 15 Sep 2009 08:38:26 -0400
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <41CEA91E-D4C3-4A5E-972F-36A7649C71EA@nuim.ie>
References: <4AAF79D0.9010606@LittleEndian.com>
	<20090915124654.d9134b34.padawan12@obiwannabe.co.uk>
	<41CEA91E-D4C3-4A5E-972F-36A7649C71EA@nuim.ie>
Message-ID: <898dd7270909150538v6d06e655y41bec25c6379bb3f@mail.gmail.com>

Also, to clarify, do you mean the mathematics of sounds or the
mathematics of scores and notes? The latter is what is discussed in
The Topos of Music.

Regards,
Mike

On 9/15/09, Victor Lazzarini <Victor.Lazzarini at nuim.ie> wrote:
> Olson... the first book in the area I ever set my eyes on! Thanks
> for reminding me of it...
>
> Victor
> On 15 Sep 2009, at 12:46, Andy Farnell wrote:
>
>>
>> I found Dave Bensons book interesting.
>>
>> http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html
>>
>> Of course if you're serious a classic like Moore is the thing
>>
>> http://www.amazon.com/Elements-Computer-Music-Richard-Moore/dp/0132525526
>>
>> For cheap and cheerful you can get oldies like Elmore and Heald or
>> Olson in Dover for pennies these days.
>>
>> http://www.amazon.com/Music-Physics-Engineering-Harry-Olson/dp/0486217698
>>
>> Bear in mind that if you really want to understand the 'math' of music
>> you will have to stray beyond 'math books' into the realms of physics
>> and psychology too.
>>
>>
>> On Tue, 15 Sep 2009 13:26:08 +0200
>> Danijel Domazet <Danijel.Domazet at littleendian.com> wrote:
>>
>>> Hi music-dsp,
>>> I'd like to learn about mathematics of music. Could someone please
>>> recommend a book on this? Focus should be on the math, not on the
>>> whole
>>> music theory, if possible...
>>>
>>> Cheers!
>>>
>>>
>>> Danijel Domazet
>>> CEO
>>> www.LittleEndian.com
>>>
>>> --
>>> dupswapdrop -- the music-dsp mailing list and website:
>>> subscription info, FAQ, source code archive, list archive, book
>>> reviews, dsp links
>>> http://music.columbia.edu/cmc/music-dsp
>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book
>> reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>
> --
> 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
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

From Danijel.Domazet at littleendian.com  Tue Sep 15 10:13:50 2009
From: Danijel.Domazet at littleendian.com (Danijel Domazet)
Date: Tue, 15 Sep 2009 16:13:50 +0200
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <898dd7270909150538v6d06e655y41bec25c6379bb3f@mail.gmail.com>
References: <4AAF79D0.9010606@LittleEndian.com>	<20090915124654.d9134b34.padawan12@obiwannabe.co.uk>	<41CEA91E-D4C3-4A5E-972F-36A7649C71EA@nuim.ie>
	<898dd7270909150538v6d06e655y41bec25c6379bb3f@mail.gmail.com>
Message-ID: <4AAFA11E.5010809@LittleEndian.com>

Michael,
I mean the mathematics of sounds.

For example: I am trying to build a simple "harmonizer", and - I'd like 
to understand what it means to "harmonize a melody to a 4th and a 7th". 
Where do I shift my frequencies!!? Things like that.


Thanks,

Danijel Domazet
CEO
www.LittleEndian.com



Michael Gogins wrote:
> Also, to clarify, do you mean the mathematics of sounds or the
> mathematics of scores and notes? The latter is what is discussed in
> The Topos of Music.
>
> Regards,
> Mike
>
> On 9/15/09, Victor Lazzarini <Victor.Lazzarini at nuim.ie> wrote:
>   
>> Olson... the first book in the area I ever set my eyes on! Thanks
>> for reminding me of it...
>>
>> Victor
>> On 15 Sep 2009, at 12:46, Andy Farnell wrote:
>>
>>     
>>> I found Dave Bensons book interesting.
>>>
>>> http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html
>>>
>>> Of course if you're serious a classic like Moore is the thing
>>>
>>> http://www.amazon.com/Elements-Computer-Music-Richard-Moore/dp/0132525526
>>>
>>> For cheap and cheerful you can get oldies like Elmore and Heald or
>>> Olson in Dover for pennies these days.
>>>
>>> http://www.amazon.com/Music-Physics-Engineering-Harry-Olson/dp/0486217698
>>>
>>> Bear in mind that if you really want to understand the 'math' of music
>>> you will have to stray beyond 'math books' into the realms of physics
>>> and psychology too.
>>>
>>>
>>> On Tue, 15 Sep 2009 13:26:08 +0200
>>> Danijel Domazet <Danijel.Domazet at littleendian.com> wrote:
>>>
>>>       
>>>> Hi music-dsp,
>>>> I'd like to learn about mathematics of music. Could someone please
>>>> recommend a book on this? Focus should be on the math, not on the
>>>> whole
>>>> music theory, if possible...
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> Danijel Domazet
>>>> CEO
>>>> www.LittleEndian.com
>>>>
>>>> --
>>>> dupswapdrop -- the music-dsp mailing list and website:
>>>> subscription info, FAQ, source code archive, list archive, book
>>>> reviews, dsp links
>>>> http://music.columbia.edu/cmc/music-dsp
>>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>>         
>>> --
>>> dupswapdrop -- the music-dsp mailing list and website:
>>> subscription info, FAQ, source code archive, list archive, book
>>> reviews, dsp links
>>> http://music.columbia.edu/cmc/music-dsp
>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>       
>> --
>> 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
>>
>>     
>
>
>   

From douglas at music.columbia.edu  Tue Sep 15 10:30:55 2009
From: douglas at music.columbia.edu (douglas repetto)
Date: Tue, 15 Sep 2009 10:30:55 -0400
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <4AAF79D0.9010606@LittleEndian.com>
References: <4AAF79D0.9010606@LittleEndian.com>
Message-ID: <4AAFA51F.9080906@music.columbia.edu>


Great suggestions so far! Just a reminder that we have lots of book 
reviews by list members on the music-dsp website:

http://music.columbia.edu/cmc/music-dsp


If you'd like to contribute something please let me know!

douglas

Danijel Domazet wrote:
> Hi music-dsp,
> I'd like to learn about mathematics of music. Could someone please 
> recommend a book on this? Focus should be on the math, not on the whole 
> music theory, if possible...  
> 
> Cheers!
>  
> 
> Danijel Domazet
> CEO
> www.LittleEndian.com
> 
> --
> dupswapdrop -- the music-dsp mailing list and website: 
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
> http://music.columbia.edu/cmc/music-dsp 
> http://music.columbia.edu/mailman/listinfo/music-dsp
> 

-- 
............................................... http://artbots.org
.....douglas.....irving........................ http://dorkbot.org
.......................... http://music.columbia.edu/cmc/music-dsp
.......... repetto............. http://music.columbia.edu/organism
........................................ http://douglasrepetto.org


From michael.gogins at gmail.com  Tue Sep 15 10:42:03 2009
From: michael.gogins at gmail.com (Michael Gogins)
Date: Tue, 15 Sep 2009 10:42:03 -0400
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <4AAFA11E.5010809@LittleEndian.com>
References: <4AAF79D0.9010606@LittleEndian.com>
	<20090915124654.d9134b34.padawan12@obiwannabe.co.uk>
	<41CEA91E-D4C3-4A5E-972F-36A7649C71EA@nuim.ie>
	<898dd7270909150538v6d06e655y41bec25c6379bb3f@mail.gmail.com>
	<4AAFA11E.5010809@LittleEndian.com>
Message-ID: <898dd7270909150742w7b6f3736l38bd0dd15b13299c@mail.gmail.com>

Don't expect this to be small, quick, or easy.

This is an extremely deep field with over 200 years of work from world
class thinkers such as Fourier, Helmholtz, and Gabor. It overlaps with
extensive, very well funded cutting edge, secret research on signal
processing for military and spy purposes.

_A Computer Music Tutorial_ has an out of date but useful
introduction. Gareth Loy has two books, one on sounds and one on
notes, MusiMathathics I and II, that may be useful. Many computer
music people start with Ken Steiglitz' _A DSP Primer_. There are
numerous graduate texts on digital signal processing, either in
general or focused on audio and music.

You would be well advised to do your reading in tandem with a signal
processing language. DSP researchers use MatLab, Octave can also be
used. If you have Mathematica, that is an excellent tool because you
can hear any function or graph. Music researchers use any or all of
these as well as Csound, Pure Data, or other programmable software
synthesizers.

The author of Pure Data, Miller Puckette, has an online book that
provides a pretty basic introduction that could nevertheless be useful
because you can play with the examples in PD and hear everything, at
http://crca.ucsd.edu/~msp/techniques.htm.

_The Csound Book_ actually covers a lot of the same ground in a
scattered sort of way, but also with useful examples.

Hope this helps,
Mike

On 9/15/09, Danijel Domazet <Danijel.Domazet at littleendian.com> wrote:
> Michael,
> I mean the mathematics of sounds.
>
> For example: I am trying to build a simple "harmonizer", and - I'd like
> to understand what it means to "harmonize a melody to a 4th and a 7th".
> Where do I shift my frequencies!!? Things like that.
>
>
> Thanks,
>
> Danijel Domazet
> CEO
> www.LittleEndian.com
>
>
>
> Michael Gogins wrote:
>> Also, to clarify, do you mean the mathematics of sounds or the
>> mathematics of scores and notes? The latter is what is discussed in
>> The Topos of Music.
>>
>> Regards,
>> Mike
>>
>> On 9/15/09, Victor Lazzarini <Victor.Lazzarini at nuim.ie> wrote:
>>
>>> Olson... the first book in the area I ever set my eyes on! Thanks
>>> for reminding me of it...
>>>
>>> Victor
>>> On 15 Sep 2009, at 12:46, Andy Farnell wrote:
>>>
>>>
>>>> I found Dave Bensons book interesting.
>>>>
>>>> http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html
>>>>
>>>> Of course if you're serious a classic like Moore is the thing
>>>>
>>>> http://www.amazon.com/Elements-Computer-Music-Richard-Moore/dp/0132525526
>>>>
>>>> For cheap and cheerful you can get oldies like Elmore and Heald or
>>>> Olson in Dover for pennies these days.
>>>>
>>>> http://www.amazon.com/Music-Physics-Engineering-Harry-Olson/dp/0486217698
>>>>
>>>> Bear in mind that if you really want to understand the 'math' of music
>>>> you will have to stray beyond 'math books' into the realms of physics
>>>> and psychology too.
>>>>
>>>>
>>>> On Tue, 15 Sep 2009 13:26:08 +0200
>>>> Danijel Domazet <Danijel.Domazet at littleendian.com> wrote:
>>>>
>>>>
>>>>> Hi music-dsp,
>>>>> I'd like to learn about mathematics of music. Could someone please
>>>>> recommend a book on this? Focus should be on the math, not on the
>>>>> whole
>>>>> music theory, if possible...
>>>>>
>>>>> Cheers!
>>>>>
>>>>>
>>>>> Danijel Domazet
>>>>> CEO
>>>>> www.LittleEndian.com
>>>>>
>>>>> --
>>>>> dupswapdrop -- the music-dsp mailing list and website:
>>>>> subscription info, FAQ, source code archive, list archive, book
>>>>> reviews, dsp links
>>>>> http://music.columbia.edu/cmc/music-dsp
>>>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>>>
>>>> --
>>>> dupswapdrop -- the music-dsp mailing list and website:
>>>> subscription info, FAQ, source code archive, list archive, book
>>>> reviews, dsp links
>>>> http://music.columbia.edu/cmc/music-dsp
>>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>>
>>> --
>>> dupswapdrop -- the music-dsp mailing list and website:
>>> subscription info, FAQ, source code archive, list archive, book reviews,
>>> dsp
>>> links
>>> http://music.columbia.edu/cmc/music-dsp
>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>
>>>
>>
>>
>>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp
> links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

From richarddobson at blueyonder.co.uk  Tue Sep 15 10:43:06 2009
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Tue, 15 Sep 2009 15:43:06 +0100
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <4AAFA11E.5010809@LittleEndian.com>
References: <4AAF79D0.9010606@LittleEndian.com>	<20090915124654.d9134b34.padawan12@obiwannabe.co.uk>	<41CEA91E-D4C3-4A5E-972F-36A7649C71EA@nuim.ie>	<898dd7270909150538v6d06e655y41bec25c6379bb3f@mail.gmail.com>
	<4AAFA11E.5010809@LittleEndian.com>
Message-ID: <4AAFA7FA.2070303@blueyonder.co.uk>

Danijel Domazet wrote:
> Michael,
> I mean the mathematics of sounds.
> 
> For example: I am trying to build a simple "harmonizer", and - I'd like 
> to understand what it means to "harmonize a melody to a 4th and a 7th". 
> Where do I shift my frequencies!!? Things like that.
> 

Well, that is 10% maths and 90% music theory. "a 7th" is for example 
insufficient - could be a major or minor 7th (and there are other more 
exotic possibilities). Those numbers are not really mathematical, but 
simple counting - the written distance on the music staff from one note 
to another. Thus C up to F# is an "augmented fourth" since C up to F is 
a 4th, then stretched a bit; while C up to Gb (identical sound in equal 
temperament, same keys on the piano) is a "diminished 5th", since C up 
to G is a 5th; then shrunk a little bit. There is no audible difference; 
a neutral description is "a tritone".

To get numbers for a harmonizer, you need to look up 12-tone Equal 
Temperament (for which the web is more than sufficient), and work out 
how to increment frequency in ET semitones.  For a simple harmonizer you 
would offer a range over some number of semitones, the intervals being 
fixed; at a further level you ask for a key or tonic and transpose 
diatonically according to the steps of the scale; at a further level 
still you might offer tunings in different temperaments such as 
Pythagorean or Just (etc), and quarter-tone or finer intervals. And so on.

Richard Dobson





From rbj at audioimagination.com  Tue Sep 15 12:09:32 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 15 Sep 2009 12:09:32 -0400
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <4AAFA11E.5010809@LittleEndian.com>
References: <4AAF79D0.9010606@LittleEndian.com>	<20090915124654.d9134b34.padawan12@obiwannabe.co.uk>	<41CEA91E-D4C3-4A5E-972F-36A7649C71EA@nuim.ie>
	<898dd7270909150538v6d06e655y41bec25c6379bb3f@mail.gmail.com>
	<4AAFA11E.5010809@LittleEndian.com>
Message-ID: <2AC47B40-2E34-4AAF-BC7D-5A694B7F4689@audioimagination.com>


On Sep 15, 2009, at 10:13 AM, Danijel Domazet wrote:

> Michael,
> I mean the mathematics of sounds.
>
> For example: I am trying to build a simple "harmonizer", and - I'd  
> like
> to understand what it means to "harmonize a melody to a 4th and a  
> 7th".
> Where do I shift my frequencies!!? Things like that.
>
>
> Thanks,
>
> Danijel Domazet
> CEO
> www.LittleEndian.com

you have a very cool domain name.  very creative.

and politically correct (i can say that as a former big-endian, Mot  
partisan and intel detractor).

i would recommend Gereth's Musimathics (both volumes), if you want a  
book in print.  it will set you back about US$170.  i dunno the other  
books.

there's a book that Alex Case did recently on effects that can give  
you an idea about what some effects are.

if you're unfamiliar with the traditional diatonic scales and the 12  
note per octave equally-tempered scale, i know there are books about  
that, too, but i dunno who they are.  i would only say that if your  
understanding is at that remedial level, you have a way to climb  
before implementing a harmonizer, whether it be  
"intelligent" (changes the interval according to the incoming pitch)  
or not.  not meaning to discourage, just to let you know that there  
will be other technical issues to solve long after you understand  
where to shift your frequencies (based on a given interval).

keep a line on this mailing list and maybe the comp.dsp newsgroup and  
ask questions.  i think you'll learn just as much as you will from  
the books.

goud luk.

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From martin.eisenberg at udo.edu  Wed Sep 16 08:45:58 2009
From: martin.eisenberg at udo.edu (Martin Eisenberg)
Date: Wed, 16 Sep 2009 14:45:58 +0200
Subject: [music-dsp] "mathematics of music" book?
References: <4AAF79D0.9010606@LittleEndian.com>
Message-ID: <002701ca36cb$a7be2d80$8b085e4e@cpe.ish>

Does anyone know a current URL for Rocchesso's Introduction to
Sound Processing? The link reachable from his homepage at Verona
doesn't work for me.


Martin


From richarddobson at blueyonder.co.uk  Wed Sep 16 09:22:07 2009
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Wed, 16 Sep 2009 14:22:07 +0100
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <002701ca36cb$a7be2d80$8b085e4e@cpe.ish>
References: <4AAF79D0.9010606@LittleEndian.com>
	<002701ca36cb$a7be2d80$8b085e4e@cpe.ish>
Message-ID: <4AB0E67F.3@blueyonder.co.uk>

Martin Eisenberg wrote:
> Does anyone know a current URL for Rocchesso's Introduction to
> Sound Processing? The link reachable from his homepage at Verona
> doesn't work for me.
> 
> 
This one works (I have just downloaded the file):

http://profs.sci.univr.it/~rocchess/SP/sp.pdf


Richard Dobson


From martin.eisenberg at udo.edu  Wed Sep 16 10:34:16 2009
From: martin.eisenberg at udo.edu (Martin Eisenberg)
Date: Wed, 16 Sep 2009 16:34:16 +0200
Subject: [music-dsp] "mathematics of music" book?
References: <4AAF79D0.9010606@LittleEndian.com><002701ca36cb$a7be2d80$8b085e4e@cpe.ish>
	<4AB0E67F.3@blueyonder.co.uk>
Message-ID: <000701ca36da$c8896b60$8b085e4e@cpe.ish>

Richard Dobson wrote:

> http://profs.sci.univr.it/~rocchess/SP/sp.pdf

Thanks, Richard!


Martin


From lanceboyle at qwest.net  Wed Sep 16 23:29:20 2009
From: lanceboyle at qwest.net (Jerry)
Date: Wed, 16 Sep 2009 20:29:20 -0700
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <4AAF79D0.9010606@LittleEndian.com>
References: <4AAF79D0.9010606@LittleEndian.com>
Message-ID: <A470ED25-6460-44B3-A36D-BFD5CD1AC990@qwest.net>

As long as we're throwing out titles, how about

DAFX: Digital Audio Effects, edited by Z?lzer, and
Digital Audio Signal Processing, also by Z?lzer

Jerry

On Sep 15, 2009, at 4:26 AM, Danijel Domazet wrote:

> Hi music-dsp,
> I'd like to learn about mathematics of music. Could someone please
> recommend a book on this? Focus should be on the math, not on the  
> whole
> music theory, if possible...
>
> Cheers!
>
>
> Danijel Domazet
> CEO
> www.LittleEndian.com
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>


From john.lazzaro at gmail.com  Thu Sep 17 15:08:41 2009
From: john.lazzaro at gmail.com (John Lazzaro)
Date: Thu, 17 Sep 2009 12:08:41 -0700
Subject: [music-dsp] AudioUnit support in new sfront release
Message-ID: <302f570909171208h70dcf9d4l81d640ddd5609525@mail.gmail.com>

Hi everyone,

The new sfront release includes support for
creating an AudioUnit plug-in from a SAOL
program ... the easiest way to get a sense
of what it can (and can't) do in its current
form is to read this description:

http://www.eecs.berkeley.edu/~lazzaro/sa/book/special/au/index.html

And, here is the sfront download link:

http://www.eecs.berkeley.edu/~lazzaro/sa/sfman/user/install/index.html#download

Have fun,

-- 
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
john [dot] lazzaro [at] gmail [dot] com

From acsmith at willamette.edu  Wed Sep 23 17:52:42 2009
From: acsmith at willamette.edu (Andrew C. Smith)
Date: Wed, 23 Sep 2009 17:52:42 -0400
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <A470ED25-6460-44B3-A36D-BFD5CD1AC990@qwest.net>
References: <4AAF79D0.9010606@LittleEndian.com>
	<A470ED25-6460-44B3-A36D-BFD5CD1AC990@qwest.net>
Message-ID: <aefbfc050909231452q1b097216v1656041249f32fe6@mail.gmail.com>

> To get numbers for a harmonizer, you need to look up 12-tone Equal
> Temperament (for which the web is more than sufficient), and work out
> how to increment frequency in ET semitones.

Not to pick a fight, but in order to create a harmonizer you really do
need to understand the sensation of tone. For this, check out "On the
Sensation of Tone" by Helmholtz. It's a mix of history (not
"traditional" music theory) and science, but it will definitely help
you in your quest for a harmonizer.

Andrew

On Wed, Sep 16, 2009 at 11:29 PM, Jerry <lanceboyle at qwest.net> wrote:
> As long as we're throwing out titles, how about
>
> DAFX: Digital Audio Effects, edited by Z?lzer, and
> Digital Audio Signal Processing, also by Z?lzer
>
> Jerry
>
> On Sep 15, 2009, at 4:26 AM, Danijel Domazet wrote:
>
>> Hi music-dsp,
>> I'd like to learn about mathematics of music. Could someone please
>> recommend a book on this? Focus should be on the math, not on the
>> whole
>> music theory, if possible...
>>
>> Cheers!
>>
>>
>> Danijel Domazet
>> CEO
>> www.LittleEndian.com
>>
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book
>> reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>

From Danijel.Domazet at littleendian.com  Fri Sep 25 11:01:46 2009
From: Danijel.Domazet at littleendian.com (Danijel Domazet)
Date: Fri, 25 Sep 2009 17:01:46 +0200
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <2AC47B40-2E34-4AAF-BC7D-5A694B7F4689@audioimagination.com>
References: <4AAF79D0.9010606@LittleEndian.com>	<20090915124654.d9134b34.padawan12@obiwannabe.co.uk>	<41CEA91E-D4C3-4A5E-972F-36A7649C71EA@nuim.ie>	<898dd7270909150538v6d06e655y41bec25c6379bb3f@mail.gmail.com>	<4AAFA11E.5010809@LittleEndian.com>
	<2AC47B40-2E34-4AAF-BC7D-5A694B7F4689@audioimagination.com>
Message-ID: <4ABCDB5A.4080102@LittleEndian.com>

Great suggestions!
I think I will go for Gareth's "Musimathics".


Thank you all for help... thank you, big rbj :)...

Danijel Domazet
CEO
www.LittleEndian.com



robert bristow-johnson wrote:
> On Sep 15, 2009, at 10:13 AM, Danijel Domazet wrote:
>
>   
>> Michael,
>> I mean the mathematics of sounds.
>>
>> For example: I am trying to build a simple "harmonizer", and - I'd  
>> like
>> to understand what it means to "harmonize a melody to a 4th and a  
>> 7th".
>> Where do I shift my frequencies!!? Things like that.
>>
>>
>> Thanks,
>>
>> Danijel Domazet
>> CEO
>> www.LittleEndian.com
>>     
>
> you have a very cool domain name.  very creative.
>
> and politically correct (i can say that as a former big-endian, Mot  
> partisan and intel detractor).
>
> i would recommend Gereth's Musimathics (both volumes), if you want a  
> book in print.  it will set you back about US$170.  i dunno the other  
> books.
>
> there's a book that Alex Case did recently on effects that can give  
> you an idea about what some effects are.
>
> if you're unfamiliar with the traditional diatonic scales and the 12  
> note per octave equally-tempered scale, i know there are books about  
> that, too, but i dunno who they are.  i would only say that if your  
> understanding is at that remedial level, you have a way to climb  
> before implementing a harmonizer, whether it be  
> "intelligent" (changes the interval according to the incoming pitch)  
> or not.  not meaning to discourage, just to let you know that there  
> will be other technical issues to solve long after you understand  
> where to shift your frequencies (based on a given interval).
>
> keep a line on this mailing list and maybe the comp.dsp newsgroup and  
> ask questions.  i think you'll learn just as much as you will from  
> the books.
>
> goud luk.
>
> --
>
> r b-j                  rbj at 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
>   

From cheater00 at gmail.com  Fri Sep 25 20:31:18 2009
From: cheater00 at gmail.com (cheater cheater)
Date: Sat, 26 Sep 2009 01:31:18 +0100
Subject: [music-dsp] A little question about DSP performance
Message-ID: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>

Hi guys,
I have a question about band limited oscillators in relation to the
(now aged) 56303 microprocessor. The choice of hardware is dictated by
an existing hardware platform.

Suppose I wanted to run the oscillators at a sampling rate of 48kHz -
how many of them could I possibly fit on the 56303? Since older
hardware needs a bit of compromise, then I should mention that what
I'm looking for is pitch correctness, no aliasing, and that's.. pretty
much it. I'm thinking of doing the 'virtual analog' BLT stuff as well
as the wavetable stuff.

How many BLT based oscillators can go onto the 56303? If you have
experience with this and can come up with numbers - then what approach
would you be using to implement them?

Alternatively: what is the computationally least expensive
implementation of band limited oscillators? We're talking about PW,
triangle, saw, sin, and that's about it.

Thanks a lot

From badmuthahubbard at gmail.com  Fri Sep 25 21:00:04 2009
From: badmuthahubbard at gmail.com (Chuckk Hubbard)
Date: Sat, 26 Sep 2009 04:00:04 +0300
Subject: [music-dsp] "mathematics of music" book?
In-Reply-To: <79EE22ED-D479-48CF-B307-0C56B637E22C@nuim.ie>
References: <4AAF79D0.9010606@LittleEndian.com>
	<79EE22ED-D479-48CF-B307-0C56B637E22C@nuim.ie>
Message-ID: <8200bab70909251800p7cd8b0ffn405cb1c72e5741c@mail.gmail.com>

Any book with Wendy Carlos, Harry Partch, and Adriaan Fokker is fine with me.

For psychology I enjoyed Meyer's 'Emotion and Meaning in Music'.

-Chuckk

On Tue, Sep 15, 2009 at 2:31 PM, Victor Lazzarini
<Victor.Lazzarini at nuim.ie> wrote:
> I like this one:
>
> http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html
>
> Victor
>
> On 15 Sep 2009, at 12:26, Danijel Domazet wrote:
>
>> Hi music-dsp,
>> I'd like to learn about mathematics of music. Could someone please
>> recommend a book on this? Focus should be on the math, not on the
>> whole
>> music theory, if possible...
>>
>> Cheers!
>>
>>
>> Danijel Domazet
>> CEO
>> www.LittleEndian.com
>>
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book
>> reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>



-- 
http://www.badmuthahubbard.com

From rbj at audioimagination.com  Fri Sep 25 21:42:41 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Fri, 25 Sep 2009 21:42:41 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
References: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
Message-ID: <CD750B6E-8EDE-47C3-AD03-CDAD153A99E9@audioimagination.com>

On Sep 25, 2009, at 8:31 PM, cheater cheater wrote:

> Hi guys,
> I have a question about band limited oscillators in relation to the
> (now aged) 56303 microprocessor. The choice of hardware is dictated by
> an existing hardware platform.
>
> Suppose I wanted to run the oscillators at a sampling rate of 48kHz -
> how many of them could I possibly fit on the 56303? Since older
> hardware needs a bit of compromise, then I should mention that what
> I'm looking for is pitch correctness, no aliasing, and that's.. pretty
> much it. I'm thinking of doing the 'virtual analog' BLT stuff as well
> as the wavetable stuff.

it's been a while since i was doing this with the 56K, but to do a  
bandlimited oscillator on the 56K, i am convinced that the best and  
least expensive and most general method is wavetable synthesis (do  
*not* try to do this algorithmically) with a set of large wavetables  
(that costs memory but not instruction cycles) and linear  
interpolation.  linear interpolation is still pretty cheap, but if  
memory costs are no object, you could consider direct table lookup  
with no interpolation and save some computation.  for a single  
waveform (but at different pitches), you have several wavetables of  
the same waveform except with progressively missing upper harmonics  
which are used for higher pitches.  you can even mix or interpolate  
between adjacent wavetables as your note goes up the keyboard.


lessee....


     move                 x:increment,x0
     move                 x:phase,b
     move                 #>(1.0/wavetable_size),x1
     move                 #>output_ptr,r0
     move                 b1,y0               ; this causes wrap  
around that we want
     mpy    x1,y0,a       #>wavetable,r4
     do     #num_samples_in_block,sample_loop
     nop
     move                                a1,n4       ; integer part
     move                 a0,a1                      ; fractional part
     nop
     nop
     lsr    a                            (r4)+n4
     add   x0,b                          y:(r4)+,y0  ; incr phase
     tfr   y0,a           a1,y1
     mac   -y1,y0,a                      y:(r4)-n4,y0
     macr  y1,y0,a        x:(r0),y0
     add   y0,a           b1,y0
     nop
     mpy    x1,y0,a       a,x:(r0)+      y:(r4)-,y0  ; dummy read to y0
sample_loop
     move                 b,x:phase

the nops are unnecessary, but they accurately reflect necessary  
pipelining delays.  i would not be surprized if this could be  
optimized better, but it looks like about 13 instruction cycles per  
sample per oscillator.  with that you can do the math to find out how  
many oscillators you can do.  maybe you can do something to cut down  
on the pipeline delays.

i tried to get Kurzweil interested in this (wavetable synthesis) for  
their bandlimited waveforms (not with the 56300 but with their  
existing sample-playback technology that has the interpolation built  
in).  they weren't interested and insisted that i do it their way  
(which i did but you can't for the general case, it works only for  
specific waveforms) and then after that they fired me (literally a  
day after i got the alias-suppressed hard-sync to work).  even smart  
people have closed minds and do dumb things.  i'm not immune to that  
either.

rots o' ruck

r b-j

>
>
> How many BLT based oscillators can go onto the 56303? If you have
> experience with this and can come up with numbers - then what approach
> would you be using to implement them?
>
> Alternatively: what is the computationally least expensive
> implementation of band limited oscillators? We're talking about PW,
> triangle, saw, sin, and that's about it.
>
> Thanks a lot
> --
> 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
>

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From cheater00 at gmail.com  Sat Sep 26 05:08:27 2009
From: cheater00 at gmail.com (cheater cheater)
Date: Sat, 26 Sep 2009 10:08:27 +0100
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <CD750B6E-8EDE-47C3-AD03-CDAD153A99E9@audioimagination.com>
References: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
	<CD750B6E-8EDE-47C3-AD03-CDAD153A99E9@audioimagination.com>
Message-ID: <cf1e1cb10909260208g61a7295aie94fb7eb08279634@mail.gmail.com>

Wow, sorry to hear about Kurzweil, Robert! Well, I'm not surprised
they are not releasing any new keyboards if they fired the good
workers. Too bad for them - someone else can make cool samplers now.
Hope you've found a good place since.

I was wondering about the wavetable approach. One of the premises is
to implement ppg-style 'wavetables' with interpolation. The main
problem could turn out to be the amount of memory available on the
platform (which sadly cannot be increased that I know of)

Another requirement is to do hard sync, which is impossible without
band limited transients. And then throw FM on top of that.

What are your pointers?

Cheers
D.



On Sat, Sep 26, 2009 at 2:42 AM, robert bristow-johnson
<rbj at audioimagination.com> wrote:
> On Sep 25, 2009, at 8:31 PM, cheater cheater wrote:
>
>> Hi guys,
>> I have a question about band limited oscillators in relation to the
>> (now aged) 56303 microprocessor. The choice of hardware is dictated by
>> an existing hardware platform.
>>
>> Suppose I wanted to run the oscillators at a sampling rate of 48kHz -
>> how many of them could I possibly fit on the 56303? Since older
>> hardware needs a bit of compromise, then I should mention that what
>> I'm looking for is pitch correctness, no aliasing, and that's.. pretty
>> much it. I'm thinking of doing the 'virtual analog' BLT stuff as well
>> as the wavetable stuff.
>
> it's been a while since i was doing this with the 56K, but to do a
> bandlimited oscillator on the 56K, i am convinced that the best and
> least expensive and most general method is wavetable synthesis (do
> *not* try to do this algorithmically) with a set of large wavetables
> (that costs memory but not instruction cycles) and linear
> interpolation. ?linear interpolation is still pretty cheap, but if
> memory costs are no object, you could consider direct table lookup
> with no interpolation and save some computation. ?for a single
> waveform (but at different pitches), you have several wavetables of
> the same waveform except with progressively missing upper harmonics
> which are used for higher pitches. ?you can even mix or interpolate
> between adjacent wavetables as your note goes up the keyboard.
>
>
> lessee....
>
>
> ? ? move ? ? ? ? ? ? ? ? x:increment,x0
> ? ? move ? ? ? ? ? ? ? ? x:phase,b
> ? ? move ? ? ? ? ? ? ? ? #>(1.0/wavetable_size),x1
> ? ? move ? ? ? ? ? ? ? ? #>output_ptr,r0
> ? ? move ? ? ? ? ? ? ? ? b1,y0 ? ? ? ? ? ? ? ; this causes wrap
> around that we want
> ? ? mpy ? ?x1,y0,a ? ? ? #>wavetable,r4
> ? ? do ? ? #num_samples_in_block,sample_loop
> ? ? nop
> ? ? move ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?a1,n4 ? ? ? ; integer part
> ? ? move ? ? ? ? ? ? ? ? a0,a1 ? ? ? ? ? ? ? ? ? ? ?; fractional part
> ? ? nop
> ? ? nop
> ? ? lsr ? ?a ? ? ? ? ? ? ? ? ? ? ? ? ? ?(r4)+n4
> ? ? add ? x0,b ? ? ? ? ? ? ? ? ? ? ? ? ?y:(r4)+,y0 ?; incr phase
> ? ? tfr ? y0,a ? ? ? ? ? a1,y1
> ? ? mac ? -y1,y0,a ? ? ? ? ? ? ? ? ? ? ?y:(r4)-n4,y0
> ? ? macr ?y1,y0,a ? ? ? ?x:(r0),y0
> ? ? add ? y0,a ? ? ? ? ? b1,y0
> ? ? nop
> ? ? mpy ? ?x1,y0,a ? ? ? a,x:(r0)+ ? ? ?y:(r4)-,y0 ?; dummy read to y0
> sample_loop
> ? ? move ? ? ? ? ? ? ? ? b,x:phase
>
> the nops are unnecessary, but they accurately reflect necessary
> pipelining delays. ?i would not be surprized if this could be
> optimized better, but it looks like about 13 instruction cycles per
> sample per oscillator. ?with that you can do the math to find out how
> many oscillators you can do. ?maybe you can do something to cut down
> on the pipeline delays.
>
> i tried to get Kurzweil interested in this (wavetable synthesis) for
> their bandlimited waveforms (not with the 56300 but with their
> existing sample-playback technology that has the interpolation built
> in). ?they weren't interested and insisted that i do it their way
> (which i did but you can't for the general case, it works only for
> specific waveforms) and then after that they fired me (literally a
> day after i got the alias-suppressed hard-sync to work). ?even smart
> people have closed minds and do dumb things. ?i'm not immune to that
> either.
>
> rots o' ruck
>
> r b-j
>
>>
>>
>> How many BLT based oscillators can go onto the 56303? If you have
>> experience with this and can come up with numbers - then what approach
>> would you be using to implement them?
>>
>> Alternatively: what is the computationally least expensive
>> implementation of band limited oscillators? We're talking about PW,
>> triangle, saw, sin, and that's about it.
>>
>> Thanks a lot
>> --
>> 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
>>
>
> --
>
> r b-j ? ? ? ? ? ? ? ? ?rbj at 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
>

From didid at skynet.be  Sat Sep 26 18:11:38 2009
From: didid at skynet.be (Didier Dambrin)
Date: Sun, 27 Sep 2009 00:11:38 +0200
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
References: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
Message-ID: <C2D3392ED55542859E6AD308C913A93F@GOLAMD>

It probably won't help you, but I'm currently working on a 'sine bank' 
processor to compute common shape through additive synthesis.
Using various tricks it can be very efficient, efficient enough for a 
classic synthesizer. But it's very CPU-dependent, using SSE & pairing 
tricks, & I have no idea if that would be possible on your targetted CPU.




> Hi guys,
> I have a question about band limited oscillators in relation to the
> (now aged) 56303 microprocessor. The choice of hardware is dictated by
> an existing hardware platform.
>
> Suppose I wanted to run the oscillators at a sampling rate of 48kHz -
> how many of them could I possibly fit on the 56303? Since older
> hardware needs a bit of compromise, then I should mention that what
> I'm looking for is pitch correctness, no aliasing, and that's.. pretty
> much it. I'm thinking of doing the 'virtual analog' BLT stuff as well
> as the wavetable stuff.
>
> How many BLT based oscillators can go onto the 56303? If you have
> experience with this and can come up with numbers - then what approach
> would you be using to implement them?
>
> Alternatively: what is the computationally least expensive
> implementation of band limited oscillators? We're talking about PW,
> triangle, saw, sin, and that's about it.
>
> Thanks a lot
> -- 


From rej at 2uptech.com  Sat Sep 26 19:46:20 2009
From: rej at 2uptech.com (Randy Jones)
Date: Sat, 26 Sep 2009 16:46:20 -0700
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <7A8BE7E7-3676-48BF-921B-D705DE83B6C6@madronalabs.com>
References: <mailman.802.1254003118.139.music-dsp@music.columbia.edu>
	<7A8BE7E7-3676-48BF-921B-D705DE83B6C6@madronalabs.com>
Message-ID: <EE2462BA-8AA5-470A-9EA4-32B51C9A3466@2uptech.com>


There's a paper from DAFX09 by Nam, Valimaki, Abel and Smith (JOS)  
that you might be interested in:   "Alias-free Virtual Analog  
Oscillators Using a Feedback Delay Loop".

-Randy

On Sep 26, 2009, at 3:11 PM, music-dsp-request at music.columbia.edu wrote:

>>
>> Alternatively: what is the computationally least expensive
>> implementation of band limited oscillators? We're talking about PW,
>> triangle, saw, sin, and that's about it.
>


From gwenhwyfaer at gmail.com  Sat Sep 26 21:14:49 2009
From: gwenhwyfaer at gmail.com (Gwenhwyfaer)
Date: Sun, 27 Sep 2009 02:14:49 +0100
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <EE2462BA-8AA5-470A-9EA4-32B51C9A3466@2uptech.com>
References: <mailman.802.1254003118.139.music-dsp@music.columbia.edu>
	<7A8BE7E7-3676-48BF-921B-D705DE83B6C6@madronalabs.com>
	<EE2462BA-8AA5-470A-9EA4-32B51C9A3466@2uptech.com>
Message-ID: <df5b05ea0909261814o42fc6b9aj7248bec29116a880@mail.gmail.com>

On 27/09/2009, Randy Jones <rej at 2uptech.com> wrote:
>
> There's a paper from DAFX09 by Nam, Valimaki, Abel and Smith (JOS)
> that you might be interested in:   "Alias-free Virtual Analog
> Oscillators Using a Feedback Delay Loop".

Here's a link:  http://dafx09.como.polimi.it/proceedings/papers/paper_72.pdf

(There's probably a more straightforward way to find it than the one I
adopted, but I couldn't find it.)

From rbj at audioimagination.com  Sun Sep 27 02:40:12 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Sun, 27 Sep 2009 02:40:12 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <cf1e1cb10909260208g61a7295aie94fb7eb08279634@mail.gmail.com>
References: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
	<CD750B6E-8EDE-47C3-AD03-CDAD153A99E9@audioimagination.com>
	<cf1e1cb10909260208g61a7295aie94fb7eb08279634@mail.gmail.com>
Message-ID: <EC59AEE9-65BC-4D5E-9FE9-AEBFC76C3966@audioimagination.com>


On Sep 26, 2009, at 5:08 AM, cheater cheater wrote:

> Wow, sorry to hear about Kurzweil, Robert! Well, I'm not surprised
> they are not releasing any new keyboards if they fired the good
> workers.

well, there are variations of the PC3 and SP2, but they have an  
"engineering model" (i wouldn't know what else to call it) that  
eschews putting technology into containers.  as a result it's like  
pulling teeth to plug new features into the existing system.  they  
would deny it, but it really is like they just don't have a concept  
of an API.

> Too bad for them - someone else can make cool samplers now.
> Hope you've found a good place since.

i'm pushing 54 now.  i don't think i'll ever be other than self- 
employed.  when i'm contracting, i usually don't wanna say who i'm  
working for on a list like this (or on USENET).


> I was wondering about the wavetable approach. One of the premises is
> to implement ppg-style 'wavetables' with interpolation.

"interpolation" with wavetables can mean a few different things.   
there is interpolation between adjacent samples in the wavetable (the  
linear interpolation i tried to depict in the 56K code, but in other  
contexts it could be gooder sinc-like interpolation).  there is also  
interpolation between wavetables as a function of some parameter in  
another dimension.  e.g. time: as the waveform shape evolves in time,  
the waveshape is some morph between two adjacent wavetables.

another dimension is the position of the note in the musical range or  
keyboard.  that is relevant for doing bandlimited classic waveforms  
like a sawtooth or square or even a hard-sync.  you have two facts  
that tell you something: 1. it is periodic (therefore fourier series  
is valid) and 2. it is bandlimited (therefore the fourier series has  
a finite limit of harmonics).  whatever analog waveform you have, and  
at whatever note on the keyboard you are playing, there is a  
waveshape that approximates your ideal sawtooth that has all of the  
harmonics all the way up to, say, one octave below Nyquist.  you can  
play that waveform up an entire octave from where it started and not  
get any aliasing and while your note moves up the keyboard, you cross- 
fade that wavetable out while fading in a similar one but missing  
even more harmonics.  this works particularly well for Fs=96 kHz  
because that top octave that may or may not have harmonics in is  
above 20 kHz, allowing you to keep the waveform harmonically rich all  
the way to 20 kHz.

> The main
> problem could turn out to be the amount of memory available on the
> platform (which sadly cannot be increased that I know of)

well, that's a problem.  if you linearly interpolate between adjacent  
samples, you might be able to get away with wavetables as big as 256  
samples.  it depends on how many harmonics you have in them.  if you  
*really* do this carefully, you can have wavetables for the lower  
notes be longer than those for higher notes and *still* interpolate  
between wavetables (of different lengths) as your note goes up the  
keyboard and harmonics start to drop off before they would alias.

> Another requirement is to do hard sync, which is impossible without
> band limited transients. And then throw FM on top of that.

if they are periodic functions (or quasi-periodic, *slowly* changing  
periodic), you can do it with wavetable whether it's hard sync, FM  
(where the carrier and modulation frequencies are both integer  
multiples of a common fundamental), or classic analog waveforms.


--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From padawan12 at obiwannabe.co.uk  Sun Sep 27 05:52:33 2009
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sun, 27 Sep 2009 10:52:33 +0100
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <C2D3392ED55542859E6AD308C913A93F@GOLAMD>
References: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
	<C2D3392ED55542859E6AD308C913A93F@GOLAMD>
Message-ID: <20090927105233.ed2b570b.padawan12@obiwannabe.co.uk>


would certainly like to hear of any cool SSE tricks
in this regard. Also exploring the possibility of using
GPU in a new synthesis project.


On Sun, 27 Sep 2009 00:11:38 +0200
"Didier Dambrin" <didid at skynet.be> wrote:

> It probably won't help you, but I'm currently working on a 'sine bank' 
> processor to compute common shape through additive synthesis.
> Using various tricks it can be very efficient, efficient enough for a 
> classic synthesizer. But it's very CPU-dependent, using SSE & pairing 
> tricks, & I have no idea if that would be possible on your targetted CPU.
> 
> 
> 
> 
> > Hi guys,
> > I have a question about band limited oscillators in relation to the
> > (now aged) 56303 microprocessor. The choice of hardware is dictated by
> > an existing hardware platform.
> >
> > Suppose I wanted to run the oscillators at a sampling rate of 48kHz -
> > how many of them could I possibly fit on the 56303? Since older
> > hardware needs a bit of compromise, then I should mention that what
> > I'm looking for is pitch correctness, no aliasing, and that's.. pretty
> > much it. I'm thinking of doing the 'virtual analog' BLT stuff as well
> > as the wavetable stuff.
> >
> > How many BLT based oscillators can go onto the 56303? If you have
> > experience with this and can come up with numbers - then what approach
> > would you be using to implement them?
> >
> > Alternatively: what is the computationally least expensive
> > implementation of band limited oscillators? We're talking about PW,
> > triangle, saw, sin, and that's about it.
> >
> > Thanks a lot
> > -- 
> 
> --
> 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

From Victor.Lazzarini at nuim.ie  Sun Sep 27 06:30:00 2009
From: Victor.Lazzarini at nuim.ie (victor)
Date: Sun, 27 Sep 2009 11:30:00 +0100
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <EC59AEE9-65BC-4D5E-9FE9-AEBFC76C3966@audioimagination.com>
References: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
	<CD750B6E-8EDE-47C3-AD03-CDAD153A99E9@audioimagination.com>
	<cf1e1cb10909260208g61a7295aie94fb7eb08279634@mail.gmail.com>
	<EC59AEE9-65BC-4D5E-9FE9-AEBFC76C3966@audioimagination.com>
Message-ID: <F7A24BADA4D542B6A7CEDB55E961586C@LazzariniPC>

Why not? It'd be nice to know who did this or that particular
product or feature. It's like when we like to know who the composer
of this masterpiece is.

> i'm pushing 54 now.  i don't think i'll ever be other than self- 
> employed.  when i'm contracting, i usually don't wanna say who i'm  
> working for on a list like this (or on USENET).

sorry for the OT

Victor

From raga.raga at gmx.de  Sun Sep 27 06:56:06 2009
From: raga.raga at gmx.de (Jan Baumgart)
Date: Sun, 27 Sep 2009 12:56:06 +0200
Subject: [music-dsp] Global DSP online magazine Archives?
Message-ID: <4ABF44C6.7070005@gmx.de>

hi,

i've just stumbled across some interestings dsp links referring to 
www.globaldsp.com.
Unfortunately the domain seems to be down or probably sold.
Anyone knows, if there's a archive/backup of this online magazine anywhere?
Had no luck with google yet...

cheers,
jan

From didid at skynet.be  Sun Sep 27 07:54:10 2009
From: didid at skynet.be (Didier Dambrin)
Date: Sun, 27 Sep 2009 13:54:10 +0200
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <20090927105233.ed2b570b.padawan12@obiwannabe.co.uk>
References: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com><C2D3392ED55542859E6AD308C913A93F@GOLAMD>
	<20090927105233.ed2b570b.padawan12@obiwannabe.co.uk>
Message-ID: <D530481E255F4813983D960669CAB55C@GOLAMD>

Well the main trick is to use that famous sine identity to compute waveforms 
based on 2 consecutive sines and a cosine.
To do the most in parallel, you'd use SSE to process 4 or 8 per block.  But 
with single accuracy, you have to periodically refresh those parameters 
because of the accumulating error (which isn't so much a problem since you'd 
need to refresh them for pitch bending or LFO as well), computing real sines 
periodically (I use Intel's IPP for this).
Also the algo could process one waveform splitted in 4 interleaved blocks, 
but that would require computing 4x real sines per waveform, thus I instead 
process them in parallel (interleaving waveforms). But this also requires 
sorting those waveforms on the fly, since you wouldn't want to process 
waveforms that are inaudible (over nyquist, or odd harmonics or a squarewave 
that can morph to a saw).

So the amount of sines I could compute is enormous, I think at one point it 
reached 30k sines to max out my CPU, and that's without multithreading.

-however- it's a bit like an ultrafast GPU (before they also did transform) 
on a slow CPU, the CPU would struggle to transform the geometry that the GPU 
would render. Same thing here, you still have to process effects on those 
sines (which is the whole point of doing it through additive synth). So 
things like filtering will be done on the waveforms themselves, and that of 
course has a CPU cost as well.



Of course there's also FFT.
What you can do is to pre-store the FFT of your (single) oscillator. At 
voice-trigger time, you filter the FFT and you inverse it, and use that as 
your oscillator.
If you oversample 2x, you would then filter the FFT at 3/4 Nyquist, that 
would leave you a +-6 semitones room for pitch-bending.
But depending on the waveform, if you're only using a linear interpolator, 
you may need a rather big FFT, and you'll run into cache problems. And 
better interpolators will cost more than other methods.
With a good FFT library, you will see that processing such small/average 
blocks is very light on the CPU, it's really something you can afford doing 
at voice-trigger, instead of precomputing a table.





> would certainly like to hear of any cool SSE tricks
> in this regard. Also exploring the possibility of using
> GPU in a new synthesis project.
>
>
> On Sun, 27 Sep 2009 00:11:38 +0200
> "Didier Dambrin" <didid at skynet.be> wrote:
>
>> It probably won't help you, but I'm currently working on a 'sine bank'
>> processor to compute common shape through additive synthesis.
>> Using various tricks it can be very efficient, efficient enough for a
>> classic synthesizer. But it's very CPU-dependent, using SSE & pairing
>> tricks, & I have no idea if that would be possible on your targetted CPU.
>>
>>
>>
>>
>> > Hi guys,
>> > I have a question about band limited oscillators in relation to the
>> > (now aged) 56303 microprocessor. The choice of hardware is dictated by
>> > an existing hardware platform.
>> >
>> > Suppose I wanted to run the oscillators at a sampling rate of 48kHz -
>> > how many of them could I possibly fit on the 56303? Since older
>> > hardware needs a bit of compromise, then I should mention that what
>> > I'm looking for is pitch correctness, no aliasing, and that's.. pretty
>> > much it. I'm thinking of doing the 'virtual analog' BLT stuff as well
>> > as the wavetable stuff.
>> >
>> > How many BLT based oscillators can go onto the 56303? If you have
>> > experience with this and can come up with numbers - then what approach
>> > would you be using to implement them?
>> >
>> > Alternatively: what is the computationally least expensive
>> > implementation of band limited oscillators? We're talking about PW,
>> > triangle, saw, sin, and that's about it.
>> >
>> > Thanks a lot
>> > -- 
>>
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book reviews, 
>> dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, 
> dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.113/2398 - Release Date: 09/27/09 
05:51:00


From rbj at audioimagination.com  Sun Sep 27 12:06:41 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Sun, 27 Sep 2009 12:06:41 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <F7A24BADA4D542B6A7CEDB55E961586C@LazzariniPC>
References: <cf1e1cb10909251731m671cf387wc7ada97dcad115b3@mail.gmail.com>
	<CD750B6E-8EDE-47C3-AD03-CDAD153A99E9@audioimagination.com>
	<cf1e1cb10909260208g61a7295aie94fb7eb08279634@mail.gmail.com>
	<EC59AEE9-65BC-4D5E-9FE9-AEBFC76C3966@audioimagination.com>
	<F7A24BADA4D542B6A7CEDB55E961586C@LazzariniPC>
Message-ID: <584F13C9-1FE7-48C4-83A5-460D7B0C2DE6@audioimagination.com>


On Sep 27, 2009, at 6:30 AM, victor wrote:

> Why not? It'd be nice to know who did this or that particular
> product or feature. It's like when we like to know who the composer
> of this masterpiece is.
>
>> i'm pushing 54 now.  i don't think i'll ever be other than self-
>> employed.  when i'm contracting, i usually don't wanna say who i'm
>> working for on a list like this (or on USENET).
>
> sorry for the OT

i don't think it's OT.

when i've been an employee with a company and i get biz cards that  
have the company's name and my name on the same document, i can say  
that i represent the company in some manner.  i don't mind at all  
saying that the fruits of my efforts ended up in Eventide or Wave  
Mechanics (now known as SoundToys) or Kurzweil, and the companies  
can't (and don't) deny that fact.  it's different when i consult/ 
contract.

but one thing that is different, although i must (and do) respect  
their trade secrets that i may come upon in the work that i do for  
companies i contract with, the novel contribution *i* make as a  
contractor is not their property, but mine (or in the public  
domain).  i can't go say "I've implemented algorithm X for the work  
I've done for company Y."  but i can say i've done this algorithm X  
and speak publicly about it or, at my own discretion, keep it secret  
and use it again for work that i do for company Y's competitor.

i am told that my name appears (among other engineers) in the power- 
up or "About .." window in the PC3, so i think that it would not make  
any trouble if i said that i designed and implemented some synthesis  
features in the PC3 and they can't sue me for revealing any  
confidential information.  but there are certainly limits to how much  
detail i can go into.

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From passionjam at yahoo.com  Mon Sep 28 15:01:12 2009
From: passionjam at yahoo.com (Les)
Date: Mon, 28 Sep 2009 12:01:12 -0700 (PDT)
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <EC59AEE9-65BC-4D5E-9FE9-AEBFC76C3966@audioimagination.com>
Message-ID: <150537.29137.qm@web53512.mail.re2.yahoo.com>

--- On Sat, 9/26/09, robert bristow-johnson <rbj at audioimagination.com> wrote:

> if you linearly interpolate between adjacent? 
> samples, you might be able to get away with wavetables as
> big as 256?samples.? it depends on how many harmonics you have in
> them.? if you? *really* do this carefully, you can have wavetables for 
> the lower?notes be longer than those for higher notes and *still*
> interpolate between wavetables (of different lengths) as your note goes
> up the?keyboard and harmonics start to drop off before they would
> alias.

I know Korg's DW6000 and DW8000 used this approach. There were 8 versions of each waveform, with succeeding waveforms becoming more and more bandlimited. The lengths of the waveforms were 2048, 2048, 1024, 1024, 512, 512, 512, 512, for a total of 8192 bytes (the waveforms were 8 bit).

I've been curious for awhile now what kind of interpolation they used, if any, for reading the waveforms back as well as interpolating between adjacent waveforms. Unfortunately, I don't have one handy to test...

I agree it would take some care interpolating between waveforms of various lengths. When I wrote a VST synth based on this approach, I simply made all of the waveforms the same length to make things easier on myself. :)


      

From gsn10 at hotmail.com  Mon Sep 28 18:20:44 2009
From: gsn10 at hotmail.com (Scott Nordlund)
Date: Mon, 28 Sep 2009 18:20:44 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <150537.29137.qm@web53512.mail.re2.yahoo.com>
References: <EC59AEE9-65BC-4D5E-9FE9-AEBFC76C3966@audioimagination.com>
Message-ID: <SNT104-W7FFABC9EF638C6B3DEC12B4D60@phx.gbl>


 <150537.29137.qm at web53512.mail.re2.yahoo.com>
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> --- On Sat=2C 9/26/09=2C robert bristow-johnson wrote:
>
>> if you linearly interpolate between adjacent
>> samples=2C you might be able to get away with wavetables as
>> big as 256 samples. it depends on how many harmonics you have in
>> them. if you *really* do this carefully=2C you can have wavetables for
>> the lower notes be longer than those for higher notes and *still*
>> interpolate between wavetables (of different lengths) as your note goes
>> up the keyboard and harmonics start to drop off before they would
>> alias.
>
> I know Korg's DW6000 and DW8000 used this approach. There were 8 versions=
 of each waveform=2C with succeeding waveforms becoming more and more bandl=
imited. The lengths of the waveforms were 2048=2C 2048=2C 1024=2C 1024=2C 5=
12=2C 512=2C 512=2C 512=2C for a total of 8192 bytes (the waveforms were 8 =
bit).
>
> I've been curious for awhile now what kind of interpolation they used=2C =
if any=2C for reading the waveforms back as well as interpolating between a=
djacent waveforms. Unfortunately=2C I don't have one handy to test...
>
> I agree it would take some care interpolating between waveforms of variou=
s lengths. When I wrote a VST synth based on this approach=2C I simply made=
 all of the waveforms the same length to make things easier on myself. :)
=20
=20
I believe they didn't interpolate between samples or between waveforms: sim=
ply nearest neighbor playback using multisamples (split by octave=2C I thin=
k).  This uses a lot of ROM (2048 bytes for a single cycle waveform is huge=
 in 1985)=2C but the band limiting permitted nearest neighbor sample playba=
ck at a modest sample rate (50 kHz=2C I think) with not much aliasing (from=
 memory=2C it really only aliases if you're using the pitch bender or porta=
mento).  Due to the fairly low sample rate=2C all 16 oscillators can be gen=
erated by one DAC with sample and holds to demultiplex.
=20
You can compare this to the PPG Wave series=2C which uses short waveforms (=
256 samples=2C I think)=2C no multisamples=2C and high sample rate (somethi=
ng like 300 kHz)=2C but has a DAC per oscillator. 		 	   		  =0A=
_________________________________________________________________=0A=
Lauren found her dream laptop. Find the PC that=92s right for you.=0A=
http://www.microsoft.com/windows/choosepc/?ocid=3Dftp_val_wl_290=

From didid at skynet.be  Mon Sep 28 18:48:33 2009
From: didid at skynet.be (Didier Dambrin)
Date: Tue, 29 Sep 2009 00:48:33 +0200
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <150537.29137.qm@web53512.mail.re2.yahoo.com>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com>
Message-ID: <341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>


> if you linearly interpolate between adjacent
> samples, you might be able to get away with wavetables as
> big as 256 samples.  it depends on how many harmonics you have in
> them.

It's not just depending on how many harmonics, but how they're arranged. 
Change the phase of just one of the higher harmonics in a saw, and you will 
need a bigger table.  Let the user use his own waveshapes, and you will 
really need a big table. In fact, big enough to provide enough quality for 
the very last harmonic alone.

You could decide on the error you're ok with, see how much in-between values 
derive from the original waveform, & then see what table size you need. 


From rbj at audioimagination.com  Mon Sep 28 20:09:54 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Mon, 28 Sep 2009 20:09:54 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com>
	<341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>
Message-ID: <07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>


On Sep 28, 2009, at 6:48 PM, Didier Dambrin wrote:

>
>> if you linearly interpolate between adjacent
>> samples, you might be able to get away with wavetables as
>> [small] as 256 samples.  it depends on how many harmonics you have in
>> them.
note [correction].

> It's not just depending on how many harmonics, but how they're  
> arranged.
> Change the phase of just one of the higher harmonics in a saw, and  
> you will
> need a bigger table.

hmmmmm.

>   Let the user use his own waveshapes, and you will
> really need a big table.

we if he draws out some really wild-assed waveshapes with a lot of  
discontinuities, you might get a lot of loud harmonics and need a big  
wavetable for that.

> In fact, big enough to provide enough quality for
> the very last harmonic alone.

if your interpolator is good, just over two samples for the highest  
harmonic will provide the required quality.

> You could decide on the error you're ok with, see how much in- 
> between values
> derive from the original waveform, & then see what table size you  
> need.

this is interesting, or could be the onset of an interesting  
discussion because, i think, when we get down to unambiguous  
technical claims, i don't think i agree with you, Didier.  maybe i'm  
wrong.

so you're saying that, given an inter-sample interpolation method  
(that is somehow deemed "good enough"), and a bandlimited waveform  
stored in a wavetable, that if you come up with an identical waveform  
with the same set of harmonics, that when you change the phase on one  
or more of them that you will need a wavetable with more samples in  
it?  that's awful curious to me.

if i have a really kick-ass interpolator, probably not very cheap,  
like a 32-point sinc function (with, say, a kaiser window), i think  
that all i need is more than twice the number of samples in the  
wavetable as there are harmonics in the waveform.  now, this gets  
different if, for the sake of computational burden, i do something  
cheaper for interpolation (like linear).  then you need more points  
in the wavetable that is actually used in synthesis.  but you can  
take a barely-sufficiently sampled waveform (number of points are 2N 
+1) and analytically expand that (at program load time) into a  
wavetable with 2048 samples or similar for use in playback.   
sometimes having 127 harmonics (counting the fundamental) is good  
enough and, theoretically, 256 samples in the wavetable would  
accommodate that.

maybe i'm misunderstanding what you're saying.

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From didid at skynet.be  Mon Sep 28 21:56:01 2009
From: didid at skynet.be (Didier Dambrin)
Date: Tue, 29 Sep 2009 03:56:01 +0200
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com><341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>
	<07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>
Message-ID: <13ED037613D84AF1B6D9308B26D5C117@GOLAMD>


>> In fact, big enough to provide enough quality for
>> the very last harmonic alone.
>
> if your interpolator is good, just over two samples for the highest
> harmonic will provide the required quality.
>

Ok but if the interpolator starts costing a lot of CPU, maybe using bigger 
tables & have cache problems will still perform better.

What interpolation would you suggest here btw?  That would reproduce a sine 
accurately enough with just 2 samples?



> so you're saying that, given an inter-sample interpolation method
> (that is somehow deemed "good enough"), and a bandlimited waveform
> stored in a wavetable, that if you come up with an identical waveform
> with the same set of harmonics, that when you change the phase on one
> or more of them that you will need a wavetable with more samples in
> it?  that's awful curious to me.
>

no I was only talking of linear interpolation, which is probably what 
everyone would use here.

I mean yes, a sinc would certainly accurately recreate the highest harmonic 
out of 2 samples, but it's not very realistic - the additive synthesis 
method I suggested, while slow, still performs better than a sinc 
interpolator with enough taps.

I'm working on this right now, I have a sinc interpolator that's optimized 
to death, I can't get it under 1.5% of my CPU/stream with 64 taps, while a 
giant wavetable & its cache-inefficiency still only eats 0.05%/stream. I 
mean it's totally in another league in efficiency, I would never use a sinc 
to resample a single-cycle shape that can be easily upsampled.

So if you don't want to spend a lot of CPU on an oscillator, then I don't 
think you wanna use a sinc. And if you have a lot of CPU to spend, then I 
wouldn't use a table at all, I would stack up sines.




From didid at skynet.be  Mon Sep 28 22:13:22 2009
From: didid at skynet.be (Didier Dambrin)
Date: Tue, 29 Sep 2009 04:13:22 +0200
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <13ED037613D84AF1B6D9308B26D5C117@GOLAMD>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com><341E98C0F2384DD0AD5B79BE05E24351@GOLAMD><07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>
	<13ED037613D84AF1B6D9308B26D5C117@GOLAMD>
Message-ID: <54A2F8F69D6A4C79AFB2D33F5F09FFFD@GOLAMD>

Btw (a little OT), this reminds me of the old debate about sampling rates, 
you know a lot of uneducated ppl often make claim about the need for higher 
samplerates, that freqs over 20khz are important and blah blah (& there's of 
course always marketing not far behind to give people what they ask for, 
even if it's dumb).

In those debates there's usually the guy who's pointing out how freqs near 
nyquist look like triangles, thus assumes they can't properly represent 
sinewaves.
Here you would agree with me that yes, we can properly represent all freqs 
up to Nyquist.

*however*, that's without counting real-life uses of pieces of audio.
I mean, these days it's quite common to have streams of various samplerates 
being output to a different one, either resampled realtime by the 
soundcard's driver, the Windows mixer, or the audio player.
And how likely are we to find a good sinc interpolation in those? 
(especially since only the player can do it without introducing latency).

I once made a simple test, I had stored freqs above 20khz in a 96khz piece 
of audio. Then I asked Winamp to play it and.. they became audible, because 
of poor resampling (somewhere in the chain, most likely in Winamp but I'm 
not even sure).
Meaning that, while normally you would rather improve resampling instead of 
upsampling pieces of audio, if you take into account how people play music 
tracks, then yes one could argue that storing a piece of audio at above 
44khz is useful.





>>> In fact, big enough to provide enough quality for
>>> the very last harmonic alone.
>>
>> if your interpolator is good, just over two samples for the highest
>> harmonic will provide the required quality.
>>
>
> Ok but if the interpolator starts costing a lot of CPU, maybe using bigger
> tables & have cache problems will still perform better.
>
> What interpolation would you suggest here btw?  That would reproduce a 
> sine
> accurately enough with just 2 samples?
>
>
>
>> so you're saying that, given an inter-sample interpolation method
>> (that is somehow deemed "good enough"), and a bandlimited waveform
>> stored in a wavetable, that if you come up with an identical waveform
>> with the same set of harmonics, that when you change the phase on one
>> or more of them that you will need a wavetable with more samples in
>> it?  that's awful curious to me.
>>
>
> no I was only talking of linear interpolation, which is probably what
> everyone would use here.
>
> I mean yes, a sinc would certainly accurately recreate the highest 
> harmonic
> out of 2 samples, but it's not very realistic - the additive synthesis
> method I suggested, while slow, still performs better than a sinc
> interpolator with enough taps.
>
> I'm working on this right now, I have a sinc interpolator that's optimized
> to death, I can't get it under 1.5% of my CPU/stream with 64 taps, while a
> giant wavetable & its cache-inefficiency still only eats 0.05%/stream. I
> mean it's totally in another league in efficiency, I would never use a 
> sinc
> to resample a single-cycle shape that can be easily upsampled.
>
> So if you don't want to spend a lot of CPU on an oscillator, then I don't
> think you wanna use a sinc. And if you have a lot of CPU to spend, then I
> wouldn't use a table at all, I would stack up sines.
>
> 

From rbj at audioimagination.com  Tue Sep 29 15:37:48 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 29 Sep 2009 15:37:48 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <13ED037613D84AF1B6D9308B26D5C117@GOLAMD>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com><341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>
	<07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>
	<13ED037613D84AF1B6D9308B26D5C117@GOLAMD>
Message-ID: <936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com>


On Sep 28, 2009, at 9:56 PM, Didier Dambrin wrote:

>>> In fact, big enough to provide enough quality for
>>> the very last harmonic alone.
>>
>> if your interpolator is good, just over two samples for the highest
>> harmonic will provide the required quality.
>
> Ok but if the interpolator starts costing a lot of CPU, maybe using  
> bigger
> tables & have cache problems will still perform better.
>
> What interpolation would you suggest here btw?  That would  
> reproduce a sine
> accurately enough with just 2 samples?

i said "just over two samples".  with "good" interpolation, whatever  
that is.

>> so you're saying that, given an inter-sample interpolation method
>> (that is somehow deemed "good enough"), and a bandlimited waveform
>> stored in a wavetable, that if you come up with an identical waveform
>> with the same set of harmonics, that when you change the phase on one
>> or more of them that you will need a wavetable with more samples in
>> it?  that's awful curious to me.
>>
>
> no I was only talking of linear interpolation, which is probably what
> everyone would use here.

yes.  and i must confess that's what i was talking of at first, which  
is a problem.  i made a claim about linear interpolation and then i  
forgot i had that qualification.  certainly there are waveforms rich  
in harmonics (up to just under 1/2 the number of points in the  
wavetable) that can be theoretically nicely interpolated with a sinc- 
like thing, but would suck with linear interpolation.

but, where i think i disagree with you is; if you have a waveform  
with a limited number of harmonics (and limited much below the  
Nyquist limit, so that there are way more than 2N points in the  
wavetable) that come out "good" with linear interpolation, i do not  
believe that phase shifting one of those harmonics will make it come  
out "bad" with the same linear interpolation.  maybe increasing the  
amplitude of a high harmonic (which will also increase the  
interpolation noise) or introducing additional harmonics of higher  
frequency, *that* could make a good waveform sound bad with linear  
interpolation.

> I mean yes, a sinc would certainly accurately recreate the highest  
> harmonic
> out of 2 samples,

it has to be a hair more than 2.

> but it's not very realistic - the additive synthesis
> method I suggested, while slow, still performs better than a sinc
> interpolator with enough taps.

is that this "SSE" thing?  i don't know what that is.

> I'm working on this right now, I have a sinc interpolator that's  
> optimized
> to death, I can't get it under 1.5% of my CPU/stream with 64 taps,  
> while a
> giant wavetable & its cache-inefficiency still only eats 0.05%/ 
> stream. I
> mean it's totally in another league in efficiency, I would never  
> use a sinc
> to resample a single-cycle shape that can be easily upsampled.
>
> So if you don't want to spend a lot of CPU on an oscillator, then I  
> don't
> think you wanna use a sinc.

i'm in agreement with this.  if memory costs are cheap to nil, then  
no interpolation (a.k.a. "drop sample") on a very large wavetable or  
linear interpolation on a large, but less large, wavetable makes a  
lot more sense.

> And if you have a lot of CPU to spend, then I
> wouldn't use a table at all, I would stack up sines.

you mean additive synthesis, right?  otherwise i dunno what you mean.

what about doing the additive synthesis in advance of the real-time  
playback?  that is what wavetable synthesis is.  but it only works if  
the overtones are all pretty much harmonic.


--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From didid at skynet.be  Tue Sep 29 16:17:03 2009
From: didid at skynet.be (Didier Dambrin)
Date: Tue, 29 Sep 2009 22:17:03 +0200
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com><341E98C0F2384DD0AD5B79BE05E24351@GOLAMD><07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com><13ED037613D84AF1B6D9308B26D5C117@GOLAMD>
	<936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com>
Message-ID: <64A84B011B2A48BCBF9D83D6E801B26C@GOLAMD>

>> And if you have a lot of CPU to spend, then I
>> wouldn't use a table at all, I would stack up sines.
>
> you mean additive synthesis, right?  otherwise i dunno what you mean.
>
> what about doing the additive synthesis in advance of the real-time
> playback?  that is what wavetable synthesis is.  but it only works if
> the overtones are all pretty much harmonic.


Yes, through additive synthesis (I wrote stacking up sines as 'additive' is 
too generic).

And yes the wavetable is the same principle, with the problems that

-you would precompute a waveform per semitone (=over a hundred waveforms), 
or maybe one per octave if you work at twice the samplerate & downsample

-if the precomputation takes a lot of time, that means no real user 
interaction with the waveforms

-during pitch bends you may need to interpolate between waveforms


So I would advice, instead of using a wavetable, to compute the bandlimited 
waveform at voice trigger time, considering that a small FFT using a good 
library can be pretty much transparent on the CPU these days.




>i do not
>believe that phase shifting one of those harmonics will make it come
>out "bad" with the same linear interpolation.

Maybe not by shifting just one of them, indeed.

But I believe it's possible to increase or reduce the linear interpolation 
noise by just messing with phases, though.  Like a sawtooth with all phases 
messed up would probably do worse than a normal sawtooth that's very close 
to a linear ramp for its longest part.



>
> --
>
> r b-j                  rbj at audioimagination.com
>
> "Imagination is more important than knowledge."
>
>
>
>


From rbj at audioimagination.com  Tue Sep 29 21:02:50 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 29 Sep 2009 21:02:50 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <64A84B011B2A48BCBF9D83D6E801B26C@GOLAMD>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com><341E98C0F2384DD0AD5B79BE05E24351@GOLAMD><07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com><13ED037613D84AF1B6D9308B26D5C117@GOLAMD>
	<936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com>
	<64A84B011B2A48BCBF9D83D6E801B26C@GOLAMD>
Message-ID: <8DF4E8D4-E0BB-47D1-BE3F-3A7CBD056E73@audioimagination.com>


On Sep 29, 2009, at 4:17 PM, Didier Dambrin wrote:

>>> And if you have a lot of CPU to spend, then I
>>> wouldn't use a table at all, I would stack up sines.
>>
>> you mean additive synthesis, right?  otherwise i dunno what you mean.
>>
>> what about doing the additive synthesis in advance of the real-time
>> playback?  that is what wavetable synthesis is.  but it only works if
>> the overtones are all pretty much harmonic.
>
>
> Yes, through additive synthesis (I wrote stacking up sines as  
> 'additive' is
> too generic).
>
> And yes the wavetable is the same principle, with the problems that
>
> -you would precompute a waveform per semitone (=over a hundred  
> waveforms),
> or maybe one per octave if you work at twice the samplerate &  
> downsample
>

you wouldn't have to do that.  maybe a couple of wavetables per  
octave.  and, in fact, you need to be able to, real-time resample  
(interpolate between samples) and interpolate between wavetables at  
*any* pitch so you can emulate classic analog waveforms (or whatever,  
as long as it's quasi-periodic) with vibrato or portamento or pitch- 
wheel bending.  so, no, the number of precomputed wavetables has  
little to do with the number of keys on the keyboard.

> -if the precomputation takes a lot of time, that means no real user
> interaction with the waveforms

one thing, with either additive synthesis (to emulate existing tones,  
like electric piano notes or something) or wavetable, in that process  
("let's make our synthesizer sound like a Wurlitzer model 200  
electric piano of which we have several sampled notes") is a  
computationally intensive process that may likely not be anywhere  
close to real time.

> -during pitch bends you may need to interpolate between waveforms

i'm suggesting that, if you have to do something in the worst case  
(interpolating between waveforms based on the pitch value), you may  
as well design the thing to do that in any case.  and for a classic  
analog sounding, bandlimited sawtooth, you probably only need two  
wavetables per octave, each missing more harmonics (and stored as a  
shorter wavetable) as you go up the keyboard.  pretty simple.  but  
you have to make sure you have lined up the harmonics that remain.

>
> So I would advice, instead of using a wavetable, to compute the  
> bandlimited
> waveform at voice trigger time,

outa additive synthesis data?  at the attack time?


> considering that a small FFT using a good
> library can be pretty much transparent on the CPU these days.

okay, fine.  but what is to be gained with that over simply sampling  
the attack?

the main issue, as far as i can tell, in choosing between additive  
and wavetable is if, in the sustained part of the note, if there are  
overtones that are largely inharmonic or not.  if not, wavetable will  
produce whatever waveform you get with additive with just as many  
degrees of freedom that changes the sound when the user pulls on the  
mod wheel (or some other parameter) and with fewer  
"oscillators" (each sine in your additive stack is its own wavetable  
and you're scaling and mixing them).


>> i do not
>> believe that phase shifting one of those harmonics will make it come
>> out "bad" with the same linear interpolation.
>
> Maybe not by shifting just one of them, indeed.
>
> But I believe it's possible to increase or reduce the linear  
> interpolation
> noise by just messing with phases, though.  Like a sawtooth with  
> all phases
> messed up would probably do worse than a normal sawtooth that's  
> very close
> to a linear ramp for its longest part.

no, if you really mess up the phases, you ain't gonna see anything  
like a linear ramp in that.  but it doesn't matter.  if the linear  
interpolation was good enough in one case, it's good enough in the  
other with screwed-up phases.  there's nothing about the phase of the  
waveform that Nyquist and Shannon worry about.  but if there are  
harmonics that are too high and too loud (doesn't matter what the  
phase), linear interpolation might not sound so good.

i have to dig it up, but i have matlab files that will slowly screw  
up the phases of a bandlimited square and saw to demonstrate what we  
can hear.  (they can also pass the waveform through a non-linearity  
and then, for sure, you can hear a difference.  but linear  
interpolation is not non-linear.  it's like running the sample  
impulses through a filter with a triangular pulse as an impulse  
response and then resampling.)  i can look for that if you want.

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."





From didid at skynet.be  Tue Sep 29 21:56:45 2009
From: didid at skynet.be (Didier Dambrin)
Date: Wed, 30 Sep 2009 03:56:45 +0200
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <8DF4E8D4-E0BB-47D1-BE3F-3A7CBD056E73@audioimagination.com>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com><341E98C0F2384DD0AD5B79BE05E24351@GOLAMD><07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com><13ED037613D84AF1B6D9308B26D5C117@GOLAMD><936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com><64A84B011B2A48BCBF9D83D6E801B26C@GOLAMD>
	<8DF4E8D4-E0BB-47D1-BE3F-3A7CBD056E73@audioimagination.com>
Message-ID: <1C41CBB1D5304B7B854BA9AF404F137C@GOLAMD>

> you wouldn't have to do that.  maybe a couple of wavetables per
> octave.  and, in fact, you need to be able to, real-time resample
> (interpolate between samples) and interpolate between wavetables at
> *any* pitch so you can emulate classic analog waveforms (or whatever,
> as long as it's quasi-periodic) with vibrato or portamento or pitch-
> wheel bending.  so, no, the number of precomputed wavetables has
> little to do with the number of keys on the keyboard.
>

Depends when you wanna start the filter. If you start at 16khz (assuming 
44khz samplerate), looks like you could indeed get away with 2 tables per 
octave.



>> -if the precomputation takes a lot of time, that means no real user
>> interaction with the waveforms
>
> one thing, with either additive synthesis (to emulate existing tones,
> like electric piano notes or something) or wavetable, in that process
> ("let's make our synthesizer sound like a Wurlitzer model 200
> electric piano of which we have several sampled notes") is a
> computationally intensive process that may likely not be anywhere
> close to real time.
>

Why not?
If we're still talking about harmonics (still talking about bandlimited 
single-cycles), in the worst case (a very low fundamental), you will have 
maybe 500 harmonics.
(but that's not for the OP's targeted CPU)



>> -during pitch bends you may need to interpolate between waveforms
>
> i'm suggesting that, if you have to do something in the worst case
> (interpolating between waveforms based on the pitch value), you may
> as well design the thing to do that in any case.  and for a classic
> analog sounding, bandlimited sawtooth, you probably only need two
> wavetables per octave, each missing more harmonics (and stored as a
> shorter wavetable) as you go up the keyboard.  pretty simple.  but
> you have to make sure you have lined up the harmonics that remain.
>
>>
>> So I would advice, instead of using a wavetable, to compute the
>> bandlimited
>> waveform at voice trigger time,
>
> outa additive synthesis data?  at the attack time?
>

no, out of a precomputed FFT (as I described in another post, you precompute 
the FFT of your shape, and at voice trigger time you filter and inverse it. 
If we're still talking about short waveforms of 256 to 1024 samples, an FFT 
of that size, using a good library, will be lightning fast, even enough to 
re-create it during pitch bends (although I'd still suggest oversampling 2x 
instead).
That's how I do in a synth of mine, works pretty well.




>> considering that a small FFT using a good
>> library can be pretty much transparent on the CPU these days.
>
> okay, fine.  but what is to be gained with that over simply sampling
> the attack?
>

..to avoid a wavetable, & let the user mess with waveforms (the CPU may not 
be neglectable if you're precomputing 20-30 bandlimited waveforms each time 
the user messes with the waveform [like through a little additive editor])

And let's face it, if it's only for a precomputed classic saw & pulse, 
wouldn't one use that MinBLEP thing (which I know nothing of, but it looks 
popular) instead?



> the main issue, as far as i can tell, in choosing between additive
> and wavetable is if, in the sustained part of the note, if there are
> overtones that are largely inharmonic or not.  if not, wavetable will
> produce whatever waveform you get with additive with just as many
> degrees of freedom that changes the sound when the user pulls on the
> mod wheel (or some other parameter) and with fewer
> "oscillators" (each sine in your additive stack is its own wavetable
> and you're scaling and mixing them).
>

But wait, I'm not suggesting to the OP to do it by additive synthesis.  I 
just said that I'd rather use additive synthesis than a sinc, as the sinc 
will eat even more CPU. But I wouldn't use a sinc either. I'd still suggest 
the voice-trigger inverse FFT method along with a linear interpolator, and 
possibly 2x oversampling - it worked well for me.



>>> i do not
>>> believe that phase shifting one of those harmonics will make it come
>>> out "bad" with the same linear interpolation.
>>
>> Maybe not by shifting just one of them, indeed.
>>
>> But I believe it's possible to increase or reduce the linear
>> interpolation
>> noise by just messing with phases, though.  Like a sawtooth with
>> all phases
>> messed up would probably do worse than a normal sawtooth that's
>> very close
>> to a linear ramp for its longest part.
>
> no, if you really mess up the phases, you ain't gonna see anything
> like a linear ramp in that.  but it doesn't matter.  if the linear
> interpolation was good enough in one case, it's good enough in the
> other with screwed-up phases.  there's nothing about the phase of the
> waveform that Nyquist and Shannon worry about.  but if there are
> harmonics that are too high and too loud (doesn't matter what the
> phase), linear interpolation might not sound so good.
>
> i have to dig it up, but i have matlab files that will slowly screw
> up the phases of a bandlimited square and saw to demonstrate what we
> can hear.  (they can also pass the waveform through a non-linearity
> and then, for sure, you can hear a difference.  but linear
> interpolation is not non-linear.  it's like running the sample
> impulses through a filter with a triangular pulse as an impulse
> response and then resampling.)  i can look for that if you want.
>

Talking about this, something interesting I found out recently, a 'classic' 
saw is NOT the version of the saw that produces the lowest peak (which may 
matter in a mix or when compressed, that's debatable, but it can also be 
interesting when waveshaping).
When you mess with phases in a saw it's very easy to make it peak several dB 
above, however if you only shift the first 3 harmonics by half of the phase, 
you will get a lower peak, and also a more stable peak when lowpassing it. & 
it sounds only slightly different.




From rbj at audioimagination.com  Wed Sep 30 03:00:31 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Wed, 30 Sep 2009 03:00:31 -0400
Subject: [music-dsp] A little question about DSP performance
Message-ID: <20090930030031.11163@web004.roc2.bluetie.com>




--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."

-----Original Message-----
From: "Didier Dambrin" [didid at skynet.be]
Date: 09/29/2009 21:57
To: "A discussion list for music-related DSP" <music-dsp at music.columbia.edu>
Subject: Re: [music-dsp] A little question about DSP performance

>> you wouldn't have to do that.  maybe a couple of wavetables per
>> octave.  and, in fact, you need to be able to, real-time resample
>> (interpolate between samples) and interpolate between wavetables at
>> *any* pitch so you can emulate classic analog waveforms (or whatever,
>> as long as it's quasi-periodic) with vibrato or portamento or pitch-
>> wheel bending.  so, no, the number of precomputed wavetables has
>> little to do with the number of keys on the keyboard.
>
> Depends when you wanna start the filter. If you start at 16khz (assuming 
> 44khz samplerate), looks like you could indeed get away with 2 tables per 
> octave.

or how about a 96 kHz synth and start the filter at whatever inaudible frequency you want.  say, 20 kHz (but i'm good 'd deaf at 16 kHz, but for a super-high-performance synth or processory, i wouldn't assume so, but i might also assume Fs = 96 kHz)

>> -if the precomputation takes a lot of time, that means no real user
>> interaction with the waveforms
>
>> one thing, with either additive synthesis (to emulate existing tones,
>> like electric piano notes or something) or wavetable, in that process
>> ("let's make our synthesizer sound like a Wurlitzer model 200
>> electric piano of which we have several sampled notes") is a
>> computationally intensive process that may likely not be anywhere
>> close to real time.


> Why not?

okay, i'm gonna make some self-referential points, please forgive me for that.  i just can't think of the other early authors in CMJ.  so, i suggest, if you haven't done so, to take a look at the Wavetable Synthesis 101 paper (it's not meant to be a patronizing title, just an anally precise one) that is on the music-dsp site.

in either additive synthesis or wavetable synthesis (let's assume all of the overtones are virtually harmonic, any small deviation of the overtone from precisely harmonic is modeled as a slowly changing phase which becomes a slowly changing amplitude on the two quadrature components of each harmonic).  now, when "paramterizing" the data of the original waveform, represented either as a collection of envelopes on your additive sines or as a collection of envelopes each governing a particular point in the wavetable (if it's harmonic, the wavetable point envelopes ain't any nastier than the additive synth envelopes), there is an issue of optimally representing those envelopes with a finite set, indeed a compressed set of data.  a simple and useful method is representing these envelopes as continuous piecewise-linear functions.  where are the breakpoints in those piecewise-linear functions?

so you plunk your guitar note into the sound editor (or whatever the front end software is), press "convert to additive synth data" or "convert to wavetable data" and then a little smoke comes out of your computer and *ding* you have your additive synth or wavetable data for that particular note.  i don't expect or need that analysis and data reduction to be real-time.  it doesn't make any sense for it to be real-time, but it should be reasonably fast.  (you shouldn't need to go get a cup of coffee while you wait.  but it might take a second or two or even ten.)

> If we're still talking about harmonics (still talking about bandlimited 
> single-cycles), in the worst case (a very low fundamental), you will have 
> maybe 500 harmonics.
> (but that's not for the OP's targeted CPU)

wow.  you mean that in your bandlimited saw playing at, say, A-55 Hz, that if you were missing all of the harmonics above the bottom 250, it would make a real difference?  i know that's still in the below 20 kHz range, but i have my doubts.  anyway, if you need 500 harmonics, better put it in a 1024 point wavetable.  if you can get away with 250 harmonics, then a 512 point wavetable suffices.  for storage purposes, a 256 point wavetable can accurately and independently represent and control each harmonic up to the 127th.  so, if you had 127 independent amplitude envelopes and 127 independent phase envelopes (and the time-derivative of those represent the frequency deviation of the overtone from exactly harmonic), then you can convert those 254 envelopes into 256 envelopes governing each point of the wavetable (the difference of 2 is because, to make our lives and maths simple, let's assume that the envelopes for DC and for the Nyquist frequency are 0).  in either case your synthesizer has to keep up with ca. 2N envelopes in real-time.  but in additive synthesis, you have the additional burden of scaling a bunch of sines with those envelopes and adding it up.  with wavetable, you need only interpolate between adjacent wavetable points.  for the wavetable points that are not involved in the interpolation (and if you expand the wavetable data from a compressed storage form into a large playback wavetable at program load time, you can do linear interpolation and only two wavetable points are involved), you need do nothing to update the associated envelopes since they are simple piecewise-linear functions.

anyway this "interpolate between wavetables" is the same problem as "define envelopes governing wavetable points" problem.

>> -during pitch bends you may need to interpolate between waveforms
>>
>>>> i'm suggesting that, if you have to do something in the worst case
>>>> (interpolating between waveforms based on the pitch value), you may
>>>> as well design the thing to do that in any case.  and for a classic
>>>> analog sounding, bandlimited sawtooth, you probably only need two
>>>> wavetables per octave, each missing more harmonics (and stored as a
>>>> shorter wavetable) as you go up the keyboard.  pretty simple.  but
>>>> you have to make sure you have lined up the harmonics that remain.
>>>
>>> So I would advice, instead of using a wavetable, to compute the
>>> bandlimited
>>> waveform at voice trigger time,
>>
>> outa additive synthesis data?  at the attack time?
>
> no, out of a precomputed FFT (as I described in another post, you precompute 
> the FFT of your shape, and at voice trigger time you filter and inverse it. 
> If we're still talking about short waveforms of 256 to 1024 samples, an FFT 
> of that size, using a good library, will be lightning fast, even enough to 
> re-create it during pitch bends (although I'd still suggest oversampling 2x 
> instead).
> That's how I do in a synth of mine, works pretty well.

my question is, why bother to precompute frequency-domain data, when ultimately your output waveform is time domain?  what if the data needed at note-on time, can be time-domain and, from that, you can compute your output waveform (at the desired pitch) from the time-domain data without having to do an inverse FFT?  if you get do that with no loss of generality, why bother to have it in the frequency domain?  now, again, i recognize that additive synthesis of inharmonic overtones (like bells) can't be done with a single wavetable synth, but *maybe* with what's called "group additive synthesis".  here instead of summing N sine oscillators, you are summing 2 or 3 wavetable oscillators, each governing a harmonic group.  that's *still* much cheaper than additive synthesis, still not as general, but more general than simple wavetable synthesis.  Andrew Horner and some student(s) of his did a paper or fifteen about that.

>>> considering that a small FFT using a good
>>> library can be pretty much transparent on the CPU these days.
>>
>> okay, fine.  but what is to be gained with that over simply sampling
>> the attack?


> ..to avoid a wavetable, & let the user mess with waveforms (the CPU may not 
> be neglectable if you're precomputing 20-30 bandlimited waveforms each time 
> the user messes with the waveform [like through a little additive editor])

you can mess with waveforms with wavetables synthesis.  you can convert to equivalent additive synth data, let the user mess up the envelopes on each harmonic to his/her heart's content, and then convert back to wavetable.  unless the user wants to detune (away from exactly harmonic) the overtones a great deal, nothing is restricted.  also, the user can manipulate the waveforms in real-time just as expressively (as long as those overtones stay harmonic) with wavetable synthesis.  it can be a gas!  like with the Prophet VS.

> And let's face it, if it's only for a precomputed classic saw & pulse, 
> wouldn't one use that MinBLEP thing (which I know nothing of, but it looks 
> popular) instead?

you can, but it's about the same as wavetable synthesis with an integrator (unless you are somehow computing that Dirichlet periodic sinc function algorithmically, which seems like a pain-in-arse).  if you are integrating a Dirichlet function to get your sawtooth, where do you get your Dirichlet function?  from a table?  if so, then you are doing wavetable synthesis.  may as well keep it simple.

>> the main issue, as far as i can tell, in choosing between additive
>> and wavetable is if, in the sustained part of the note, if there are
>> overtones that are largely inharmonic or not.  if not, wavetable will
>> produce whatever waveform you get with additive with just as many
>> degrees of freedom that changes the sound when the user pulls on the
>> mod wheel (or some other parameter) and with fewer
>> "oscillators" (each sine in your additive stack is its own wavetable
>> and you're scaling and mixing them).
> 
> But wait, I'm not suggesting to the OP to do it by additive synthesis.  I 
> just said that I'd rather use additive synthesis than a sinc, as the sinc 
> will eat even more CPU. But I wouldn't use a sinc either. I'd still suggest 
> the voice-trigger inverse FFT method along with a linear interpolator, and 
> possibly 2x oversampling - it worked well for me.

i dunno all of what that means.  do you mean "additive synthesis" vs. "sinc interpolation of a wavetable" or vs. a BLEP?

there's more, but i'm tired.

r b-j

From padawan12 at obiwannabe.co.uk  Wed Sep 30 03:25:11 2009
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Wed, 30 Sep 2009 08:25:11 +0100
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <8DF4E8D4-E0BB-47D1-BE3F-3A7CBD056E73@audioimagination.com>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com>
	<341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>
	<07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>
	<13ED037613D84AF1B6D9308B26D5C117@GOLAMD>
	<936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com>
	<64A84B011B2A48BCBF9D83D6E801B26C@GOLAMD>
	<8DF4E8D4-E0BB-47D1-BE3F-3A7CBD056E73@audioimagination.com>
Message-ID: <20090930082511.2abc7d5e.padawan12@obiwannabe.co.uk>

On Tue, 29 Sep 2009 21:02:50 -0400
robert bristow-johnson <rbj at audioimagination.com> wrote:


> i have to dig it up, but i have matlab files that will slowly screw  
> up the phases of a bandlimited square and saw to demonstrate what we  
> can hear.  (they can also pass the waveform through a non-linearity  
> and then, for sure, you can hear a difference.  but linear  
> interpolation is not non-linear.  it's like running the sample  
> impulses through a filter with a triangular pulse as an impulse  
> response and then resampling.)  i can look for that if you want.

Yes please Robert, that sounds like a lovely demo for teaching, I'd
be grateful to see it if you can find it.

Andy

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

From didid at skynet.be  Wed Sep 30 10:36:07 2009
From: didid at skynet.be (Didier Dambrin)
Date: Wed, 30 Sep 2009 16:36:07 +0200
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <20090930030031.11163@web004.roc2.bluetie.com>
References: <20090930030031.11163@web004.roc2.bluetie.com>
Message-ID: <7E21943CE879413E87D156B0CDE49B8F@GOLAMD>


>>> one thing, with either additive synthesis (to emulate existing tones,
>>> like electric piano notes or something) or wavetable, in that process
>>> ("let's make our synthesizer sound like a Wurlitzer model 200
>>> electric piano of which we have several sampled notes") is a
>>> computationally intensive process that may likely not be anywhere
>>> close to real time.
>
>
>> Why not?
>
> okay, i'm gonna make some self-referential points, please forgive me for 
> that.  i just can't think of the other early authors in CMJ.  so, i 
> suggest, if you haven't done so, to take a look at the Wavetable Synthesis 
> 101 paper (it's not meant to be a patronizing title, just an anally 
> precise one) that is on the music-dsp site.
>
> in either additive synthesis or wavetable synthesis (let's assume all of 
> the overtones are virtually harmonic, any small deviation of the overtone 
> from precisely harmonic is modeled as a slowly changing phase which 
> becomes a slowly changing amplitude on the two quadrature components of 
> each harmonic).  now, when "paramterizing" the data of the original 
> waveform, represented either as a collection of envelopes on your additive 
> sines or as a collection of envelopes each governing a particular point in 
> the wavetable (if it's harmonic, the wavetable point envelopes ain't any 
> nastier than the additive synth envelopes), there is an issue of optimally 
> representing those envelopes with a finite set, indeed a compressed set of 
> data.  a simple and useful method is representing these envelopes as 
> continuous piecewise-linear functions.  where are the breakpoints in those 
> piecewise-linear functions?
>


Mmh but I'm still talking about a single-cycle here, I'm not talking about 
resynthesis of existing things.  To start with, I don't even much believe in 
resynthesis, there's usually a noise component that will be lost or emulated 
in a half-assed way.
Also even when you can resynthesize something, there's still the problem of 
giving the user ways to play with a huge amount of data, and multipoint 
envelopes are useless here (no one would start refining hundreds of 
envelopes). That leaves spectral editing through bitmaps, the only good way 
IMHO, but only a way to create new sounds out of existing ones, not to 
accurately reproduce instruments.
Anyway, additive synthesis isn't necessarily resynthesis, it can even be 
"subtractive" - what I'm working on right now (pretty cool to test all kinds 
of filter shapes, like you would do with FIRs, but without the latency).




>> If we're still talking about harmonics (still talking about bandlimited
>> single-cycles), in the worst case (a very low fundamental), you will have
>> maybe 500 harmonics.
>> (but that's not for the OP's targeted CPU)
>
> wow.  you mean that in your bandlimited saw playing at, say, A-55 Hz, that 
> if you were missing all of the harmonics above the bottom 250, it would 
> make a real difference?  i know that's still in the below 20 kHz range, 
> but i have my doubts.


Let me check, for a 55hz fundamental, you need up to 350 harmonics.
Testing.. yes you can notice less clarity with just 250 (but if you're not 
picky you can probably get away with it, if you also fade out the last 
ones).

With 512 I'm basing myself on a worst-case C32hz, probably the lowest note 
needed for real uses, at one point it moves away from audio rate & it just a 
succession of clicks.

But it's dynamic anyway, if the user uses higher keys, then it eats less 
CPU.



>anyway, if you need 500 harmonics, better put it in a 1024 point wavetable. 
>if you can get away with 250 harmonics, then a 512 point wavetable 
>suffices.  for

For the OP's use, yes. But again, think of all you can do when you can mess 
with the harmonics, it's not useless.
-filtering with any slope/shape you can imagine, with slopes in Hz or in 
octaves
-PWM-like effects by special filtering as well

well anything you can imagine.. Anyway, I'm working on that so I'll see if 
it's a step forward from normal subtractive synthesis. I think it will be 
great since I don't have unstability problem with resonance.



>storage purposes, a 256 point wavetable can accurately and independently 
>represent and control each harmonic up to the 127th.  so, if you had 127 
>independent >amplitude envelopes and 127 independent phase envelopes (and 
>the time-derivative of those represent the frequency deviation of the 
>overtone from exactly >harmonic), then you can convert those 254 envelopes 
>into 256 envelopes governing each point of the wavetable (the difference of 
>2 is because, to make our lives and >maths simple, let's assume that the 
>envelopes for DC and for the Nyquist frequency are 0).  in either case your 
>sy

Or are you talking about using a wavetable to do additive synthesis? (I'm 
not quite following here)
Well, no since the computation of the sine (using that famous trigonometric 
property) is already lighter on CPU than a linear interpolation. But that 
probably depends on the choice of CPU.



> nthesizer has to keep up with ca. 2N envelopes in real-time.  but in 
> additive synthesis, you have the additional burden of scaling a bunch of 
> sines with those >envelopes and adding it up.  with wavetable, you need 
> only interpolate between adjacent wavetable points.  for the wavetable 
> points that are not involved in the >interpolation (and if you expand the 
> wavetable data from a compressed storage form into a large playback 
> wavetable at program load time, you can do linear >nerpolation and only 
> two wavetable points are involved), you need do nothing to update the 
> associated envelopes since they are simple piecewise-linear functions.
>


>> no, out of a precomputed FFT (as I described in another post, you 
>> precompute
>> the FFT of your shape, and at voice trigger time you filter and inverse 
>> it.
>> If we're still talking about short waveforms of 256 to 1024 samples, an 
>> FFT
>> of that size, using a good library, will be lightning fast, even enough 
>> to
>> re-create it during pitch bends (although I'd still suggest oversampling 
>> 2x
>> instead).
>> That's how I do in a synth of mine, works pretty well.
>
> my question is, why bother to precompute frequency-domain data, when 
> ultimately your output waveform is time domain?  what if the data needed 
> at note-on time, >an be time-domain and, from that, you can compute your 
> output waveform (at the desired pitch) from the time-domain data without 
> having to do an inverse FFT?  if

To filter it, according to a parameter (pitch) that's only known at 
voice-trigger time..



>you get do that with no loss of generality, why bother to have it in the 
>frequency domain?  now, again, i recognize that additive synthesis of 
>inharmonic overtones (like bells) can't be done with a single wavetable 
>synth, but *maybe* with what's called "group additive synthesis".  here 
>instead of summing N sine oscillators, you are summing 2 or 3 wavetable 
>oscillators, each governing a harmonic group.  that's *still* much cheaper 
>than additive synthesis, still not as general, but more general than simple 
>wavetable synthesis.  Andrew Horner and some student(s) of his did a paper 
>or fifteen about that.
>

I also thought of that, but if you're precomputing freq bands & stack them 
up, you can as well precompute a normal bandlimited wavetable in the first 
place, so I don't see the point.



>>>> considering that a small FFT using a good
>>>> library can be pretty much transparent on the CPU these days.
>>>
>>> okay, fine.  but what is to be gained with that over simply sampling
>>> the attack?
>
>
>> ..to avoid a wavetable, & let the user mess with waveforms (the CPU may 
>> not
>> be neglectable if you're precomputing 20-30 bandlimited waveforms each 
>> time
>> the user messes with the waveform [like through a little additive 
>> editor])
>
> you can mess with waveforms with wavetables synthesis.  you can convert to 
> equivalent additive synth data, let the user mess up the envelopes on each 
> harmonic to his/her heart's content, and then convert back to wavetable. 
> unless the user wants to detune (away from exactly harmonic) the overtones 
> a great deal, nothing is


Yes, convert back to a wavetable, as opposed to just FFTing it.
So with your method you have a big CPU hit at editing time, no CPU hit at 
voice-trigger time, and slight CPU hit at voice processing time (for the 
interpolation between 2 waveforms from the wavetable).
With mine you have a slight CPU hit at editing time, a slight CPU hit at 
voice-trigger time, and no need to interpolate between 2 waveforms.




>restricted.  also, the user can manipulate the waveforms in real-time just 
>as expressively (as long as those overtones stay harmonic) with wavetable 
>synthesis.  it can be a gas!  like with the Prophet VS.
>
>> And let's face it, if it's only for a precomputed classic saw & pulse,
>> wouldn't one use that MinBLEP thing (which I know nothing of, but it 
>> looks
>> popular) instead?
>
> you can, but it's about the same as wavetable synthesis with an integrator 
> (unless you are somehow computing that Dirichlet periodic sinc function 
> algorithmically, which seems like a pain-in-arse).  if you are integrating 
> a Dirichlet function to get your sawtooth, where do you get your Dirichlet 
> function?  from a table?  if so, then you are doing wavetable synthesis. 
> may as well keep it simple.
>
>>> the main issue, as far as i can tell, in choosing between additive
>>> and wavetable is if, in the sustained part of the note, if there are
>>> overtones that are largely inharmonic or not.  if not, wavetable will
>>> produce whatever waveform you get with additive with just as many
>>> degrees of freedom that changes the sound when the user pulls on the
>>> mod wheel (or some other parameter) and with fewer
>>> "oscillators" (each sine in your additive stack is its own wavetable
>>> and you're scaling and mixing them).
>>
>> But wait, I'm not suggesting to the OP to do it by additive synthesis.  I
>> just said that I'd rather use additive synthesis than a sinc, as the sinc
>> will eat even more CPU. But I wouldn't use a sinc either. I'd still 
>> suggest
>> the voice-trigger inverse FFT method along with a linear interpolator, 
>> and
>> possibly 2x oversampling - it worked well for me.
>
> i dunno all of what that means.  do you mean "additive synthesis" vs. 
> "sinc interpolation of a wavetable" or vs. a BLEP?
>

yes I mean I'd rather do (and I'm doing) additive synthesis than a sinc 
interpolation on a single-cycle.

I've spend a lot of time optimizing a sinc interpolator. I ended it up 
almost as fast as table-based ones, but without tables so more freedom (of 
adapting the # of taps realtime, for example).  It's still a lot of CPU 
wasted.
And btw, you need the same kind of tricks as with additive synthesis anyway, 
since a 64-taps sinc interpolator requires 64 sin per sample, that's already 
the same as an additive synthesizer with 64 harmonics. But since there's 
less room for optimization, since there's memory access, since there's also 
a division involved, it's slow, slower than my current additive synthesizer.





From rbj at audioimagination.com  Wed Sep 30 21:27:23 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Wed, 30 Sep 2009 21:27:23 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <20090930082511.2abc7d5e.padawan12@obiwannabe.co.uk>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com>
	<341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>
	<07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>
	<13ED037613D84AF1B6D9308B26D5C117@GOLAMD>
	<936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com>
	<64A84B011B2A48BCBF9D83D6E801B26C@GOLAMD>
	<8DF4E8D4-E0BB-47D1-BE3F-3A7CBD056E73@audioimagination.com>
	<20090930082511.2abc7d5e.padawan12@obiwannabe.co.uk>
Message-ID: <95B1D381-6F08-4FBE-86B3-F24A8AE7C434@audioimagination.com>


On Sep 30, 2009, at 3:25 AM, Andy Farnell wrote:

> On Tue, 29 Sep 2009 21:02:50 -0400
> robert bristow-johnson <rbj at audioimagination.com> wrote:
>
>
>> i have to dig it up, but i have matlab files that will slowly screw
>> up the phases of a bandlimited square and saw to demonstrate what we
>> can hear.  (they can also pass the waveform through a non-linearity
>> and then, for sure, you can hear a difference.  but linear
>> interpolation is not non-linear.  it's like running the sample
>> impulses through a filter with a triangular pulse as an impulse
>> response and then resampling.)  i can look for that if you want.
>
> Yes please Robert, that sounds like a lovely demo for teaching, I'd
> be grateful to see it if you can find it.
>


since i dunno if Douglas's list software propagates attachments, i'll  
just append the code below.  i cannot tell where the lines get  
wrapped, so you might have to fix spurious line wraps.

enjoy.

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




_______________________________________________________________________


%
%   sawtooth_phase.m
%
%   a test to see if we can really hear phase changes
%   in the harmonics of a Nyquist limited sawtooth wave.
%
%   (c) 2004 rbj at audioimagination.com
%

if ~exist('Fs')
     Fs = 44100                      % sample rate, Hz
end

if ~exist('f0')
     f0 = 110.25                     % fundamental freq, Hz
end

if ~exist('tone_duration')
     tone_duration = 2.0             % seconds
end

if ~exist('change_rate')
     change_rate = 1.0               % Hz
end

if ~exist('max_harmonic')
     max_harmonic = floor((Fs/2)/f0) - 1
end

if ~exist('amplitude_factor')
     amplitude_factor = 0.25         % this just keeps things from  
clipping
end

if ~exist('outFile')
     outFile = 'sawtooth_phase.wav'
end


                                   % make sure we don't uber-Nyquist  
anything
max_harmonic = min(max_harmonic, floor((Fs/2)/f0)-1);

t = linspace(0.0, tone_duration, Fs*tone_duration+1);

detune = change_rate;

x = sin(2*pi*f0*t);                  % start with 1st harmonic

n = 2;                               % continue with 2nd harmonic
while (n <= max_harmonic)
     if ((n-1) == 2*floor((n-1)/2))  % lessee if it's an "even" or  
"odd" term
         x = x + (1/n)*sin(2*pi*n*f0*t);
      else
         x = x - (1/n)*sin(2*pi*(n*f0+detune)*t);
         detune = -detune;       % comment this line in and see some
     end                         % funky intermediate waveforms
     n = n + 1;                      % continue with next 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

_______________________________________________________________________


%
%   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 rbj at audioimagination.com
%

if ~exist('Fs')
     Fs = 44100                      % sample rate, Hz
end

if ~exist('f0')
     f0 = 110.25                     % fundamental freq, Hz
end

if ~exist('tone_duration')
     tone_duration = 2.0             % seconds
end

if ~exist('change_rate')
     change_rate = 1.0               % Hz
end

if ~exist('max_harmonic')
     max_harmonic = floor((Fs/2)/f0) - 1
end

if ~exist('amplitude_factor')
     amplitude_factor = 0.25         % this just keeps things from  
clipping
end

if ~exist('outFile')
     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 and 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


_______________________________________________________________________



From douglas at music.columbia.edu  Wed Sep 30 21:30:59 2009
From: douglas at music.columbia.edu (douglas repetto)
Date: Wed, 30 Sep 2009 21:30:59 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <95B1D381-6F08-4FBE-86B3-F24A8AE7C434@audioimagination.com>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com>	<341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>	<07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>	<13ED037613D84AF1B6D9308B26D5C117@GOLAMD>	<936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com>	<64A84B011B2A48BCBF9D83D6E801B26C@GOLAMD>	<8DF4E8D4-E0BB-47D1-BE3F-3A7CBD056E73@audioimagination.com>	<20090930082511.2abc7d5e.padawan12@obiwannabe.co.uk>
	<95B1D381-6F08-4FBE-86B3-F24A8AE7C434@audioimagination.com>
Message-ID: <4AC40653.6070108@music.columbia.edu>

robert bristow-johnson wrote:

> 
> since i dunno if Douglas's list software propagates attachments, i'll  
> just append the code below.  i cannot tell where the lines get  
> wrapped, so you might have to fix spurious line wraps.
> 
> enjoy.
> 


It looks like it came through okay as text. In the future, if anyone 
wants to post files, just email them to me privately and I'll post them 
on the list website for you.

best,
douglas

-- 
............................................... http://artbots.org
.....douglas.....irving........................ http://dorkbot.org
.......................... http://music.columbia.edu/cmc/music-dsp
.......... repetto............. http://music.columbia.edu/organism
........................................ http://douglasrepetto.org


From rbj at audioimagination.com  Wed Sep 30 21:35:34 2009
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Wed, 30 Sep 2009 21:35:34 -0400
Subject: [music-dsp] A little question about DSP performance
In-Reply-To: <4AC40653.6070108@music.columbia.edu>
References: <150537.29137.qm@web53512.mail.re2.yahoo.com>	<341E98C0F2384DD0AD5B79BE05E24351@GOLAMD>	<07B8F263-ADA9-4770-863D-C21CE43EBF00@audioimagination.com>	<13ED037613D84AF1B6D9308B26D5C117@GOLAMD>	<936CBAB1-BA45-4A03-A9B5-B39F204DAA52@audioimagination.com>	<64A84B011B2A48BCBF9D83D6E801B26C@GOLAMD>	<8DF4E8D4-E0BB-47D1-BE3F-3A7CBD056E73@audioimagination.com>	<20090930082511.2abc7d5e.padawan12@obiwannabe.co.uk>
	<95B1D381-6F08-4FBE-86B3-F24A8AE7C434@audioimagination.com>
	<4AC40653.6070108@music.columbia.edu>
Message-ID: <93023143-D32C-4CAF-A528-C5F23C9BD71D@audioimagination.com>


On Sep 30, 2009, at 9:30 PM, douglas repetto wrote:

> robert bristow-johnson wrote:
>
>>
>> since i dunno if Douglas's list software propagates attachments, i'll
>> just append the code below.  i cannot tell where the lines get
>> wrapped, so you might have to fix spurious line wraps.
>>
>> enjoy.
>>
>
>
> It looks like it came through okay as text.

"anything" and ""odd"" got wrapped.  easy to fix.

> In the future, if anyone
> wants to post files, just email them to me privately and I'll post  
> them
> on the list website for you.


i could do that.  you're welcome to post these.  please unwrap those  
4 lines.  (or i can send you files.)

--

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."