From douglas at music.columbia.edu  Wed Feb  1 07:00:00 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Wed,  1 Feb 2012 07:00:00 -0500 (EST)
Subject: [music-dsp] [admin] music-dsp FAQ
Message-ID: <20120201120000.2C4925A73D74@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 anooj.patel90 at gmail.com  Thu Feb  2 04:52:21 2012
From: anooj.patel90 at gmail.com (Anooj Patel)
Date: Thu, 2 Feb 2012 09:52:21 +0000
Subject: [music-dsp] Great Job Opportunity - Top Audio Engineers Wanted!
Message-ID: <CAEh0E7wPdqw_UsMy-+_bL38uuxVqez9ri1MYjmev3DCFuf-78A@mail.gmail.com>

Looking for top Audio Engineers with a great understanding of audio
and speech signal processing with excellent C/C++ skills.

If you are interested please email me at anooj at digimobjobs.com for
further information :)

Anooj

From dan.stowell at eecs.qmul.ac.uk  Mon Feb  6 05:11:32 2012
From: dan.stowell at eecs.qmul.ac.uk (Dan Stowell)
Date: Mon, 06 Feb 2012 10:11:32 +0000
Subject: [music-dsp] Fwd: The SuperCollider Algostep Remix Competition
In-Reply-To: <CANuikkpt2m26TzEibnu1acHx-D+sokMgVwY6xMKR9KsmjuEkcQ@mail.gmail.com>
References: <CANuikkpt2m26TzEibnu1acHx-D+sokMgVwY6xMKR9KsmjuEkcQ@mail.gmail.com>
Message-ID: <4F2FA754.8040601@eecs.qmul.ac.uk>

---------- Forwarded message ----------
From: SuperCollider Symposium London <info at sc2012.org.uk>
Date: 2012/2/6


Hi,

To celebrate the SuperCollider Symposium 2012 we're announcing a very
special competition about music and code. Music made by computers, for
computers. A competition for dance music producers and hackers
everywhere.

We want you to take algorithmically-generated dance music and rework
it. Submissions will be judged by three hand-reared computer
algorithms, for the chance to win one of three Novation Launchpads.

Full details: http://bit.ly/x4YS37

Best
sc2012
http://www.sc2012.org.uk/

From lists at richbreen.com  Mon Feb  6 11:28:41 2012
From: lists at richbreen.com (Rich Breen)
Date: Mon, 6 Feb 2012 08:28:41 -0800
Subject: [music-dsp] ANN: audio programming course
In-Reply-To: <mailman.161.1328523100.148.music-dsp@music.columbia.edu>
References: <mailman.161.1328523100.148.music-dsp@music.columbia.edu>
Message-ID: <A2504B59-4AEF-49CA-B454-CDE58887BBB9@richbreen.com>

I don't suppose there's any chance this class can be taken remotely?

thanks,
rich


On Feb 6, 2012, at 2:11 AM, music-dsp-request at music.columbia.edu wrote:

> Subject: [music-dsp] ANN: audio programming course
> Message-ID: <4F27D260.5040209 at blueyonder.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> I guess nobody in this list needs such a thing, but you may know other 
> people who might be interested:
> 
> 
> Bath University is running its audio programming course (C, maybe C++ as 
> well) again this year, on Wednesdays for 8 Weeks: 22 Feb-25 Apr (not 4 
> 11 Apr), 7.15pm-9.15pm, East Building 0.10, University of Bath.
> 
> Full details for booking etc:
> 
> http://www.bath.ac.uk/icia/classes/ssd.html
> 
> We are also planning a weekend intensive in the summer, to suit people 
> living a distance away. We have no details to announce yet, but it is 
> intended to both cover the material of the weekly sessions and go beyond 
> to real-time interactive this and that. Expressions of interest are invited!

-----
rich at richbreen.com
<http://www.richbreen.com>


From np at planetarc.de  Mon Feb  6 15:28:40 2012
From: np at planetarc.de (Nils Pipenbrinck)
Date: Mon, 06 Feb 2012 21:28:40 +0100
Subject: [music-dsp] choice of Q for graphic equalizers
Message-ID: <4F3037F8.9060706@planetarc.de>

A quick question:

I am writing a little 31 band graphical equalizer (three bands per
octave), and I want to use the peaking-eq biquads from Roberts excellent
filter cookbook.

Everything is working fine so far, but I wonder what Q should I choose for the filters? is 1/3 okay?

Cheers,
  Nils



From rbj at audioimagination.com  Tue Feb  7 00:04:59 2012
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 07 Feb 2012 00:04:59 -0500
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <4F3037F8.9060706@planetarc.de>
References: <4F3037F8.9060706@planetarc.de>
Message-ID: <4F30B0FB.6040808@audioimagination.com>

On 2/6/12 3:28 PM, Nils Pipenbrinck wrote:
> A quick question:
>
> I am writing a little 31 band graphical equalizer (three bands per
> octave), and I want to use the peaking-eq biquads from Roberts excellent
> filter cookbook.
>
> Everything is working fine so far, but I wonder what Q should I choose for the filters? is 1/3 okay?
>

so it looks like you have 31 biquads in cascade, right?  and they are 
all peaking-EQ filters from the cookbook, right?  (perhaps the bottom 
band and the top band are shelving EQs.)

i would suggest not using Q, but use the BW option in the cookbook and 
try setting the BW to 1/3 octave or thereabouts and see what you get.

i dunno.

-- 

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




From dgm at baykitty.com  Tue Feb  7 00:26:01 2012
From: dgm at baykitty.com (dgm)
Date: Tue, 7 Feb 2012 13:26:01 +0800
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <4F30B0FB.6040808@audioimagination.com>
References: <4F3037F8.9060706@planetarc.de>
	<4F30B0FB.6040808@audioimagination.com>
Message-ID: <4D580E24-2CE6-4F14-B770-4D0C6CC15612@baykitty.com>

I wrote several 1/3 octave EQs for cinema sound equipment.

They were all based in the main on the RBJ cookbook, the only changes being to code in assembly language and make the calculation real-time adjustable.

I used a Butterworth characteristic Q and added two shelving filters 3k (approx) and down on the low end and 9-10k (approx) and above in the high end.

Worked very well, got good reviews and sold well.

dgm

On Feb 7, 2012, at 1:04 PM, robert bristow-johnson wrote:

> On 2/6/12 3:28 PM, Nils Pipenbrinck wrote:
>> A quick question:
>> 
>> I am writing a little 31 band graphical equalizer (three bands per
>> octave), and I want to use the peaking-eq biquads from Roberts excellent
>> filter cookbook.
>> 
>> Everything is working fine so far, but I wonder what Q should I choose for the filters? is 1/3 okay?
>> 
> 
> so it looks like you have 31 biquads in cascade, right?  and they are all peaking-EQ filters from the cookbook, right?  (perhaps the bottom band and the top band are shelving EQs.)
> 
> i would suggest not using Q, but use the BW option in the cookbook and try setting the BW to 1/3 octave or thereabouts and see what you get.
> 
> i dunno.
> 
> -- 
> 
> 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 shanx.shashank at gmail.com  Tue Feb  7 01:31:32 2012
From: shanx.shashank at gmail.com (Shashank Kumar (shanxS))
Date: Tue, 7 Feb 2012 12:01:32 +0530
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <4F3037F8.9060706@planetarc.de>
References: <4F3037F8.9060706@planetarc.de>
Message-ID: <CAC6zbP9ToT6qfP0R7exuGe1E2HY-8Xd6=9LBFrV6hBhDjc5=Pg@mail.gmail.com>

I had a doubt regarding filter designing.
Filters defined in Robert's cookbook are iir filters, i.e. Phase
respone is non linear.

But for audio applications, like EQ design, isn't the phase response
supposed to be linear ?

Shashank

On 2/7/12, Nils Pipenbrinck <np at planetarc.de> wrote:
> A quick question:
>
> I am writing a little 31 band graphical equalizer (three bands per
> octave), and I want to use the peaking-eq biquads from Roberts excellent
> filter cookbook.
>
> Everything is working fine so far, but I wonder what Q should I choose for
> the filters? is 1/3 okay?
>
> Cheers,
>   Nils
>
>
> --
> 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 shanx.shashank at gmail.com  Tue Feb  7 01:31:32 2012
From: shanx.shashank at gmail.com (Shashank Kumar (shanxS))
Date: Tue, 7 Feb 2012 12:01:32 +0530
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <4F3037F8.9060706@planetarc.de>
References: <4F3037F8.9060706@planetarc.de>
Message-ID: <CAC6zbP9ToT6qfP0R7exuGe1E2HY-8Xd6=9LBFrV6hBhDjc5=Pg@mail.gmail.com>

I had a doubt regarding filter designing.
Filters defined in Robert's cookbook are iir filters, i.e. Phase
respone is non linear.

But for audio applications, like EQ design, isn't the phase response
supposed to be linear ?

Shashank

On 2/7/12, Nils Pipenbrinck <np at planetarc.de> wrote:
> A quick question:
>
> I am writing a little 31 band graphical equalizer (three bands per
> octave), and I want to use the peaking-eq biquads from Roberts excellent
> filter cookbook.
>
> Everything is working fine so far, but I wonder what Q should I choose for
> the filters? is 1/3 okay?
>
> Cheers,
>   Nils
>
>
> --
> 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 shanx.shashank at gmail.com  Tue Feb  7 01:39:10 2012
From: shanx.shashank at gmail.com (Shashank Kumar (shanxS))
Date: Tue, 7 Feb 2012 12:09:10 +0530
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <4F3037F8.9060706@planetarc.de>
References: <4F3037F8.9060706@planetarc.de>
Message-ID: <CAC6zbP-grKGOmPpF=wb4e9gTQmMketa9QVZy96ja_bwF1DDcXw@mail.gmail.com>

I had a doubt regarding filter designing.
Filters defined in Robert's cookbook are iir filters, i.e. Phase
respone is non linear.

But for audio applications, like EQ design, isn't the phase response
supposed to be linear ?

Shashank

On 2/7/12, Nils Pipenbrinck <np at planetarc.de> wrote:
> A quick question:
>
> I am writing a little 31 band graphical equalizer (three bands per
> octave), and I want to use the peaking-eq biquads from Roberts excellent
> filter cookbook.
>
> Everything is working fine so far, but I wonder what Q should I choose for
> the filters? is 1/3 okay?
>
> Cheers,
>   Nils
>
>
> --
> 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 rossb-lists at audiomulch.com  Tue Feb  7 01:45:48 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Tue, 07 Feb 2012 17:45:48 +1100
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <CAC6zbP9ToT6qfP0R7exuGe1E2HY-8Xd6=9LBFrV6hBhDjc5=Pg@mail.gmail.com>
References: <4F3037F8.9060706@planetarc.de>
	<CAC6zbP9ToT6qfP0R7exuGe1E2HY-8Xd6=9LBFrV6hBhDjc5=Pg@mail.gmail.com>
Message-ID: <4F30C89C.5030806@audiomulch.com>



On 7/02/2012 5:31 PM, Shashank Kumar (shanxS) wrote:
> But for audio applications, like EQ design, isn't the phase response
> supposed to be linear ?

I would say not.

Most audio EQ filters don't have linear phase.

Additionally, the ear is very sensitive to acausality so, especially for 
radical filtering, using a symmetric FIR filter for EQ does unnatural 
things to transients.

There are of course counter examples.

Ross.





From earlevel at earlevel.com  Tue Feb  7 02:14:39 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Mon, 6 Feb 2012 23:14:39 -0800
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <4F30C89C.5030806@audiomulch.com>
References: <4F3037F8.9060706@planetarc.de>
	<CAC6zbP9ToT6qfP0R7exuGe1E2HY-8Xd6=9LBFrV6hBhDjc5=Pg@mail.gmail.com>
	<4F30C89C.5030806@audiomulch.com>
Message-ID: <8C22A1A9-FD4F-4C5D-9854-5DE43A4E2AF2@earlevel.com>

Shashank: Analog filters?the kind in analog mixing consoles that mixed most of what you grew up on?are IIR. So are most of their digital counterparts. So, that's what people are used to.

Of course Ross is right about transients, depending on the amount of filtering used, but linear phase has it's uses and proponents too. I recall that Bob Katz, a respected mastering engineer, said that IIR filters then to move parts of the image forward or backwards in a mix, which is good or bad depending on the situation. He also said that linear phase filters gave a smoother, more subtle sound. Steven St Croix was a proponent of linear phase filtering, with similar comments about being smoother and more natural.

OK, I looked up Bob's comments?here he says he prefers linear phase for about 75% of his work:

http://www.digido.com/audio-faq/l/linear-phase-equalization.html


On Feb 6, 2012, at 10:45 PM, Ross Bencina wrote:
> 
> On 7/02/2012 5:31 PM, Shashank Kumar (shanxS) wrote:
>> But for audio applications, like EQ design, isn't the phase response
>> supposed to be linear ?
> 
> I would say not.
> 
> Most audio EQ filters don't have linear phase.
> 
> Additionally, the ear is very sensitive to acausality so, especially for radical filtering, using a symmetric FIR filter for EQ does unnatural things to transients.
> 
> There are of course counter examples.
> 
> Ross.


From rossb-lists at audiomulch.com  Tue Feb  7 05:20:53 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Tue, 07 Feb 2012 21:20:53 +1100
Subject: [music-dsp] stereo-wide pan law?
Message-ID: <4F30FB05.6000802@audiomulch.com>

Hi Everyone,

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

By "stereo-wide" I mean panning something beyond the speakers by using 
180-degree shifted signal in the opposite speaker. For example, for 
"beyond hard left" you would output full gain signal to the left 
speaker, and some inverted phase signal to the right speaker.

I know this is a somewhat dubious method but I'm wondering if there are 
known pan laws that handle this case.

Thank you,

Ross.

From didid at skynet.be  Tue Feb  7 05:49:31 2012
From: didid at skynet.be (Didier Dambrin)
Date: Tue, 7 Feb 2012 11:49:31 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F30FB05.6000802@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com>
Message-ID: <FDC896669A0B42808E75F604531BB357@ProprietairePC>

I've never heard of it, but it's interesting. You mean the pan would become 
a 360deg rotary, going from center to left, to stereo-wide center, to right 
& back to center?
In that case I'd just use the same law as for the front/left/right (which 
could be any), only with shifting for the lower half of the circle.


-----Message d'origine----- 
From: Ross Bencina
Sent: Tuesday, February 07, 2012 11:20 AM
To: A discussion list for music-related DSP
Subject: [music-dsp] stereo-wide pan law?

Hi Everyone,

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

By "stereo-wide" I mean panning something beyond the speakers by using
180-degree shifted signal in the opposite speaker. For example, for
"beyond hard left" you would output full gain signal to the left
speaker, and some inverted phase signal to the right speaker.

I know this is a somewhat dubious method but I'm wondering if there are
known pan laws that handle this case.

Thank you,

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


-----
Aucun virus trouve dans ce message.
Analyse effectuee par AVG - www.avg.fr
Version: 2012.0.1913 / Base de donnees virale: 2112/4793 - Date: 06/02/2012 


From pcorvo at blitzgamesstudios.com  Tue Feb  7 05:50:52 2012
From: pcorvo at blitzgamesstudios.com (pcorvo)
Date: Tue, 07 Feb 2012 10:50:52 +0000
Subject: [music-dsp] ANN: audio programming course
In-Reply-To: <A2504B59-4AEF-49CA-B454-CDE58887BBB9@richbreen.com>
References: <mailman.161.1328523100.148.music-dsp@music.columbia.edu>
	<A2504B59-4AEF-49CA-B454-CDE58887BBB9@richbreen.com>
Message-ID: <4F31020C.3010608@blitzgamesstudios.com>

My thoughts exactly :)

Thanks.

On 06/02/2012 16:28, Rich Breen wrote:
> I don't suppose there's any chance this class can be taken remotely?
>
> thanks,
> rich
>
>
> On Feb 6, 2012, at 2:11 AM, music-dsp-request at music.columbia.edu wrote:
>
>> Subject: [music-dsp] ANN: audio programming course
>> Message-ID:<4F27D260.5040209 at blueyonder.co.uk>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> I guess nobody in this list needs such a thing, but you may know other
>> people who might be interested:
>>
>>
>> Bath University is running its audio programming course (C, maybe C++ as
>> well) again this year, on Wednesdays for 8 Weeks: 22 Feb-25 Apr (not 4
>> 11 Apr), 7.15pm-9.15pm, East Building 0.10, University of Bath.
>>
>> Full details for booking etc:
>>
>> http://www.bath.ac.uk/icia/classes/ssd.html
>>
>> We are also planning a weekend intensive in the summer, to suit people
>> living a distance away. We have no details to announce yet, but it is
>> intended to both cover the material of the weekly sessions and go beyond
>> to real-time interactive this and that. Expressions of interest are invited!
> -----
> rich at richbreen.com
> <http://www.richbreen.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 pcorvo at blitzgamesstudios.com  Tue Feb  7 06:35:35 2012
From: pcorvo at blitzgamesstudios.com (pcorvo)
Date: Tue, 07 Feb 2012 11:35:35 +0000
Subject: [music-dsp]  Multichannel Panning Method
Message-ID: <4F310C87.4090905@blitzgamesstudios.com>

Hello everyone,

Just putting this out there in case anyone has some suggestions. We are 
currently looking at a multichannel panning method for 3D audio, we have 
found a paper that describes the "Speaker-Placement Correction Amplitude 
Panning (SPCAP)" method which seems to be an improvement over the 
"Vector Base Amplitude Panning (VBAP)" method. Has anybody used these 
before and have any suggestions or even other methods worth looking at?

Thank you for your help,
Pedro


From tom_info at ticino.com  Tue Feb  7 08:17:32 2012
From: tom_info at ticino.com (Tom O'Hara)
Date: Tue, 07 Feb 2012 14:17:32 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F30FB05.6000802@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com>
Message-ID: <4F31246C.7080802@ticino.com>

L = ((1+w)L + (1-w)R)/2
R = ((1+w)R + (1-w)L)/2

0<=w<=2

0 = mono
1 = normal
2 = full wide

Tom


On 07-Feb-12 11:20, Ross Bencina wrote:
> Hi Everyone,
>
> Does anyone know if there's a "standard" way to calculate pan laws for
> stereo-wide panning ?
>
> By "stereo-wide" I mean panning something beyond the speakers by using
> 180-degree shifted signal in the opposite speaker. For example, for
> "beyond hard left" you would output full gain signal to the left
> speaker, and some inverted phase signal to the right speaker.
>
> I know this is a somewhat dubious method but I'm wondering if there
> are known pan laws that handle this case.
>
> Thank you,
>
> 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
>

From richarddobson at blueyonder.co.uk  Tue Feb  7 09:02:55 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Tue, 07 Feb 2012 14:02:55 +0000
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <FDC896669A0B42808E75F604531BB357@ProprietairePC>
References: <4F30FB05.6000802@audiomulch.com>
	<FDC896669A0B42808E75F604531BB357@ProprietairePC>
Message-ID: <4F312F0F.40903@blueyonder.co.uk>

"Beyond" needs to be defined. It may be worth remembering that the 
mostly standard pan law is predicated on the virtual source passing 
along an arc of a circle centred on the listener (constant power), so 
"going beyond" has to be defined in that context - the motion between 
the speakers with "normal" panning is not a straight line between them. 
Such an illusion would be totally dependent on a specific listener 
distance; i.e. how much louder/nearer the sound gets in the middle.

One simple device that may help give the illusion of increasing distance 
(and especially when simulating movement) is to reduce the level when 
panning "beyond" following the inverse-square law. Much would depend on 
how much further away "beyond" is meant to be. But this soon takes you 
away from the notion of a generic pan law into electro-acoustic 
composition territory.

Otherwise, you are looking at hrtf plus crosstalk cancellation  (some 
techniques such as ambiophonics claim to be able to create the sense of 
full surround using just the two speakers), or at some other more or 
less sophisticated psycho-acoustic illusion,  which as per usual will 
likely not work for everyone.

Richard Dobson

On 07/02/2012 10:49, Didier Dambrin wrote:
> I've never heard of it, but it's interesting. You mean the pan would
> become a 360deg rotary, going from center to left, to stereo-wide
> center, to right & back to center?
> In that case I'd just use the same law as for the front/left/right
> (which could be any), only with shifting for the lower half of the circle.
>
>
> -----Message d'origine----- From: Ross Bencina
> Sent: Tuesday, February 07, 2012 11:20 AM
> To: A discussion list for music-related DSP
> Subject: [music-dsp] stereo-wide pan law?
>
> Hi Everyone,
>
> Does anyone know if there's a "standard" way to calculate pan laws for
> stereo-wide panning ?
>
> By "stereo-wide" I mean panning something beyond the speakers by using
> 180-degree shifted signal in the opposite speaker. For example, for
> "beyond hard left" you would output full gain signal to the left
> speaker, and some inverted phase signal to the right speaker.
>
> I know this is a somewhat dubious method but I'm wondering if there are
> known pan laws that handle this case.
>

From glasgal at ambiophonics.org  Tue Feb  7 11:02:41 2012
From: glasgal at ambiophonics.org (Ralph Glasgal)
Date: Tue, 7 Feb 2012 11:02:41 -0500
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F30FB05.6000802@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com>
Message-ID: <018f01cce5b1$eca5e950$c5f1bbf0$@org>

There is no valid psychoacoustic method to accomplish this and so there can
be no valid pan laws to accomplish this.  The stereo illusion is like an
optical illusion and is quite restricted.  The only reason that one can on
rare occasions here something beyond the angle of the speakers (in the 60
degree arrangement) is because some crosstalk is inadvertently cancelled or
at higher frequencies you tickle the pinna just right.  That pinna thing is
the reverse polarity combing cancellation pattern that mimics a direction
finding pattern for an instant or two.  Many of these reverse polarity wide
image flukes are fleeting and of course will vary from individual to
individual and are also room and speaker dependant.  I would say this is a
dead end idea.

While applying crosstalk cancellation formulas to the pair to be panned can
do the job, XTC equations such as RACE work better with speakers closer
together.  However, you can get a reasonable result even if the speakers are
at 60 degrees.  At least it will be better than just sending an out of
polarity signal to the other speaker.  The RACE equations are at
www.ambiophonics.org and there are free VST plugins if you want to try it.
What this amounts to is making a pre crosstalk cancelled 2.0 recording for
some sound sources mixed with other sources that remain in ordinary stereo.
That is a mixture of 2 ray and 4 ray pan potted pairs.  Interesting.

Ralph Glasgal 

-----Original Message-----
From: music-dsp-bounces at music.columbia.edu
[mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Ross Bencina
Sent: Tuesday, February 07, 2012 5:21 AM
To: A discussion list for music-related DSP
Subject: [music-dsp] stereo-wide pan law?

Hi Everyone,

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

By "stereo-wide" I mean panning something beyond the speakers by using 
180-degree shifted signal in the opposite speaker. For example, for 
"beyond hard left" you would output full gain signal to the left 
speaker, and some inverted phase signal to the right speaker.

I know this is a somewhat dubious method but I'm wondering if there are 
known pan laws that handle this case.

Thank you,

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



From shanx.shashank at gmail.com  Tue Feb  7 12:31:36 2012
From: shanx.shashank at gmail.com (Shashank Kumar (shanxS))
Date: Tue, 7 Feb 2012 23:01:36 +0530
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <8C22A1A9-FD4F-4C5D-9854-5DE43A4E2AF2@earlevel.com>
References: <4F3037F8.9060706@planetarc.de>
	<CAC6zbP9ToT6qfP0R7exuGe1E2HY-8Xd6=9LBFrV6hBhDjc5=Pg@mail.gmail.com>
	<4F30C89C.5030806@audiomulch.com>
	<8C22A1A9-FD4F-4C5D-9854-5DE43A4E2AF2@earlevel.com>
Message-ID: <CAC6zbP_AUZ=6zyfy6PhevqpJE=RAyyv9-Rgn15ZYOvo0rqsQWQ@mail.gmail.com>

@Ross, Nigel: Thanks for information. That was enlightening. :)

I'd be really grateful if someone would suggest a book audio filter
design where I can see all of these comparisons in form of
mathematical equations ?

Regards,
Shashank

On Tue, Feb 7, 2012 at 12:44 PM, Nigel Redmon <earlevel at earlevel.com> wrote:
> Shashank: Analog filters?the kind in analog mixing consoles that mixed most of what you grew up on?are IIR. So are most of their digital counterparts. So, that's what people are used to.
>
> Of course Ross is right about transients, depending on the amount of filtering used, but linear phase has it's uses and proponents too. I recall that Bob Katz, a respected mastering engineer, said that IIR filters then to move parts of the image forward or backwards in a mix, which is good or bad depending on the situation. He also said that linear phase filters gave a smoother, more subtle sound. Steven St Croix was a proponent of linear phase filtering, with similar comments about being smoother and more natural.
>
> OK, I looked up Bob's comments?here he says he prefers linear phase for about 75% of his work:
>
> http://www.digido.com/audio-faq/l/linear-phase-equalization.html
>
>
> On Feb 6, 2012, at 10:45 PM, Ross Bencina wrote:
>>
>> On 7/02/2012 5:31 PM, Shashank Kumar (shanxS) wrote:
>>> But for audio applications, like EQ design, isn't the phase response
>>> supposed to be linear ?
>>
>> I would say not.
>>
>> Most audio EQ filters don't have linear phase.
>>
>> Additionally, the ear is very sensitive to acausality so, especially for radical filtering, using a symmetric FIR filter for EQ does unnatural things to transients.
>>
>> There are of course counter examples.
>>
>> 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

From np at planetarc.de  Tue Feb  7 13:45:37 2012
From: np at planetarc.de (Nils Pipenbrinck)
Date: Tue, 07 Feb 2012 19:45:37 +0100
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <4F30B0FB.6040808@audioimagination.com>
References: <4F3037F8.9060706@planetarc.de>
	<4F30B0FB.6040808@audioimagination.com>
Message-ID: <4F317151.7090202@planetarc.de>

On 02/07/2012 06:04 AM, robert bristow-johnson wrote:
>
> so it looks like you have 31 biquads in cascade, right?  and they are
> all peaking-EQ filters from the cookbook, right?  (perhaps the bottom
> band and the top band are shelving EQs.)
>
> i would suggest not using Q, but use the BW option in the cookbook and
> try setting the BW to 1/3 octave or thereabouts and see what you get.

Will try that... If I see something unexpected on the frequency response
I'll come back to you folks.

Thanks a lot,
  Nils


From glasgal at ambiophonics.org  Tue Feb  7 15:59:46 2012
From: glasgal at ambiophonics.org (Ralph Glasgal)
Date: Tue, 7 Feb 2012 15:59:46 -0500
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F312F0F.40903@blueyonder.co.uk>
References: <4F30FB05.6000802@audiomulch.com>	<FDC896669A0B42808E75F604531BB357@ProprietairePC>
	<4F312F0F.40903@blueyonder.co.uk>
Message-ID: <01a501cce5db$6d022f40$47068dc0$@org>

Ambiophonics (actually Panambiophonics) requires four speakers to reproduce
a full 360 degrees of direct sound localization in the horizontal plane.  It
deliberately does not employ HRTFs.  The basic program is RACE which stands
for Recursive Ambiophonic Crosstalk Elimination.  It is a shame that it is
not a contraption within AudioMulch which would make it so easy to use in a
4.0 (DTS, etc.) surround application instead of having to use VST plugins in
DAWs or Transcoders working under Java.  The four speakers needed are quite
easy to place.  Just two in front spaced about 20 degrees (either side of a
TV screen) and two behind the same and two independent copies of RACE
running.  You never need a front center speaker or a rear center either.
(RACE is in the public domain.)  For the record, Ambisonics and Wavefield
Synthesis are the other Loudspeaker Binaural technologies that are HRTF
free, but only Ambiophonics (including the Princeton version) is compatible
with all existing 2.0, 5.1, 7.1, etc. media and formats.

Ralph Glasgal
www.ambiophonics.org

-----Original Message-----
From: music-dsp-bounces at music.columbia.edu
[mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Richard Dobson
Sent: Tuesday, February 07, 2012 9:03 AM
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] stereo-wide pan law?

....
Otherwise, you are looking at hrtf plus crosstalk cancellation  (some 
techniques such as ambiophonics claim to be able to create the sense of 
full surround using just the two speakers), or at some other more or 
less sophisticated psycho-acoustic illusion,  which as per usual will 
likely not work for everyone.

Richard Dobson




From richarddobson at blueyonder.co.uk  Tue Feb  7 16:17:44 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Tue, 07 Feb 2012 21:17:44 +0000
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <01a501cce5db$6d022f40$47068dc0$@org>
References: <4F30FB05.6000802@audiomulch.com>	<FDC896669A0B42808E75F604531BB357@ProprietairePC>	<4F312F0F.40903@blueyonder.co.uk>
	<01a501cce5db$6d022f40$47068dc0$@org>
Message-ID: <4F3194F8.7070004@blueyonder.co.uk>

Unless I am completely mixing this up with some other system, I recall 
some demo soundfile you posted some while back (must have been via 
sursound) using two adjacent speakers, and getting a 
quasi-surround/widening effect. I recall it particularly, because just 
using my two toy Apple speakers either side of a round iMac (so hardly a 
definitive or rigorous test!) I actually got the effect quite clearly. 
If that was not yours, whose might it have been?

Richard Dobson

On 07/02/2012 20:59, Ralph Glasgal wrote:
> Ambiophonics (actually Panambiophonics) requires four speakers to reproduce
> a full 360 degrees of direct sound localization in the horizontal plane.  It
> deliberately does not employ HRTFs.  The basic program is RACE which stands
> for Recursive Ambiophonic Crosstalk Elimination.  It is a shame that it is
> not a contraption within AudioMulch which would make it so easy to use in a
> 4.0 (DTS, etc.) surround application instead of having to use VST plugins in
> DAWs or Transcoders working under Java.  The four speakers needed are quite
> easy to place.  Just two in front spaced about 20 degrees (either side of a
> TV screen) and two behind the same and two independent copies of RACE
> running.  You never need a front center speaker or a rear center either.
> (RACE is in the public domain.)  For the record, Ambisonics and Wavefield
> Synthesis are the other Loudspeaker Binaural technologies that are HRTF
> free, but only Ambiophonics (including the Princeton version) is compatible
> with all existing 2.0, 5.1, 7.1, etc. media and formats.
>

From o at iki.fi  Tue Feb  7 16:39:19 2012
From: o at iki.fi (Olli Niemitalo)
Date: Tue, 7 Feb 2012 23:39:19 +0200
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F30FB05.6000802@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com>
Message-ID: <CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>

On Tue, Feb 7, 2012 at 12:20 PM, Ross Bencina
<rossb-lists at audiomulch.com> wrote:
> Hi Everyone,
>
> Does anyone know if there's a "standard" way to calculate pan laws for
> stereo-wide panning ?
>
> By "stereo-wide" I mean panning something beyond the speakers by using
> 180-degree shifted signal in the opposite speaker.

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

-olli

From glasgal at ambiophonics.org  Tue Feb  7 16:51:13 2012
From: glasgal at ambiophonics.org (Ralph Glasgal)
Date: Tue, 7 Feb 2012 16:51:13 -0500
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F3194F8.7070004@blueyonder.co.uk>
References: <4F30FB05.6000802@audiomulch.com>	<FDC896669A0B42808E75F604531BB357@ProprietairePC>	<4F312F0F.40903@blueyonder.co.uk>	<01a501cce5db$6d022f40$47068dc0$@org>
	<4F3194F8.7070004@blueyonder.co.uk>
Message-ID: <01aa01cce5e2$9ce93300$d6bb9900$@org>

That was mine.  There are several demo tracks on the Ambiophonic website
that you can download.  But you should get the free Apple/Android(not free)
Ambiophonic app or the free Hotto Transcoder and play your own favorite
recordings via good speakers.  Angelo Farina and others on the Sursound list
know all about this and have contributed to advancing this technology.

Ralph Glasgal 

-----Original Message-----
From: music-dsp-bounces at music.columbia.edu
[mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Richard Dobson
Sent: Tuesday, February 07, 2012 4:18 PM
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] stereo-wide pan law?

Unless I am completely mixing this up with some other system, I recall 
some demo soundfile you posted some while back (must have been via 
sursound) using two adjacent speakers, and getting a 
quasi-surround/widening effect. I recall it particularly, because just 
using my two toy Apple speakers either side of a round iMac (so hardly a 
definitive or rigorous test!) I actually got the effect quite clearly. 
If that was not yours, whose might it have been?

Richard Dobson

On 07/02/2012 20:59, Ralph Glasgal wrote:
> Ambiophonics (actually Panambiophonics) requires four speakers to
reproduce
> a full 360 degrees of direct sound localization in the horizontal plane.
It
> deliberately does not employ HRTFs.  The basic program is RACE which
stands
> for Recursive Ambiophonic Crosstalk Elimination.  It is a shame that it is
> not a contraption within AudioMulch which would make it so easy to use in
a
> 4.0 (DTS, etc.) surround application instead of having to use VST plugins
in
> DAWs or Transcoders working under Java.  The four speakers needed are
quite
> easy to place.  Just two in front spaced about 20 degrees (either side of
a
> TV screen) and two behind the same and two independent copies of RACE
> running.  You never need a front center speaker or a rear center either.
> (RACE is in the public domain.)  For the record, Ambisonics and Wavefield
> Synthesis are the other Loudspeaker Binaural technologies that are HRTF
> free, but only Ambiophonics (including the Princeton version) is
compatible
> with all existing 2.0, 5.1, 7.1, etc. media and formats.
>
--
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 dgm at baykitty.com  Tue Feb  7 21:53:15 2012
From: dgm at baykitty.com (dgm)
Date: Wed, 8 Feb 2012 10:53:15 +0800
Subject: [music-dsp] choice of Q for graphic equalizers
In-Reply-To: <4F317151.7090202@planetarc.de>
References: <4F3037F8.9060706@planetarc.de>
	<4F30B0FB.6040808@audioimagination.com>
	<4F317151.7090202@planetarc.de>
Message-ID: <A4683FDF-045C-4BA1-801E-0797B5E1E55A@baykitty.com>


To correct what I wrote yesterday, I now recall that I had to tune the filters when I first built the equalizer, so bandwidth would be the correct way to go.
dgm

On Feb 8, 2012, at 2:45 AM, Nils Pipenbrinck wrote:

> On 02/07/2012 06:04 AM, robert bristow-johnson wrote:
>> 
>> so it looks like you have 31 biquads in cascade, right?  and they are
>> all peaking-EQ filters from the cookbook, right?  (perhaps the bottom
>> band and the top band are shelving EQs.)
>> 
>> i would suggest not using Q, but use the BW option in the cookbook and
>> try setting the BW to 1/3 octave or thereabouts and see what you get.
> 
> Will try that... If I see something unexpected on the frequency response
> I'll come back to you folks.
> 
> Thanks a lot,
>  Nils
> 
> --
> 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  Tue Feb  7 22:51:55 2012
From: didid at skynet.be (Didier Dambrin)
Date: Wed, 8 Feb 2012 04:51:55 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F3194F8.7070004@blueyonder.co.uk>
References: <4F30FB05.6000802@audiomulch.com>	<FDC896669A0B42808E75F604531BB357@ProprietairePC>	<4F312F0F.40903@blueyonder.co.uk><01a501cce5db$6d022f40$47068dc0$@org>
	<4F3194F8.7070004@blueyonder.co.uk>
Message-ID: <B72C53DA03294F5DBFFF5CB41103C706@ProprietairePC>

To me the (really) old "invert a channel" trick has never been a proper way 
to get surround, & while I'd avoid it because it's totally not mono-friendly 
(obviously), I like the idea of enhancing a panning knob with it, as to me 
it's always useful to have a section (in a sequencer or synth) that's fully 
dedicated to stereo gain, which includes volume, panning, stereo 
enhancing/shrinking, and phase inversion. So it doesn't seem a bad idea to 
enhance the panning with a way to achieve phase inversion on one of the 
channels only.

As lame as that effect can be, it's still efficient, especially with 
headphones, not for "surround" but for "another stereo". This said, you get 
similar results by using other light stereo effects (like with allpasses) 
that are more mono-compatible.



-----Message d'origine----- 
From: Richard Dobson
Sent: Tuesday, February 07, 2012 10:17 PM
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] stereo-wide pan law?

Unless I am completely mixing this up with some other system, I recall
some demo soundfile you posted some while back (must have been via
sursound) using two adjacent speakers, and getting a
quasi-surround/widening effect. I recall it particularly, because just
using my two toy Apple speakers either side of a round iMac (so hardly a
definitive or rigorous test!) I actually got the effect quite clearly.
If that was not yours, whose might it have been?

Richard Dobson

On 07/02/2012 20:59, Ralph Glasgal wrote:
> Ambiophonics (actually Panambiophonics) requires four speakers to 
> reproduce
> a full 360 degrees of direct sound localization in the horizontal plane. 
> It
> deliberately does not employ HRTFs.  The basic program is RACE which 
> stands
> for Recursive Ambiophonic Crosstalk Elimination.  It is a shame that it is
> not a contraption within AudioMulch which would make it so easy to use in 
> a
> 4.0 (DTS, etc.) surround application instead of having to use VST plugins 
> in
> DAWs or Transcoders working under Java.  The four speakers needed are 
> quite
> easy to place.  Just two in front spaced about 20 degrees (either side of 
> a
> TV screen) and two behind the same and two independent copies of RACE
> running.  You never need a front center speaker or a rear center either.
> (RACE is in the public domain.)  For the record, Ambisonics and Wavefield
> Synthesis are the other Loudspeaker Binaural technologies that are HRTF
> free, but only Ambiophonics (including the Princeton version) is 
> compatible
> with all existing 2.0, 5.1, 7.1, etc. media and formats.
>
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp


-----
Aucun virus trouve dans ce message.
Analyse effectuee par AVG - www.avg.fr
Version: 2012.0.1913 / Base de donnees virale: 2112/4794 - Date: 07/02/2012 


From rbj at audioimagination.com  Tue Feb  7 23:31:27 2012
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 07 Feb 2012 23:31:27 -0500
Subject: [music-dsp] test
Message-ID: <4F31FA9F.8000505@audioimagination.com>


test.

-- 

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




From rbj at audioimagination.com  Tue Feb  7 23:35:01 2012
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 07 Feb 2012 23:35:01 -0500
Subject: [music-dsp] (no subject)
Message-ID: <4F31FB75.3070707@audioimagination.com>

On 2/7/12 1:45 PM, Nils Pipenbrinck wrote:
> On 02/07/2012 06:04 AM, robert bristow-johnson wrote:
>> so it looks like you have 31 biquads in cascade, right?  and they are
>> all peaking-EQ filters from the cookbook, right?  (perhaps the bottom
>> band and the top band are shelving EQs.)
>>
>> i would suggest not using Q, but use the BW option in the cookbook and
>> try setting the BW to 1/3 octave or thereabouts and see what you get.
> Will try that... If I see something unexpected on the frequency response
> I'll come back to you folks.
>
what i'm expecting is that at the band boundaries, which are at the 
midpoints between band centers in log-frequency, that the dB gain should 
be at the midpoint between the gains at the band centers. this is 
because the way BW is defined for the peaking EQ in the cookbook where 
the two bandedges are at the half the dB gain as the peak.

and the gains at the band centers better be what your faders say the 
gains are, i guess that's sorta the whole point.  you might get some 
anomalous behavior with a 1/3 octave graphic EQ when you alternate each 
fader +24 dB, -24 dB, etc.  i dunno for sure that it will hit the fader 
gains perfectly at the band centers but it should cross 0 dB at the band 
boundaries.

> Thanks a lot,
>

let us know how it turns out.

-- 

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




From rossb-lists at audiomulch.com  Wed Feb  8 01:10:04 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Wed, 08 Feb 2012 17:10:04 +1100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F30FB05.6000802@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com>
Message-ID: <4F3211BC.3090406@audiomulch.com>

Thanks for the responses,

Seems like I may have asked the wrong question.

Ralph Glasgal wrote:
 > There is no valid psychoacoustic method to accomplish this and so
 > there can be no valid pan laws to accomplish this.

In this instance I'm not really concerned with psychoacoustics. What I 
need is something that gives a sensible result under the assumption that 
I want to send some anti-phase in the opposite speaker. "Sensible" could 
be defined as "perceptually smooth", or "energy smooth".

Ambisonics uses anti-phase panning. What if we assume that the speakers 
are on either side of the head. Does that give a valid physical basis 
for stereo anti-phase panning?

As I already said, I realise that it's a somewhat dubious idea -- I'm 
not looking for criticisms of that. I'm working on a simple extension of 
an existing effect algorithm (a somewhat well known stereo chorus) that 
uses this inverse phase business to "pan" the chorused voices -- and I 
want to limit my algorithm to that.

What I'm aiming to achieve is one slider that can pan each voice between 
from left to right, and also smoothly cross into dubious "beyond the 
speakerness" by sending inverse phase to the opposite speaker. It could 
be as simple as ramping up the inverse phase signal but I thought it 
might be possible to formulate something that has some kind of basis in 
stereo panning law theory -- not necessarily concerning spatial 
perception but at least concerning perceived signal energy.


To get really concrete: at the moment I have two sliders (one for left 
level and one for right level) and two checkboxes for inverting the 
phase of each side. This is a most unsatisfactory user interface. I need 
to get to the point of having a single "pan" or "width" slider.


Tom's response comes closest:

On 8/02/2012 12:17 AM, Tom O'Hara wrote:
 > L = ((1+w)L + (1-w)R)/2
 > R = ((1+w)R + (1-w)L)/2
 >
 > 0<=w<=2
 >
 > 0 = mono
 > 1 = normal
 > 2 = full wide


But it is a stereo image processing formula not a panning formula, and 
it uses linear ramps (amplitude sums to unity for left and right) so 
doesn't appear to follow the usual power laws associated with stereo 
panning.

I could use a regular panning law for between the speakers and use Tom's 
linear constant-amplitude extension for beyond the speakers, but somehow 
increasing the amplitude of the the in-phase speaker to give a unity 
amplitude sum with the anti-phase speaker doesn't seem right. If 
anything I would think that the in-phase speaker amplitude should be 
reduced -- perhaps in a mirror image of the between-the speakers fade 
curves with the polarity of one side reversed?


I hope that makes my question clearer.

Thanks!

Ross


On 7/02/2012 9:20 PM, Ross Bencina wrote:
> Hi Everyone,
>
> Does anyone know if there's a "standard" way to calculate pan laws for
> stereo-wide panning ?
>
> By "stereo-wide" I mean panning something beyond the speakers by using
> 180-degree shifted signal in the opposite speaker. For example, for
> "beyond hard left" you would output full gain signal to the left
> speaker, and some inverted phase signal to the right speaker.
>
> I know this is a somewhat dubious method but I'm wondering if there are
> known pan laws that handle this case.
>
> Thank you,
>
> 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
>

From emanuel.landeholm at gmail.com  Wed Feb  8 05:27:27 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Wed, 8 Feb 2012 11:27:27 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
Message-ID: <CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>

Lol! Actually, when reading the OP the first thought that went through
my head was "Hilbert transformer". So I scanned the thread, and sure
enough...

It would seem that once you have an analytic signal, all you need to
do is to apply a simple complex rotation with a phase offset for the
second channel.

left = cos 0 * Re - sin 0 * Im = Re
right = sin theta * Re + cos theta * Im

Is this how it's done in Dolby?

> You could cook up something from the Dolby Stereo mixing matrix, but
> the implementation is going to need a Hilbert transformer.
>
> -olli
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp

From o at iki.fi  Wed Feb  8 08:04:22 2012
From: o at iki.fi (Olli Niemitalo)
Date: Wed, 8 Feb 2012 15:04:22 +0200
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
	<CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
Message-ID: <CAAKWUFEe6OJNQ656uvPAjQvSez6y_21_dgiZODh5uwvGcs2jsA@mail.gmail.com>

It think it's first explained in the patent US4577305 issued March 18, 1986:

  http://www.google.com/patents?id=CcI2AAAAEBAJ

>From the patent:

  LT = L + 0.7 C - 0.7 j S
  RT = R + 0.7 C + 0.7 j S

There, by j they mean a 90 degree phase shift, L, R, C, S are left,
right, center, surround, and T means "total". I don't know if they
ever go to specifics about panning. It's more like a 4 channel --> 2
channel encoding. Note that 0.7 is approximately 1/sqrt(2) or
sqrt(1/2), so the center channel alone would give about the same LT
and RT as panning to the center with a constant power stereo panning
law. In the context of the current discussion, S could be treated as a
rear channel to be used in "extreme" panning.

-olli

On Wed, Feb 8, 2012 at 12:27 PM, Emanuel Landeholm
<emanuel.landeholm at gmail.com> wrote:
> Lol! Actually, when reading the OP the first thought that went through
> my head was "Hilbert transformer". So I scanned the thread, and sure
> enough...
>
> It would seem that once you have an analytic signal, all you need to
> do is to apply a simple complex rotation with a phase offset for the
> second channel.
>
> left = cos 0 * Re - sin 0 * Im = Re
> right = sin theta * Re + cos theta * Im
>
> Is this how it's done in Dolby?
>
>> You could cook up something from the Dolby Stereo mixing matrix, but
>> the implementation is going to need a Hilbert transformer.
>>
>> -olli
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
> --
> 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 emanuel.landeholm at gmail.com  Wed Feb  8 08:54:39 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Wed, 8 Feb 2012 14:54:39 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
	<CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
Message-ID: <CAML4ZX5JAQhYM4M8Ce26pHa=wvpjNM8JAUUWh6aBJqAXe33OJg@mail.gmail.com>

On Wed, Feb 8, 2012 at 11:27 AM, Emanuel Landeholm
<emanuel.landeholm at gmail.com> wrote:
> simple complex rotation

Wait... What did I just write? o_O

From o at iki.fi  Wed Feb  8 09:06:08 2012
From: o at iki.fi (Olli Niemitalo)
Date: Wed, 8 Feb 2012 16:06:08 +0200
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F3211BC.3090406@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
Message-ID: <CAAKWUFH-04q1o7=1h6J3ucpLBCHbeVQXO0bnS0G7+irmXo6WGA@mail.gmail.com>

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

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

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

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

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

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

-olli

On Wed, Feb 8, 2012 at 8:10 AM, Ross Bencina <rossb-lists at audiomulch.com> wrote:
> What I'm aiming to achieve is one slider that can pan each voice between
> from left to right, and also smoothly cross into dubious "beyond the
> speakerness" by sending inverse phase to the opposite speaker. It could be
> as simple as ramping up the inverse phase signal but I thought it might be
> possible to formulate something that has some kind of basis in stereo
> panning law theory -- not necessarily concerning spatial perception but at
> least concerning perceived signal energy.

From o at iki.fi  Wed Feb  8 09:17:09 2012
From: o at iki.fi (Olli Niemitalo)
Date: Wed, 8 Feb 2012 16:17:09 +0200
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAAKWUFH-04q1o7=1h6J3ucpLBCHbeVQXO0bnS0G7+irmXo6WGA@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<CAAKWUFH-04q1o7=1h6J3ucpLBCHbeVQXO0bnS0G7+irmXo6WGA@mail.gmail.com>
Message-ID: <CAAKWUFFX7HWbS2+owD-3JLvAhLBkUp+fxaTGx_3bmoNs4ypO1Q@mail.gmail.com>

Oopsy, correcting from the previously 3-row equation:

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

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

-olli

On Wed, Feb 8, 2012 at 4:06 PM, Olli Niemitalo <o at iki.fi> wrote:
> Knowing that you're panning chorus voices to be summed with the input
> signal gives something to work on.
>
> Let's say there's just one chorus voice and someone sets up the
> delays, volume and whatnot so that it is actually identical to the
> input signal. Now, it would be unreasonable if, compared to input, the
> output would have an opposite polarity in L or R. So, the most extreme
> panning should be no more extreme than to have a gain of -1 in either
> channel of the chorus voice. Let's define exactly that as the most
> extreme setting. So at extreme-L or extreme-R, output R or L will be
> muted. Now, at the same time, what should the gain of the other chorus
> voice channel be? In all fairness, it should be as loud as the
> inverted other channel, so the gain should be at least 1. It would
> also be weird if it was louder than the input signal, so let's fix the
> value at exactly 1.
>
> Done all that, the extended-range panning of the chorus voice
> effectively amplifies the input signal by 6 dB and pans it in the
> regular fashion. So you might require that in the described situation,
> the output, with respect to the input, is panned by your favorite
> panning law f(p), where p = -1..1, such that the total gains of the
> two channels are 2*f(p) and 2*f(-p). We can write the extended-range
> panning law g in terms of f as:
>
> 1 + g(p) = 2*f(p)
> ==> g(p) =2*f(p) - 1
> ==> g(p) = f(p) - 0.5
>
> For a chorus voice, as channel gains, use g(p) = f(p) - 0.5 and g(-p)
> = f(-p) - 0.5, where p = -1..1 is the panning and f(p) is a vanilla
> panning law of your choice. This means that with g(p), you will have
> to re-label "full left" and "full right" to mean the values of p for
> which f(p) = 0.5 or f(-p) = 0.5. Consequently, f(p) can't be a linear
> panning law, but must satisfy f(0) > 0.5. A constant-power panning law
> can be used as f(p).
>
> Well, that's the best I could come up with!
>
> -olli

From rossb-lists at audiomulch.com  Wed Feb  8 09:54:03 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Thu, 09 Feb 2012 01:54:03 +1100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAAKWUFH-04q1o7=1h6J3ucpLBCHbeVQXO0bnS0G7+irmXo6WGA@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<CAAKWUFH-04q1o7=1h6J3ucpLBCHbeVQXO0bnS0G7+irmXo6WGA@mail.gmail.com>
Message-ID: <4F328C8B.4070303@audiomulch.com>



On 9/02/2012 1:06 AM, Olli Niemitalo wrote:
> Now, it would be unreasonable if, compared to input, the
> output would have an opposite polarity in L or R.

I'm not sure what you're getting at here, for example, the following is 
reasonable:

Considering the left channel only (right is opposite and is also added 
into the two outputs ):


leftVoice = modulated_delay( leftInput );

leftOutput = leftInput + -.2 * leftVoice;
rightOutput = leftVoice * .55;


In this case the modulated delay of the left input is panned "extreme 
right".

Ross.

From o at iki.fi  Wed Feb  8 10:19:28 2012
From: o at iki.fi (Olli Niemitalo)
Date: Wed, 8 Feb 2012 17:19:28 +0200
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F328C8B.4070303@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<CAAKWUFH-04q1o7=1h6J3ucpLBCHbeVQXO0bnS0G7+irmXo6WGA@mail.gmail.com>
	<4F328C8B.4070303@audiomulch.com>
Message-ID: <CAAKWUFHZXh7QpEmNfp8fu8x+MMcjhX0ud7CPfnhaEQAqP-=DCg@mail.gmail.com>

Ross, okay, I did not realize you channel mix left and right in the
voices. I thought the panning was simply different gains in the two
channels, possibly negative in one channel for the "extreme" effect.

-olli

On Wed, Feb 8, 2012 at 4:54 PM, Ross Bencina <rossb-lists at audiomulch.com> wrote:
>
>
> On 9/02/2012 1:06 AM, Olli Niemitalo wrote:
>>
>> Now, it would be unreasonable if, compared to input, the
>> output would have an opposite polarity in L or R.
>
>
> I'm not sure what you're getting at here, for example, the following is
> reasonable:
>
> Considering the left channel only (right is opposite and is also added into
> the two outputs ):
>
>
> leftVoice = modulated_delay( leftInput );
>
> leftOutput = leftInput + -.2 * leftVoice;
> rightOutput = leftVoice * .55;
>
>
> In this case the modulated delay of the left input is panned "extreme
> right".
>
>
> 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

From rossb-lists at audiomulch.com  Wed Feb  8 10:35:55 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Thu, 09 Feb 2012 02:35:55 +1100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAAKWUFFX7HWbS2+owD-3JLvAhLBkUp+fxaTGx_3bmoNs4ypO1Q@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<CAAKWUFH-04q1o7=1h6J3ucpLBCHbeVQXO0bnS0G7+irmXo6WGA@mail.gmail.com>
	<CAAKWUFFX7HWbS2+owD-3JLvAhLBkUp+fxaTGx_3bmoNs4ypO1Q@mail.gmail.com>
Message-ID: <4F32965B.30308@audiomulch.com>



On 9/02/2012 1:17 AM, Olli Niemitalo wrote:
> 1 + g(p) = 2*f(p)
> ==>  g(p) = 2*f(p) - 1
>
> For a chorus voice, as channel gains, use g(p) = 2f(p) - 1 and g(-p)
> = 2f(-p) - 1, where p = -1..1 is the panning and f(p) is a vanilla
> panning law of your choice. This means that with g(p), you will have
> to re-label "full left" and "full right" to mean the values of p for
> which f(p) = 0.5 or f(-p) = 0.5. Consequently, f(p) can't be a linear
> panning law, but must satisfy f(0)>  0.5. A constant-power panning law
> can be used as f(p).

That works quite nicely, thanks!

Ross.

From jchandjr at bellsouth.net  Wed Feb  8 10:46:48 2012
From: jchandjr at bellsouth.net (James Chandler Jr)
Date: Wed, 8 Feb 2012 10:46:48 -0500
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F328C8B.4070303@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com>
	<4F3211BC.3090406@audiomulch.com><CAAKWUFH-04q1o7=1h6J3ucpLBCHbeVQXO0bnS0G7+irmXo6WGA@mail.gmail.com>
	<4F328C8B.4070303@audiomulch.com>
Message-ID: <BB798F8370E040BBA364C6A8E41BA89C@HPWin7>

I didn't see this idea mentioned. Maybe the idea was already mentioned or 
perhaps the idea is inappropriate to the task at hand.

Sometime long ago I experimented with panning by adding a very small delay to 
one channel, in addition to the channel volume scaling. That would be similar to 
phase modification, but more so.

Sitting in front of an ordinary near-field studio speaker setup, the small delay 
seemed to make a much more noticeable subjective audible positioning, compared 
to merely adjusting channel volumes or phase. It also seemed a very "satisfying" 
stereo positioning with headphones.

I never messed with it beyond brief experimentation because the technique seemed 
too likely to cause mono mix problems, or bad problems in certain listening 
environments. 


From theover at tiscali.nl  Wed Feb  8 11:25:14 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Wed, 08 Feb 2012 17:25:14 +0100
Subject: [music-dsp] stereo-wide pan law?
Message-ID: <4F32A1EA.2080409@tiscali.nl>

 > left = cos 0 * Re - sin 0 * Im = Re
 > right = sin theta * Re + cos theta * Im

It sometimes amazes me where people learn all this ..., though I 
partially know the answer.

How can you take the Real and imaginary part of a general audio signal, 
really, will somebody *with* a proper Electrical Engineering background 
try to explain that to themselves, that should be good for a few laughs.

Seriously, a Hilbert space has to do with the mathematical Fourier (not 
necessarily the Fast FF) transform (beginning of the 19th century, so 
hardly the pinnacle of contemporary mathematics, which would be more in 
the field of the Fock transform), and a transform as such will probably 
refer to the some variation on the important Fourier Theory. But, 
people, the head directionality approximation and thereflectivity of 
audio sounds, and even the strengths and relative distances of various 
frequencies emanating from small speakers have not directly to do with 
this transform, and the idea of the real and imaginary part in 
electrical signals has more to do with the three phases of wires 
carrying sinusoidal signals coming from an electricity generator than 
any sensible audio signal, unless it concerns an extremely specialistic 
subclass.

Just saying.

Ir. Theo Verelst

From emanuel.landeholm at gmail.com  Wed Feb  8 11:37:22 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Wed, 8 Feb 2012 17:37:22 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F32A1EA.2080409@tiscali.nl>
References: <4F32A1EA.2080409@tiscali.nl>
Message-ID: <CAML4ZX7ozNVQA-Hu6NKouvRa1tAKu+wvz3sbhpdShb0mFPWBhQ@mail.gmail.com>

On Wed, Feb 8, 2012 at 5:25 PM, Theo Verelst <theover at tiscali.nl> wrote:
>> left = cos 0 * Re - sin 0 * Im = Re
>> right = sin theta * Re + cos theta * Im
>
> It sometimes amazes me where people learn all this ..., though I partially
> know the answer.
>
> How can you take the Real and imaginary part of a general audio signal,
> really, will somebody *with* a proper Electrical Engineering background try
> to explain that to themselves, that should be good for a few laughs.

http://en.wikipedia.org/wiki/Analytic_Signal

This concept is really useful for a range of signal applications. FM
demodulation, frequency shifting, cepstrum/liftering techniques, min
phase filtering ...

Sorry, no proper EE background here tho. I'm just a math geek. :-)

> Seriously, a Hilbert space has to do with the mathematical Fourier (not
> necessarily the Fast FF) transform (beginning of the 19th century, so hardly
> the pinnacle of contemporary mathematics, which would be more in the field
> of the Fock transform), and a transform as such will probably refer to the
> some variation on the important Fourier Theory. But, people, the head
> directionality approximation and thereflectivity of audio sounds, and even
> the strengths and relative distances of various frequencies emanating from
> small speakers have not directly to do with this transform, and the idea of
> the real and imaginary part in electrical signals has more to do with the
> three phases of wires carrying sinusoidal signals coming from an electricity
> generator than any sensible audio signal, unless it concerns an extremely
> specialistic subclass.

Well, Hilbert space != Hilbert transform
Also, naive mono => stereo widening (like L = x, R= -x) is really a
special case of the method I suggested.
But I was just thinking out loud.

Regards,

From mathieu.barthet at eecs.qmul.ac.uk  Wed Feb  8 11:40:54 2012
From: mathieu.barthet at eecs.qmul.ac.uk (mathieu barthet)
Date: Wed, 8 Feb 2012 16:40:54 +0000
Subject: [music-dsp] CMMR 2012 Music Deadline Extension and News
Message-ID: <D4219EEDAA22E24EBD3A4B779CB428F723DC447D10@staff-mail2.vpn.elec.qmul.ac.uk>

--------------------------------------
Apologies for potential cross-postings
--------------------------------------

** CMMR 2012 Music Deadline Extension and News **

** New deadline for Music: 20th February 2012 **

9th International Symposium on Computer Music Modeling and Retrieval (CMMR) "Music and Emotions"
19-22 June 2012
Queen Mary University of London
Conference website: http://www.cmmr2012.eecs.qmul.ac.uk/
CMMR 2012 Easy Chair portal: https://www.easychair.org/conferences/?conf=cmmr2012
Twitter: @CMMR2012

Dear all,

The deadline for music contributions to CMMR 2012 has been extended to 20th February 2012. Information on the call for music and the submission process can be found below.

** News **

- I like music because...

In order to uncover people's affective relationships with music, please give your opinion and complete the sentence "I like music because..." on the CMMR 2012 Facebook page at: http://www.facebook.com/cmmr2012

Some of your answers may be used during the conference panel discussions.

- Keynote speakers

We are pleased to invite three distinguished keynote speakers working in the fields of music informatics, music perception, and soundtrack composition: Prof. Laurent Daudet from Paris Diderot University, France ("The why, how, and what of sparse representations for audio"), Prof. Patrik N. Juslin from Uppsala University, Sweden ("Hearing with our hearts: Psychological perspectives on music and emotions"), and BAFTA nominated British film score composer Simon Boswell ("Music in cinema: How soundtrack composers act on the way people feel").

More information at: http://cmmr2012.eecs.qmul.ac.uk/keynotes

** Call for Music **

+ Topics:

Original contributions are encouraged in, but not limited to, the following areas:

  * Music for instruments and electroacoustics
  * Live or recorded electronic music for up to 8 channels
  * Augmented instruments and novel controllers/interfaces
  * Instrumental acoustic music composed with algorithmic or tools based on Music Information Retrieval
  * Music composed for visuals (e.g. soundtracks, multimedia compositions, etc.)
  * Performances of traditional music enhanced with live visualisation or interactive technology
  * Performances relating to the conference theme "Music and Emotions"
  * Installations and interactive pieces

Submissions from any musical style or genre are warmly welcomed.

For pieces involving traditional instruments, an ensemble consisting of flute (piccolo/alto flute), clarinet (bass clarinet), violin, cello, piano and percussion (1 player) will be available. Submitters are also welcome to provide their own performers. Submissions of 15 minutes or less are preferred, however music of any length will be considered. We will provide PA equipment including an 8-channel sound system, a video projector and a grand piano. Performers should bring any other required instruments or equipment. The projection of films in the digital format will be possible for film soundtracks.

+ Submission Materials:

Music submission should include:

1. PDF document of up to 3 sides of A4 specifying the following information:

- Author name(s), affiliations (if relevant), and contact information
- Title of proposed performance or installation
- Program notes (1-3 paragraphs)
- Indication if the performance relates to a separate submission to the technical programme (in such case, please indicate the title, authors and submission number of the separate submission)
- Intended venue: evening concert, installation, or afternoon demo
- Duration and instrumentation
- Names of performers, if relevant, or indicate that you will use conference ensemble
- Optionally, composer / performer bios or a link to where these can be found online 
- Detailed description of technical requirements, including equipment and setup time
- Stage plot and input list for live performances

2. An attachment consisting in 1 archive file in the ZIP or TGZ format with the following documents:

- All performer scores (if applicable)
- Audio file(s) for evaluation of the submission. MP3, AAC or FLAC preferred (limit of 20MB per submission). For multichannel submissions, please provide a stereo mix if possible; submitting both stereo and multichannel versions is also acceptable.
- Video files (optional) in e.g. MPEG-2 or H.264/MPEG-4.

Additional information on submission are provided at:

http://cmmr2012.eecs.qmul.ac.uk/author-instructions

+ Important Dates:

Music submission deadline (extended):
20th February 2012

Notification of acceptance: 		
20th March 2012

Provision of detailed performance materials:
19th April 2012

Concert dates:
20th and 22nd June 2012

Conference dates:
19-22 June 2012

Please make your submissions following the instructions on the conference website:

http://cmmr2012.eecs.qmul.ac.uk/author-instructions

and by using the CMMR 2012 Easy Chair portal:

https://www.easychair.org/conferences/?conf=cmmr2012

We are looking forward to your contributions!

Thanks for forwarding this call to interested parties.

+ Symposium General Chairs:

Mathieu Barthet, Queen Mary University of London, UK
Simon Dixon, Queen Mary University of London, UK

+ Music Chairs:

Andrew McPherson, Queen Mary University of London, UK
Elaine Chew, Queen Mary University of London, UK

+ Music Committee (confirmed):

Bertrand Arnold, Soundisplay, UK
Mathieu Barthet, Queen Mary University of London, UK
Elaine Chew, Queen Mary University of London, UK
Philippe Festou, Laboratoire Musique et Informatique, France
Pascal Gobin, Conservatoire National de R?gion Marseille, France
Keeril Makan, Massachusetts Institute of Technology, USA
Andrew McPherson, Queen Mary University of London, UK
Eduardo Miranda, University of Plymouth, UK
Isaac Schankler, University of Southern California, USA
Jeff Snyder, Princeton University, USA

+ Paper and Program Chairs:

Richard Kronland-Martinet, CNRS-LMA, France
Mitsuko Aramaki, CNRS-LMA, France
Solvi Ystad, CNRS-LMA, France
Panos Kudumakis, Queen Mary University of London, UK

+ Demonstrations, Panels & Tutorials Chairs:

Daniele Barchiesi, Queen Mary University of London, UK
Steven Hargreaves, Queen Mary University of London, UK

+ Organizing Committee:

Daniele Barchiesi, Queen Mary University of London, UK
Emmanouil Benetos, Queen Mary University of London, UK
Luis Figueira, Queen Mary University of London, UK
Steven Hargreaves, Queen Mary University of London, UK
Sefki Kolozali, Queen Mary University of London, UK
Asma Rafiq, Queen Mary University of London, UK
Sue White, Queen Mary University of London, UK

+ Program Committee (confirmed):

Mitsuko Aramaki, CNRS-LMA, France
Federico Avanzini, University of Padova, Italy
Isabel Barbancho, University of M?laga, Spain
Mathieu Barthet, Queen Mary University of London, UK
Roberto Bresin, KTH, Sweden
Antonio Camurri, University of Genova, Italy
Olivier Derrien, Toulon-Var University, France
Simon Dixon, Queen Mary University of London, UK
Barry Eaglestone, University of Sheffield, UK
C?dric F?votte, CNRS-TELECOM ParisTech, France
Bruno Giordano, McGill University, Canada
Emilia G?mez, Pompeu Fabra University, Spain
Brian Gygi, East Bay Institute for Research and Education, USA
Goffredo Haus, Laboratory for Computer Applications in Music, Italy
Henkjan Honing, University of Amsterdam, The Netherlands
Kristoffer Jensen, Aalborg University, Denmark
Youngmoo E. Kim, Drexel University, USA
Anssi Klapuri, Queen Mary University of London, UK
Richard Kronland-Martinet, CNRS-LMA, France
Panos Kudumakis, Queen Mary University of London, UK
Daniel Leech-Wilkinson, King's College London, UK
Sylvain Marchand, Universit? de Bretagne Occidentale, France
Matthias Mauch, Queen Mary University of London, UK
Eduardo Miranda, University of Plymouth, UK
Emery Schubert, University of New South Wales, Australia
Bj?rn Schuller, Munich University of Technology, Germany
Bob Sturm, Aalborg University, Denmark
George Tzanetakis, University of Victoria, Canada
Geraint A. Wiggins, Queen Mary University of London, UK
S?lvi Ystad, CNRS-LMA, France

From theover at tiscali.nl  Wed Feb  8 11:51:37 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Wed, 08 Feb 2012 17:51:37 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <mailman.372.1328719274.148.music-dsp@music.columbia.edu>
References: <mailman.372.1328719274.148.music-dsp@music.columbia.edu>
Message-ID: <4F32A819.2010401@tiscali.nl>


 > Sorry, no proper EE background here tho. I'm just a math geek. :-)


Auw man

From richarddobson at blueyonder.co.uk  Wed Feb  8 12:09:28 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Wed, 08 Feb 2012 17:09:28 +0000
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F32A1EA.2080409@tiscali.nl>
References: <4F32A1EA.2080409@tiscali.nl>
Message-ID: <4F32AC48.5050502@blueyonder.co.uk>

On 08/02/2012 16:25, Theo Verelst wrote:
>  > left = cos 0 * Re - sin 0 * Im = Re
>  > right = sin theta * Re + cos theta * Im
>
> It sometimes amazes me where people learn all this ..., though I
> partially know the answer.
>
> How can you take the Real and imaginary part of a general audio signal,
> really, will somebody *with* a proper Electrical Engineering background
> try to explain that to themselves, that should be good for a few laughs.
>

At the end of the day, people are not doing EE, they are doing music 
dsp, and the latter includes the principle of "if I do ~this~, what will 
it sound like?" And if the answer is "cool", people do it. There are 
plenty of situations where full math/ee rigour is called for, but also 
plenty of others where people do the dsp equivalent of hardware hacking. 
Converting a real audio signal into quadrature quasi-analytic signal via 
a Hilbert transform, and then deriving a panning trick from that, is a 
mild example. Another slighttly more exotic is splitting up the bins of 
pvoc (FFT-derived) analysis frames into separate groups, and 
resynthesising each group to a separate audio output. Or simply, all odd 
bins to the left, all even bins to the right. Breaks just about every 
dsp/ee rule in the book, but "nobody cares" if it creates a cool sound, 
preferably one where everyone asks "how on earth did they do ~that~?" 
and "where can I buy one?". And, inevitably, "is it patented?".

Richard Dobson

From edward.audiodsp at gmail.com  Wed Feb  8 13:43:42 2012
From: edward.audiodsp at gmail.com (Edward Stein)
Date: Wed, 8 Feb 2012 10:43:42 -0800
Subject: [music-dsp] Multichannel Panning Method
In-Reply-To: <4F310C87.4090905@blitzgamesstudios.com>
References: <4F310C87.4090905@blitzgamesstudios.com>
Message-ID: <CAMkOJ-+q2HyE8=E8rpy4uik+0zzBwWqJYzUxSiajwUm3oQiftw@mail.gmail.com>

Hello Pedro,

I have used both (SPCAP and VBAP/VBIP - an intensity equivalent), they
both have strengths and either would likely do well.

VBAP/VBIP does well to match the expected results for Gerzon vectors
so in many cases that is useful when you are trying to do synthesis
based on some spatial analysis.  The other advantage is discreteness -
VBAP methods inherently use no more than 3 speakers in 3D space to
render any direction.  So you would never get leakage to the opposite
side etc.  However, you have to be careful how you pair or
"triplet-ize" your speakers in 3D space to make sure transitions for
faster moving sources are not significant.  That is not much of an
issue if you know the speaker layout, but if you are trying to
generalize the panner without cases, it can be a challenge to
automatically make good choices.

SPCAP is really good at the generic case because it is not "paired".
The math is straight forward and already generalized for positions
alone.  I think on the whole, it is likely cheaper at run-time unless
you have carefully ordered your VBAP pairs/triplets so that you don't
check the wrong sets as often (say order the checks for the front
pairs first)

The only thing to be aware of is that because it is essentially
virtual microphones, you must control the "pickup" called tightness in
the paper.  Doing so based on the speaker spread (say for the front 3
speakers vs. the back 2 in a 5.1) can improve initial leakage which
helps keep a smoother trajectory.  Otherwise, you might get the sense
the source "sticks" to the wider spaced speakers in an orbit.  If you
adjust the tightness to compensate for that, you actually get fairly
good sounding results and then a tightness modifier can double as a
spatial effect.  Scaling back creates more leakage which eventually
gives more volume or proximity.  In a VBAP/VBIP system you would need
to add a cross-fade with a neutral weighted mix of speakers or pan two
opposite direction sources to achieve similar "effects".

Hope that helps,
Edward



On Tue, Feb 7, 2012 at 3:35 AM, pcorvo <pcorvo at blitzgamesstudios.com> wrote:
> Hello everyone,
>
> Just putting this out there in case anyone has some suggestions. We are
> currently looking at a multichannel panning method for 3D audio, we have
> found a paper that describes the "Speaker-Placement Correction Amplitude
> Panning (SPCAP)" method which seems to be an improvement over the "Vector
> Base Amplitude Panning (VBAP)" method. Has anybody used these before and
> have any suggestions or even other methods worth looking at?
>
> Thank you for your help,
> Pedro
>
> --
> 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 freequencies at gmail.com  Wed Feb  8 14:30:07 2012
From: freequencies at gmail.com (=?ISO-8859-1?B?eOQ=?=)
Date: Wed, 8 Feb 2012 20:30:07 +0100
Subject: [music-dsp] Audio Release >> Pure-data muzik >> G-_-404 dAAX!
	Garage404
Message-ID: <CANLD8kOGbXk75Wk=NZ2SMsG1uXEU3cJA+Gek6Y_yFozf1LQcOw@mail.gmail.com>

/////////////////////////////////////////////////////////////////////////////////////////////////////
G-_-404

>From now you have available, the dAAX! release garage404 that finally
has been released from the HD, after an hibernation year )))


Wanna thanx those who have already support with the
face2face-crowdfunding of the G-_-404 physical release.
Remember that anyway are still availables the last releases for those
who wanna support (despite the download) all the effort of the
handcraftedsoft technologies in Open Source, and at the same time
support the independent and autoedited culture.

Here is the URL:

http://www.noconventions.mobi/x!/rilises/garage404


Enjoy :)

pt?
x!
@txa


||||||||???????????||||||?????||???|||???|||???||??||???|||||||||||||||||||||||?????||||||||||||||???|||||||???|||||||??|||||||||||||||?????????????????????????|||||
||||||||???????????||||||?????||???|||???|||???||??||???|||||||||||||||||||||||?????||||||||||||||???|||||||???|||||||??|||||||||||||||?????????????????????????|||||


Sound Programming::::::: dAAX!

TiTLE:::::::: garage 404

LABEL:::::::: noconventions.mobi

SOURCE::::::: http://noconventions.mobi/x!

GENRE:::::::: 404

LICENSE:::::::: CC BY SA maig 2010

SOFT LICENSE::: GPL v.3 + Pdcore +libraries O.S.License

TRACK LIST ::::::::::::

00___dAAX!____urndedjln! ::::::::::::::::: 2.32
01___dAAX!____d((404))b :::::::::::::::::: 1.31
02___dAAX!____frikkandoo ::::::::::::::::: 2.05
03___dAAX!____luOS ?:::::::::::::::::::::: 2.16
05___dAAX!____((truita404))::::::::::::::: 2.32
08___dAAX!____identitatsguitarreres::::::: 2.37
13___dAAX!____wu404uw :::::::::::::::::::: 1.35
21___dAAX!____dramanbuzi ::::::::::::::::: 3.13
34___dAAX!____pneumatika404 :::::::::::::: 1.23
55___dAAX!____robot404+ :::::::::::::::::: 2.22
89___dAAX!____404atmosferesdeforatdecuc :: 2.12
144__dAAX!____1ss4m::::::::::::::::::::::: 4.14

TOTAL LENGHT :::::::::::::::::::::::::::: 28.36


Programed with Pd visual programming language by dAAX!

Programmed, performed and recorded by x! (x? manzanares)
Record/programming stages > Figueres // Barcelona // Sa? Paulo
cc-by-sa 2010
dAAX! releases available at http://noconventions.mobi/daax
dAAX! physical releases available at http://daax.hotglue.me/G404process

produced by http://noconventions.mobi
noconventions.mobi is a project container that hosts
only 100% DIY FLOSS software under open licenses

((-_-))

||||||||???????????||||||?????||???|||???|||???||??||???|||||||||||||||||||||||?????||||||||||||||???|||||||???|||||||??|||||||||||||||?????????????????????????|||||
||||||||???????????||||||?????||???|||???|||???||??||???|||||||||||||||||||||||?????||||||||||||||???|||||||???|||||||??|||||||||||||||?????????????????????????|||||

From lanceboyle at qwest.net  Wed Feb  8 19:02:40 2012
From: lanceboyle at qwest.net (Jerry)
Date: Wed, 8 Feb 2012 17:02:40 -0700
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F3211BC.3090406@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
Message-ID: <9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>

(Good grief, people.) You want the *very famous* Bauer's Law of Sines:

Benjamin B. Bauer, Phasor Analysis of Some Stereophonic Phenomena, IRE Transactions on Audio, January-February, 1962.

This panning law is mentioned in many introductory books on stereo theory.

Here it is, quoting from the paper:

Sin theta_I   (S_l - S_r)
----------- = -----------
Sin theta_A   (S_l + S_r)

where

theta_I is the azimuth angle of the virtual image, and 
theta_A is the azimuth angleof the real sources.
S_l and S_r, are the strengths of the signals applied
to the left and right loudspeakers, respectively.

This we call the ?stereophonic law of sines,? and it 
shows that through appropriate distribution of in-phase 
signals to the loudspeakers, the position of the virtual 
image for the centrally placed observer may be adjusted 
anywhere relative to the loudspeaker.

End of quote.

The angles are "half-angles" relative to the listeners nose, i.e., for loudspeakers at +/- 30 degrees, theta_A = 30 degrees.

This four-page paper is recommended reading for everyone. 8^)

This panning law agrees exactly with the panning described by HRTF methods at the low frequency limit (and only there).

Jerry


On Feb 7, 2012, at 11:10 PM, Ross Bencina wrote:

> Thanks for the responses,
> 
> Seems like I may have asked the wrong question.
> 
> Ralph Glasgal wrote:
> > There is no valid psychoacoustic method to accomplish this and so
> > there can be no valid pan laws to accomplish this.
> 
> In this instance I'm not really concerned with psychoacoustics. What I need is something that gives a sensible result under the assumption that I want to send some anti-phase in the opposite speaker. "Sensible" could be defined as "perceptually smooth", or "energy smooth".
> 
> Ambisonics uses anti-phase panning. What if we assume that the speakers are on either side of the head. Does that give a valid physical basis for stereo anti-phase panning?
> 
> As I already said, I realise that it's a somewhat dubious idea -- I'm not looking for criticisms of that. I'm working on a simple extension of an existing effect algorithm (a somewhat well known stereo chorus) that uses this inverse phase business to "pan" the chorused voices -- and I want to limit my algorithm to that.
> 
> What I'm aiming to achieve is one slider that can pan each voice between from left to right, and also smoothly cross into dubious "beyond the speakerness" by sending inverse phase to the opposite speaker. It could be as simple as ramping up the inverse phase signal but I thought it might be possible to formulate something that has some kind of basis in stereo panning law theory -- not necessarily concerning spatial perception but at least concerning perceived signal energy.
> 
> 
> To get really concrete: at the moment I have two sliders (one for left level and one for right level) and two checkboxes for inverting the phase of each side. This is a most unsatisfactory user interface. I need to get to the point of having a single "pan" or "width" slider.
> 
> 
> Tom's response comes closest:
> 
> On 8/02/2012 12:17 AM, Tom O'Hara wrote:
> > L = ((1+w)L + (1-w)R)/2
> > R = ((1+w)R + (1-w)L)/2
> >
> > 0<=w<=2
> >
> > 0 = mono
> > 1 = normal
> > 2 = full wide
> 
> 
> But it is a stereo image processing formula not a panning formula, and it uses linear ramps (amplitude sums to unity for left and right) so doesn't appear to follow the usual power laws associated with stereo panning.
> 
> I could use a regular panning law for between the speakers and use Tom's linear constant-amplitude extension for beyond the speakers, but somehow increasing the amplitude of the the in-phase speaker to give a unity amplitude sum with the anti-phase speaker doesn't seem right. If anything I would think that the in-phase speaker amplitude should be reduced -- perhaps in a mirror image of the between-the speakers fade curves with the polarity of one side reversed?
> 
> 
> I hope that makes my question clearer.
> 
> Thanks!
> 
> Ross
> 
> 
> On 7/02/2012 9:20 PM, Ross Bencina wrote:
>> Hi Everyone,
>> 
>> Does anyone know if there's a "standard" way to calculate pan laws for
>> stereo-wide panning ?
>> 
>> By "stereo-wide" I mean panning something beyond the speakers by using
>> 180-degree shifted signal in the opposite speaker. For example, for
>> "beyond hard left" you would output full gain signal to the left
>> speaker, and some inverted phase signal to the right speaker.
>> 
>> I know this is a somewhat dubious method but I'm wondering if there are
>> known pan laws that handle this case.
>> 
>> Thank you,
>> 
>> 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
>> 
> --
> 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 decoy at iki.fi  Wed Feb  8 23:27:52 2012
From: decoy at iki.fi (Sampo Syreeni)
Date: Thu, 9 Feb 2012 06:27:52 +0200 (EET)
Subject: [music-dsp] Multichannel Panning Method
In-Reply-To: <4F310C87.4090905@blitzgamesstudios.com>
References: <4F310C87.4090905@blitzgamesstudios.com>
Message-ID: <alpine.DEB.2.00.1202090623230.17089@lakka.kapsi.fi>

On 2012-02-07, pcorvo wrote:

> We are currently looking at a multichannel panning method for 3D 
> audio, we have found a paper that describes the "Speaker-Placement 
> Correction Amplitude Panning (SPCAP)" method which seems to be an 
> improvement over the "Vector Base Amplitude Panning (VBAP)" method.

I'm reasonably sure that anybody interested in spatial audio methods 
should at least visit sursound-list. Sure, many of us are ambisonics 
freaks. But then, many of us are not nor have been -- it isn't as though 
VBAP hasn't been fully dissected on-list, with its inventor being 
present... ;)
-- 
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

From decoy at iki.fi  Wed Feb  8 23:33:38 2012
From: decoy at iki.fi (Sampo Syreeni)
Date: Thu, 9 Feb 2012 06:33:38 +0200 (EET)
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202090631390.17089@lakka.kapsi.fi>

On 2012-02-07, Olli Niemitalo wrote:

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

Pretty much any simple implementation is going to need one. Any higher 
end one in the fully digital domain is going to require a long 
convolution. That is then what Ralph and the folks do. Ralph then does 
it even in a stereo-input-arbitrarily-many-output fashion.
-- 
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

From decoy at iki.fi  Thu Feb  9 00:01:51 2012
From: decoy at iki.fi (Sampo Syreeni)
Date: Thu, 9 Feb 2012 07:01:51 +0200 (EET)
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F3211BC.3090406@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
Message-ID: <alpine.DEB.2.00.1202090635420.17089@lakka.kapsi.fi>

On 2012-02-08, Ross Bencina wrote:

> Ambisonics uses anti-phase panning.

Fully, at the low frequencies, and a controlled amount of it higher up. 
Yes.

> What if we assume that the speakers are on either side of the head.

Then you are assuming something beyond the conventional ambisonic 
decoding theory. Nobody claims that the conventional theory could deal 
with something like that. Ambisonics only starts to work with the 
conventional 2.5-3 transmission channels, against four speakers, in 
general position, around a single listener. (It *can* do more, but 
that's what it's optimized for. The only thing it ever guarantees.)

> Does that give a valid physical basis for stereo anti-phase panning?

Under its assumptions, yes, it does even that. Especially in the lower 
frequencies.

> I'm working on a simple extension of an existing effect algorithm (a 
> somewhat well known stereo chorus) that uses this inverse phase 
> business to "pan" the chorused voices -- and I want to limit my 
> algorithm to that.

Thus, you're working with a narrow-band approximation to a time-bariable 
delay, within a feedback loop?

> What I'm aiming to achieve is one slider that can pan each voice 
> between from left to right, and also smoothly cross into dubious 
> "beyond the speakerness" by sending inverse phase to the opposite 
> speaker.

The simplest ambisonic solution would be to simply pan each voice into 
pantophonic B-format, and then to encode into BHJ. It gives you plenty 
of super stereo, and sometimes even rather plausible side/back sources, 
as far as two channel stereo goes.

> It could be as simple as ramping up the inverse phase signal but I 
> thought it might be possible to formulate something that has some kind 
> of basis in stereo panning law theory -- not necessarily concerning 
> spatial perception but at least concerning perceived signal energy.

UHJ already encapsulates everything "simple" you could hope from a 
panning law. It does require a Hilbert transformer on the way, but 
nothing more.

> To get really concrete: at the moment I have two sliders (one for left 
> level and one for right level) and two checkboxes for inverting the 
> phase of each side. This is a most unsatisfactory user interface. I 
> need to get to the point of having a single "pan" or "width" slider.

Width, it works rather well with ambisonic B-format as well, since the 
most effective "stereo widener" circuit touched only the mid channel of 
a mid/side signal set, in a frequency dependent way. Under ambisonic 
that comes for free, in a more or less optimal fashion, by interpolating 
between the omnidirectional W signal and whichever combination of X and 
Y you need for your directional center. After that, the UHJ encoding 
equations fold your signal set more or less optimally downto both 
superstereo (without decoding) and 360 degree without-height surround 
(BHJ, which translates into pretty good pantophony if you happen to have 
a decoder at hand).

> Tom's response comes closest:
>
> On 8/02/2012 12:17 AM, Tom O'Hara wrote:
>> L = ((1+w)L + (1-w)R)/2
>> R = ((1+w)R + (1-w)L)/2

It may, if you think panning should be stateless. Under ambisonics it 
isn't, and it isn't so for a good reason. At the same time, it's still 
fully LTI, and it couldn't be much besides. Also for a good reason. ;)
-- 
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

From decoy at iki.fi  Thu Feb  9 00:19:57 2012
From: decoy at iki.fi (Sampo Syreeni)
Date: Thu, 9 Feb 2012 07:19:57 +0200 (EET)
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
	<CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202090702380.17089@lakka.kapsi.fi>

On 2012-02-08, Emanuel Landeholm wrote:

> Is this how it's done in Dolby?

In Dolby, the encoder is an analog approximation to a wide-band 90 
degree phase shift. But it's very much an approximation, and it's also 
about approximating a relative shift, not an absolute one. The filters 
go pretty much haywire in the LF and HF, and even in between the 
channels wonder rather far from 0 degree (linear) phase shift, while 
keeping their mutual optimization goal of being 90 degrees out of synch.

The end result is that you can for the most part recover the surround 
signal by subtracting L from R, and the center one by summing the two. 
But the system can never really even approach the ideal quadraphony it 
was based on. Moreover, if it wanted to approach the psychoacoustics it 
was predicated upon with its surround channel, it should have *at least* 
decoded the surround channel back with two opposite Hilbert 
transformers, fed to many different outputs, instead of just 
differencing the channels and feeding them in synch to a lot of 
backwards speakers. But as always, it took 5.1/7.1/Pro Logic II/a couple 
of decades to bring that obvious little thingy to consumer hardware. (If 
you look at Dolby's hardware patents, that's why the decoder for the 
first time mentions the imaginary unit in Pro Logic II.)

And that stuff is still far from optimal with entire soundscapes. At 
best, it can deal with isolated sounds coming from left, center (dialog) 
or right, and then surround. Somewhat with any two combinations of them, 
thanks to statistical a priori assumptions. But no two or three of them, 
meaning it can't really cope with realistic soundscapes with echoes and 
the lot. Ambisonic can, because it doesn't rely on active steering, but 
just lets bleedthrough be bleedthrough, and optimizes against that.

The funny thing about it, then, is that BBC did some blind listening 
tests against one of its earlier versions and its steering derivative. 
That was somewhere in the sixties, I think. The listening tests did show 
that for single, direct sounds the steered derivative was better. But 
for any and *all* realistic soundscapes it was worse, even within the 
same matrix. That was then for a matrix far inferior to how Ambisonics 
UHJ now stands.
-- 
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

From decoy at iki.fi  Thu Feb  9 00:21:43 2012
From: decoy at iki.fi (Sampo Syreeni)
Date: Thu, 9 Feb 2012 07:21:43 +0200 (EET)
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAML4ZX5JAQhYM4M8Ce26pHa=wvpjNM8JAUUWh6aBJqAXe33OJg@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
	<CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
	<CAML4ZX5JAQhYM4M8Ce26pHa=wvpjNM8JAUUWh6aBJqAXe33OJg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202090721090.17089@lakka.kapsi.fi>

On 2012-02-08, Emanuel Landeholm wrote:

>> simple complex rotation
>
> Wait... What did I just write? o_O

You thought it just right. You were just working in the Fourier domain, 
weren't you? ;)
-- 
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

From rossb-lists at audiomulch.com  Thu Feb  9 01:18:34 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Thu, 09 Feb 2012 17:18:34 +1100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
Message-ID: <4F33653A.80305@audiomulch.com>

Hi Jerry,

On 9/02/2012 11:02 AM, Jerry wrote:
> (Good grief, people.) You want the *very famous* Bauer's Law of Sines:
>
> Benjamin B. Bauer, Phasor Analysis of Some Stereophonic Phenomena, IRE Transactions on Audio, January-February, 1962.

If anyone knows where this can be read without forking over $30 bucks to 
an institutional paywall I'd love to hear about it.


> This panning law is mentioned in many introductory books on stereo theory.

Would you care to cite any "introductory books on stereo theory" -- I 
never read one, could be interesting.

And yes, after 20 years out of university (studying music), going and 
getting an EE degree is looking like a serious option.

Thanks

Ross.



> Here it is, quoting from the paper:
>
> Sin theta_I   (S_l - S_r)
> ----------- = -----------
> Sin theta_A   (S_l + S_r)
>
> where
>
> theta_I is the azimuth angle of the virtual image, and
> theta_A is the azimuth angleof the real sources.
> S_l and S_r, are the strengths of the signals applied
> to the left and right loudspeakers, respectively.
>
> This we call the ?stereophonic law of sines,? and it
> shows that through appropriate distribution of in-phase
> signals to the loudspeakers, the position of the virtual
> image for the centrally placed observer may be adjusted
> anywhere relative to the loudspeaker.
>
> End of quote.
>
> The angles are "half-angles" relative to the listeners nose, i.e., for loudspeakers at +/- 30 degrees, theta_A = 30 degrees.
>
> This four-page paper is recommended reading for everyone. 8^)
>
> This panning law agrees exactly with the panning described by HRTF methods at the low frequency limit (and only there).
>
> Jerry
>
>
> On Feb 7, 2012, at 11:10 PM, Ross Bencina wrote:
>
>> Thanks for the responses,
>>
>> Seems like I may have asked the wrong question.
>>
>> Ralph Glasgal wrote:
>>> There is no valid psychoacoustic method to accomplish this and so
>>> there can be no valid pan laws to accomplish this.
>>
>> In this instance I'm not really concerned with psychoacoustics. What I need is something that gives a sensible result under the assumption that I want to send some anti-phase in the opposite speaker. "Sensible" could be defined as "perceptually smooth", or "energy smooth".
>>
>> Ambisonics uses anti-phase panning. What if we assume that the speakers are on either side of the head. Does that give a valid physical basis for stereo anti-phase panning?
>>
>> As I already said, I realise that it's a somewhat dubious idea -- I'm not looking for criticisms of that. I'm working on a simple extension of an existing effect algorithm (a somewhat well known stereo chorus) that uses this inverse phase business to "pan" the chorused voices -- and I want to limit my algorithm to that.
>>
>> What I'm aiming to achieve is one slider that can pan each voice between from left to right, and also smoothly cross into dubious "beyond the speakerness" by sending inverse phase to the opposite speaker. It could be as simple as ramping up the inverse phase signal but I thought it might be possible to formulate something that has some kind of basis in stereo panning law theory -- not necessarily concerning spatial perception but at least concerning perceived signal energy.
>>
>>
>> To get really concrete: at the moment I have two sliders (one for left level and one for right level) and two checkboxes for inverting the phase of each side. This is a most unsatisfactory user interface. I need to get to the point of having a single "pan" or "width" slider.
>>
>>
>> Tom's response comes closest:
>>
>> On 8/02/2012 12:17 AM, Tom O'Hara wrote:
>>> L = ((1+w)L + (1-w)R)/2
>>> R = ((1+w)R + (1-w)L)/2
>>>
>>> 0<=w<=2
>>>
>>> 0 = mono
>>> 1 = normal
>>> 2 = full wide
>>
>>
>> But it is a stereo image processing formula not a panning formula, and it uses linear ramps (amplitude sums to unity for left and right) so doesn't appear to follow the usual power laws associated with stereo panning.
>>
>> I could use a regular panning law for between the speakers and use Tom's linear constant-amplitude extension for beyond the speakers, but somehow increasing the amplitude of the the in-phase speaker to give a unity amplitude sum with the anti-phase speaker doesn't seem right. If anything I would think that the in-phase speaker amplitude should be reduced -- perhaps in a mirror image of the between-the speakers fade curves with the polarity of one side reversed?
>>
>>
>> I hope that makes my question clearer.
>>
>> Thanks!
>>
>> Ross
>>
>>
>> On 7/02/2012 9:20 PM, Ross Bencina wrote:
>>> Hi Everyone,
>>>
>>> Does anyone know if there's a "standard" way to calculate pan laws for
>>> stereo-wide panning ?
>>>
>>> By "stereo-wide" I mean panning something beyond the speakers by using
>>> 180-degree shifted signal in the opposite speaker. For example, for
>>> "beyond hard left" you would output full gain signal to the left
>>> speaker, and some inverted phase signal to the right speaker.
>>>
>>> I know this is a somewhat dubious method but I'm wondering if there are
>>> known pan laws that handle this case.
>>>
>>> Thank you,
>>>
>>> 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
>>>
>> --
>> 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 lanceboyle at qwest.net  Thu Feb  9 02:09:42 2012
From: lanceboyle at qwest.net (Jerry)
Date: Thu, 9 Feb 2012 00:09:42 -0700
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F33653A.80305@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
	<4F33653A.80305@audiomulch.com>
Message-ID: <8474A309-CF67-4FEC-948C-FDC72F727443@qwest.net>


On Feb 8, 2012, at 11:18 PM, Ross Bencina wrote:

> Hi Jerry,
> 
> On 9/02/2012 11:02 AM, Jerry wrote:
>> (Good grief, people.) You want the *very famous* Bauer's Law of Sines:
>> 
>> Benjamin B. Bauer, Phasor Analysis of Some Stereophonic Phenomena, IRE Transactions on Audio, January-February, 1962.
> 
> If anyone knows where this can be read without forking over $30 bucks to an institutional paywall I'd love to hear about it.

Remember libraries? ;-)

Bauer has an identically-titled paper from J. Acoustical Society of America from 1956 but I haven't seen it.
> 
> 
>> This panning law is mentioned in many introductory books on stereo theory.
> 
> Would you care to cite any "introductory books on stereo theory" -- I never read one, could be interesting.

I was thinking of John Eargle's "Sound Recording." Even though he does the "phasor analysis" for an out-of-array phantom image, the book appears to be devoid of equations so the law does not explicitly appear. Check Amazon for this and other books by Eargle.

Jerry
> 
> And yes, after 20 years out of university (studying music), going and getting an EE degree is looking like a serious option.
> 
> Thanks
> 
> Ross.
> 
> 
> 
>> Here it is, quoting from the paper:
>> 
>> Sin theta_I   (S_l - S_r)
>> ----------- = -----------
>> Sin theta_A   (S_l + S_r)
>> 
>> where
>> 
>> theta_I is the azimuth angle of the virtual image, and
>> theta_A is the azimuth angleof the real sources.
>> S_l and S_r, are the strengths of the signals applied
>> to the left and right loudspeakers, respectively.
>> 
>> This we call the ?stereophonic law of sines,? and it
>> shows that through appropriate distribution of in-phase
>> signals to the loudspeakers, the position of the virtual
>> image for the centrally placed observer may be adjusted
>> anywhere relative to the loudspeaker.
>> 
>> End of quote.
>> 
>> The angles are "half-angles" relative to the listeners nose, i.e., for loudspeakers at +/- 30 degrees, theta_A = 30 degrees.
>> 
>> This four-page paper is recommended reading for everyone. 8^)
>> 
>> This panning law agrees exactly with the panning described by HRTF methods at the low frequency limit (and only there).
>> 
>> Jerry
>> 
>> 
>> On Feb 7, 2012, at 11:10 PM, Ross Bencina wrote:
>> 
>>> Thanks for the responses,
>>> 
>>> Seems like I may have asked the wrong question.
>>> 
>>> Ralph Glasgal wrote:
>>>> There is no valid psychoacoustic method to accomplish this and so
>>>> there can be no valid pan laws to accomplish this.
>>> 
>>> In this instance I'm not really concerned with psychoacoustics. What I need is something that gives a sensible result under the assumption that I want to send some anti-phase in the opposite speaker. "Sensible" could be defined as "perceptually smooth", or "energy smooth".
>>> 
>>> Ambisonics uses anti-phase panning. What if we assume that the speakers are on either side of the head. Does that give a valid physical basis for stereo anti-phase panning?
>>> 
>>> As I already said, I realise that it's a somewhat dubious idea -- I'm not looking for criticisms of that. I'm working on a simple extension of an existing effect algorithm (a somewhat well known stereo chorus) that uses this inverse phase business to "pan" the chorused voices -- and I want to limit my algorithm to that.
>>> 
>>> What I'm aiming to achieve is one slider that can pan each voice between from left to right, and also smoothly cross into dubious "beyond the speakerness" by sending inverse phase to the opposite speaker. It could be as simple as ramping up the inverse phase signal but I thought it might be possible to formulate something that has some kind of basis in stereo panning law theory -- not necessarily concerning spatial perception but at least concerning perceived signal energy.
>>> 
>>> 
>>> To get really concrete: at the moment I have two sliders (one for left level and one for right level) and two checkboxes for inverting the phase of each side. This is a most unsatisfactory user interface. I need to get to the point of having a single "pan" or "width" slider.
>>> 
>>> 
>>> Tom's response comes closest:
>>> 
>>> On 8/02/2012 12:17 AM, Tom O'Hara wrote:
>>>> L = ((1+w)L + (1-w)R)/2
>>>> R = ((1+w)R + (1-w)L)/2
>>>> 
>>>> 0<=w<=2
>>>> 
>>>> 0 = mono
>>>> 1 = normal
>>>> 2 = full wide
>>> 
>>> 
>>> But it is a stereo image processing formula not a panning formula, and it uses linear ramps (amplitude sums to unity for left and right) so doesn't appear to follow the usual power laws associated with stereo panning.
>>> 
>>> I could use a regular panning law for between the speakers and use Tom's linear constant-amplitude extension for beyond the speakers, but somehow increasing the amplitude of the the in-phase speaker to give a unity amplitude sum with the anti-phase speaker doesn't seem right. If anything I would think that the in-phase speaker amplitude should be reduced -- perhaps in a mirror image of the between-the speakers fade curves with the polarity of one side reversed?
>>> 
>>> 
>>> I hope that makes my question clearer.
>>> 
>>> Thanks!
>>> 
>>> Ross
>>> 
>>> 
>>> On 7/02/2012 9:20 PM, Ross Bencina wrote:
>>>> Hi Everyone,
>>>> 
>>>> Does anyone know if there's a "standard" way to calculate pan laws for
>>>> stereo-wide panning ?
>>>> 
>>>> By "stereo-wide" I mean panning something beyond the speakers by using
>>>> 180-degree shifted signal in the opposite speaker. For example, for
>>>> "beyond hard left" you would output full gain signal to the left
>>>> speaker, and some inverted phase signal to the right speaker.
>>>> 
>>>> I know this is a somewhat dubious method but I'm wondering if there are
>>>> known pan laws that handle this case.
>>>> 
>>>> Thank you,
>>>> 
>>>> 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
>>>> 
>>> --
>>> 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 pcorvo at blitzgamesstudios.com  Thu Feb  9 03:51:49 2012
From: pcorvo at blitzgamesstudios.com (pcorvo)
Date: Thu, 09 Feb 2012 08:51:49 +0000
Subject: [music-dsp] Multichannel Panning Method
In-Reply-To: <CAMkOJ-+q2HyE8=E8rpy4uik+0zzBwWqJYzUxSiajwUm3oQiftw@mail.gmail.com>
References: <4F310C87.4090905@blitzgamesstudios.com>
	<CAMkOJ-+q2HyE8=E8rpy4uik+0zzBwWqJYzUxSiajwUm3oQiftw@mail.gmail.com>
Message-ID: <4F338925.5010102@blitzgamesstudios.com>

Hi Edward,

Thank you so much for your answer, it makes a lot of sense. We've just 
got something working with the SPCAP method and it looks promising. I'll 
investigate further and post the results.

Thanks again,
Pedro

On 08/02/2012 18:43, Edward Stein wrote:
> Hello Pedro,
>
> I have used both (SPCAP and VBAP/VBIP - an intensity equivalent), they
> both have strengths and either would likely do well.
>
> VBAP/VBIP does well to match the expected results for Gerzon vectors
> so in many cases that is useful when you are trying to do synthesis
> based on some spatial analysis.  The other advantage is discreteness -
> VBAP methods inherently use no more than 3 speakers in 3D space to
> render any direction.  So you would never get leakage to the opposite
> side etc.  However, you have to be careful how you pair or
> "triplet-ize" your speakers in 3D space to make sure transitions for
> faster moving sources are not significant.  That is not much of an
> issue if you know the speaker layout, but if you are trying to
> generalize the panner without cases, it can be a challenge to
> automatically make good choices.
>
> SPCAP is really good at the generic case because it is not "paired".
> The math is straight forward and already generalized for positions
> alone.  I think on the whole, it is likely cheaper at run-time unless
> you have carefully ordered your VBAP pairs/triplets so that you don't
> check the wrong sets as often (say order the checks for the front
> pairs first)
>
> The only thing to be aware of is that because it is essentially
> virtual microphones, you must control the "pickup" called tightness in
> the paper.  Doing so based on the speaker spread (say for the front 3
> speakers vs. the back 2 in a 5.1) can improve initial leakage which
> helps keep a smoother trajectory.  Otherwise, you might get the sense
> the source "sticks" to the wider spaced speakers in an orbit.  If you
> adjust the tightness to compensate for that, you actually get fairly
> good sounding results and then a tightness modifier can double as a
> spatial effect.  Scaling back creates more leakage which eventually
> gives more volume or proximity.  In a VBAP/VBIP system you would need
> to add a cross-fade with a neutral weighted mix of speakers or pan two
> opposite direction sources to achieve similar "effects".
>
> Hope that helps,
> Edward
>
>
>
> On Tue, Feb 7, 2012 at 3:35 AM, pcorvo<pcorvo at blitzgamesstudios.com>  wrote:
>> Hello everyone,
>>
>> Just putting this out there in case anyone has some suggestions. We are
>> currently looking at a multichannel panning method for 3D audio, we have
>> found a paper that describes the "Speaker-Placement Correction Amplitude
>> Panning (SPCAP)" method which seems to be an improvement over the "Vector
>> Base Amplitude Panning (VBAP)" method. Has anybody used these before and
>> have any suggestions or even other methods worth looking at?
>>
>> Thank you for your help,
>> Pedro
>>
>> --
>> 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 pcorvo at blitzgamesstudios.com  Thu Feb  9 03:53:43 2012
From: pcorvo at blitzgamesstudios.com (pcorvo)
Date: Thu, 09 Feb 2012 08:53:43 +0000
Subject: [music-dsp] Multichannel Panning Method
In-Reply-To: <alpine.DEB.2.00.1202090623230.17089@lakka.kapsi.fi>
References: <4F310C87.4090905@blitzgamesstudios.com>
	<alpine.DEB.2.00.1202090623230.17089@lakka.kapsi.fi>
Message-ID: <4F338997.5070704@blitzgamesstudios.com>

Ah cool, I didn't know of the existence of such list. I'll take a look :)

Thank you,
Pedro

On 09/02/2012 04:27, Sampo Syreeni wrote:
> On 2012-02-07, pcorvo wrote:
>
>> We are currently looking at a multichannel panning method for 3D 
>> audio, we have found a paper that describes the "Speaker-Placement 
>> Correction Amplitude Panning (SPCAP)" method which seems to be an 
>> improvement over the "Vector Base Amplitude Panning (VBAP)" method.
>
> I'm reasonably sure that anybody interested in spatial audio methods 
> should at least visit sursound-list. Sure, many of us are ambisonics 
> freaks. But then, many of us are not nor have been -- it isn't as 
> though VBAP hasn't been fully dissected on-list, with its inventor 
> being present... ;)


From emanuel.landeholm at gmail.com  Thu Feb  9 04:24:25 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Thu, 9 Feb 2012 10:24:25 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <alpine.DEB.2.00.1202090721090.17089@lakka.kapsi.fi>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
	<CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
	<CAML4ZX5JAQhYM4M8Ce26pHa=wvpjNM8JAUUWh6aBJqAXe33OJg@mail.gmail.com>
	<alpine.DEB.2.00.1202090721090.17089@lakka.kapsi.fi>
Message-ID: <CAML4ZX67mVGJ8M1sfuhWcjDC=_yZM1Wz9M9Lmw-_cxxyO02t9g@mail.gmail.com>

On Thu, Feb 9, 2012 at 6:21 AM, Sampo Syreeni <decoy at iki.fi> wrote:
> On 2012-02-08, Emanuel Landeholm wrote:
>
>>> simple complex rotation
>>
>>
>> Wait... What did I just write? o_O
>
>
> You thought it just right. You were just working in the Fourier domain,
> weren't you? ;)

I was just reacting to the oxymoronic juxtaposition of two blatant
opposites. And no.. I wasn't thinking in the Fourier domain. It's a
complex rotation in time domain analytic signal. Pseudo notation: [ L
R ] ^ T = [[ complex rotation plus phase offset ]] HilbertTransform{ x
} ^ T

From glasgal at ambiophonics.org  Thu Feb  9 11:08:32 2012
From: glasgal at ambiophonics.org (Ralph Glasgal)
Date: Thu, 9 Feb 2012 11:08:32 -0500
Subject: [music-dsp] stereo-wide pan law?
Message-ID: <000501cce745$1322cff0$39686fd0$@org>

Ross, There is an .amh file that allows you to do what you want rather
easily.  Go to ambiophonics.org/PCMac.html and scroll down, way down, to see
the contraptions used and how to set their controls to get what you want.
The key element is your ping pong gizmo.  Basically you feed in say a left
only signal and you get out a left and right signal pair that when played
through two speakers in front separated by 60 degrees, or hopefully less,
will produce an image at the far side well beyond the speakers.  If it comes
out too far to the side then feed the same signal attenuated by say 8 dB to
the right input and see if this produces the angle you want and so on.  If
you want motion you can get if smoothly from far left to far right just by
using an input balance control after your soundinput contraption.

It does work more reliably if you can move the monitors closer together, but
you don't seem to want the absolute ultimate  in this sort of thing.

This method of pan potting is recursive and so does not have the side
effects of a onetime polarity reversal.  Remember that in some of the
methods proposed so far in this thread, the out of polarity signal is loud
enough to reach the wrong ear with little attenuation and this dilutes the
wide image effect and makes it unstable.  You may remember when Robin Miller
contacted you about doing this years ago.

Ambisonics was mentioned in an earlier post.  Ambiophonics has nothing to do
with Ambisonics (or Wavefield Synthesis) except that they are both what I
term "loudspeaker binaural" paradigms.  Ambiophonics has the advantage over
these others in that it only requires two speakers for a full width front
stage and can play any 2.0 data file including the existing library of LPs
and CDs.  4 speakers gets you a full circle of direct sound.  You should all
hear Avatar this way.

Ralph Glasgal


From gsn10 at hotmail.com  Thu Feb  9 11:43:03 2012
From: gsn10 at hotmail.com (Scott Nordlund)
Date: Thu, 9 Feb 2012 11:43:03 -0500
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <mailman.336.1328681418.148.music-dsp@music.columbia.edu>
References: <mailman.336.1328681418.148.music-dsp@music.columbia.edu>
Message-ID: <SNT104-W58F13AC290641AD75294E9B47B0@phx.gbl>


> Ross Bencina wrote:
>
> In this instance I'm not really concerned with psychoacoustics. What I
> need is something that gives a sensible result under the assumption that
> I want to send some anti-phase in the opposite speaker. "Sensible" could
> be defined as "perceptually smooth", or "energy smooth".
>
> As I already said, I realise that it's a somewhat dubious idea -- I'm
> not looking for criticisms of that. I'm working on a simple extension of
> an existing effect algorithm (a somewhat well known stereo chorus) that
> uses this inverse phase business to "pan" the chorused voices -- and I
> want to limit my algorithm to that.
?I know a lot of sophisticated ideas have been suggested already, but if you just use a first order all pass filter and smoothly adjust the coefficient between -1 and 1, you can smoothly interpolate between an inverted and non inverted signal (with a 1 sample delay in the middle). If your goal is just to "do something interesting", that might get you somewhere.? 		 	   		  

From rossb-lists at audiomulch.com  Fri Feb 10 01:48:04 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Fri, 10 Feb 2012 17:48:04 +1100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
Message-ID: <4F34BDA4.8080503@audiomulch.com>



On 9/02/2012 11:02 AM, Jerry wrote:
> (Good grief, people.) You want the *very famous* Bauer's Law of Sines:
>
> Benjamin B. Bauer, Phasor Analysis of Some Stereophonic Phenomena, IRE Transactions on Audio, January-February, 1962.
>
> This panning law is mentioned in many introductory books on stereo theory.
>
> Here it is, quoting from the paper:
>
> Sin theta_I   (S_l - S_r)
> ----------- = -----------
> Sin theta_A   (S_l + S_r)
>
> where
>
> theta_I is the azimuth angle of the virtual image, and
> theta_A is the azimuth angleof the real sources.
> S_l and S_r, are the strengths of the signals applied
> to the left and right loudspeakers, respectively.
>
> This we call the ?stereophonic law of sines,? and it
> shows that through appropriate distribution of in-phase
> signals to the loudspeakers, the position of the virtual
> image for the centrally placed observer may be adjusted
> anywhere relative to the loudspeaker.
>
> End of quote.
>
> The angles are "half-angles" relative to the listeners nose, i.e., for loudspeakers at +/- 30 degrees, theta_A = 30 degrees.
>
> This four-page paper is recommended reading for everyone. 8^)
>
> This panning law agrees exactly with the panning described by HRTF methods at the low frequency limit (and only there).


Just wanted to write again and say thanks for this Jerry. It is indeed 
what I was looking for.

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

For my case I set the speaker angle very narrow (7.5 degrees) so that I 
can get extreme-antiphase gain out of the equations. Then I warped 
theta_I by ^4 so that 50% of my panning range pans between the speakers 
and the outer 25% on each end of the panning range moves into the 
with-antiphase region.

Thanks for everyone elses comments. Clearly there's plenty of scope to 
go beyond this.

Best wishes,

Ross.






From o at iki.fi  Fri Feb 10 09:23:06 2012
From: o at iki.fi (Olli Niemitalo)
Date: Fri, 10 Feb 2012 16:23:06 +0200
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F34BDA4.8080503@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
	<4F34BDA4.8080503@audiomulch.com>
Message-ID: <CAAKWUFGe8rs1Xn3f5fgqXh3qMJi0MNjnHe6mu_-pppM0s-Aosg@mail.gmail.com>

On Fri, Feb 10, 2012 at 8:48 AM, Ross Bencina
<rossb-lists at audiomulch.com> wrote:
>
> On 9/02/2012 11:02 AM, Jerry wrote:
>>
>> (Good grief, people.) You want the *very famous* Bauer's Law of Sines:
...
>> Sin theta_I ? (S_l - S_r)
>> ----------- = -----------
>> Sin theta_A ? (S_l + S_r)
>
> Solving for S_l^2 + S_r^2 = 1 it seems to work very well for my needs. It
> doesn't suffer from the dip in level in the middle which Olli's previous
> solution did.
>
> For my case I set the speaker angle very narrow (7.5 degrees) so that I can
> get extreme-antiphase gain out of the equations.

Got something like this?

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

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

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

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

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

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

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

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

-olli

From lanceboyle at qwest.net  Fri Feb 10 22:27:23 2012
From: lanceboyle at qwest.net (Jerry)
Date: Fri, 10 Feb 2012 20:27:23 -0700
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F34BDA4.8080503@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
	<4F34BDA4.8080503@audiomulch.com>
Message-ID: <16CDA044-A716-47FF-BC8C-70A5CBF9959B@qwest.net>


On Feb 9, 2012, at 11:48 PM, Ross Bencina wrote:

> 
> 
> On 9/02/2012 11:02 AM, Jerry wrote:
>> (Good grief, people.) You want the *very famous* Bauer's Law of Sines:
>> 
>> Benjamin B. Bauer, Phasor Analysis of Some Stereophonic Phenomena, IRE Transactions on Audio, January-February, 1962.
>> 
>> This panning law is mentioned in many introductory books on stereo theory.
>> 
>> Here it is, quoting from the paper:
>> 
>> Sin theta_I   (S_l - S_r)
>> ----------- = -----------
>> Sin theta_A   (S_l + S_r)
>> 
>> where
>> 
>> theta_I is the azimuth angle of the virtual image, and
>> theta_A is the azimuth angleof the real sources.
>> S_l and S_r, are the strengths of the signals applied
>> to the left and right loudspeakers, respectively.
>> 
>> This we call the ?stereophonic law of sines,? and it
>> shows that through appropriate distribution of in-phase
>> signals to the loudspeakers, the position of the virtual
>> image for the centrally placed observer may be adjusted
>> anywhere relative to the loudspeaker.
>> 
>> End of quote.
>> 
>> The angles are "half-angles" relative to the listeners nose, i.e., for loudspeakers at +/- 30 degrees, theta_A = 30 degrees.
>> 
>> This four-page paper is recommended reading for everyone. 8^)
>> 
>> This panning law agrees exactly with the panning described by HRTF methods at the low frequency limit (and only there).
> 
> 
> Just wanted to write again and say thanks for this Jerry. It is indeed what I was looking for.
> 
> Solving for S_l^2 + S_r^2 = 1 it seems to work very well for my needs. It doesn't suffer from the dip in level in the middle which Olli's previous solution did.
> 
> For my case I set the speaker angle very narrow (7.5 degrees) so that I can get extreme-antiphase gain out of the equations. Then I warped theta_I by ^4 so that 50% of my panning range pans between the speakers and the outer 25% on each end of the panning range moves into the with-antiphase region.
> 
> Thanks for everyone elses comments. Clearly there's plenty of scope to go beyond this.
> 
> Best wishes,
> 
> Ross.

Glad to help. With your set-up, if you try to put a loud low frequency signal well outside the loudspeaker array, you will notice that your speakers and/or amplifiers will have melted. To the extent that sin(theta_A) = theta_A (small-angle approximation), for every halving that you reduce the loudspeaker spacing, there is a doubling of low frequency amplitude requirements for images at 90 degrees. There is a cure for this--let me know if this situation bites you. (Also, for every halving of loudspeaker angle, there is an octave added to the frequency range over which the widening works.)

Jerry
> 
> 
> 
> 
> 
> --
> 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 rossb-lists at audiomulch.com  Sat Feb 11 03:00:13 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sat, 11 Feb 2012 19:00:13 +1100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <16CDA044-A716-47FF-BC8C-70A5CBF9959B@qwest.net>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
	<4F34BDA4.8080503@audiomulch.com>
	<16CDA044-A716-47FF-BC8C-70A5CBF9959B@qwest.net>
Message-ID: <4F36200D.50109@audiomulch.com>



On 11/02/2012 2:27 PM, Jerry wrote:
> Glad to help. With your set-up, if you try to put a loud low frequency signal well outside the loudspeaker array, you will notice that your speakers and/or amplifiers will have melted. To the extent that sin(theta_A) = theta_A (small-angle approximation), for every halving that you reduce the loudspeaker spacing, there is a doubling of low frequency amplitude requirements for images at 90 degrees. There is a cure for this--let me know if this situation bites you. (Also, for every halving of loudspeaker angle, there is an octave added to the frequency range over which the widening works.)

Hi Jerry,

I'm not sure I follow you here.

I'm not using ITD, only amplitude (a sum of in-phase and 180-degree 
phase signals). I don't see how this can impact the frequency response. 
Can you give me a clue?

Thanks

Ross.

From decoy at iki.fi  Mon Feb 13 18:11:16 2012
From: decoy at iki.fi (Sampo Syreeni)
Date: Tue, 14 Feb 2012 01:11:16 +0200 (EET)
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAML4ZX67mVGJ8M1sfuhWcjDC=_yZM1Wz9M9Lmw-_cxxyO02t9g@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
	<CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
	<CAML4ZX5JAQhYM4M8Ce26pHa=wvpjNM8JAUUWh6aBJqAXe33OJg@mail.gmail.com>
	<alpine.DEB.2.00.1202090721090.17089@lakka.kapsi.fi>
	<CAML4ZX67mVGJ8M1sfuhWcjDC=_yZM1Wz9M9Lmw-_cxxyO02t9g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1202140105200.19007@lakka.kapsi.fi>

On 2012-02-09, Emanuel Landeholm wrote:

> I was just reacting to the oxymoronic juxtaposition of two blatant 
> opposites. And no.. I wasn't thinking in the Fourier domain. It's a 
> complex rotation in time domain analytic signal.

That is then equivalent to a *very* narrow band complex multiplication 
in the Fourier domain (by how the usual complex-differential operator 
translates into it; take it in the tempered distribution sense as well, 
since that seems to work the best for DSP in my mind).


> Pseudo notation: [ L R ] ^ T = [[ complex rotation plus phase offset 
> ]] HilbertTransform{ x } ^ T

You just took a Hilbert transform. In full generality that is the 
prototypical singular integral operator which most surely takes you to 
the realm of the dual, and the Fourier/Laplace. ;)
-- 
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

From emanuel.landeholm at gmail.com  Mon Feb 13 20:24:31 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Tue, 14 Feb 2012 02:24:31 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <alpine.DEB.2.00.1202140105200.19007@lakka.kapsi.fi>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
	<CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
	<CAML4ZX5JAQhYM4M8Ce26pHa=wvpjNM8JAUUWh6aBJqAXe33OJg@mail.gmail.com>
	<alpine.DEB.2.00.1202090721090.17089@lakka.kapsi.fi>
	<CAML4ZX67mVGJ8M1sfuhWcjDC=_yZM1Wz9M9Lmw-_cxxyO02t9g@mail.gmail.com>
	<alpine.DEB.2.00.1202140105200.19007@lakka.kapsi.fi>
Message-ID: <CAML4ZX6fX9TPmUb02twZX3M0fN-GcM9kTntR9U3qRgGLbRyLsw@mail.gmail.com>

On Tue, Feb 14, 2012 at 12:11 AM, Sampo Syreeni <decoy at iki.fi> wrote:
> On 2012-02-09, Emanuel Landeholm wrote:
>
>> I was just reacting to the oxymoronic juxtaposition of two blatant
>> opposites. And no.. I wasn't thinking in the Fourier domain. It's a complex
>> rotation in time domain analytic signal.
>
>
> That is then equivalent to a *very* narrow band complex multiplication in
> the Fourier domain (by how the usual complex-differential operator
> translates into it; take it in the tempered distribution sense as well,
> since that seems to work the best for DSP in my mind).

Sorry, the grey stuff fails me here... Just how is a time domain
complex multiplication equivalent to a frequency domain ditto? In the
dual we are doing convolution, no? Or are you saying that narrow band
convolution is asymptotically a multiplication? Help me out here, I'm
all out of coffee.

>> Pseudo notation: [ L R ] ^ T = [[ complex rotation plus phase offset ]]
>> HilbertTransform{ x } ^ T
>
>
> You just took a Hilbert transform. In full generality that is the
> prototypical singular integral operator which most surely takes you to the
> realm of the dual, and the Fourier/Laplace. ;)

Hey, don't let "transform" deceive you! The HT is domain preserving.
It even says so on the glorified wikiopedia page.

quoth WP:

"In mathematics and in signal processing, the Hilbert transform is a
linear operator which takes a function, u(t), and produces a function,
H(u(t)), with the same domain."

cheers,
Emanuel

From joren.six at hogent.be  Tue Feb 14 10:12:48 2012
From: joren.six at hogent.be (Joren Six)
Date: Tue, 14 Feb 2012 16:12:48 +0100
Subject: [music-dsp] TarsosDSP, a small Java audio processing library
Message-ID: <4F3A79F0.901@hogent.be>

Greetings List,

With this mail I would like to inform you of a DSP library I am 
developing using Java.

TarsosDSP is a collection of classes to do simple audio processing. It 
features an implementation of a percussion onset detector and two pitch 
detection algorithms. Also included is the Goertzel DTMF decoding 
algorithm and an audio time stretch algorithm (WSOLA). Its aim is to 
provide a simple interface to some audio (signal) processing algorithms 
implemented in pure Java. The source code is available on github.

https://github.com/JorenSix/TarsosDSP/

Some example applications, developed using the library, are available here:

http://tarsos.0110.be/tag/TarsosDSP

It might be interesting for some to browse through the code.

Feedback, bug reports, suggestions or assistance are always welcome.

Regards

Joren







From emanuel.landeholm at gmail.com  Tue Feb 14 17:49:34 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Tue, 14 Feb 2012 23:49:34 +0100
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <CAML4ZX6fX9TPmUb02twZX3M0fN-GcM9kTntR9U3qRgGLbRyLsw@mail.gmail.com>
References: <4F30FB05.6000802@audiomulch.com>
	<CAAKWUFGPH_kHY8QP4T0L6_JipYze66QsZNps73yveejx6Z+Ykw@mail.gmail.com>
	<CAML4ZX7kf6d6TMVjVSBViJDcq7ZABRshyYGpVzcNiG7TUPEMkw@mail.gmail.com>
	<CAML4ZX5JAQhYM4M8Ce26pHa=wvpjNM8JAUUWh6aBJqAXe33OJg@mail.gmail.com>
	<alpine.DEB.2.00.1202090721090.17089@lakka.kapsi.fi>
	<CAML4ZX67mVGJ8M1sfuhWcjDC=_yZM1Wz9M9Lmw-_cxxyO02t9g@mail.gmail.com>
	<alpine.DEB.2.00.1202140105200.19007@lakka.kapsi.fi>
	<CAML4ZX6fX9TPmUb02twZX3M0fN-GcM9kTntR9U3qRgGLbRyLsw@mail.gmail.com>
Message-ID: <CAML4ZX5ZLAmQtG9B0ty9jpQrsF8_1mFfbEX1q6aNf+d+VOzqyQ@mail.gmail.com>

Mr Syreeni, this is like the worst cliff hanger for me. Please sort
this out asap!

On Tue, Feb 14, 2012 at 2:24 AM, Emanuel Landeholm
<emanuel.landeholm at gmail.com> wrote:
> On Tue, Feb 14, 2012 at 12:11 AM, Sampo Syreeni <decoy at iki.fi> wrote:
>> On 2012-02-09, Emanuel Landeholm wrote:
>>
>>> I was just reacting to the oxymoronic juxtaposition of two blatant
>>> opposites. And no.. I wasn't thinking in the Fourier domain. It's a complex
>>> rotation in time domain analytic signal.
>>
>>
>> That is then equivalent to a *very* narrow band complex multiplication in
>> the Fourier domain (by how the usual complex-differential operator
>> translates into it; take it in the tempered distribution sense as well,
>> since that seems to work the best for DSP in my mind).
>
> Sorry, the grey stuff fails me here... Just how is a time domain
> complex multiplication equivalent to a frequency domain ditto? In the
> dual we are doing convolution, no? Or are you saying that narrow band
> convolution is asymptotically a multiplication? Help me out here, I'm
> all out of coffee.
>
>>> Pseudo notation: [ L R ] ^ T = [[ complex rotation plus phase offset ]]
>>> HilbertTransform{ x } ^ T
>>
>>
>> You just took a Hilbert transform. In full generality that is the
>> prototypical singular integral operator which most surely takes you to the
>> realm of the dual, and the Fourier/Laplace. ;)
>
> Hey, don't let "transform" deceive you! The HT is domain preserving.
> It even says so on the glorified wikiopedia page.
>
> quoth WP:
>
> "In mathematics and in signal processing, the Hilbert transform is a
> linear operator which takes a function, u(t), and produces a function,
> H(u(t)), with the same domain."
>
> cheers,
> Emanuel

From douglas at music.columbia.edu  Wed Feb 15 07:00:00 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Wed, 15 Feb 2012 07:00:00 -0500 (EST)
Subject: [music-dsp] [admin] music-dsp FAQ
Message-ID: <20120215120000.5E5885C0D73D@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 adotsdothmusic at gmail.com  Sat Feb 18 21:55:38 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Sat, 18 Feb 2012 21:55:38 -0500
Subject: [music-dsp] a little about myself
Message-ID: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>

Hey list,

My name is Adam Puckett. I am a totally blind C programmer with an
associates degree in IT and an interest in DSP. I use a program called
Csound to create music, and I also play many instruments: guitar,
piano (sometimes), drums, bass, accordion, and violin. (I played
trumpet in high school, but I usually don't count that as I wasn't
very good at it ;)). I enjoy all types of music, including rock, pop
and classical, from country to jazz.

From earlevel at earlevel.com  Mon Feb 20 01:31:57 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Sun, 19 Feb 2012 22:31:57 -0800
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
Message-ID: <39A67D10-6EF8-438B-AD6C-39A8A67BB650@earlevel.com>

Welcome Adam.


On Feb 18, 2012, at 6:55 PM, Adam Puckett wrote:

> Hey list,
> 
> My name is Adam Puckett. I am a totally blind C programmer with an
> associates degree in IT and an interest in DSP. I use a program called
> Csound to create music, and I also play many instruments: guitar,
> piano (sometimes), drums, bass, accordion, and violin. (I played
> trumpet in high school, but I usually don't count that as I wasn't
> very good at it ;)). I enjoy all types of music, including rock, pop
> and classical, from country to jazz.


From douglas at music.columbia.edu  Mon Feb 20 10:28:01 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Mon, 20 Feb 2012 10:28:01 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
Message-ID: <4F426681.2090802@music.columbia.edu>


Hi Adam,

Welcome to the list. It's slow right now, but no doubt it'll flare up 
again soon!

best,
douglas

On 2/18/12 9:55 PM, Adam Puckett wrote:
> Hey list,
>
> My name is Adam Puckett. I am a totally blind C programmer with an
> associates degree in IT and an interest in DSP. I use a program called
> Csound to create music, and I also play many instruments: guitar,
> piano (sometimes), drums, bass, accordion, and violin. (I played
> trumpet in high school, but I usually don't count that as I wasn't
> very good at it ;)). I enjoy all types of music, including rock, pop
> and classical, from country to jazz.
> --
> 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://music.columbia.edu/~douglas


From lanceboyle at qwest.net  Mon Feb 20 17:43:43 2012
From: lanceboyle at qwest.net (Jerry)
Date: Mon, 20 Feb 2012 15:43:43 -0700
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
Message-ID: <1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>

Hi Adam,

Please forgive my ignorance, but being blind, how are you able to program?

Jerry

On Feb 18, 2012, at 7:55 PM, Adam Puckett wrote:

> Hey list,
> 
> My name is Adam Puckett. I am a totally blind C programmer with an
> associates degree in IT and an interest in DSP. I use a program called
> Csound to create music, and I also play many instruments: guitar,
> piano (sometimes), drums, bass, accordion, and violin. (I played
> trumpet in high school, but I usually don't count that as I wasn't
> very good at it ;)). I enjoy all types of music, including rock, pop
> and classical, from country to jazz.


From emanuel.landeholm at gmail.com  Mon Feb 20 18:05:32 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Tue, 21 Feb 2012 00:05:32 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
Message-ID: <CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>

Adam,

I am also curious as to how you interface with a development
environment. Moreover, what are you working on? Also, wasn't there a
blind contributor around a few years ago? Your name does not ring a
bell for me, so I can only guess that you are number two (minimum)!

Also, isn't this a golden opportunity for all of us to introduce themselves?

Anyway, my name is Emanuel. I'm a computer programmer from Sweden who
loves pre-post-doc math (because post-doc math is way over my tiny
head). I am also a web developer, so the Linux/Apache/Mysql/PHP stack
is what brings lunch to my table (you like fries with that?). I'm a
very occasional contributor to the list. My post are infrequent,
random and intuitive, and for the most part safe to ignore. I do
however read every word posted to the list. music-dsp for me
represents the intersection of my love for electronic music (Cabaret
Voltaire, Kraftwerk, Aphex Twin..) and vector space formalisms.

cheers,
Emanuel

On Mon, Feb 20, 2012 at 11:43 PM, Jerry <lanceboyle at qwest.net> wrote:
> Hi Adam,
>
> Please forgive my ignorance, but being blind, how are you able to program?
>
> Jerry

From adotsdothmusic at gmail.com  Mon Feb 20 19:43:26 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Mon, 20 Feb 2012 19:43:26 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
Message-ID: <CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>

Jerry and Emanuel,

I program using a text editor, Notepad++, a screen reader (NVDA), and
a compiler suite for Windows (MinGW). I have had trouble with IDEs in
the past when I first (academically) started learning programming in
Java with Eclipse, so to this day Notepad++ is my preferred editor (my
teacher has called me a "masochist" twice because of this, jokingly of
course!).

As for Web development, I am interested in all aspects of it, from
server construction (I am planning to build a server for an online
music store selling my compositions) to scripting dynamic content
(more accurately "programming" as the dynamic content will be embedded
therein). As my second programming assignment printed, "Programming is
great fun!"

As a newby to DSP, I have checked out the musicdsp.org archive, and it
has been a great resource for DSP before I joined this list. Sadly it
seems the site may be out of date as I've checked the latest archives
Mailman generates and there seems to be some more code in the last
month, but I'm not sure because musicdsp.org/.com doesn't date their
archive entries.

On 2/20/12, Emanuel Landeholm <emanuel.landeholm at gmail.com> wrote:
> Adam,
>
> I am also curious as to how you interface with a development
> environment. Moreover, what are you working on? Also, wasn't there a
> blind contributor around a few years ago? Your name does not ring a
> bell for me, so I can only guess that you are number two (minimum)!
>
> Also, isn't this a golden opportunity for all of us to introduce themselves?
>
> Anyway, my name is Emanuel. I'm a computer programmer from Sweden who
> loves pre-post-doc math (because post-doc math is way over my tiny
> head). I am also a web developer, so the Linux/Apache/Mysql/PHP stack
> is what brings lunch to my table (you like fries with that?). I'm a
> very occasional contributor to the list. My post are infrequent,
> random and intuitive, and for the most part safe to ignore. I do
> however read every word posted to the list. music-dsp for me
> represents the intersection of my love for electronic music (Cabaret
> Voltaire, Kraftwerk, Aphex Twin..) and vector space formalisms.
>
> cheers,
> Emanuel
>
> On Mon, Feb 20, 2012 at 11:43 PM, Jerry <lanceboyle at qwest.net> wrote:
>> Hi Adam,
>>
>> Please forgive my ignorance, but being blind, how are you able to program?
>>
>> Jerry
> --
> 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 lanceboyle at qwest.net  Mon Feb 20 23:26:21 2012
From: lanceboyle at qwest.net (Jerry)
Date: Mon, 20 Feb 2012 21:26:21 -0700
Subject: [music-dsp] stereo-wide pan law?
In-Reply-To: <4F36200D.50109@audiomulch.com>
References: <4F30FB05.6000802@audiomulch.com> <4F3211BC.3090406@audiomulch.com>
	<9B23C5DB-820A-48C1-9388-8C5A40058CCC@qwest.net>
	<4F34BDA4.8080503@audiomulch.com>
	<16CDA044-A716-47FF-BC8C-70A5CBF9959B@qwest.net>
	<4F36200D.50109@audiomulch.com>
Message-ID: <AD7308FA-9C92-47B9-9466-5DE4386DC32A@qwest.net>


On Feb 11, 2012, at 1:00 AM, Ross Bencina wrote:

> 
> 
> On 11/02/2012 2:27 PM, Jerry wrote:
>> Glad to help. With your set-up, if you try to put a loud low frequency signal well outside the loudspeaker array, you will notice that your speakers and/or amplifiers will have melted. To the extent that sin(theta_A) = theta_A (small-angle approximation), for every halving that you reduce the loudspeaker spacing, there is a doubling of low frequency amplitude requirements for images at 90 degrees. There is a cure for this--let me know if this situation bites you. (Also, for every halving of loudspeaker angle, there is an octave added to the frequency range over which the widening works.)
> 
> Hi Jerry,
> 
> I'm not sure I follow you here.
> 
> I'm not using ITD, only amplitude (a sum of in-phase and 180-degree phase signals). I don't see how this can impact the frequency response. Can you give me a clue?
> 
> Thanks
> 
> Ross.

Sure I can give you a clue. (And sorry for the retarded response. ;-)

Here's an answer for your ITD question, although it doesn't seem related to the problem at hand.

You _are_ using ITD (Interaural Time Difference). Don't confuse loudspeaker time difference with ITD. Any sound which seems to be at any angle but 0 or 180 degrees has a non-zero ITD and you've just told me that Bauer is working, so therefore....

Let's constrain our thinking to low frequencies, where the interaural spacing is much less than a wavelength. (The ear spacing is equal to a wavelength at approximately 1 KHz.) With this assumption, we can ignore the head as such and consider only the ear locations as points. If the acoustical spacing of the ears is D and we use the same notation as we used for Bauer's Law of Sines (which has been deleted at this point), then with c the speed of sound, the ITD, using the left ear as the phase reference, is

      (S_l - S_r)   D * sin(theta_A)
ITD = ----------- * ----------------
      (S_l + S_r)          c

I just derived this from scratch (I'm sure its been published somewhere). I don't think I've made a mistake because it is easy to show that when using the Bauer relation the ITD is the same as for a real sound emanating from theta_I.

But I'm not sure why you ask about ITD. Your better question is about frequency response. For the moment, retain the low frequency scenario. Then the sound from one speaker will be delayed relative to the other speaker causing a severe comb filter as a function of frequency. This happens at both ears. If we look at what happens at higher frequencies (and with an actual head in place), the frequency dependence is all over the place, varying by easily 15-20 dB depending on the setting of your pan pot, relative to a real sound source at the angle that you have panned to. Amplitude panners fall apart in this respect above about 600 Hz. To fix this problem, one must use HRTF-based panners. Alternately, I am told that mixing people sometimes dial in an ad hoc EQ which can ameliorate the problem.

However, this still doesn't (quite) get to what I think you want to ask about, which is why the increased amplitude requirements when panning a low frequency sound far to the side. Consider that the speakers are acoustically close together, as they are at low frequencies. To make the phantom image far to the side, you are instructing the woofer cones to move in opposite directions at all times. (Look at the panning law.) Sources operating in these conditions are nearly cancelling each other out, with first one cone pushing air out while at the same time the other is sucking it in. Only a little bit of the sound actually radiates outwards. This is all in a valiant effort to make the air in the vicinity of your head wiggle left-and-right. The closer the speakers, the more cancellation. Looked at this way, it all makes sense, doesn't it?

HTH,
Jerry

From lanceboyle at qwest.net  Mon Feb 20 23:34:32 2012
From: lanceboyle at qwest.net (Jerry)
Date: Mon, 20 Feb 2012 21:34:32 -0700
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
Message-ID: <2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>


On Feb 20, 2012, at 5:43 PM, Adam Puckett wrote:

> Jerry and Emanuel,
> 
> I program using a text editor, Notepad++, a screen reader (NVDA), and

I didn't know about this. Pretty cool.
http://www.nvda-project.org/

The video there didn't seem to show or mention Braille. I gather there is some kind of Braille output device.

Jerry

From adotsdothmusic at gmail.com  Tue Feb 21 06:09:09 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Tue, 21 Feb 2012 06:09:09 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
Message-ID: <CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>

Yes, I have a Focus 40 Braille display. They are made by Freedom
Scientific, who also makes a screen reading product called JAWS. I use
a combination of speech and Braille to ensure speedy code reading so I
can get an idea of the algorithms or messages.

On 2/20/12, Jerry <lanceboyle at qwest.net> wrote:
>
> On Feb 20, 2012, at 5:43 PM, Adam Puckett wrote:
>
>> Jerry and Emanuel,
>>
>> I program using a text editor, Notepad++, a screen reader (NVDA), and
>
> I didn't know about this. Pretty cool.
> http://www.nvda-project.org/
>
> The video there didn't seem to show or mention Braille. I gather there is
> some kind of Braille output device.
>
> Jerry
> --
> 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  Tue Feb 21 09:05:04 2012
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 21 Feb 2012 09:05:04 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
Message-ID: <4F43A490.5030309@audioimagination.com>


you're not related to Miller Puckett, are you?

just curious.


and you're still welcome to the group no matter the answer.

-- 

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




From adotsdothmusic at gmail.com  Tue Feb 21 09:20:52 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Tue, 21 Feb 2012 09:20:52 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F43A490.5030309@audioimagination.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
Message-ID: <CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>

No, I'm not related to Miller Puckette.

On 2/21/12, robert bristow-johnson <rbj at audioimagination.com> wrote:
>
> you're not related to Miller Puckett, are you?
>
> just curious.
>
>
> and you're still welcome to the group no matter the answer.
>
> --
>
> 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 rbj at audioimagination.com  Tue Feb 21 09:24:45 2012
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Tue, 21 Feb 2012 09:24:45 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
Message-ID: <4F43A92D.2070407@audioimagination.com>

On 2/21/12 9:20 AM, Adam Puckett wrote:
> No, I'm not related to Miller Puckette.
>

that's okay.  yer still welcome.

:-)

-- 

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




From adotsdothmusic at gmail.com  Tue Feb 21 09:48:45 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Tue, 21 Feb 2012 09:48:45 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F43A92D.2070407@audioimagination.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
Message-ID: <CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>

Thanks Robert.

On 2/21/12, robert bristow-johnson <rbj at audioimagination.com> wrote:
> On 2/21/12 9:20 AM, Adam Puckett wrote:
>> No, I'm not related to Miller Puckette.
>>
>
> that's okay.  yer still welcome.
>
> :-)
>
> --
>
> 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 emanuel.landeholm at gmail.com  Tue Feb 21 09:54:07 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Tue, 21 Feb 2012 15:54:07 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
Message-ID: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>

But, if you don't mind me asking, what is it that you do music-dsp
wise? Mostly csound stuff?

It's just that the thought of a blind person using csound simply blows
my mind. csound is powerful alright, but most people, blind or not,
can't even hope to install it, much less use it for something..

kind regards,
Emanuel

From didid at skynet.be  Tue Feb 21 10:43:29 2012
From: didid at skynet.be (Didier Dambrin)
Date: Tue, 21 Feb 2012 16:43:29 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com><1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net><CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com><CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com><2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net><CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com><4F43A490.5030309@audioimagination.com><CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com><4F43A92D.2070407@audioimagination.com><CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
Message-ID: <298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>

True, I've never been able to install or figure out CSound, or make it do 
anything.
Watching on YT, I see it can do realtime stuff? I've always thought it was 
all command-line offline stuff (last time I tried in 2007).



-----Message d'origine----- 
From: Emanuel Landeholm
Sent: Tuesday, February 21, 2012 3:54 PM
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] a little about myself

But, if you don't mind me asking, what is it that you do music-dsp
wise? Mostly csound stuff?

It's just that the thought of a blind person using csound simply blows
my mind. csound is powerful alright, but most people, blind or not,
can't even hope to install it, much less use it for something..

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


-----
Aucun virus trouve dans ce message.
Analyse effectuee par AVG - www.avg.fr
Version: 2012.0.1913 / Base de donnees virale: 2113/4822 - Date: 20/02/2012 


From bastian.schnuerle at silberstein.de  Tue Feb 21 11:29:16 2012
From: bastian.schnuerle at silberstein.de (Bastian Schnuerle)
Date: Tue, 21 Feb 2012 17:29:16 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com><1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net><CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com><CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com><2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net><CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com><4F43A490.5030309@audioimagination.com><CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com><4F43A92D.2070407@audioimagination.com><CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
Message-ID: <01DA1DBF-376F-4B0E-ABD1-DD9875B5D9DB@silberstein.de>

hey adam,

yep, that also includes me .. have you ever read "curtis roads - the  
computer music tutorial" ? it was one of my main sources to get my  
degree in ee .. maybe there is a translation to braille or a digital  
version .. it is completely based on csound and i love it ..

cheers,
bastian


Am 21.02.2012 um 16:43 schrieb Didier Dambrin:

> True, I've never been able to install or figure out CSound, or make  
> it do anything.
> Watching on YT, I see it can do realtime stuff? I've always thought  
> it was all command-line offline stuff (last time I tried in 2007).
>
>
>
> -----Message d'origine----- From: Emanuel Landeholm
> Sent: Tuesday, February 21, 2012 3:54 PM
> To: A discussion list for music-related DSP
> Subject: Re: [music-dsp] a little about myself
>
> But, if you don't mind me asking, what is it that you do music-dsp
> wise? Mostly csound stuff?
>
> It's just that the thought of a blind person using csound simply blows
> my mind. csound is powerful alright, but most people, blind or not,
> can't even hope to install it, much less use it for something..
>
> kind regards,
> Emanuel
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book  
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>
>
> -----
> Aucun virus trouve dans ce message.
> Analyse effectuee par AVG - www.avg.fr
> Version: 2012.0.1913 / Base de donnees virale: 2113/4822 - Date:  
> 20/02/2012
> --
> 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 Feb 21 11:06:20 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Tue, 21 Feb 2012 16:06:20 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com><1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net><CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com><CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com><2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net><CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com><4F43A490.5030309@audioimagination.com><CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com><4F43A92D.2070407@audioimagination.com><CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
Message-ID: <4F43C0FC.1070802@blueyonder.co.uk>

On 21/02/2012 15:43, Didier Dambrin wrote:
> True, I've never been able to install or figure out CSound, or make it
> do anything.
> Watching on YT, I see it can do realtime stuff? I've always thought it
> was all command-line offline stuff (last time I tried in 2007).
>

It's been real-time for at least a decade, so was already real-time in 
2007 (much has been added since then), comes with full installers for 
Windows, OS X and Linux, and has a large number of GUI front-ends 
available, many supporting custom controls. Many users are ~only~ using 
it in real-time contexts, whether via MIDI, OSC or Wiimotes, or whatever.

The current version is 5.16, released this month:

http://sourceforge.net/projects/csound/files/csound5/

Richard Dobson

From Victor.Lazzarini at nuim.ie  Tue Feb 21 16:02:48 2012
From: Victor.Lazzarini at nuim.ie (Victor)
Date: Tue, 21 Feb 2012 21:02:48 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F43C0FC.1070802@blueyonder.co.uk>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
Message-ID: <01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>

i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years.


On 21 Feb 2012, at 16:06, Richard Dobson <richarddobson at blueyonder.co.uk> wrote:

> On 21/02/2012 15:43, Didier Dambrin wrote:
>> True, I've never been able to install or figure out CSound, or make it
>> do anything.
>> Watching on YT, I see it can do realtime stuff? I've always thought it
>> was all command-line offline stuff (last time I tried in 2007).
>> 
> 
> It's been real-time for at least a decade, so was already real-time in 2007 (much has been added since then), comes with full installers for Windows, OS X and Linux, and has a large number of GUI front-ends available, many supporting custom controls. Many users are ~only~ using it in real-time contexts, whether via MIDI, OSC or Wiimotes, or whatever.
> 
> The current version is 5.16, released this month:
> 
> http://sourceforge.net/projects/csound/files/csound5/
> 
> Richard Dobson
> --
> 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 emanuel.landeholm at gmail.com  Tue Feb 21 19:53:12 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Wed, 22 Feb 2012 01:53:12 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
Message-ID: <CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>

Well. I need to start using csound. To actually do things in the real
world instead of just solving idle mind puzzles.

On Tue, Feb 21, 2012 at 10:02 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
> i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years.
>

From michael.gogins at gmail.com  Tue Feb 21 21:57:56 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Tue, 21 Feb 2012 21:57:56 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
Message-ID: <CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>

It's very easy to use Csound to solve idle mind puzzles! I think many
of us, certainly myself, find ourselves becoming distracted by the
technical work involved in making computer music, as opposed to the
superficially easier but in reality far more difficult work of
composing.

Regards,
Mike

On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm
<emanuel.landeholm at gmail.com> wrote:
> Well. I need to start using csound. To actually do things in the real
> world instead of just solving idle mind puzzles.
>
> On Tue, Feb 21, 2012 at 10:02 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
>> i have been running csound in realtime since about 1998, which makes it what? about fourteen years, however i remember seeing code for RT audio in the version i picked up from cecelia.media.mit.edu back in 94. So, strictly this capability has been there for the best part of twenty years.
>>
> --
> 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 adotsdothmusic at gmail.com  Wed Feb 22 08:44:56 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Wed, 22 Feb 2012 08:44:56 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
Message-ID: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>

It's nice to see some familiar names in Csound's defense.

Here's something I've considered since learning C: has anyone
(attempted to) compose music in straight C (or C++) just using the
audio APIs? I think that would be quite a challenge. I can see quite a
bit more algorithmic potential there than probably any of the DSLs
written in it.

On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
> It's very easy to use Csound to solve idle mind puzzles! I think many
> of us, certainly myself, find ourselves becoming distracted by the
> technical work involved in making computer music, as opposed to the
> superficially easier but in reality far more difficult work of
> composing.
>
> Regards,
> Mike
>
> On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm
> <emanuel.landeholm at gmail.com> wrote:
>> Well. I need to start using csound. To actually do things in the real
>> world instead of just solving idle mind puzzles.
>>
>> On Tue, Feb 21, 2012 at 10:02 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
>>> i have been running csound in realtime since about 1998, which makes it
>>> what? about fourteen years, however i remember seeing code for RT audio
>>> in the version i picked up from cecelia.media.mit.edu back in 94. So,
>>> strictly this capability has been there for the best part of twenty
>>> years.
>>>
>> --
>> 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
> --
> 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 thomas.young at rebellion.co.uk  Wed Feb 22 09:09:32 2012
From: thomas.young at rebellion.co.uk (Thomas Young)
Date: Wed, 22 Feb 2012 14:09:32 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
Message-ID: <8853712D9129AD45B323A96D5396A084D398E876@oxnexch01.Rebellion.co.uk>

I've tried that before, basically writing a soft synth and a sequencer. I won't pretend I made anything that sounded very good but it was fun. In the demoscene there is a whole field of 'programmed music' which is just this, although generally they use a sequencer for the composition and just code the instruments.

I have to say I've never really seen the appeal of CSound since it seems as complicated as just writing your own code in C/C++, maybe I am missing some great use case for it.

-----Original Message-----
From: music-dsp-bounces at music.columbia.edu [mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Adam Puckett
Sent: 22 February 2012 13:45
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] a little about myself

It's nice to see some familiar names in Csound's defense.

Here's something I've considered since learning C: has anyone
(attempted to) compose music in straight C (or C++) just using the
audio APIs? I think that would be quite a challenge. I can see quite a
bit more algorithmic potential there than probably any of the DSLs
written in it.

On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
> It's very easy to use Csound to solve idle mind puzzles! I think many
> of us, certainly myself, find ourselves becoming distracted by the
> technical work involved in making computer music, as opposed to the
> superficially easier but in reality far more difficult work of
> composing.
>
> Regards,
> Mike
>
> On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm
> <emanuel.landeholm at gmail.com> wrote:
>> Well. I need to start using csound. To actually do things in the real
>> world instead of just solving idle mind puzzles.
>>
>> On Tue, Feb 21, 2012 at 10:02 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
>>> i have been running csound in realtime since about 1998, which makes it
>>> what? about fourteen years, however i remember seeing code for RT audio
>>> in the version i picked up from cecelia.media.mit.edu back in 94. So,
>>> strictly this capability has been there for the best part of twenty
>>> years.
>>>
>> --
>> 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
> --
> 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 padawan12 at obiwannabe.co.uk  Wed Feb 22 09:16:12 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Wed, 22 Feb 2012 14:16:12 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
References: <CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
Message-ID: <20120222141612.GA5723@sapphire.lan>

Speed of development is an issue, as turning ideas into sound uses 
considerable human cognition, echoic memory to listen, serial and 
linguistics faculties to interpret, and then geometric mathematical 
and procedural acrobatics to adapt the internal model. C gives great
flexibility and control, but requires such intense working that an 
idea is often lost before it can be implemented. Compactness is thus 
a desirable quality for music making (with large structures) rather 
than sound programming. For seeing programmers, visual signal flows 
like Pure Data are powerful because the algorithm is maintained as a 
compact diagram. I can understand why Csound is attractive to someone 
without sight, and I wonder if you have also explored Supercollider, 
Chuck and Nyquist, which all represent quite different language 
interfaces to sound making. But as you are a programmer I also wonder, 
if for you Adam, Faust might be something important to explore. For 
one who interprets the world more in symbolic structures it's compactness 
might be something you find very useful. 




On Wed, Feb 22, 2012 at 08:44:56AM -0500, Adam Puckett wrote:
> It's nice to see some familiar names in Csound's defense.
> 
> Here's something I've considered since learning C: has anyone
> (attempted to) compose music in straight C (or C++) just using the
> audio APIs? I think that would be quite a challenge. I can see quite a
> bit more algorithmic potential there than probably any of the DSLs
> written in it.
> 
> On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
> > It's very easy to use Csound to solve idle mind puzzles! I think many
> > of us, certainly myself, find ourselves becoming distracted by the
> > technical work involved in making computer music, as opposed to the
> > superficially easier but in reality far more difficult work of
> > composing.
> >
> > Regards,
> > Mike
> >
> > On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm
> > <emanuel.landeholm at gmail.com> wrote:
> >> Well. I need to start using csound. To actually do things in the real
> >> world instead of just solving idle mind puzzles.
> >>
> >> On Tue, Feb 21, 2012 at 10:02 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
> >>> i have been running csound in realtime since about 1998, which makes it
> >>> what? about fourteen years, however i remember seeing code for RT audio
> >>> in the version i picked up from cecelia.media.mit.edu back in 94. So,
> >>> strictly this capability has been there for the best part of twenty
> >>> years.
> >>>
> >> --
> >> 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
> > --
> > 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  Wed Feb 22 09:18:11 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Wed, 22 Feb 2012 09:18:11 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
Message-ID: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>

I have done this several times and plan to do more.

I got my start in computer music in 1986 or 1987 at the woof group at
Columbia University using cmix on a Sun workstation. cmix has never
had a runtime synthesis language; even now instrument code has to be
written in C++. Score code can be written in a variety of languages
including the built-in minc interpreter, Perl, Python, C, C++, and I
have used Lua. The pieces I made used C++ for both synthesis and score
generation. They were done using a Lindenmayer system to place
complex, recursively generated patterns of phase-aligned grains into a
soundfile.

When I created the CsoundAC class library, which is written in C++, it
was intended to be usable with C++ or with various "wrapper" languges
such as Java, Python, Lisp, or Lua. Nobody maintained the C++
interface, but I am making it usable directly from C++ again. In this
case, Csound is used for synthesis, but actually CsoundAC itself has
some rudimentary facilities for synthesis including a soundfile class
and some granular synthesis classes.

Right now, I am finishing some fixes that need to be done so that I
can compose in C++ using Qt as a toolkit for widgets that I will use
to tweak mastering (final EQ, reverb, and compression) as well as
sensitive instrument parameters (e.g. for STKBowed). In this case
also, Csound is used for synthesis but the orchestra code is
completely embedded in the C++ program. I will probably also embed
plugin opcodes written in C++ in the program and register them with
Csound just before compiling the orchestra. These plugins will not
actually be external DLLs, they will be routines in the main
composition program which will register them with Csound.

Ideally, I would like to write entire instrument definitions in C++
embedded in the program. Then Csound would serve as an engine and a
framework that would manage scheduling, voice allocation, and all
input and output. These are the hard parts of music programming. I
would manage all the score generation and sound synthesis in C++.

I am writing an article about composing in C++ with the Csound API and
CsoundAC, and I will try to get it published in the Csound Journal or
elsewhere.

All these techniques work with command-line programs as well as with GUIs.

Regards,
Mike

On Wed, Feb 22, 2012 at 8:44 AM, Adam Puckett <adotsdothmusic at gmail.com> wrote:
> It's nice to see some familiar names in Csound's defense.
>
> Here's something I've considered since learning C: has anyone
> (attempted to) compose music in straight C (or C++) just using the
> audio APIs? I think that would be quite a challenge. I can see quite a
> bit more algorithmic potential there than probably any of the DSLs
> written in it.
>
> On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
>> It's very easy to use Csound to solve idle mind puzzles! I think many
>> of us, certainly myself, find ourselves becoming distracted by the
>> technical work involved in making computer music, as opposed to the
>> superficially easier but in reality far more difficult work of
>> composing.
>>
>> Regards,
>> Mike
>>
>> On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm
>> <emanuel.landeholm at gmail.com> wrote:
>>> Well. I need to start using csound. To actually do things in the real
>>> world instead of just solving idle mind puzzles.
>>>
>>> On Tue, Feb 21, 2012 at 10:02 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
>>>> i have been running csound in realtime since about 1998, which makes it
>>>> what? about fourteen years, however i remember seeing code for RT audio
>>>> in the version i picked up from cecelia.media.mit.edu back in 94. So,
>>>> strictly this capability has been there for the best part of twenty
>>>> years.
>>>>
>>> --
>>> 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
>> --
>> 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 douglas at music.columbia.edu  Wed Feb 22 09:20:09 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Wed, 22 Feb 2012 09:20:09 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F44F779.4060402@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
Message-ID: <4F44F999.3080105@music.columbia.edu>


This is driving me nutz:

http://www.google.com


And now an image search for Hertz features lots and lots of pictures of 
a non-sinewave!

Arrg!

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


From gerhard at cs.uregina.ca  Wed Feb 22 09:24:18 2012
From: gerhard at cs.uregina.ca (David Gerhard)
Date: Wed, 22 Feb 2012 08:24:18 -0600
Subject: [music-dsp] music-dsp Digest, Vol 98, Issue 31
In-Reply-To: <mailman.1030.1329920410.148.music-dsp@music.columbia.edu>
References: <mailman.1030.1329920410.148.music-dsp@music.columbia.edu>
Message-ID: <CADx8b-K5pZ_c0PF0X0U8zTKvwmB9yF4Z=Sg=mzof9kR96s-ypQ@mail.gmail.com>

hi all,

I was also bugged by the non-sine so I made a "better" one.  Share and enjoy:

https://www.dropbox.com/gallery/6702856/1/webshare?h=1a7617

On Wed, Feb 22, 2012 at 8:20 AM,  <music-dsp-request at music.columbia.edu> wrote:
> Send music-dsp mailing list submissions to
> ? ? ? ?music-dsp at music.columbia.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> ? ? ? ?http://music.columbia.edu/mailman/listinfo/music-dsp
> or, via email, send a message with subject or body 'help' to
> ? ? ? ?music-dsp-request at music.columbia.edu
>
> You can reach the person managing the list at
> ? ? ? ?music-dsp-owner at music.columbia.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of music-dsp digest..."
>
>
> Today's Topics:
>
> ? 1. Re: a little about myself (Michael Gogins)
> ? 2. google's non-sine (douglas repetto)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 22 Feb 2012 09:18:11 -0500
> From: Michael Gogins <michael.gogins at gmail.com>
> To: A discussion list for music-related DSP
> ? ? ? ?<music-dsp at music.columbia.edu>
> Subject: Re: [music-dsp] a little about myself
> Message-ID:
> ? ? ? ?<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I have done this several times and plan to do more.
>
> I got my start in computer music in 1986 or 1987 at the woof group at
> Columbia University using cmix on a Sun workstation. cmix has never
> had a runtime synthesis language; even now instrument code has to be
> written in C++. Score code can be written in a variety of languages
> including the built-in minc interpreter, Perl, Python, C, C++, and I
> have used Lua. The pieces I made used C++ for both synthesis and score
> generation. They were done using a Lindenmayer system to place
> complex, recursively generated patterns of phase-aligned grains into a
> soundfile.
>
> When I created the CsoundAC class library, which is written in C++, it
> was intended to be usable with C++ or with various "wrapper" languges
> such as Java, Python, Lisp, or Lua. Nobody maintained the C++
> interface, but I am making it usable directly from C++ again. In this
> case, Csound is used for synthesis, but actually CsoundAC itself has
> some rudimentary facilities for synthesis including a soundfile class
> and some granular synthesis classes.
>
> Right now, I am finishing some fixes that need to be done so that I
> can compose in C++ using Qt as a toolkit for widgets that I will use
> to tweak mastering (final EQ, reverb, and compression) as well as
> sensitive instrument parameters (e.g. for STKBowed). In this case
> also, Csound is used for synthesis but the orchestra code is
> completely embedded in the C++ program. I will probably also embed
> plugin opcodes written in C++ in the program and register them with
> Csound just before compiling the orchestra. These plugins will not
> actually be external DLLs, they will be routines in the main
> composition program which will register them with Csound.
>
> Ideally, I would like to write entire instrument definitions in C++
> embedded in the program. Then Csound would serve as an engine and a
> framework that would manage scheduling, voice allocation, and all
> input and output. These are the hard parts of music programming. I
> would manage all the score generation and sound synthesis in C++.
>
> I am writing an article about composing in C++ with the Csound API and
> CsoundAC, and I will try to get it published in the Csound Journal or
> elsewhere.
>
> All these techniques work with command-line programs as well as with GUIs.
>
> Regards,
> Mike
>
> On Wed, Feb 22, 2012 at 8:44 AM, Adam Puckett <adotsdothmusic at gmail.com> wrote:
>> It's nice to see some familiar names in Csound's defense.
>>
>> Here's something I've considered since learning C: has anyone
>> (attempted to) compose music in straight C (or C++) just using the
>> audio APIs? I think that would be quite a challenge. I can see quite a
>> bit more algorithmic potential there than probably any of the DSLs
>> written in it.
>>
>> On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
>>> It's very easy to use Csound to solve idle mind puzzles! I think many
>>> of us, certainly myself, find ourselves becoming distracted by the
>>> technical work involved in making computer music, as opposed to the
>>> superficially easier but in reality far more difficult work of
>>> composing.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm
>>> <emanuel.landeholm at gmail.com> wrote:
>>>> Well. I need to start using csound. To actually do things in the real
>>>> world instead of just solving idle mind puzzles.
>>>>
>>>> On Tue, Feb 21, 2012 at 10:02 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
>>>>> i have been running csound in realtime since about 1998, which makes it
>>>>> what? about fourteen years, however i remember seeing code for RT audio
>>>>> in the version i picked up from cecelia.media.mit.edu back in 94. So,
>>>>> strictly this capability has been there for the best part of twenty
>>>>> years.
>>>>>
>>>> --
>>>> 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
>>> --
>>> 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
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 22 Feb 2012 09:20:09 -0500
> From: douglas repetto <douglas at music.columbia.edu>
> To: A discussion list for music-related DSP
> ? ? ? ?<music-dsp at music.columbia.edu>
> Subject: [music-dsp] google's non-sine
> Message-ID: <4F44F999.3080105 at music.columbia.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> This is driving me nutz:
>
> http://www.google.com
>
>
> And now an image search for Hertz features lots and lots of pictures of
> a non-sinewave!
>
> Arrg!
>
> --
> ............................................... http://artbots.org
> .....douglas.....irving........................ http://dorkbot.org
> .......................... http://music.columbia.edu/cmc/music-dsp
> ...........repetto............. http://music.columbia.edu/organism
> ............................... http://music.columbia.edu/~douglas
>
>
>
> ------------------------------
>
> --
> 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
>
> End of music-dsp Digest, Vol 98, Issue 31
> *****************************************



-- 
David Gerhard, Associate Professor
Computer Science, University of Regina
phone: 306.585.5227? fax: 306.585.4745
web: http://www2.cs.uregina.ca/~gerhard

From padawan12 at obiwannabe.co.uk  Wed Feb 22 09:29:50 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Wed, 22 Feb 2012 14:29:50 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
References: <4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
Message-ID: <20120222142950.GC5723@sapphire.lan>

On Wed, Feb 22, 2012 at 09:18:11AM -0500, Michael Gogins wrote:

> I am writing an article about composing in C++ with the Csound API and
> CsoundAC, and I will try to get it published in the Csound Journal or
> elsewhere.

Definitely looking forward to that Michael.

From david at olofson.net  Wed Feb 22 09:42:42 2012
From: david at olofson.net (David Olofson)
Date: Wed, 22 Feb 2012 15:42:42 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
Message-ID: <201202221542.42767.david@olofson.net>

On Wednesday 22 February 2012, at 14.44.56, Adam Puckett 
<adotsdothmusic at gmail.com> wrote:
> It's nice to see some familiar names in Csound's defense.
> 
> Here's something I've considered since learning C: has anyone
> (attempted to) compose music in straight C (or C++) just using the
> audio APIs? I think that would be quite a challenge. I can see quite a
> bit more algorithmic potential there than probably any of the DSLs
> written in it.

There was this Comprez2000 thing twelve years ago (obviously!), where one was 
supposed to write a C program of less than 5000 lines, generating a sound 
file. Started on something back then, but the whole thing was abandoned, so I 
never finished it...

More recently, I set out to hack a tiny, fast, usable sound engine for games, 
and ended up with ChipSound; a realtime script driven synth in less than 2000 
lines of C, "compiler" (or rather assembler) included. The basic concept is to 
allow subsample accurate scripting instead of relying on lots of hardwired 
traditional "synth" features.

It's now some 5000 lines, with a nicer language and stuff, but it's still the 
same basic design. VM programs essentially run as processes in a tiny RTOS, 
with instructions for spawning new programs, sending messages etc. No 
distinction between instruments and music, other than programming conventions.

I'm using it in my WIP game Kobo II; all sounds still built from sine, saw, 
triangle, square waves and noise, no filters or anything. Going to do some 
(possibly recursive) render-sound-into-waveform stuff, add filters and other 
units etc later on, but this will do for now. :-)

	http://olofsonarcade.com/2011/11/06/kobo-ii-another-song-wip/
	http://olofsonarcade.com/2011/02/10/kobo-ii-title-song-wip/


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From bastian.schnuerle at silberstein.de  Wed Feb 22 09:45:41 2012
From: bastian.schnuerle at silberstein.de (Bastian Schnuerle)
Date: Wed, 22 Feb 2012 15:45:41 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <20120222141612.GA5723@sapphire.lan>
References: <CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
	<20120222141612.GA5723@sapphire.lan>
Message-ID: <37481691-69EC-4EFC-96D5-34582759FDD2@silberstein.de>

+1

Am 22.02.2012 um 15:16 schrieb Andy Farnell:

> Speed of development is an issue, as turning ideas into sound uses
> considerable human cognition, echoic memory to listen, serial and
> linguistics faculties to interpret, and then geometric mathematical
> and procedural acrobatics to adapt the internal model. C gives great
> flexibility and control, but requires such intense working that an
> idea is often lost before it can be implemented. Compactness is thus
> a desirable quality for music making (with large structures) rather
> than sound programming. For seeing programmers, visual signal flows
> like Pure Data are powerful because the algorithm is maintained as a
> compact diagram. I can understand why Csound is attractive to someone
> without sight, and I wonder if you have also explored Supercollider,
> Chuck and Nyquist, which all represent quite different language
> interfaces to sound making. But as you are a programmer I also wonder,
> if for you Adam, Faust might be something important to explore. For
> one who interprets the world more in symbolic structures it's  
> compactness
> might be something you find very useful.
>
>
>
>
> On Wed, Feb 22, 2012 at 08:44:56AM -0500, Adam Puckett wrote:
>> It's nice to see some familiar names in Csound's defense.
>>
>> Here's something I've considered since learning C: has anyone
>> (attempted to) compose music in straight C (or C++) just using the
>> audio APIs? I think that would be quite a challenge. I can see  
>> quite a
>> bit more algorithmic potential there than probably any of the DSLs
>> written in it.
>>
>> On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
>>> It's very easy to use Csound to solve idle mind puzzles! I think  
>>> many
>>> of us, certainly myself, find ourselves becoming distracted by the
>>> technical work involved in making computer music, as opposed to the
>>> superficially easier but in reality far more difficult work of
>>> composing.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm
>>> <emanuel.landeholm at gmail.com> wrote:
>>>> Well. I need to start using csound. To actually do things in the  
>>>> real
>>>> world instead of just solving idle mind puzzles.
>>>>
>>>> On Tue, Feb 21, 2012 at 10:02 PM, Victor  
>>>> <Victor.Lazzarini at nuim.ie> wrote:
>>>>> i have been running csound in realtime since about 1998, which  
>>>>> makes it
>>>>> what? about fourteen years, however i remember seeing code for  
>>>>> RT audio
>>>>> in the version i picked up from cecelia.media.mit.edu back in  
>>>>> 94. So,
>>>>> strictly this capability has been there for the best part of  
>>>>> twenty
>>>>> years.
>>>>>
>>>> --
>>>> 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
>>> --
>>> 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 risto.holopainen at imv.uio.no  Wed Feb 22 11:17:30 2012
From: risto.holopainen at imv.uio.no (Risto Holopainen)
Date: Wed, 22 Feb 2012 17:17:30 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
Message-ID: <fb4b17db5067f41b9b3b61a41a24b6e2.squirrel@webmail.uio.no>


Yes, it's quite a challenge to compose music just using C/C++. Lately, I
have tried to compose entire pieces written in C++. Many of them are just
monolithic feedback systems with oscillators, filters and some low-level
feature extractors. There are no hierarchic levels of control functions,
the musical form emerges from the specific algorithm. In principle,
similar programs should be possible to write in csound and other
languages, but I have found it easier to use C++ for this. As others have
pointed out, you easily forget your musical ideas while programming. The
trick is: don't have any ideas to begin with!

And speaking of short programs, this reminds me of the Obfuscated C
contest and, not least, the new style of bytebeat (well, to me it seems
like a revival of nonstandard / instruction synthesis):

http://canonical.org/~kragen/bytebeat/
There is also a paper at arXiv by Heikkil? that explains it.


Risto Holopainen
Department of Musicology
University of Oslo




> It's nice to see some familiar names in Csound's defense.
>
> Here's something I've considered since learning C: has anyone
> (attempted to) compose music in straight C (or C++) just using the
> audio APIs? I think that would be quite a challenge. I can see quite a
> bit more algorithmic potential there than probably any of the DSLs
> written in it.
>
> On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
>> It's very easy to use Csound to solve idle mind puzzles! I think many
>> of us, certainly myself, find ourselves becoming distracted by the
>> technical work involved in making computer music, as opposed to the
>> superficially easier but in reality far more difficult work of
>> composing.
>>
>> Regards,
>> Mike
>>


From michael.gogins at gmail.com  Wed Feb 22 12:34:58 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Wed, 22 Feb 2012 12:34:58 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <fb4b17db5067f41b9b3b61a41a24b6e2.squirrel@webmail.uio.no>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
	<fb4b17db5067f41b9b3b61a41a24b6e2.squirrel@webmail.uio.no>
Message-ID: <CAFswGP2gpOAWgxfQMFChxdKkf6_RkGAP2X_5No0knOhSmx+S5w@mail.gmail.com>

For me as a composer working almost exclusively with algorithmic
composition and synthesis, the question of language is complex. It's
not just the power of the language, but also the ease of writing code,
plus the time for building, plus the time for maintaining any
necessary build system and other parts of the toolchain, plus the
number of steps involved in the compose/build/run/listen,
compose/build/run/listen cycle, plus any postproduction or mastering
steps... and the actual runtime speed of the code is often critical as
some of the algorithmic composition procedures are quite
compute-intensive.

I've experimented with many languages, computer music languages, etc.,
and it's come down to using Csound plus as few other parts as
possible. But runtime speed always turns out to more important than
one might expect... That in turn means a choice between composing in
LuaJIT or composing in C++, with qtcreator taking care of the build
system and toolchain maintenance, and some additions to CsoundAC
taking care of the post-processing stuff.

I would prefer to compose using just one language, but at least this
way I only have to deal with the Csound orchestra language plus one
other language, either Lua or C++. I don't have enough experience yet
to tell which way I will end up going, but right now it looks like
each piece will be a C++ program written in qtcreator and run from
qtcreator. Each piece will have as much as GUI as it needs for
mastering and testing instrument parameters, and automatically do any
necessary post-processing, Jack configuration, etc.

This is what I will be writing about...

Regards,
Mike

On Wed, Feb 22, 2012 at 11:17 AM, Risto Holopainen
<risto.holopainen at imv.uio.no> wrote:
>
> Yes, it's quite a challenge to compose music just using C/C++. Lately, I
> have tried to compose entire pieces written in C++. Many of them are just
> monolithic feedback systems with oscillators, filters and some low-level
> feature extractors. There are no hierarchic levels of control functions,
> the musical form emerges from the specific algorithm. In principle,
> similar programs should be possible to write in csound and other
> languages, but I have found it easier to use C++ for this. As others have
> pointed out, you easily forget your musical ideas while programming. The
> trick is: don't have any ideas to begin with!
>
> And speaking of short programs, this reminds me of the Obfuscated C
> contest and, not least, the new style of bytebeat (well, to me it seems
> like a revival of nonstandard / instruction synthesis):
>
> http://canonical.org/~kragen/bytebeat/
> There is also a paper at arXiv by Heikkil? that explains it.
>
>
> Risto Holopainen
> Department of Musicology
> University of Oslo
>
>
>
>
>> It's nice to see some familiar names in Csound's defense.
>>
>> Here's something I've considered since learning C: has anyone
>> (attempted to) compose music in straight C (or C++) just using the
>> audio APIs? I think that would be quite a challenge. I can see quite a
>> bit more algorithmic potential there than probably any of the DSLs
>> written in it.
>>
>> On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
>>> It's very easy to use Csound to solve idle mind puzzles! I think many
>>> of us, certainly myself, find ourselves becoming distracted by the
>>> technical work involved in making computer music, as opposed to the
>>> superficially easier but in reality far more difficult work of
>>> composing.
>>>
>>> Regards,
>>> Mike
>>>
>
> --
> 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 jerry at novadsp.com  Wed Feb 22 12:39:22 2012
From: jerry at novadsp.com (Jerry Evans)
Date: Wed, 22 Feb 2012 17:39:22 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <201202221542.42767.david@olofson.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
	<201202221542.42767.david@olofson.net>
Message-ID: <4F45284A.2040803@NovaDSP.com>

> More recently, I set out to hack a tiny, fast, usable sound engine for games,
> and ended up with ChipSound
Nice idea.

> I'm using it in my WIP game Kobo II; all sounds still built from sine, saw,
> triangle, square waves and noise, no filters or anything. Going to do some
> (possibly recursive) render-sound-into-waveform stuff, add filters and other
> units etc later on, but this will do for now.
>
> 	http://olofsonarcade.com/2011/11/06/kobo-ii-another-song-wip/
> 	http://olofsonarcade.com/2011/02/10/kobo-ii-title-song-wip/

Excellent noises!

Please shout when the engine is available for experimentation.

ATB

Jerry



From rbj at audioimagination.com  Wed Feb 22 12:58:18 2012
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Wed, 22 Feb 2012 12:58:18 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F44F999.3080105@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
Message-ID: <4F452CBA.7090202@audioimagination.com>

On 2/22/12 9:20 AM, douglas repetto wrote:
>
> This is driving me nutz:
>
> http://www.google.com
>
>
> And now an image search for Hertz features lots and lots of pictures 
> of a non-sinewave!
>
> Arrg!
>

i was wondering if it was the same Hertz.  i guess it is.

sometimes Google's authority is dubious.

-- 

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




From theover at tiscali.nl  Wed Feb 22 13:00:45 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Wed, 22 Feb 2012 19:00:45 +0100
Subject: [music-dsp] a little about myself
Message-ID: <4F452D4D.1040207@tiscali.nl>


 > Speed of development is an issue, as turning ideas into sound uses
 > considerable human cognition, echoic memory to listen, serial and
 > linguistics faculties to interpret, and then geometric mathematical
 > and procedural acrobatics to adapt the internal model.

True. And the search algorithm applied, or, better, not applied. I mean 
to say music as an utterance for rational or emotional soul stirrings or 
for all I care as an elevator (lift) composition/rendering should not 
necessarily be burdened by a whole army of copycats claiming territory 
only for the sake of "having". Subtracting the for me un-serious (as 
music) "house"-y type of crap, I'd have to say that automatic 
composition tools probably take place at various levels of aggregation, 
and are seldom about the higher contemporal musical, instrument-wise and 
production-type of wisdom items associated with why everything from 
black Shabbath over Aha to the recet Black Crowes as well as The Beatles 
to Lets say recent Kraftwerk works are so appealing to many people.

Simple algorithms and a lot of uncomely and (provably) systematically 
unharmonic sample-mushing are not going to answer that question, by a 
battle mile, I'm sure. On the other hand I too find the idea of a 10-tap 
analog sequencer changing something on a (preferably real or good 
imitation) Moog modular is exciting, and would sure be part of my free 
or professional time-fill. I mean to say: while it's fun to play around 
with sound programs, a lot of the outcomes of a lot of games that can be 
played with that are predictable and will predictably lead to 
"compositions" (quite possibly without the quotes) which, when led by 
certain well known breeds of people, will turn out predictably 
unmusical, and absolutely of little interest to the community at large 
after Jazz and rock in the 50s or so.

Anyhow, recently I've worked (amoung other things) on making a sound 
synthesizer for FPGA systems (Field Programmable Gate Array, computer 
logic) by trying to add an Open Source (long Live the Open Source idea) 
32-bit mini-computer to it. That's ongoing, but Scott Gravenhorst (who I 
seem to recall hangs out here too) has for long been making various 
types of sound synthesis work in fpga hardware form, by using a small 
(though fast) type of micro controller in the FPGA fabric. He's recently 
used a number of FPGA boards to render a Beethoven composition, which  I 
processed through my considerably complex studio signal processing path 
for improving the loudness (in-) sensitivity of the material, making 
sure the mid-range has loudness (in the sense of peak power) warnings 
built in, and adding Lexicon quality reverberation, on top of an amount 
of dynamic harmonisation, in the sense of making chords and solos sound 
in a more harmonic way, and generally making the result probably sound 
better on decent stereo systems.

It's an experiment, but the custom real-time DSP in the FPGA followed by 
the few hundred 192kH/32bit jack (Ladspa) based plugins are worth a listen:


    http://www.theover.org/Fpgasynth/beetho1.mp3
       44.1kHz 256 kb/s stereo mp3, ca. 30MB


( Original thread: 
http://rubidium.dyndns.org/pipermail/fpga-synth/2012-February/002047.html )

Theo Verelst

From renato.fabbri at gmail.com  Wed Feb 22 13:07:21 2012
From: renato.fabbri at gmail.com (Renato Fabbri)
Date: Wed, 22 Feb 2012 16:07:21 -0200
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCFp-YpjzA@mail.gmail.com>
Message-ID: <CALqdYOxSOh27ayt2SSE2VRh5SwV8tcXirNwUqABagXfVBvbXLw@mail.gmail.com>

you mean like:

in pure python, without external libs etc, synthesizing every single
sample, in one file.py:
http://paste.org/45689

OR

PPEPPS: Pure Python EP: Project Solvent

   $ git clone git://labmacambira.git.sourceforge.net/gitroot/labmacambira/FIGGUS
   $ cd FIGGUS
   $ sudo python setup.py install     # not dependent on anything else
   $ python RUNME_make_now_an_EP_MUSIC.py

Go to ep-Projeto_Solvente/ and enjoy symmetry music for easing altered
states of mind.

more:
IRC Channel #labmacambira @ irc.freenode.net
http://wiki.nosdigitais.teia.org.br/FIGGUS

???

Em 22 de fevereiro de 2012 11:44, Adam Puckett
<adotsdothmusic at gmail.com> escreveu:
> It's nice to see some familiar names in Csound's defense.
>
> Here's something I've considered since learning C: has anyone
> (attempted to) compose music in straight C (or C++) just using the
> audio APIs? I think that would be quite a challenge. I can see quite a
> bit more algorithmic potential there than probably any of the DSLs
> written in it.
>
> On 2/21/12, Michael Gogins <michael.gogins at gmail.com> wrote:
>> It's very easy to use Csound to solve idle mind puzzles! I think many
>> of us, certainly myself, find ourselves becoming distracted by the
>> technical work involved in making computer music, as opposed to the
>> superficially easier but in reality far more difficult work of
>> composing.
>>
>> Regards,
>> Mike
>>
>> On Tue, Feb 21, 2012 at 7:53 PM, Emanuel Landeholm
>> <emanuel.landeholm at gmail.com> wrote:
>>> Well. I need to start using csound. To actually do things in the real
>>> world instead of just solving idle mind puzzles.
>>>
>>> On Tue, Feb 21, 2012 at 10:02 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
>>>> i have been running csound in realtime since about 1998, which makes it
>>>> what? about fourteen years, however i remember seeing code for RT audio
>>>> in the version i picked up from cecelia.media.mit.edu back in 94. So,
>>>> strictly this capability has been there for the best part of twenty
>>>> years.
>>>>
>>> --
>>> 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
>> --
>> 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



-- 
GNU/Linux User #479299
labmacambira.sf.net

From earlevel at earlevel.com  Wed Feb 22 14:16:49 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Wed, 22 Feb 2012 11:16:49 -0800
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F44F999.3080105@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
Message-ID: <3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>

Apparently, the "wave" is made from shapes that are roughly those of the letters (and their colors) in the Google logo...annoying to us, but there is some logic behind it...


On Feb 22, 2012, at 6:20 AM, douglas repetto wrote:
> 
> This is driving me nutz:
> 
> http://www.google.com
> 
> 
> And now an image search for Hertz features lots and lots of pictures of a non-sinewave!
> 
> Arrg!
> 
> -- 
> ............................................... http://artbots.org
> .....douglas.....irving........................ http://dorkbot.org
> .......................... http://music.columbia.edu/cmc/music-dsp
> ...........repetto............. http://music.columbia.edu/organism
> ............................... http://music.columbia.edu/~douglas


From philburk at mobileer.com  Wed Feb 22 14:25:49 2012
From: philburk at mobileer.com (Phil Burk)
Date: Wed, 22 Feb 2012 11:25:49 -0800
Subject: [music-dsp] google's non-sine
In-Reply-To: <3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
Message-ID: <4F45413D.1000600@mobileer.com>

I couldn't help myself. The Google waveform appears to be made of random 
elliptical segments.  Here is a JSyn Applet that plays the "wave doodle":

<http://www.softsynth.com/jsyn/examples/googlewave.php>

Phil Burk

From thomas.young at rebellion.co.uk  Wed Feb 22 14:28:17 2012
From: thomas.young at rebellion.co.uk (Thomas Young)
Date: Wed, 22 Feb 2012 19:28:17 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F45413D.1000600@mobileer.com>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
Message-ID: <8853712D9129AD45B323A96D5396A084D398EAAE@oxnexch01.Rebellion.co.uk>

Haha, great stuff

-----Original Message-----
From: music-dsp-bounces at music.columbia.edu [mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Phil Burk
Sent: 22 February 2012 19:26
To: music-dsp at music.columbia.edu
Subject: Re: [music-dsp] google's non-sine

I couldn't help myself. The Google waveform appears to be made of random 
elliptical segments.  Here is a JSyn Applet that plays the "wave doodle":

<http://www.softsynth.com/jsyn/examples/googlewave.php>

Phil Burk
--
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 david at olofson.net  Wed Feb 22 14:33:02 2012
From: david at olofson.net (David Olofson)
Date: Wed, 22 Feb 2012 20:33:02 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <4F45284A.2040803@NovaDSP.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202221542.42767.david@olofson.net>
	<4F45284A.2040803@NovaDSP.com>
Message-ID: <201202222033.02703.david@olofson.net>

On Wednesday 22 February 2012, at 18.39.22, Jerry Evans <jerry at novadsp.com> 
wrote:
> > More recently, I set out to hack a tiny, fast, usable sound engine for
> > games, and ended up with ChipSound
> 
> Nice idea.
> 
> > I'm using it in my WIP game Kobo II; all sounds still built from sine,
> > saw, triangle, square waves and noise, no filters or anything. Going to
> > do some (possibly recursive) render-sound-into-waveform stuff, add
> > filters and other units etc later on, but this will do for now.
> > 
> > 	http://olofsonarcade.com/2011/11/06/kobo-ii-another-song-wip/
> > 	http://olofsonarcade.com/2011/02/10/kobo-ii-title-song-wip/
> 
> Excellent noises!

Thanks!


> Please shout when the engine is available for experimentation.

There is a version here, actually:
	http://eel.olofson.net/download/ChipSound-20111207.tar.bz2

It was released along with a little Ludum Dare jam entry I made using the 
"Kobo II" engine in the (rather messy) state it was in at the point. There is 
a small SDL + console test program included with ChipSound, but the debug 
sound test dialog in the game is probably more useful. It requires OpenGL 
though, as it's built using the in-game GUI toolkit.

The game also includes a tiny MIDI sequencer, BTW...! :-D Might turn that into 
some kind of "live" ChipSound code editor with MIDI support later on. I've 
realized I rather like just using a text editor, and having all the sounds and 
everything right there. A bit like working with a tracker (Amiga style), but 
more free-form, or something. All I want is instant automatic recompiles, and 
being able to record a melody or a few chords from MIDI once in a while - 
other than that, I'm not really missing the world of Cubase clones much. :-)

LD entry page:
	http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=2901

Source downloads:
	http://eel.olofson.net/news.html

I intend to keep the whole set of "engines" (EEL with API bindings, physics 
engine etc, ZeeSpace and ChipSound) Free/Open Source. Most of it is LGPL, but 
ChipSound doesn't actually have a license at this point. It'll be either LGPL 
or something like the zlib license.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From emburke07 at gmail.com  Wed Feb 22 14:39:45 2012
From: emburke07 at gmail.com (Elliott M Burke)
Date: Wed, 22 Feb 2012 14:39:45 -0500
Subject: [music-dsp] music-dsp Digest, Vol 98, Issue 37
In-Reply-To: <mailman.1059.1329939194.148.music-dsp@music.columbia.edu>
References: <mailman.1059.1329939194.148.music-dsp@music.columbia.edu>
Message-ID: <A8F94FAF-14FD-4D49-B5CB-F5C174DAF912@gmail.com>

Please unsubscribe me. I've too many notices from this account today. 

Sent from my iPhone

On Feb 22, 2012, at 2:33 PM, music-dsp-request at music.columbia.edu wrote:

> Send music-dsp mailing list submissions to
>    music-dsp at music.columbia.edu
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://music.columbia.edu/mailman/listinfo/music-dsp
> or, via email, send a message with subject or body 'help' to
>    music-dsp-request at music.columbia.edu
> 
> You can reach the person managing the list at
>    music-dsp-owner at music.columbia.edu
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of music-dsp digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: google's non-sine (Phil Burk)
>   2. Re: google's non-sine (Thomas Young)
>   3. Re: a little about myself (David Olofson)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 22 Feb 2012 11:25:49 -0800
> From: Phil Burk <philburk at mobileer.com>
> To: music-dsp at music.columbia.edu
> Subject: Re: [music-dsp] google's non-sine
> Message-ID: <4F45413D.1000600 at mobileer.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> I couldn't help myself. The Google waveform appears to be made of random 
> elliptical segments.  Here is a JSyn Applet that plays the "wave doodle":
> 
> <http://www.softsynth.com/jsyn/examples/googlewave.php>
> 
> Phil Burk
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 22 Feb 2012 19:28:17 +0000
> From: Thomas Young <thomas.young at rebellion.co.uk>
> To: A discussion list for music-related DSP
>    <music-dsp at music.columbia.edu>
> Subject: Re: [music-dsp] google's non-sine
> Message-ID:
>    <8853712D9129AD45B323A96D5396A084D398EAAE at oxnexch01.Rebellion.co.uk>
> Content-Type: text/plain; charset="us-ascii"
> 
> Haha, great stuff
> 
> -----Original Message-----
> From: music-dsp-bounces at music.columbia.edu [mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Phil Burk
> Sent: 22 February 2012 19:26
> To: music-dsp at music.columbia.edu
> Subject: Re: [music-dsp] google's non-sine
> 
> I couldn't help myself. The Google waveform appears to be made of random 
> elliptical segments.  Here is a JSyn Applet that plays the "wave doodle":
> 
> <http://www.softsynth.com/jsyn/examples/googlewave.php>
> 
> Phil Burk
> --
> 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
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 22 Feb 2012 20:33:02 +0100
> From: David Olofson <david at olofson.net>
> To: music-dsp at music.columbia.edu
> Subject: Re: [music-dsp] a little about myself
> Message-ID: <201202222033.02703.david at olofson.net>
> Content-Type: Text/Plain;  charset="iso-8859-1"
> 
> On Wednesday 22 February 2012, at 18.39.22, Jerry Evans <jerry at novadsp.com> 
> wrote:
>>> More recently, I set out to hack a tiny, fast, usable sound engine for
>>> games, and ended up with ChipSound
>> 
>> Nice idea.
>> 
>>> I'm using it in my WIP game Kobo II; all sounds still built from sine,
>>> saw, triangle, square waves and noise, no filters or anything. Going to
>>> do some (possibly recursive) render-sound-into-waveform stuff, add
>>> filters and other units etc later on, but this will do for now.
>>> 
>>>    http://olofsonarcade.com/2011/11/06/kobo-ii-another-song-wip/
>>>    http://olofsonarcade.com/2011/02/10/kobo-ii-title-song-wip/
>> 
>> Excellent noises!
> 
> Thanks!
> 
> 
>> Please shout when the engine is available for experimentation.
> 
> There is a version here, actually:
>    http://eel.olofson.net/download/ChipSound-20111207.tar.bz2
> 
> It was released along with a little Ludum Dare jam entry I made using the 
> "Kobo II" engine in the (rather messy) state it was in at the point. There is 
> a small SDL + console test program included with ChipSound, but the debug 
> sound test dialog in the game is probably more useful. It requires OpenGL 
> though, as it's built using the in-game GUI toolkit.
> 
> The game also includes a tiny MIDI sequencer, BTW...! :-D Might turn that into 
> some kind of "live" ChipSound code editor with MIDI support later on. I've 
> realized I rather like just using a text editor, and having all the sounds and 
> everything right there. A bit like working with a tracker (Amiga style), but 
> more free-form, or something. All I want is instant automatic recompiles, and 
> being able to record a melody or a few chords from MIDI once in a while - 
> other than that, I'm not really missing the world of Cubase clones much. :-)
> 
> LD entry page:
>    http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=2901
> 
> Source downloads:
>    http://eel.olofson.net/news.html
> 
> I intend to keep the whole set of "engines" (EEL with API bindings, physics 
> engine etc, ZeeSpace and ChipSound) Free/Open Source. Most of it is LGPL, but 
> ChipSound doesn't actually have a license at this point. It'll be either LGPL 
> or something like the zlib license.
> 
> 
> -- 
> //David Olofson - Consultant, Developer, Artist, Open Source Advocate
> 
> .--- Games, examples, libraries, scripting, sound, music, graphics ---.
> |   http://consulting.olofson.net          http://olofsonarcade.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
> 
> End of music-dsp Digest, Vol 98, Issue 37
> *****************************************

From jerry at novadsp.com  Wed Feb 22 14:47:20 2012
From: jerry at novadsp.com (Jerry Evans)
Date: Wed, 22 Feb 2012 19:47:20 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <201202222033.02703.david@olofson.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202221542.42767.david@olofson.net>
	<4F45284A.2040803@NovaDSP.com>
	<201202222033.02703.david@olofson.net>
Message-ID: <4F454648.8080900@NovaDSP.com>


On 22/02/2012 19:33, David Olofson wrote:
> There is a version here, actually:
> 	http://eel.olofson.net/download/ChipSound-20111207.tar.bz2
>
> It was released along with a little Ludum Dare jam entry I made using the
> "Kobo II" engine in the (rather messy) state it was in at the point. There is
> a small SDL + console test program included with ChipSound, but the debug
> sound test dialog in the game is probably more useful. It requires OpenGL
> though, as it's built using the in-game GUI toolkit.
Excellent and thanks. As soon as I get the mythical 5 minutes ...



From adotsdothmusic at gmail.com  Wed Feb 22 15:06:59 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Wed, 22 Feb 2012 15:06:59 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F454648.8080900@NovaDSP.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202221542.42767.david@olofson.net>
	<4F45284A.2040803@NovaDSP.com>
	<201202222033.02703.david@olofson.net>
	<4F454648.8080900@NovaDSP.com>
Message-ID: <CAK1FW3UAoGEKiqnzHjEoe-rvSOXOVYXqu=n4o1FV1edwN02CeQ@mail.gmail.com>

David,

How did you mix all the sounds in the song?

On 2/22/12, Jerry Evans <jerry at novadsp.com> wrote:
>
> On 22/02/2012 19:33, David Olofson wrote:
>> There is a version here, actually:
>> 	http://eel.olofson.net/download/ChipSound-20111207.tar.bz2
>>
>> It was released along with a little Ludum Dare jam entry I made using the
>> "Kobo II" engine in the (rather messy) state it was in at the point. There
>> is
>> a small SDL + console test program included with ChipSound, but the debug
>> sound test dialog in the game is probably more useful. It requires OpenGL
>> though, as it's built using the in-game GUI toolkit.
> Excellent and thanks. As soon as I get the mythical 5 minutes ...
>
>
> --
> 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  Wed Feb 22 16:40:01 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Wed, 22 Feb 2012 16:40:01 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F45413D.1000600@mobileer.com>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
Message-ID: <4F4560B1.4000102@music.columbia.edu>


That's close, Phil. But to really get it you need to find a way to 
output two sample values in the same sample period -- they've got the 
ellipses joined at the zero crossings!

On 2/22/12 2:25 PM, Phil Burk wrote:
> I couldn't help myself. The Google waveform appears to be made of random
> elliptical segments. Here is a JSyn Applet that plays the "wave doodle":
>
> <http://www.softsynth.com/jsyn/examples/googlewave.php>
>
> Phil Burk
> --
> 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://music.columbia.edu/~douglas


From adotsdothmusic at gmail.com  Wed Feb 22 17:06:16 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Wed, 22 Feb 2012 17:06:16 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F4560B1.4000102@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
Message-ID: <CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>

Why not use something like an "inverse plotting" program (that would
stream the samples from the actual Doodle?).

On 2/22/12, douglas repetto <douglas at music.columbia.edu> wrote:
>
> That's close, Phil. But to really get it you need to find a way to
> output two sample values in the same sample period -- they've got the
> ellipses joined at the zero crossings!
>
> On 2/22/12 2:25 PM, Phil Burk wrote:
>> I couldn't help myself. The Google waveform appears to be made of random
>> elliptical segments. Here is a JSyn Applet that plays the "wave doodle":
>>
>> <http://www.softsynth.com/jsyn/examples/googlewave.php>
>>
>> Phil Burk
>> --
>> 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://music.columbia.edu/~douglas
>
> --
> 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  Wed Feb 22 17:25:27 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Wed, 22 Feb 2012 17:25:27 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
Message-ID: <4F456B57.6070805@music.columbia.edu>


I was making a bit of a joke -- no time domain signal can have two 
different values at the same point in time. So since the Google doodle 
isn't a proper time domain signal, there's no "correct" way to 
synthesize it...

douglas

On 2/22/12 5:06 PM, Adam Puckett wrote:
> Why not use something like an "inverse plotting" program (that would
> stream the samples from the actual Doodle?).
>
> On 2/22/12, douglas repetto<douglas at music.columbia.edu>  wrote:
>>
>> That's close, Phil. But to really get it you need to find a way to
>> output two sample values in the same sample period -- they've got the
>> ellipses joined at the zero crossings!
>>
>> On 2/22/12 2:25 PM, Phil Burk wrote:
>>> I couldn't help myself. The Google waveform appears to be made of random
>>> elliptical segments. Here is a JSyn Applet that plays the "wave doodle":
>>>
>>> <http://www.softsynth.com/jsyn/examples/googlewave.php>
>>>
>>> Phil Burk
>>> --
>>> 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://music.columbia.edu/~douglas
>>
>> --
>> 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://artbots.org
.....douglas.....irving........................ http://dorkbot.org
.......................... http://music.columbia.edu/cmc/music-dsp
...........repetto............. http://music.columbia.edu/organism
............................... http://music.columbia.edu/~douglas


From adotsdothmusic at gmail.com  Wed Feb 22 17:54:37 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Wed, 22 Feb 2012 17:54:37 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F456B57.6070805@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>
Message-ID: <CAK1FW3WX5sK=bUAS5LbOnMHF9m6+t3kiuxmRbkC22grUpQBNow@mail.gmail.com>

Maybe it's a chord?

On 2/22/12, douglas repetto <douglas at music.columbia.edu> wrote:
>
> I was making a bit of a joke -- no time domain signal can have two
> different values at the same point in time. So since the Google doodle
> isn't a proper time domain signal, there's no "correct" way to
> synthesize it...
>
> douglas
>
> On 2/22/12 5:06 PM, Adam Puckett wrote:
>> Why not use something like an "inverse plotting" program (that would
>> stream the samples from the actual Doodle?).
>>
>> On 2/22/12, douglas repetto<douglas at music.columbia.edu>  wrote:
>>>
>>> That's close, Phil. But to really get it you need to find a way to
>>> output two sample values in the same sample period -- they've got the
>>> ellipses joined at the zero crossings!
>>>
>>> On 2/22/12 2:25 PM, Phil Burk wrote:
>>>> I couldn't help myself. The Google waveform appears to be made of random
>>>> elliptical segments. Here is a JSyn Applet that plays the "wave doodle":
>>>>
>>>> <http://www.softsynth.com/jsyn/examples/googlewave.php>
>>>>
>>>> Phil Burk
>>>> --
>>>> 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://music.columbia.edu/~douglas
>>>
>>> --
>>> 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://artbots.org
> .....douglas.....irving........................ http://dorkbot.org
> .......................... http://music.columbia.edu/cmc/music-dsp
> ...........repetto............. http://music.columbia.edu/organism
> ............................... http://music.columbia.edu/~douglas
>
> --
> 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 mr.x.wen at gmail.com  Wed Feb 22 18:25:08 2012
From: mr.x.wen at gmail.com (Wen Xue)
Date: Wed, 22 Feb 2012 23:25:08 -0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F456B57.6070805@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu><4F44F999.3080105@music.columbia.edu><3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com><4F45413D.1000600@mobileer.com><4F4560B1.4000102@music.columbia.edu><CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>
Message-ID: <195D6232A0464A4FBD2F7E59ED123EFE@XPC>

Ay, but you always anti-alias your doodle before sampling. That'll sort it 
out fine.
w.x.

-----Original Message----- 
From: douglas repetto
Sent: Wednesday, February 22, 2012 10:25 PM
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] google's non-sine


I was making a bit of a joke -- no time domain signal can have two
different values at the same point in time. So since the Google doodle
isn't a proper time domain signal, there's no "correct" way to
synthesize it...

douglas

On 2/22/12 5:06 PM, Adam Puckett wrote:
> Why not use something like an "inverse plotting" program (that would
> stream the samples from the actual Doodle?).
>
> On 2/22/12, douglas repetto<douglas at music.columbia.edu>  wrote:
>>
>> That's close, Phil. But to really get it you need to find a way to
>> output two sample values in the same sample period -- they've got the
>> ellipses joined at the zero crossings!
>>
>> On 2/22/12 2:25 PM, Phil Burk wrote:
>>> I couldn't help myself. The Google waveform appears to be made of random
>>> elliptical segments. Here is a JSyn Applet that plays the "wave doodle":
>>>
>>> <http://www.softsynth.com/jsyn/examples/googlewave.php>
>>>
>>> Phil Burk
>>> --
>>> 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://music.columbia.edu/~douglas
>>
>> --
>> 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://artbots.org
.....douglas.....irving........................ http://dorkbot.org
.......................... http://music.columbia.edu/cmc/music-dsp
...........repetto............. http://music.columbia.edu/organism
............................... http://music.columbia.edu/~douglas

--
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 david at olofson.net  Wed Feb 22 18:51:23 2012
From: david at olofson.net (David Olofson)
Date: Thu, 23 Feb 2012 00:51:23 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3UAoGEKiqnzHjEoe-rvSOXOVYXqu=n4o1FV1edwN02CeQ@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<4F454648.8080900@NovaDSP.com>
	<CAK1FW3UAoGEKiqnzHjEoe-rvSOXOVYXqu=n4o1FV1edwN02CeQ@mail.gmail.com>
Message-ID: <201202230051.23785.david@olofson.net>

On Wednesday 22 February 2012, at 21.06.59, Adam Puckett 
<adotsdothmusic at gmail.com> wrote:
> David,
> 
> How did you mix all the sounds in the song?

No mixer, fx chains or anything just yet, so all voices mix into a single 
output buffer. In fact, mixing is not even stereo yet - I'm just adding a 
simple stereo feedback delay before final output conversion. :-)

For the mp3s, I used JAMin to add a bit of EQ and multiband compression, to 
bring loudness a bit closer to "standard."


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From philburk at mobileer.com  Wed Feb 22 19:08:57 2012
From: philburk at mobileer.com (Phil Burk)
Date: Wed, 22 Feb 2012 16:08:57 -0800
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F456B57.6070805@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>
Message-ID: <4F458399.6050706@mobileer.com>



On 2/22/12 2:25 PM, douglas repetto wrote:
> I was making a bit of a joke -- no time domain signal can have two
> different values at the same point in time. So since the Google doodle
> isn't a proper time domain signal, there's no "correct" way to
> synthesize it...

Haha. It sure looks impossible from the doodle.

But the ellipses only have infinite slope at the zero crossing. So all I 
have to do is output a single 0.0. If I am on either side of the zero 
crossing then the slope is non-zero and it acts like a proper function.

Whether the Google doodle is actually ellipses is open to interpretation.

Phil

From adotsdothmusic at gmail.com  Wed Feb 22 20:29:02 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Wed, 22 Feb 2012 20:29:02 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F458399.6050706@mobileer.com>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>
	<4F458399.6050706@mobileer.com>
Message-ID: <CAK1FW3V4yRap26nJfcpKOGAAtFCAaY4B94+khsPuZvp9EU7KGA@mail.gmail.com>

Phil,

Is jSyn dependent on any other Java libraries?

On 2/22/12, Phil Burk <philburk at mobileer.com> wrote:
>
>
> On 2/22/12 2:25 PM, douglas repetto wrote:
>> I was making a bit of a joke -- no time domain signal can have two
>> different values at the same point in time. So since the Google doodle
>> isn't a proper time domain signal, there's no "correct" way to
>> synthesize it...
>
> Haha. It sure looks impossible from the doodle.
>
> But the ellipses only have infinite slope at the zero crossing. So all I
> have to do is output a single 0.0. If I am on either side of the zero
> crossing then the slope is non-zero and it acts like a proper function.
>
> Whether the Google doodle is actually ellipses is open to interpretation.
>
> Phil
> --
> 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 adotsdothmusic at gmail.com  Wed Feb 22 20:30:34 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Wed, 22 Feb 2012 20:30:34 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <201202230051.23785.david@olofson.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<4F454648.8080900@NovaDSP.com>
	<CAK1FW3UAoGEKiqnzHjEoe-rvSOXOVYXqu=n4o1FV1edwN02CeQ@mail.gmail.com>
	<201202230051.23785.david@olofson.net>
Message-ID: <CAK1FW3Uj7moKbo_dTxH9HqkEm7bT-xQEwXc+SfdejWtSR9ZPwg@mail.gmail.com>

What was the algorithm though? It sounds pretty high-end to me.

On 2/22/12, David Olofson <david at olofson.net> wrote:
> On Wednesday 22 February 2012, at 21.06.59, Adam Puckett
> <adotsdothmusic at gmail.com> wrote:
>> David,
>>
>> How did you mix all the sounds in the song?
>
> No mixer, fx chains or anything just yet, so all voices mix into a single
> output buffer. In fact, mixing is not even stereo yet - I'm just adding a
> simple stereo feedback delay before final output conversion. :-)
>
> For the mp3s, I used JAMin to add a bit of EQ and multiband compression, to
> bring loudness a bit closer to "standard."
>
>
> --
> //David Olofson - Consultant, Developer, Artist, Open Source Advocate
>
> .--- Games, examples, libraries, scripting, sound, music, graphics ---.
> |   http://consulting.olofson.net          http://olofsonarcade.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 david at olofson.net  Wed Feb 22 21:13:23 2012
From: david at olofson.net (David Olofson)
Date: Thu, 23 Feb 2012 03:13:23 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3Uj7moKbo_dTxH9HqkEm7bT-xQEwXc+SfdejWtSR9ZPwg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202230051.23785.david@olofson.net>
	<CAK1FW3Uj7moKbo_dTxH9HqkEm7bT-xQEwXc+SfdejWtSR9ZPwg@mail.gmail.com>
Message-ID: <201202230313.23201.david@olofson.net>

On Thursday 23 February 2012, at 02.30.34, Adam Puckett 
<adotsdothmusic at gmail.com> wrote:
> What was the algorithm though? It sounds pretty high-end to me.

Technically, it's all additive synthesis, using only basic geometric waveforms 
and noise. (It's possible to load arbitrary one-shot and looped waveforms, but 
I'm not using that yet.)

However, the scripting allows (mostly) subsample accurate control of pitch, 
amplitude, oscillator phase and waveform, so there is a bit of AM/RM and FM 
going on as well. That's how the distorted and resonant filter-ish sounds are 
created.

You'll find a lot of the techniques I used in game and demo music on the 
Commodore C64 and other "pre-sampling" era computers. I'm just doing it more 
accurately, and using some 30-100 voices total, instead of three or four.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From adotsdothmusic at gmail.com  Wed Feb 22 21:16:10 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Wed, 22 Feb 2012 21:16:10 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <201202230313.23201.david@olofson.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202230051.23785.david@olofson.net>
	<CAK1FW3Uj7moKbo_dTxH9HqkEm7bT-xQEwXc+SfdejWtSR9ZPwg@mail.gmail.com>
	<201202230313.23201.david@olofson.net>
Message-ID: <CAK1FW3VgDDAJQ_WS4sjL_scHUPoZwFG6q=sJutugwJMQu6u3fg@mail.gmail.com>

How are you not getting samples out of range with all those voices?

On 2/22/12, David Olofson <david at olofson.net> wrote:
> On Thursday 23 February 2012, at 02.30.34, Adam Puckett
> <adotsdothmusic at gmail.com> wrote:
>> What was the algorithm though? It sounds pretty high-end to me.
>
> Technically, it's all additive synthesis, using only basic geometric
> waveforms
> and noise. (It's possible to load arbitrary one-shot and looped waveforms,
> but
> I'm not using that yet.)
>
> However, the scripting allows (mostly) subsample accurate control of pitch,
> amplitude, oscillator phase and waveform, so there is a bit of AM/RM and FM
> going on as well. That's how the distorted and resonant filter-ish sounds
> are
> created.
>
> You'll find a lot of the techniques I used in game and demo music on the
> Commodore C64 and other "pre-sampling" era computers. I'm just doing it more
> accurately, and using some 30-100 voices total, instead of three or four.
>
>
> --
> //David Olofson - Consultant, Developer, Artist, Open Source Advocate
>
> .--- Games, examples, libraries, scripting, sound, music, graphics ---.
> |   http://consulting.olofson.net          http://olofsonarcade.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 david at olofson.net  Wed Feb 22 21:32:42 2012
From: david at olofson.net (David Olofson)
Date: Thu, 23 Feb 2012 03:32:42 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3VgDDAJQ_WS4sjL_scHUPoZwFG6q=sJutugwJMQu6u3fg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202230313.23201.david@olofson.net>
	<CAK1FW3VgDDAJQ_WS4sjL_scHUPoZwFG6q=sJutugwJMQu6u3fg@mail.gmail.com>
Message-ID: <201202230332.42226.david@olofson.net>

On Thursday 23 February 2012, at 03.16.10, Adam Puckett 
<adotsdothmusic at gmail.com> wrote:
> How are you not getting samples out of range with all those voices?

Just the usual deal: Scale amplitudes down. :-) I generally compensate 
instruments so they all land at reasonable levels regardless of internal voice 
count, and from there it's just like working with any normal synth.

Also, levels are not that much of a problem with large numbers of voices, as 
they don't add up in a linear fashion. For all practical matters, it becomes 
more like adding up white noise sources; something like sqrt(2) greater peak 
amplitude for doubling the number of sources.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From philburk at mobileer.com  Wed Feb 22 21:34:01 2012
From: philburk at mobileer.com (Phil Burk)
Date: Wed, 22 Feb 2012 18:34:01 -0800
Subject: [music-dsp] google's non-sine
In-Reply-To: <CAK1FW3V4yRap26nJfcpKOGAAtFCAaY4B94+khsPuZvp9EU7KGA@mail.gmail.com>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>
	<4F458399.6050706@mobileer.com>
	<CAK1FW3V4yRap26nJfcpKOGAAtFCAaY4B94+khsPuZvp9EU7KGA@mail.gmail.com>
Message-ID: <4F45A599.8040005@mobileer.com>

On 2/22/12 5:29 PM, Adam Puckett wrote:
> Is jSyn dependent on any other Java libraries?

No. JSyn works with just the standard JDK. There are no dependencies 
except that JSyn uses JavaSound for audio output. JavaSound is available 
on Windows, Mac and Linux but not on Android.

There is a single JSyn jar file, jsyn-beta-16.4.6.jar, that can be 
downloaded from here:

<http://www.softsynth.com/jsyn/developers/download.php>

Just add that JAR file to your Java CLASSPATH. You can then build JSyn 
apps using a text editor and the JDK command line tools, or Eclipse.

A programmers guide is here:

<http://www.softsynth.com/jsyn/docs/usersguide.php>

A list of the most important unit generators are here:

<http://www.softsynth.com/jsyn/docs/unitlist.php>

I have found that Java code runs slightly slower than native 'C'. It's 
about 80% as fast. But I can program much faster in Java than 'C' and my 
time is more important than the computer's time.

Enjoy,
Phil Burk




From douglas at music.columbia.edu  Wed Feb 22 22:19:17 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Wed, 22 Feb 2012 22:19:17 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F458399.6050706@mobileer.com>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>
	<4F458399.6050706@mobileer.com>
Message-ID: <4F45B035.2080600@music.columbia.edu>


To continue this very important and not at all didactic discussion:

I see some of the sections as semi-circles on either side of the middle 
line. So there's no actual circle data on the dividing line, but rather 
there's a point from the top circle and a point from the bottom circle 
on either side of the line, and those points are on the same line on the 
y axis. I don't think that even w.x.'s anti-aliasing trick will take 
care of that...

This reminds me of various waveform drawing gizmos I've seen over the 
years -- it's always a bit disconcerting to realize that moving to a new 
x,y location has to erase whatever value was previous at that point. 
You're not allowed to draw a circle! So it's kinda like drawing, but 
drawing with no history or state. Maybe the Google designer was making 
some sort of signal processing pun...


douglas


On 2/22/12 7:08 PM, Phil Burk wrote:
>
>
> On 2/22/12 2:25 PM, douglas repetto wrote:
>> I was making a bit of a joke -- no time domain signal can have two
>> different values at the same point in time. So since the Google doodle
>> isn't a proper time domain signal, there's no "correct" way to
>> synthesize it...
>
> Haha. It sure looks impossible from the doodle.
>
> But the ellipses only have infinite slope at the zero crossing. So all I
> have to do is output a single 0.0. If I am on either side of the zero
> crossing then the slope is non-zero and it acts like a proper function.
>
> Whether the Google doodle is actually ellipses is open to interpretation.
>
> Phil
> --
> 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://music.columbia.edu/~douglas


From adotsdothmusic at gmail.com  Wed Feb 22 22:25:13 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Wed, 22 Feb 2012 22:25:13 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F45B035.2080600@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>
	<4F458399.6050706@mobileer.com>
	<4F45B035.2080600@music.columbia.edu>
Message-ID: <CAK1FW3U=XuA7RWKtzCaFUcLgtygsfMx-2kei4BVnGwhRJUJf1Q@mail.gmail.com>

Maybe he was deliberately going for silence, possibly further
protesting SOPA/PIPA?

On 2/22/12, douglas repetto <douglas at music.columbia.edu> wrote:
>
> To continue this very important and not at all didactic discussion:
>
> I see some of the sections as semi-circles on either side of the middle
> line. So there's no actual circle data on the dividing line, but rather
> there's a point from the top circle and a point from the bottom circle
> on either side of the line, and those points are on the same line on the
> y axis. I don't think that even w.x.'s anti-aliasing trick will take
> care of that...
>
> This reminds me of various waveform drawing gizmos I've seen over the
> years -- it's always a bit disconcerting to realize that moving to a new
> x,y location has to erase whatever value was previous at that point.
> You're not allowed to draw a circle! So it's kinda like drawing, but
> drawing with no history or state. Maybe the Google designer was making
> some sort of signal processing pun...
>
>
> douglas
>
>
> On 2/22/12 7:08 PM, Phil Burk wrote:
>>
>>
>> On 2/22/12 2:25 PM, douglas repetto wrote:
>>> I was making a bit of a joke -- no time domain signal can have two
>>> different values at the same point in time. So since the Google doodle
>>> isn't a proper time domain signal, there's no "correct" way to
>>> synthesize it...
>>
>> Haha. It sure looks impossible from the doodle.
>>
>> But the ellipses only have infinite slope at the zero crossing. So all I
>> have to do is output a single 0.0. If I am on either side of the zero
>> crossing then the slope is non-zero and it acts like a proper function.
>>
>> Whether the Google doodle is actually ellipses is open to interpretation.
>>
>> Phil
>> --
>> 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://music.columbia.edu/~douglas
>
> --
> 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 doctorbill at gmail.com  Wed Feb 22 23:16:06 2012
From: doctorbill at gmail.com (Bill Moorier)
Date: Wed, 22 Feb 2012 20:16:06 -0800
Subject: [music-dsp] Introducing myself
Message-ID: <CAFpHsCMKpVTQnnhgEe5u+0xCmigEd0bpJYobOP1ngxPGVcYVNA@mail.gmail.com>

Hello, just thought I would introduce myself to the list since I've
been lurking for a little while but haven't posted anything yet.

I'm been programming computers since I was 9 years old, so 27 years
now.  I got started on a zx81 - it had a whole 1kB of user memory!

I've never really done too much music-related software though, until
now.  In my spare time, I've started working on an engine for doing
realtime audio DSP in javascript.  It works surprisingly well!  Not
ready to release anything yet, but it's good fun :)

The biggest thing holding me back right now is my lack of a background
in audio.  Often it means I have no idea how to track down problems,
like today's for example.  I built a dead-simple autopanner:
http://abstractnonsense.com/22-feb-2012-js.html

It works nicely when you keep the input parameter (from 0.0 to 1.0)
fixed, but it sounds *awful* when you change the parameter, no matter
how smoothly you do it.  Here's a sample output:
http://abstractnonsense.com/22-feb-2012-swept.mp3

Any pointers for figuring out things like this?  I seem to be able to
make a lot of "dead-simple" versions of effects, but it all goes wrong
when I try to beef them up!

Anyway, thanks for having me on the list, I'm already learning a lot :)

Cheers,
Bill.
--
Bill Moorier abstractnonsense.com | @billmoorier

From alessandro.saccoia at gmail.com  Thu Feb 23 00:04:55 2012
From: alessandro.saccoia at gmail.com (Alessandro Saccoia)
Date: Wed, 22 Feb 2012 23:04:55 -0600
Subject: [music-dsp] Introducing myself
In-Reply-To: <CAFpHsCMKpVTQnnhgEe5u+0xCmigEd0bpJYobOP1ngxPGVcYVNA@mail.gmail.com>
References: <CAFpHsCMKpVTQnnhgEe5u+0xCmigEd0bpJYobOP1ngxPGVcYVNA@mail.gmail.com>
Message-ID: <4A66117D-17FA-45C1-9B80-4A6D2DAF6ADF@gmail.com>

Hello Bill,
I take your question as a chance to introduce myself.
When you sweep the input parameter you are introducing discontinuities in the output signal, and that sounds awful.
The simplest case to figure that out in your code is imagining that you have the input variable set at 0 (pan = 0), and then abruptly you change the input parameter to a value that will make the value of the pan variable jump to 1. Both of the channels will generate a square wave, that will sound badly because of the aliasing. One solution is to control the slew rate of your parameter lowpass filtering your parameter. A simple moving average filter should do the job correctly.

I have been reading this newsletter for a couple of years now, and I think that it's the best place to learn about the practical applications of musical dsp. I have been working in the digital audio field since 3 years now, even though I have been interested in computer music since my first years at the university.
Now I am freelancing in this field, and I also get to play music more often. This is really stimulating my imagination, and I hope that in the next months I will have the time to implement some new effect or instruments. 
Thank you for all the nice things that I have learnt here, 

Alessandro



On Feb 22, 2012, at 10:16 PM, Bill Moorier wrote:

> Hello, just thought I would introduce myself to the list since I've
> been lurking for a little while but haven't posted anything yet.
> 
> I'm been programming computers since I was 9 years old, so 27 years
> now.  I got started on a zx81 - it had a whole 1kB of user memory!
> 
> I've never really done too much music-related software though, until
> now.  In my spare time, I've started working on an engine for doing
> realtime audio DSP in javascript.  It works surprisingly well!  Not
> ready to release anything yet, but it's good fun :)
> 
> The biggest thing holding me back right now is my lack of a background
> in audio.  Often it means I have no idea how to track down problems,
> like today's for example.  I built a dead-simple autopanner:
> http://abstractnonsense.com/22-feb-2012-js.html
> 
> It works nicely when you keep the input parameter (from 0.0 to 1.0)
> fixed, but it sounds *awful* when you change the parameter, no matter
> how smoothly you do it.  Here's a sample output:
> http://abstractnonsense.com/22-feb-2012-swept.mp3
> 
> Any pointers for figuring out things like this?  I seem to be able to
> make a lot of "dead-simple" versions of effects, but it all goes wrong
> when I try to beef them up!
> 
> Anyway, thanks for having me on the list, I'm already learning a lot :)
> 
> Cheers,
> Bill.
> --
> Bill Moorier abstractnonsense.com | @billmoorier
> --
> 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 ot at iki.fi  Thu Feb 23 02:22:47 2012
From: ot at iki.fi (Oskari Tammelin)
Date: Thu, 23 Feb 2012 09:22:47 +0200
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F44F999.3080105@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
Message-ID: <op.v94er9ttr70oxz@ot-pc.dhcp.inet.fi>

On Wed, 22 Feb 2012 16:20:09 +0200, douglas repetto  
<douglas at music.columbia.edu> wrote:

>
> This is driving me nutz:
>
> http://www.google.com
>
>
> And now an image search for Hertz features lots and lots of pictures of  
> a non-sinewave!
>
> Arrg!
>

Come on, it's a perfect visualization of their understanding of audio.

From earlevel at earlevel.com  Thu Feb 23 03:01:05 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Thu, 23 Feb 2012 00:01:05 -0800
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F458399.6050706@mobileer.com>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>
	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>
	<4F458399.6050706@mobileer.com>
Message-ID: <6B4EA70D-8FB0-49EA-A47F-52502733CEBB@earlevel.com>

If the sample rate is much higher than the resolution of the image, no problem making that vertical-looking section in the real world ;-)

On Feb 22, 2012, at 4:08 PM, Phil Burk wrote:
> 
> On 2/22/12 2:25 PM, douglas repetto wrote:
>> I was making a bit of a joke -- no time domain signal can have two
>> different values at the same point in time. So since the Google doodle
>> isn't a proper time domain signal, there's no "correct" way to
>> synthesize it...
> 
> Haha. It sure looks impossible from the doodle.
> 
> But the ellipses only have infinite slope at the zero crossing. So all I have to do is output a single 0.0. If I am on either side of the zero crossing then the slope is non-zero and it acts like a proper function.
> 
> Whether the Google doodle is actually ellipses is open to interpretation.
> 
> Phil
> --


From rossb-lists at audiomulch.com  Thu Feb 23 04:05:51 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Thu, 23 Feb 2012 20:05:51 +1100
Subject: [music-dsp] google's non-sine
In-Reply-To: <op.v94er9ttr70oxz@ot-pc.dhcp.inet.fi>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<op.v94er9ttr70oxz@ot-pc.dhcp.inet.fi>
Message-ID: <4F46016F.7010707@audiomulch.com>



On 23/02/2012 6:22 PM, Oskari Tammelin wrote:
> Come on, it's a perfect visualization of their understanding of audio.

+1

From xue.wen at eecs.qmul.ac.uk  Thu Feb 23 04:15:49 2012
From: xue.wen at eecs.qmul.ac.uk (Wen Xue)
Date: Thu, 23 Feb 2012 09:15:49 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F45B035.2080600@music.columbia.edu>
References: <4F44F779.4060402@music.columbia.edu>
	<4F44F999.3080105@music.columbia.edu>
	<3DC4229F-11D0-4DEF-984A-F10F73E853D7@earlevel.com>
	<4F45413D.1000600@mobileer.com>	<4F4560B1.4000102@music.columbia.edu>
	<CAK1FW3Wc1vrBKgKp5tqHTHa6f-UoshcAgrQGpFSX_sEzpmZQFw@mail.gmail.com>
	<4F456B57.6070805@music.columbia.edu>	<4F458399.6050706@mobileer.com>
	<4F45B035.2080600@music.columbia.edu>
Message-ID: <4F4603C5.6070203@eecs.qmul.ac.uk>

The magic of anti-aliasing is that it is an integral - you can integrate 
over dx along any route f(x,y)=0 as long as it converges, and there will 
be an equivalent single-valued route g(x)-y=0 that gives the same 
integration result.

In the case of a circle dx will be negative half the journey so the 
equivalent route is subtracting the two branches, which makes a 
semicircle streched to twice height.

If your doodle comes in the shape of a "Z" then the convolution will 
come out as if it is a "\" (sum of top and bottom branches minus the 
middle one).

Of course you may need to rewrite the code to do such convolution but it 
follows the definition perfectly.

w.x.


on 23/02/2012 03:19, douglas repetto wrote:
> To continue this very important and not at all didactic discussion:
>
> I see some of the sections as semi-circles on either side of the middle
> line. So there's no actual circle data on the dividing line, but rather
> there's a point from the top circle and a point from the bottom circle
> on either side of the line, and those points are on the same line on the
> y axis. I don't think that even w.x.'s anti-aliasing trick will take
> care of that...
>
> This reminds me of various waveform drawing gizmos I've seen over the
> years -- it's always a bit disconcerting to realize that moving to a new
> x,y location has to erase whatever value was previous at that point.
> You're not allowed to draw a circle! So it's kinda like drawing, but
> drawing with no history or state. Maybe the Google designer was making
> some sort of signal processing pun...
>
>
> douglas
>
>
> On 2/22/12 7:08 PM, Phil Burk wrote:
>>
>> On 2/22/12 2:25 PM, douglas repetto wrote:
>>> I was making a bit of a joke -- no time domain signal can have two
>>> different values at the same point in time. So since the Google doodle
>>> isn't a proper time domain signal, there's no "correct" way to
>>> synthesize it...
>> Haha. It sure looks impossible from the doodle.
>>
>> But the ellipses only have infinite slope at the zero crossing. So all I
>> have to do is output a single 0.0. If I am on either side of the zero
>> crossing then the slope is non-zero and it acts like a proper function.
>>
>> Whether the Google doodle is actually ellipses is open to interpretation.
>>
>> Phil
>> --
>> 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 emanuel.landeholm at gmail.com  Thu Feb 23 08:03:54 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Thu, 23 Feb 2012 14:03:54 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <201202230332.42226.david@olofson.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202230313.23201.david@olofson.net>
	<CAK1FW3VgDDAJQ_WS4sjL_scHUPoZwFG6q=sJutugwJMQu6u3fg@mail.gmail.com>
	<201202230332.42226.david@olofson.net>
Message-ID: <CAML4ZX41mALJU2bHTva9KUhuqatcxXnOo7jV5rEWx31R9gKcSQ@mail.gmail.com>

There is a another approach you could take when summing many voices
that may be correlated in time and frequency, Indiividually pass your
voices through a simple 2:nd order all pass with semi random phase
angle before down mixing. This will  reduce the risk of peaks lining
up and might save you some headroom. Ofcourse, this means one extra
IIR per voice, so it comes with a cost.

On Thu, Feb 23, 2012 at 3:32 AM, David Olofson <david at olofson.net> wrote:
> On Thursday 23 February 2012, at 03.16.10, Adam Puckett
> <adotsdothmusic at gmail.com> wrote:
>> How are you not getting samples out of range with all those voices?
>
> Just the usual deal: Scale amplitudes down. :-) I generally compensate
> instruments so they all land at reasonable levels regardless of internal voice
> count, and from there it's just like working with any normal synth.
>
> Also, levels are not that much of a problem with large numbers of voices, as
> they don't add up in a linear fashion. For all practical matters, it becomes
> more like adding up white noise sources; something like sqrt(2) greater peak
> amplitude for doubling the number of sources.
>
>
> --
> //David Olofson - Consultant, Developer, Artist, Open Source Advocate
>
> .--- Games, examples, libraries, scripting, sound, music, graphics ---.
> | ? http://consulting.olofson.net ? ? ? ? ?http://olofsonarcade.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 theover at tiscali.nl  Thu Feb 23 08:18:19 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Thu, 23 Feb 2012 14:18:19 +0100
Subject: [music-dsp] google's non-sine
In-Reply-To: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
Message-ID: <4F463C9B.6030205@tiscali.nl>


What's the challenge being met by Google with their wavy lines?

It clearly isn't a graphics problem, nor a particularly good synthesis 
engine being promoted (the page with the application is fun and maybe 
sound fun, but isn't put forward as the next big thing in audio).

Neither is the graph (in the sense of wiggly line, not ropes and dots) 
particularly pleasing in some form of to me known theory being applied 
with graphically or audio-wise special aesthetics, like a critically 
damped spring system or a perfect way to reflect compressed waves or 
some something like such ideas.

Probably it is cartoon like doodle making fun of the buzz-word 
elliptical which has been abused probably since pick-up elements and 
certain Helmholz integrals have been proclaimed holy as such. No that 
there is all too much fun in that, or in exchanging sinc functions  with 
fourier integrals, squared energy terms with 1/(1+x) fractions, repeated 
FFTs with correct impulses and linear systems with systems time varying 
systems, necessarily.

I suppose (being rather versed in computer graphics and interpolation) 
the fun is some kind of "curve" suggestion, pointing at the many errors 
being often made, and how stupid the results are without making people 
ashamed!

Theo

From jpff at cs.bath.ac.uk  Thu Feb 23 09:18:00 2012
From: jpff at cs.bath.ac.uk (jpff at cs.bath.ac.uk)
Date: Thu, 23 Feb 2012 14:18:00 -0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAML4ZX41mALJU2bHTva9KUhuqatcxXnOo7jV5rEWx31R9gKcSQ@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202230313.23201.david@olofson.net>
	<CAK1FW3VgDDAJQ_WS4sjL_scHUPoZwFG6q=sJutugwJMQu6u3fg@mail.gmail.com>
	<201202230332.42226.david@olofson.net>
	<CAML4ZX41mALJU2bHTva9KUhuqatcxXnOo7jV5rEWx31R9gKcSQ@mail.gmail.com>
Message-ID: <69953094e14280f6d246d68c9a794450.squirrel@www.cs.bath.ac.uk>

Joining in late.... I have been using real-time Csound since 1996.  I
also write much of my music in C to create scores to drive Csound, and
the rest directly in Csound.  While I do not really do real-time I
know that many of our users do, and as for installation, there are
Debian and SuSE packages, OSX and Windows installers, etc.  No harder
than installing much stuff (I failed to install audacity yesterday on
a Linux machine).
==John ffitch





From david at olofson.net  Thu Feb 23 09:35:39 2012
From: david at olofson.net (David Olofson)
Date: Thu, 23 Feb 2012 15:35:39 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAML4ZX41mALJU2bHTva9KUhuqatcxXnOo7jV5rEWx31R9gKcSQ@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202230332.42226.david@olofson.net>
	<CAML4ZX41mALJU2bHTva9KUhuqatcxXnOo7jV5rEWx31R9gKcSQ@mail.gmail.com>
Message-ID: <201202231535.39796.david@olofson.net>

On Thursday 23 February 2012, at 14.03.54, Emanuel Landeholm 
<emanuel.landeholm at gmail.com> wrote:
> There is a another approach you could take when summing many voices
> that may be correlated in time and frequency, Indiividually pass your
> voices through a simple 2:nd order all pass with semi random phase
> angle before down mixing. This will  reduce the risk of peaks lining
> up and might save you some headroom. Ofcourse, this means one extra
> IIR per voice, so it comes with a cost.

In this case, I tend to use multiple voices specifically *because* I want them 
slightly offset in phase and/or frequency, so that's already in there, so to 
speak.

For example, the strings are made from a few sawtooth waves starting at random 
phases, then having pitch and amplitude randomly modulated. The random 
modulation is absolutely essential for avoiding that harsh, metallic sound, 
but I suspect that it also has the side effect of reducing the probability of 
extreme peaks, compared to just randomizing initial phase and detune.

If you want to be really clever, I suppose you could augment the randomization 
with logic that tracks all voices and tweaks the "random" values as needed to 
avoid peaks piling up... Interesting exercise if you really want to push the 
limits. :-)

Anyway, I think the only safe and "proper" solution for the general case is a 
multiband compressor as the final stage before hard clip and output 
conversion.

For an FPS game, this is where you insert a limiter that triggers a crossfade 
over to a ringing ears sound. ;-) That solves the clipping problem while also 
adding quite effective "Whoa, too close to home!" feedback. If you just want 
to psychoacoustically emphasize really loud noises, a compressor/limiter with 
suitable settings might work - unlike a transparent multiband compressor 
setup, which tends to have the opposite effect.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From emanuel.landeholm at gmail.com  Thu Feb 23 09:44:17 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Thu, 23 Feb 2012 15:44:17 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <201202231535.39796.david@olofson.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202230332.42226.david@olofson.net>
	<CAML4ZX41mALJU2bHTva9KUhuqatcxXnOo7jV5rEWx31R9gKcSQ@mail.gmail.com>
	<201202231535.39796.david@olofson.net>
Message-ID: <CAML4ZX7YXqrhYFrQQMzpQvB5egHBe8JMo2TMJhMBTwjdzzgvFg@mail.gmail.com>

> For example, the strings are made from a few sawtooth waves starting at random
> phases, then having pitch and amplitude randomly modulated. The random
> modulation is absolutely essential for avoiding that harsh, metallic sound,
> but I suspect that it also has the side effect of reducing the probability of
> extreme peaks, compared to just randomizing initial phase and detune.

Makes sense. No need to do an all pass stage on chorused, detuned or
heavily modulated voices.

> Anyway, I think the only safe and "proper" solution for the general case is a
> multiband compressor as the final stage before hard clip and output
> conversion.

Agreed.

cheers,
Emanuel

From didid at skynet.be  Thu Feb 23 09:53:04 2012
From: didid at skynet.be (Didier Dambrin)
Date: Thu, 23 Feb 2012 15:53:04 +0100
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F463C9B.6030205@tiscali.nl>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
Message-ID: <D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>

There's also the fact that it's not easy to draw a sinewave in existing 
tools out there.
Those who have drawn GUIs here and had to show waveforms know what I mean, I 
remember I've ended up with google-like non-sines as I was trying to draw a 
sine using 2 half ellipses. It may be what happened to the guy who drew 
that.
Ask yourself how you'd do it.. the most accurate would be to use a real plot 
of a sine, but now good luck converting that to vectors in a proper image 
editing tool, for a nice antialiased display.





-----Message d'origine----- 
From: Theo Verelst
Sent: Thursday, February 23, 2012 2:18 PM
To: music-dsp at music.columbia.edu
Subject: Re: [music-dsp] google's non-sine


What's the challenge being met by Google with their wavy lines?

It clearly isn't a graphics problem, nor a particularly good synthesis
engine being promoted (the page with the application is fun and maybe
sound fun, but isn't put forward as the next big thing in audio).

Neither is the graph (in the sense of wiggly line, not ropes and dots)
particularly pleasing in some form of to me known theory being applied
with graphically or audio-wise special aesthetics, like a critically
damped spring system or a perfect way to reflect compressed waves or
some something like such ideas.

Probably it is cartoon like doodle making fun of the buzz-word
elliptical which has been abused probably since pick-up elements and
certain Helmholz integrals have been proclaimed holy as such. No that
there is all too much fun in that, or in exchanging sinc functions  with
fourier integrals, squared energy terms with 1/(1+x) fractions, repeated
FFTs with correct impulses and linear systems with systems time varying
systems, necessarily.

I suppose (being rather versed in computer graphics and interpolation)
the fun is some kind of "curve" suggestion, pointing at the many errors
being often made, and how stupid the results are without making people
ashamed!

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


-----
Aucun virus trouve dans ce message.
Analyse effectuee par AVG - www.avg.fr
Version: 2012.0.1913 / Base de donnees virale: 2114/4827 - Date: 23/02/2012 


From adotsdothmusic at gmail.com  Thu Feb 23 10:13:02 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Thu, 23 Feb 2012 10:13:02 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
Message-ID: <CAK1FW3WYePrwCx+Z4WEEKw6_ORX3p-GKzM-UdaLaaGJ5KJ4hqQ@mail.gmail.com>

If they'd used raster graphics I'm sure it would've looked more real.

On 2/23/12, Didier Dambrin <didid at skynet.be> wrote:
> There's also the fact that it's not easy to draw a sinewave in existing
> tools out there.
> Those who have drawn GUIs here and had to show waveforms know what I mean, I
> remember I've ended up with google-like non-sines as I was trying to draw a
> sine using 2 half ellipses. It may be what happened to the guy who drew
> that.
> Ask yourself how you'd do it.. the most accurate would be to use a real plot
> of a sine, but now good luck converting that to vectors in a proper image
> editing tool, for a nice antialiased display.
>
>
>
>
>
> -----Message d'origine-----
> From: Theo Verelst
> Sent: Thursday, February 23, 2012 2:18 PM
> To: music-dsp at music.columbia.edu
> Subject: Re: [music-dsp] google's non-sine
>
>
> What's the challenge being met by Google with their wavy lines?
>
> It clearly isn't a graphics problem, nor a particularly good synthesis
> engine being promoted (the page with the application is fun and maybe
> sound fun, but isn't put forward as the next big thing in audio).
>
> Neither is the graph (in the sense of wiggly line, not ropes and dots)
> particularly pleasing in some form of to me known theory being applied
> with graphically or audio-wise special aesthetics, like a critically
> damped spring system or a perfect way to reflect compressed waves or
> some something like such ideas.
>
> Probably it is cartoon like doodle making fun of the buzz-word
> elliptical which has been abused probably since pick-up elements and
> certain Helmholz integrals have been proclaimed holy as such. No that
> there is all too much fun in that, or in exchanging sinc functions  with
> fourier integrals, squared energy terms with 1/(1+x) fractions, repeated
> FFTs with correct impulses and linear systems with systems time varying
> systems, necessarily.
>
> I suppose (being rather versed in computer graphics and interpolation)
> the fun is some kind of "curve" suggestion, pointing at the many errors
> being often made, and how stupid the results are without making people
> ashamed!
>
> Theo
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp
> links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>
>
> -----
> Aucun virus trouve dans ce message.
> Analyse effectuee par AVG - www.avg.fr
> Version: 2012.0.1913 / Base de donnees virale: 2114/4827 - Date: 23/02/2012
>
> --
> 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 adotsdothmusic at gmail.com  Thu Feb 23 10:17:38 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Thu, 23 Feb 2012 10:17:38 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAML4ZX7YXqrhYFrQQMzpQvB5egHBe8JMo2TMJhMBTwjdzzgvFg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<201202230332.42226.david@olofson.net>
	<CAML4ZX41mALJU2bHTva9KUhuqatcxXnOo7jV5rEWx31R9gKcSQ@mail.gmail.com>
	<201202231535.39796.david@olofson.net>
	<CAML4ZX7YXqrhYFrQQMzpQvB5egHBe8JMo2TMJhMBTwjdzzgvFg@mail.gmail.com>
Message-ID: <CAK1FW3WSfsJQO_q_aKYqrwyqfkYJQcFgD-Hmc3tTtBmsx+jrTg@mail.gmail.com>

Interesting. How would you make an ear ringing sound?

On 2/23/12, Emanuel Landeholm <emanuel.landeholm at gmail.com> wrote:
>> For example, the strings are made from a few sawtooth waves starting at
>> random
>> phases, then having pitch and amplitude randomly modulated. The random
>> modulation is absolutely essential for avoiding that harsh, metallic
>> sound,
>> but I suspect that it also has the side effect of reducing the probability
>> of
>> extreme peaks, compared to just randomizing initial phase and detune.
>
> Makes sense. No need to do an all pass stage on chorused, detuned or
> heavily modulated voices.
>
>> Anyway, I think the only safe and "proper" solution for the general case
>> is a
>> multiband compressor as the final stage before hard clip and output
>> conversion.
>
> Agreed.
>
> cheers,
> Emanuel
> --
> 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 emanuel.landeholm at gmail.com  Thu Feb 23 10:37:51 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Thu, 23 Feb 2012 16:37:51 +0100
Subject: [music-dsp] google's non-sine
In-Reply-To: <D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
Message-ID: <CAML4ZX42bJF76JcpRBbd6dQ8Wibm5BGkRGyJ_YqmtxdoT94fyQ@mail.gmail.com>

NURBS should do the trick.

On Thu, Feb 23, 2012 at 3:53 PM, Didier Dambrin <didid at skynet.be> wrote:
> There's also the fact that it's not easy to draw a sinewave in existing
> tools out there.
> Those who have drawn GUIs here and had to show waveforms know what I mean, I
> remember I've ended up with google-like non-sines as I was trying to draw a
> sine using 2 half ellipses. It may be what happened to the guy who drew
> that.
> Ask yourself how you'd do it.. the most accurate would be to use a real plot
> of a sine, but now good luck converting that to vectors in a proper image
> editing tool, for a nice antialiased display.

From adotsdothmusic at gmail.com  Thu Feb 23 10:58:45 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Thu, 23 Feb 2012 10:58:45 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <CAML4ZX42bJF76JcpRBbd6dQ8Wibm5BGkRGyJ_YqmtxdoT94fyQ@mail.gmail.com>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<CAML4ZX42bJF76JcpRBbd6dQ8Wibm5BGkRGyJ_YqmtxdoT94fyQ@mail.gmail.com>
Message-ID: <CAK1FW3W56q_sTdkbc8tAmRUnbcC+a0HUFhyTi60+CJZCbgZQJg@mail.gmail.com>

What is NURBS?

On 2/23/12, Emanuel Landeholm <emanuel.landeholm at gmail.com> wrote:
> NURBS should do the trick.
>
> On Thu, Feb 23, 2012 at 3:53 PM, Didier Dambrin <didid at skynet.be> wrote:
>> There's also the fact that it's not easy to draw a sinewave in existing
>> tools out there.
>> Those who have drawn GUIs here and had to show waveforms know what I mean,
>> I
>> remember I've ended up with google-like non-sines as I was trying to draw
>> a
>> sine using 2 half ellipses. It may be what happened to the guy who drew
>> that.
>> Ask yourself how you'd do it.. the most accurate would be to use a real
>> plot
>> of a sine, but now good luck converting that to vectors in a proper image
>> editing tool, for a nice antialiased display.
> --
> 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 david at olofson.net  Thu Feb 23 11:10:52 2012
From: david at olofson.net (David Olofson)
Date: Thu, 23 Feb 2012 17:10:52 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3WSfsJQO_q_aKYqrwyqfkYJQcFgD-Hmc3tTtBmsx+jrTg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAML4ZX7YXqrhYFrQQMzpQvB5egHBe8JMo2TMJhMBTwjdzzgvFg@mail.gmail.com>
	<CAK1FW3WSfsJQO_q_aKYqrwyqfkYJQcFgD-Hmc3tTtBmsx+jrTg@mail.gmail.com>
Message-ID: <201202231710.52667.david@olofson.net>

On Thursday 23 February 2012, at 16.17.38, Adam Puckett 
<adotsdothmusic at gmail.com> wrote:
> Interesting. How would you make an ear ringing sound?

That's a good question...! :-D

I was just thinking of Half-Life 2, which has this feature. They're playing 
the same pre-generated waveform, AFAICT. It does the job, and it's quite 
obivous what it's intended to be, but perhaps not very realistic.

A more realistic approach might be to FFT the offending audio snippet that 
triggers the effect, remove all bands but the "too loud" peaks and then IFFT 
that to create the "ring" waveform.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From david at olofson.net  Thu Feb 23 11:14:52 2012
From: david at olofson.net (David Olofson)
Date: Thu, 23 Feb 2012 17:14:52 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <201202231710.52667.david@olofson.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAK1FW3WSfsJQO_q_aKYqrwyqfkYJQcFgD-Hmc3tTtBmsx+jrTg@mail.gmail.com>
	<201202231710.52667.david@olofson.net>
Message-ID: <201202231714.52511.david@olofson.net>

On Thursday 23 February 2012, at 17.10.52, David Olofson <david at olofson.net> 
wrote:
> On Thursday 23 February 2012, at 16.17.38, Adam Puckett
> 
> <adotsdothmusic at gmail.com> wrote:
> > Interesting. How would you make an ear ringing sound?
[...]
> A more realistic approach might be to FFT the offending audio snippet that
> triggers the effect, remove all bands but the "too loud" peaks and then
> IFFT that to create the "ring" waveform.

Oh, wait. Probably throw in some heavy distortion before the FFT, 
approximating the mechanical distortion in the ear...? Also, the whole thing 
needs to take in account that the "too loud" level is highly frequency 
dependent.

Nothing is ever nearly as simple as it may seem at first. ;-)


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From thomas.young at rebellion.co.uk  Thu Feb 23 11:39:36 2012
From: thomas.young at rebellion.co.uk (Thomas Young)
Date: Thu, 23 Feb 2012 16:39:36 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <201202231714.52511.david@olofson.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAK1FW3WSfsJQO_q_aKYqrwyqfkYJQcFgD-Hmc3tTtBmsx+jrTg@mail.gmail.com>
	<201202231710.52667.david@olofson.net>
	<201202231714.52511.david@olofson.net>
Message-ID: <8853712D9129AD45B323A96D5396A084D6552266@oxnexch01.Rebellion.co.uk>

Ringing in your ears due to exposure to loud noise is the stereocilia (small hair cells) being damaged and falsely reporting to your brain that there is still sound vibration present. The frequency of the ringing is not a function of the sound that damaged your ears (a super loud bassy sound doesn't cause a bassy ringing in your ears).

Tom

-----Original Message-----
From: music-dsp-bounces at music.columbia.edu [mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of David Olofson
Sent: 23 February 2012 16:15
To: music-dsp at music.columbia.edu
Subject: Re: [music-dsp] a little about myself

On Thursday 23 February 2012, at 17.10.52, David Olofson <david at olofson.net> 
wrote:
> On Thursday 23 February 2012, at 16.17.38, Adam Puckett
> 
> <adotsdothmusic at gmail.com> wrote:
> > Interesting. How would you make an ear ringing sound?
[...]
> A more realistic approach might be to FFT the offending audio snippet that
> triggers the effect, remove all bands but the "too loud" peaks and then
> IFFT that to create the "ring" waveform.

Oh, wait. Probably throw in some heavy distortion before the FFT, 
approximating the mechanical distortion in the ear...? Also, the whole thing 
needs to take in account that the "too loud" level is highly frequency 
dependent.

Nothing is ever nearly as simple as it may seem at first. ;-)


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.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 theover at tiscali.nl  Thu Feb 23 12:09:22 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Thu, 23 Feb 2012 18:09:22 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <mailman.1113.1330010283.148.music-dsp@music.columbia.edu>
References: <mailman.1113.1330010283.148.music-dsp@music.columbia.edu>
Message-ID: <4F4672C2.4080807@tiscali.nl>


Thomas Young thomas.young at rebellion.co.uk wrote at Thu Feb 23 
11:39:36 EST 2012

 >..
 >  The frequency of the ringing is not a function of the sound that 
damaged your ears (a super loud bassy sound doesn't cause a bassy 
ringing in your ears)
 >..

There's real danger in mid-sized powerful speakers producing "ringing" 
tones in a very reverberant space, because the sound levels from a 
directed, say 70 Watt 8 inch speakers going round and getting tuned to 
amplify themselves can be exceedingly high, and as it appears also in 
the for the hearing sensitive mid-range. So to my knowledge *all* 
materials of official form (records, taps, vhses, cds dvds blurays, even 
tv, etc) must be checked to have those types of waves

   a) checked out to remain only moderately amplified by all common 
"room" slapback echos and reverberating "rings"
   b) in the builtup of songs and the use of the midrange, there should 
be a clear indication of how much mid-range is present, without sudden 
_averaged peaks_.

The averaging and the expansion envelope patterns possible with the 
"averaged" midrange are in my experience even to be found, emphasized 
and removed from all top audio materials, and make people put on an 
intro of Metallica on their powefull stereos not too loud, and make it 
not possible to get ringing ears from playing Abba's "Ring Ring" voices 
at really loud stereo or media-centre amps in a concrete living room, 
because all the waves which would lead to the obvious repeating 
reverberation sound-buildup have been sufficiently removed/altered.

I recall from being an early teenager that even a (for the time) big 
500W disco system in a medium sized and heavy echoing school hall could 
be used, without causing more than the hearing adjusting itself to lower 
internal volume, and of course after the show was over in half an hour 
or so back to "normal", and I'm sure after repeating the experience more 
than few times I still could easily hear leaves moving and 18 kHz test 
tones ;) ! And thus system was so loud one would have to shout at on 
another at 30 cm or less be be intelligible, I seriously doubt most home 
systems and most hobby studio systems ever get so loud. Probably it's 
more a certain transient or resonance/shear wave causing the unnatural 
ringing effect, and of course I'd like to stay way clear of that...

Theo Verelst

From alex at pixar.com  Thu Feb 23 12:53:03 2012
From: alex at pixar.com (Alex Stahl)
Date: Thu, 23 Feb 2012 09:53:03 -0800
Subject: [music-dsp] a little about myself
In-Reply-To: <8853712D9129AD45B323A96D5396A084D6552266@oxnexch01.Rebellion.co.uk>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAK1FW3WSfsJQO_q_aKYqrwyqfkYJQcFgD-Hmc3tTtBmsx+jrTg@mail.gmail.com>
	<201202231710.52667.david@olofson.net>
	<201202231714.52511.david@olofson.net>
	<8853712D9129AD45B323A96D5396A084D6552266@oxnexch01.Rebellion.co.uk>
Message-ID: <A59D5B5E-C448-4BFC-94EE-178039988094@pixar.com>

I worked with an audiologist once to make a system for people suffering from tinnitus. The idea was patients  would turn knobs until a synthesized sound matched what they heard in their heads. This would then be used to configure a special hearing aid to generate a masking tone.

The typical result was a sine wave in the two to five kilohertz range, mixed with some white noise passed through a narrow bandpass filter at about the same frequency. And/or, a second sinewave tuned a few hundred hertz away from the first, to make a rough  dissonance.

Um, this was in the mid 1970's. I was in high school, my neighbor had one of the first Putney's (EMS VC3 analog synth) in the US. My best friend's dad was a doctor, and didn't like the music I liked, and put me up to this experiment. I guess it all worked out: my friend and I stopped standing in the very front row at rock concerts, and more importantly, my neighbor ended up giving me the VCS3, that I still have :).

I assume and hope tinnitus treatments have come a long way since then. According to some current friends who have ringing in the ears, the synth patch we came up with is still pretty good...

Alex

On Feb 23, 2012, at 8:39, Thomas Young <thomas.young at rebellion.co.uk> wrote:

> Ringing in your ears due to exposure to loud noise is the stereocilia (small hair cells) being damaged and falsely reporting to your brain that there is still sound vibration present. The frequency of the ringing is not a function of the sound that damaged your ears (a super loud bassy sound doesn't cause a bassy ringing in your ears).
> 
> Tom
> 
> -----Original Message-----
> From: music-dsp-bounces at music.columbia.edu [mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of David Olofson
> Sent: 23 February 2012 16:15
> To: music-dsp at music.columbia.edu
> Subject: Re: [music-dsp] a little about myself
> 
> On Thursday 23 February 2012, at 17.10.52, David Olofson <david at olofson.net> 
> wrote:
>> On Thursday 23 February 2012, at 16.17.38, Adam Puckett
>> 
>> <adotsdothmusic at gmail.com> wrote:
>>> Interesting. How would you make an ear ringing sound?
> [...]
>> A more realistic approach might be to FFT the offending audio snippet that
>> triggers the effect, remove all bands but the "too loud" peaks and then
>> IFFT that to create the "ring" waveform.
> 
> Oh, wait. Probably throw in some heavy distortion before the FFT, 
> approximating the mechanical distortion in the ear...? Also, the whole thing 
> needs to take in account that the "too loud" level is highly frequency 
> dependent.
> 
> Nothing is ever nearly as simple as it may seem at first. ;-)
> 
> 
> -- 
> //David Olofson - Consultant, Developer, Artist, Open Source Advocate
> 
> .--- Games, examples, libraries, scripting, sound, music, graphics ---.
> |   http://consulting.olofson.net          http://olofsonarcade.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 doctorbill at gmail.com  Thu Feb 23 13:04:38 2012
From: doctorbill at gmail.com (Bill Moorier)
Date: Thu, 23 Feb 2012 10:04:38 -0800
Subject: [music-dsp] Introducing myself (Alessandro Saccoia)
Message-ID: <CAFpHsCOdXS46DbwWrLkZ79pvGzJ=d-wZ3cOZksGDKYAyQOe44Q@mail.gmail.com>

Thanks Alessandro!  Unfortunately I don't think this is the problem though.

I added a simple moving average on the parameter and it didn't make
the nasty artifacts go away.  So I rewrote the whole thing as a VST so
I can post more code without having to reveal my messy in-progress
javascript framework ;)  Here it is:
http://abstractnonsense.com/23-feb-2012-cc.html

So if I sweep the parameter smoothly with this VST loaded in Ableton,
I get nasty artifacts as the sweep is happening.  I can see from the
trace that the parameter isn't changing too quickly, and the resulting
"frequency" variable always changes by less than 0.01Hz between
samples.  But the "pan" variable ends up changing by a lot - often
nearly as much as 0.1 between samples!

Thinking about it some more, I'm getting suspicious of the code that
writes to the "pan" variable - it's supposed to be an LFO.  The thing
that makes me suspicious is, if we change the frequency, even very
slightly, between samples then we're "gluing together" two different
sine waves.  But we're not taking into account phase!  If the "time"
variable gets big (which it will), then there doesn't seem to be any
reason to believe that two slightly-different-frequency sine waves
would have almost the same values at the current "time".  The ends of
the sine waves might not match up when we glue them together!

Am I on the right track with this line of thinking?  Is there a better
way to write a variable-frequency LFO than just:
float pan = sin(2 * PI * frequency * time++ / 44100);

Thanks again,
Bill.



> Hello Bill,
> I take your question as a chance to introduce myself.
> When you sweep the input parameter you are introducing discontinuities in the output signal, and that sounds awful.
> The simplest case to figure that out in your code is imagining that you have the input variable set at 0 (pan = 0), and then abruptly you change the input parameter to a value that will make the value of the pan variable jump to 1. Both of the channels will generate a square wave, that will sound badly because of the aliasing. One solution is to control the slew rate of your parameter lowpass filtering your parameter. A simple moving average filter should do the job correctly.
>
> I have been reading this newsletter for a couple of years now, and I think that it's the best place to learn about the practical applications of musical dsp. I have been working in the digital audio field since 3 years now, even though I have been interested in computer music since my first years at the university.
> Now I am freelancing in this field, and I also get to play music more often. This is really stimulating my imagination, and I hope that in the next months I will have the time to implement some new effect or instruments.
> Thank you for all the nice things that I have learnt here,
>
> Alessandro

-- 
Bill Moorier abstractnonsense.com | @billmoorier

From thomas.young at rebellion.co.uk  Thu Feb 23 13:19:12 2012
From: thomas.young at rebellion.co.uk (Thomas Young)
Date: Thu, 23 Feb 2012 18:19:12 +0000
Subject: [music-dsp] Introducing myself (Alessandro Saccoia)
In-Reply-To: <CAFpHsCOdXS46DbwWrLkZ79pvGzJ=d-wZ3cOZksGDKYAyQOe44Q@mail.gmail.com>
References: <CAFpHsCOdXS46DbwWrLkZ79pvGzJ=d-wZ3cOZksGDKYAyQOe44Q@mail.gmail.com>
Message-ID: <8853712D9129AD45B323A96D5396A084D655232C@oxnexch01.Rebellion.co.uk>

> float pan = sin(2 * PI * frequency * time++ / 44100);

As 'time' increases, changes to 'frequency' will result in larger and larger discontinuities. You should offset (add) the change in time rather than multiplying by it.  

-----Original Message-----
From: music-dsp-bounces at music.columbia.edu [mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Bill Moorier
Sent: 23 February 2012 18:05
To: music-dsp at music.columbia.edu
Subject: Re: [music-dsp] Introducing myself (Alessandro Saccoia)

Thanks Alessandro!  Unfortunately I don't think this is the problem though.

I added a simple moving average on the parameter and it didn't make
the nasty artifacts go away.  So I rewrote the whole thing as a VST so
I can post more code without having to reveal my messy in-progress
javascript framework ;)  Here it is:
http://abstractnonsense.com/23-feb-2012-cc.html

So if I sweep the parameter smoothly with this VST loaded in Ableton,
I get nasty artifacts as the sweep is happening.  I can see from the
trace that the parameter isn't changing too quickly, and the resulting
"frequency" variable always changes by less than 0.01Hz between
samples.  But the "pan" variable ends up changing by a lot - often
nearly as much as 0.1 between samples!

Thinking about it some more, I'm getting suspicious of the code that
writes to the "pan" variable - it's supposed to be an LFO.  The thing
that makes me suspicious is, if we change the frequency, even very
slightly, between samples then we're "gluing together" two different
sine waves.  But we're not taking into account phase!  If the "time"
variable gets big (which it will), then there doesn't seem to be any
reason to believe that two slightly-different-frequency sine waves
would have almost the same values at the current "time".  The ends of
the sine waves might not match up when we glue them together!

Am I on the right track with this line of thinking?  Is there a better
way to write a variable-frequency LFO than just:
float pan = sin(2 * PI * frequency * time++ / 44100);

Thanks again,
Bill.



> Hello Bill,
> I take your question as a chance to introduce myself.
> When you sweep the input parameter you are introducing discontinuities in the output signal, and that sounds awful.
> The simplest case to figure that out in your code is imagining that you have the input variable set at 0 (pan = 0), and then abruptly you change the input parameter to a value that will make the value of the pan variable jump to 1. Both of the channels will generate a square wave, that will sound badly because of the aliasing. One solution is to control the slew rate of your parameter lowpass filtering your parameter. A simple moving average filter should do the job correctly.
>
> I have been reading this newsletter for a couple of years now, and I think that it's the best place to learn about the practical applications of musical dsp. I have been working in the digital audio field since 3 years now, even though I have been interested in computer music since my first years at the university.
> Now I am freelancing in this field, and I also get to play music more often. This is really stimulating my imagination, and I hope that in the next months I will have the time to implement some new effect or instruments.
> Thank you for all the nice things that I have learnt here,
>
> Alessandro

-- 
Bill Moorier abstractnonsense.com | @billmoorier
--
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 czhenry at gmail.com  Thu Feb 23 14:18:39 2012
From: czhenry at gmail.com (Charles Henry)
Date: Thu, 23 Feb 2012 13:18:39 -0600
Subject: [music-dsp] Introducing myself (Alessandro Saccoia)
In-Reply-To: <8853712D9129AD45B323A96D5396A084D655232C@oxnexch01.Rebellion.co.uk>
References: <CAFpHsCOdXS46DbwWrLkZ79pvGzJ=d-wZ3cOZksGDKYAyQOe44Q@mail.gmail.com>
	<8853712D9129AD45B323A96D5396A084D655232C@oxnexch01.Rebellion.co.uk>
Message-ID: <CAPfmNOFWNjCwHb-KaGmqNW6RsT_hGLcLWZgKq5BZ-QZBFAzk1Q@mail.gmail.com>

Hi Thomas

Your interpretation seems right, but I'd recommend to use the
frequency variable to calculate your increment size (phase per
sample).

phase += 2*PI*frequency/44100;
pan = sin(phase);

Chuck

On Thu, Feb 23, 2012 at 12:19 PM, Thomas Young
<thomas.young at rebellion.co.uk> wrote:
>> float pan = sin(2 * PI * frequency * time++ / 44100);
>
> As 'time' increases, changes to 'frequency' will result in larger and larger discontinuities. You should offset (add) the change in time rather than multiplying by it.
>
> -----Original Message-----
> From: music-dsp-bounces at music.columbia.edu [mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Bill Moorier
> Sent: 23 February 2012 18:05
> To: music-dsp at music.columbia.edu
> Subject: Re: [music-dsp] Introducing myself (Alessandro Saccoia)
>
> Thanks Alessandro! ?Unfortunately I don't think this is the problem though.
>
> I added a simple moving average on the parameter and it didn't make
> the nasty artifacts go away. ?So I rewrote the whole thing as a VST so
> I can post more code without having to reveal my messy in-progress
> javascript framework ;) ?Here it is:
> http://abstractnonsense.com/23-feb-2012-cc.html
>
> So if I sweep the parameter smoothly with this VST loaded in Ableton,
> I get nasty artifacts as the sweep is happening. ?I can see from the
> trace that the parameter isn't changing too quickly, and the resulting
> "frequency" variable always changes by less than 0.01Hz between
> samples. ?But the "pan" variable ends up changing by a lot - often
> nearly as much as 0.1 between samples!
>
> Thinking about it some more, I'm getting suspicious of the code that
> writes to the "pan" variable - it's supposed to be an LFO. ?The thing
> that makes me suspicious is, if we change the frequency, even very
> slightly, between samples then we're "gluing together" two different
> sine waves. ?But we're not taking into account phase! ?If the "time"
> variable gets big (which it will), then there doesn't seem to be any
> reason to believe that two slightly-different-frequency sine waves
> would have almost the same values at the current "time". ?The ends of
> the sine waves might not match up when we glue them together!
>
> Am I on the right track with this line of thinking? ?Is there a better
> way to write a variable-frequency LFO than just:
> float pan = sin(2 * PI * frequency * time++ / 44100);
>
> Thanks again,
> Bill.
>
>
>
>> Hello Bill,
>> I take your question as a chance to introduce myself.
>> When you sweep the input parameter you are introducing discontinuities in the output signal, and that sounds awful.
>> The simplest case to figure that out in your code is imagining that you have the input variable set at 0 (pan = 0), and then abruptly you change the input parameter to a value that will make the value of the pan variable jump to 1. Both of the channels will generate a square wave, that will sound badly because of the aliasing. One solution is to control the slew rate of your parameter lowpass filtering your parameter. A simple moving average filter should do the job correctly.
>>
>> I have been reading this newsletter for a couple of years now, and I think that it's the best place to learn about the practical applications of musical dsp. I have been working in the digital audio field since 3 years now, even though I have been interested in computer music since my first years at the university.
>> Now I am freelancing in this field, and I also get to play music more often. This is really stimulating my imagination, and I hope that in the next months I will have the time to implement some new effect or instruments.
>> Thank you for all the nice things that I have learnt here,
>>
>> Alessandro
>
> --
> Bill Moorier abstractnonsense.com | @billmoorier
> --
> 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 jerry at novadsp.com  Thu Feb 23 14:28:38 2012
From: jerry at novadsp.com (Jerry Evans)
Date: Thu, 23 Feb 2012 19:28:38 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <A59D5B5E-C448-4BFC-94EE-178039988094@pixar.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAK1FW3WSfsJQO_q_aKYqrwyqfkYJQcFgD-Hmc3tTtBmsx+jrTg@mail.gmail.com>
	<201202231710.52667.david@olofson.net>
	<201202231714.52511.david@olofson.net>
	<8853712D9129AD45B323A96D5396A084D6552266@oxnexch01.Rebellion.co.uk>
	<A59D5B5E-C448-4BFC-94EE-178039988094@pixar.com>
Message-ID: <4F469366.2090106@NovaDSP.com>


On 23/02/2012 17:53, Alex Stahl wrote:
> Um, this was in the mid 1970's. I was in high school, my neighbor had one of the first Putney's (EMS VC3 analog synth) in the US. ... and more importantly, my neighbor ended up giving me the VCS3, that I still have:).
I think you need to big up the smiley count there Alex!



From philburk at mobileer.com  Thu Feb 23 14:50:01 2012
From: philburk at mobileer.com (Phil Burk)
Date: Thu, 23 Feb 2012 11:50:01 -0800
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F463C9B.6030205@tiscali.nl>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
Message-ID: <4F469869.8020707@mobileer.com>

Hello Theo,

On 2/23/12 5:18 AM, Theo Verelst wrote:
 > What's the challenge being met by Google with their wavy lines?

They were celebrating Heinrich Hertz' 155th birthday.

> It clearly isn't a graphics problem, nor a particularly good synthesis
> engine being promoted

I'm sorry you don't like JSyn. Is there anything in particular that I 
can improve? Have you tried developing a program using JSyn?

My goal in developing JSyn was to provide a synthesis API for Java 
programmers that could run in a web browser. There are other synthesis 
engines, eg. SuperCollider and Chuck, that are more powerful than JSyn. 
But they have their own language and are not easily used from Java.

Also please note that there is no connection between Google and JSyn. I 
was just responding to their doodle.

 > (the page with the application is fun and maybe
 > sound fun, but isn't put forward as the next big thing in audio).

I'm puzzled. Does it have to be the next big thing? I obviously just did 
it for fun because we were having fun talking about the Google doodle. 
Some folks enjoyed it. That's enough for me.

Phil Burk
www.softsynth.com

From adotsdothmusic at gmail.com  Thu Feb 23 14:59:43 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Thu, 23 Feb 2012 14:59:43 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F469869.8020707@mobileer.com>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl> <4F469869.8020707@mobileer.com>
Message-ID: <CAK1FW3W_-14Xj=Li-Uge_=eafwVhx--jx-9gVFiB7gyYAwNsbQ@mail.gmail.com>

Phil,

I don't think Theo was referring to JSyn, but to the algorithm as the
"synth engine" that may not be the "next big thing."

On 2/23/12, Phil Burk <philburk at mobileer.com> wrote:
> Hello Theo,
>
> On 2/23/12 5:18 AM, Theo Verelst wrote:
>  > What's the challenge being met by Google with their wavy lines?
>
> They were celebrating Heinrich Hertz' 155th birthday.
>
>> It clearly isn't a graphics problem, nor a particularly good synthesis
>> engine being promoted
>
> I'm sorry you don't like JSyn. Is there anything in particular that I
> can improve? Have you tried developing a program using JSyn?
>
> My goal in developing JSyn was to provide a synthesis API for Java
> programmers that could run in a web browser. There are other synthesis
> engines, eg. SuperCollider and Chuck, that are more powerful than JSyn.
> But they have their own language and are not easily used from Java.
>
> Also please note that there is no connection between Google and JSyn. I
> was just responding to their doodle.
>
>  > (the page with the application is fun and maybe
>  > sound fun, but isn't put forward as the next big thing in audio).
>
> I'm puzzled. Does it have to be the next big thing? I obviously just did
> it for fun because we were having fun talking about the Google doodle.
> Some folks enjoyed it. That's enough for me.
>
> Phil Burk
> www.softsynth.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 doctorbill at gmail.com  Thu Feb 23 16:31:08 2012
From: doctorbill at gmail.com (Bill Moorier)
Date: Thu, 23 Feb 2012 13:31:08 -0800
Subject: [music-dsp] Introducing myself (Alessandro Saccoia)
Message-ID: <CAFpHsCN3AZj_oKFrwkkiiiq+Thg=xr1dkRZhbOkRzw2BD1hj0g@mail.gmail.com>

This works fantastically, and is very intuitive too!  Thanks!


> Your interpretation seems right, but I'd recommend to use the
> frequency variable to calculate your increment size (phase per
> sample).
>
> phase += 2*PI*frequency/44100;
> pan = sin(phase);
>
> Chuck

-- 
Bill Moorier abstractnonsense.com | @billmoorier

From douglas at music.columbia.edu  Thu Feb 23 18:27:05 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Thu, 23 Feb 2012 18:27:05 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
Message-ID: <4F46CB49.307@music.columbia.edu>


But it's Google!!! Surely they have the resources to generate a sinewave 
animation that features an actual sinewave if they want to.

I know it's a silly thing to rant about. But the Google front page has a 
lot of reach (how many millions of hits a day?), and it gives me deep 
nerd pain to think about something so fundamental and so beautiful -- 
yes, there's a deep connection between a circle and a sinewave! -- being 
botched.

I'll stop ranting now!

douglas

On 2/23/12 9:53 AM, Didier Dambrin wrote:
> There's also the fact that it's not easy to draw a sinewave in existing
> tools out there.
> Those who have drawn GUIs here and had to show waveforms know what I
> mean, I remember I've ended up with google-like non-sines as I was
> trying to draw a sine using 2 half ellipses. It may be what happened to
> the guy who drew that.
> Ask yourself how you'd do it.. the most accurate would be to use a real
> plot of a sine, but now good luck converting that to vectors in a proper
> image editing tool, for a nice antialiased display.
>


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


From contact at quikquak.com  Thu Feb 23 21:15:09 2012
From: contact at quikquak.com (QuikQuak)
Date: Fri, 24 Feb 2012 02:15:09 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F46CB49.307@music.columbia.edu>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
Message-ID: <BB7006E2-2216-4E16-893F-280F0B2316AA@quikquak.com>

They are too busy in money making decision madness to focus on what the new guy does for the daily graphics job for minimum wage, something that goes like "do a thing that's animated and looks different and cool and get it on my computer by lunch time!"
So they do that and go for a burger, and all is done for the day. : )




On 23 Feb 2012, at 23:27, douglas repetto <douglas at music.columbia.edu> wrote:

> 
> But it's Google!!! Surely they have the resources to generate a sinewave animation that features an actual sinewave if they want to.
> 
> I know it's a silly thing to rant about. But the Google front page has a lot of reach (how many millions of hits a day?), and it gives me deep nerd pain to think about something so fundamental and so beautiful -- yes, there's a deep connection between a circle and a sinewave! -- being botched.
> 
> I'll stop ranting now!
> 
> douglas
> 
> On 2/23/12 9:53 AM, Didier Dambrin wrote:
>> There's also the fact that it's not easy to draw a sinewave in existing
>> tools out there.
>> Those who have drawn GUIs here and had to show waveforms know what I
>> mean, I remember I've ended up with google-like non-sines as I was
>> trying to draw a sine using 2 half ellipses. It may be what happened to
>> the guy who drew that.
>> Ask yourself how you'd do it.. the most accurate would be to use a real
>> plot of a sine, but now good luck converting that to vectors in a proper
>> image editing tool, for a nice antialiased display.
>> 
> 
> 
> -- 
> ............................................... http://artbots.org
> .....douglas.....irving........................ http://dorkbot.org
> .......................... http://music.columbia.edu/cmc/music-dsp
> ...........repetto............. http://music.columbia.edu/organism
> ............................... http://music.columbia.edu/~douglas
> 
> --
> 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  Thu Feb 23 21:36:05 2012
From: didid at skynet.be (Didier Dambrin)
Date: Fri, 24 Feb 2012 03:36:05 +0100
Subject: [music-dsp] google's non-sine
In-Reply-To: <BB7006E2-2216-4E16-893F-280F0B2316AA@quikquak.com>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu><4F463C9B.6030205@tiscali.nl><D22AC5EFC0A4433A92176571208A7E28@ProprietairePC><4F46CB49.307@music.columbia.edu>
	<BB7006E2-2216-4E16-893F-280F0B2316AA@quikquak.com>
Message-ID: <1D9E37CBF9484B10BEAD0C492E52F936@ProprietairePC>

they actually have a team behind doodles
http://www.google.com/doodles/about
http://www.google.com/doodle4google/press.html
& even a shop http://www.zazzle.fr/googledoodles

it's a pretty big thing, if you consider that it's probably the most seen 
"art" on earth, if you think of it



-----Message d'origine----- 
From: QuikQuak
Sent: Friday, February 24, 2012 3:15 AM
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] google's non-sine

They are too busy in money making decision madness to focus on what the new 
guy does for the daily graphics job for minimum wage, something that goes 
like "do a thing that's animated and looks different and cool and get it on 
my computer by lunch time!"
So they do that and go for a burger, and all is done for the day. : )




On 23 Feb 2012, at 23:27, douglas repetto <douglas at music.columbia.edu> 
wrote:

>
> But it's Google!!! Surely they have the resources to generate a sinewave 
> animation that features an actual sinewave if they want to.
>
> I know it's a silly thing to rant about. But the Google front page has a 
> lot of reach (how many millions of hits a day?), and it gives me deep nerd 
> pain to think about something so fundamental and so beautiful -- yes, 
> there's a deep connection between a circle and a sinewave! -- being 
> botched.
>
> I'll stop ranting now!
>
> douglas
>
> On 2/23/12 9:53 AM, Didier Dambrin wrote:
>> There's also the fact that it's not easy to draw a sinewave in existing
>> tools out there.
>> Those who have drawn GUIs here and had to show waveforms know what I
>> mean, I remember I've ended up with google-like non-sines as I was
>> trying to draw a sine using 2 half ellipses. It may be what happened to
>> the guy who drew that.
>> Ask yourself how you'd do it.. the most accurate would be to use a real
>> plot of a sine, but now good luck converting that to vectors in a proper
>> image editing tool, for a nice antialiased display.
>>
>
>
> -- 
> ............................................... http://artbots.org
> .....douglas.....irving........................ http://dorkbot.org
> .......................... http://music.columbia.edu/cmc/music-dsp
> ...........repetto............. http://music.columbia.edu/organism
> ............................... http://music.columbia.edu/~douglas
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, 
> dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp


-----
Aucun virus trouve dans ce message.
Analyse effectuee par AVG - www.avg.fr
Version: 2012.0.1913 / Base de donnees virale: 2114/4827 - Date: 23/02/2012 


From contact at quikquak.com  Thu Feb 23 22:04:12 2012
From: contact at quikquak.com (QuikQuak)
Date: Fri, 24 Feb 2012 03:04:12 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <1D9E37CBF9484B10BEAD0C492E52F936@ProprietairePC>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
	<BB7006E2-2216-4E16-893F-280F0B2316AA@quikquak.com>
	<1D9E37CBF9484B10BEAD0C492E52F936@ProprietairePC>
Message-ID: <21676368-20E3-44B6-BB2C-DAE66BBF257D@quikquak.com>


And only noticed by four people out of 1 billion unique users a month?
Why would they care? A flash, and the day is over. 


On 24 Feb 2012, at 02:36, "Didier Dambrin" <didid at skynet.be> wrote:

> they actually have a team behind doodles
> http://www.google.com/doodles/about
> http://www.google.com/doodle4google/press.html
> & even a shop http://www.zazzle.fr/googledoodles
> 
> it's a pretty big thing, if you consider that it's probably the most seen "art" on earth, if you think of it
> 
> 
> 
> -----Message d'origine----- From: QuikQuak
> Sent: Friday, February 24, 2012 3:15 AM
> To: A discussion list for music-related DSP
> Subject: Re: [music-dsp] google's non-sine
> 
> They are too busy in money making decision madness to focus on what the new guy does for the daily graphics job for minimum wage, something that goes like "do a thing that's animated and looks different and cool and get it on my computer by lunch time!"
> So they do that and go for a burger, and all is done for the day. : )
> 
> 
> 
> 
> On 23 Feb 2012, at 23:27, douglas repetto <douglas at music.columbia.edu> wrote:
> 
>> 
>> But it's Google!!! Surely they have the resources to generate a sinewave animation that features an actual sinewave if they want to.
>> 
>> I know it's a silly thing to rant about. But the Google front page has a lot of reach (how many millions of hits a day?), and it gives me deep nerd pain to think about something so fundamental and so beautiful -- yes, there's a deep connection between a circle and a sinewave! -- being botched.
>> 
>> I'll stop ranting now!
>> 
>> douglas
>> 
>> On 2/23/12 9:53 AM, Didier Dambrin wrote:
>>> There's also the fact that it's not easy to draw a sinewave in existing
>>> tools out there.
>>> Those who have drawn GUIs here and had to show waveforms know what I
>>> mean, I remember I've ended up with google-like non-sines as I was
>>> trying to draw a sine using 2 half ellipses. It may be what happened to
>>> the guy who drew that.
>>> Ask yourself how you'd do it.. the most accurate would be to use a real
>>> plot of a sine, but now good luck converting that to vectors in a proper
>>> image editing tool, for a nice antialiased display.
>>> 
>> 
>> 
>> -- 
>> ............................................... http://artbots.org
>> .....douglas.....irving........................ http://dorkbot.org
>> .......................... http://music.columbia.edu/cmc/music-dsp
>> ...........repetto............. http://music.columbia.edu/organism
>> ............................... http://music.columbia.edu/~douglas
>> 
>> --
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
> 
> 
> -----
> Aucun virus trouve dans ce message.
> Analyse effectuee par AVG - www.avg.fr
> Version: 2012.0.1913 / Base de donnees virale: 2114/4827 - Date: 23/02/2012 
> --
> 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 garton at columbia.edu  Thu Feb 23 23:01:43 2012
From: garton at columbia.edu (Brad Garton)
Date: Thu, 23 Feb 2012 23:01:43 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<1BB2D695-D3E1-4FFF-BB74-1710CBD3057D@qwest.net>
	<CAML4ZX5+jiw_e1XDBuz=3ZQUDh0+8Gdn=PmhFoxbgiEZ7GfKsg@mail.gmail.com>
	<CAK1FW3U4wJeCikoLUs28+PEHq9OFWJ2eu+UJf4S6983PS703TQ@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!
	p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
Message-ID: <698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>

Joining this conversation a little late, but what the heck...

On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote:

> I got my start in computer music in 1986 or 1987 at the woof group at
> Columbia University using cmix on a Sun workstation.

Michael was a stalwart back in those wild Ancient Days!

> cmix has never
> had a runtime synthesis language; even now instrument code has to be
> written in C++.

One possible misconception -- by "runtime synthesis language" I'm sure Michael
means a design language for instantiating synthesis/DSP algorithms *in real time*
as the language/synth-engine is running.  I tend to think of languages like ChucK
or Supercollider more in that sense than Csound, and even SC differentiates between
the language and then sending the synth-code to the server.

RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has now for almost
two decades.  The trade-off in writing C/C++ code is that it is one of the most
efficient languages currently in use.  We've also taken a route which allows it
to be 'imbedded' in other environments.  rtcmix~ was the first of the 'language
objects' I did for max/msp.  iRTcmix (RTcmix in iOS) even passes muster at the
clamped App Store, check out iLooch for fun:  http://music.columbia.edu/~brad/ilooch/
(almost 2 years old now).

For me the deeper issue is how these various languages/environments shape
creative thinking.  I tend to like the way I think about music, especially algorthmic
composityon, using the RTcmix parse language than I do in, say SC.  Each system
has things 'it likes to do', and i think it important to be aware of these.

brad
http://music.columbia.edu/~brad


From earlevel at earlevel.com  Fri Feb 24 02:56:26 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Thu, 23 Feb 2012 23:56:26 -0800
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F46CB49.307@music.columbia.edu>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
Message-ID: <E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>

Eh, I still say they weren't going for a sine wave at all. Look at their other doodles. I'm sure that their designers would have felt that a sine wave would have missed the point for them.

http://www.zazzle.com/robert_schumanns_200th_birthday_tshirt-235517387819488097


On Feb 23, 2012, at 3:27 PM, douglas repetto wrote:
> 
> But it's Google!!! Surely they have the resources to generate a sinewave animation that features an actual sinewave if they want to.
> 
> I know it's a silly thing to rant about. But the Google front page has a lot of reach (how many millions of hits a day?), and it gives me deep nerd pain to think about something so fundamental and so beautiful -- yes, there's a deep connection between a circle and a sinewave! -- being botched.
> 
> I'll stop ranting now!
> 
> douglas
> 
> On 2/23/12 9:53 AM, Didier Dambrin wrote:
>> There's also the fact that it's not easy to draw a sinewave in existing
>> tools out there.
>> Those who have drawn GUIs here and had to show waveforms know what I
>> mean, I remember I've ended up with google-like non-sines as I was
>> trying to draw a sine using 2 half ellipses. It may be what happened to
>> the guy who drew that.
>> Ask yourself how you'd do it.. the most accurate would be to use a real
>> plot of a sine, but now good luck converting that to vectors in a proper
>> image editing tool, for a nice antialiased display.
>> 
> 
> 
> -- 
> ............................................... http://artbots.org
> .....douglas.....irving........................ http://dorkbot.org
> .......................... http://music.columbia.edu/cmc/music-dsp
> ...........repetto............. http://music.columbia.edu/organism
> ............................... http://music.columbia.edu/~douglas
> 
> --


From rossb-lists at audiomulch.com  Fri Feb 24 03:25:29 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Fri, 24 Feb 2012 19:25:29 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!
	p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
Message-ID: <4F474979.1090307@audiomulch.com>

Hi Brad,

On 24/02/2012 3:01 PM, Brad Garton wrote:
> Joining this conversation a little late, but what the heck...

Me too...

> On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote:
>
>> I got my start in computer music in 1986 or 1987 at the woof group at
>> Columbia University using cmix on a Sun workstation.
>
> Michael was a stalwart back in those wild Ancient Days!
>
>> cmix has never
>> had a runtime synthesis language; even now instrument code has to be
>> written in C++.
>
> One possible misconception -- by "runtime synthesis language" I'm sure Michael
> means a design language for instantiating synthesis/DSP algorithms *in real time*
> as the language/synth-engine is running.  I tend to think of languages like ChucK
> or Supercollider more in that sense than Csound, and even SC differentiates between
> the language and then sending the synth-code to the server.

My reading would be that Michael may be implying that there is a 
difference between interpretation and compilation.

CSound does not have a runtime synthesis language either. It's a 
compiler with a VM. There is no way to re-write the code while it's running.

SC3 is very limited in this regard too (you can restructure the synth 
graph but there's no way to edit a synthdef except by replacing it, and 
there's no language code running sample synchronously in the server). So 
you have a kind of runtime compilation model.

I didn't get much of a chance to play with SC1 but my understanding is 
that you could actually process samples in the synthesis loop (like you 
can with cmix). To me this is real runtime synthesis. You get this in 
C/C++ too -- your program can make signal dependent runtime decisions 
about what synthesis code to execute.

Anything else is just plugging unit generators together, which is 
limiting in many situations (one reason I abandoned these kind of 
environments and started writing my algorithms in C++).


> RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has now for almost
> two decades.  The trade-off in writing C/C++ code is that it is one of the most
> efficient languages currently in use.  We've also taken a route which allows it
> to be 'imbedded' in other environments.  rtcmix~ was the first of the 'language
> objects' I did for max/msp.  iRTcmix (RTcmix in iOS) even passes muster at the
> clamped App Store, check out iLooch for fun:  http://music.columbia.edu/~brad/ilooch/
> (almost 2 years old now).
>
> For me the deeper issue is how these various languages/environments shape
> creative thinking.  I tend to like the way I think about music, especially algorthmic
> composityon, using the RTcmix parse language than I do in, say SC.  Each system
> has things 'it likes to do', and i think it important to be aware of these.

Indeed.

The problem with "plug unit generators languages" for me is that they 
privilege the process (network of unit generators) over the content (the 
signal). Programming in C++ makes the signal efficiently accessible. 
Nothing wrong with patchable environments of course :) just that their 
not the whole story.

Ross.





From thomas.young at rebellion.co.uk  Fri Feb 24 05:05:50 2012
From: thomas.young at rebellion.co.uk (Thomas Young)
Date: Fri, 24 Feb 2012 10:05:50 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
	<E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>
Message-ID: <8853712D9129AD45B323A96D5396A084D6552401@oxnexch01.Rebellion.co.uk>

Yes, I'm pretty sure Google programmers are smart enough to render a sine wave should they so desire. It was obviously an artistic decision, be it a somewhat misguided one :P

-----Original Message-----
From: music-dsp-bounces at music.columbia.edu [mailto:music-dsp-bounces at music.columbia.edu] On Behalf Of Nigel Redmon
Sent: 24 February 2012 07:56
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] google's non-sine

Eh, I still say they weren't going for a sine wave at all. Look at their other doodles. I'm sure that their designers would have felt that a sine wave would have missed the point for them.

http://www.zazzle.com/robert_schumanns_200th_birthday_tshirt-235517387819488097


On Feb 23, 2012, at 3:27 PM, douglas repetto wrote:
> 
> But it's Google!!! Surely they have the resources to generate a sinewave animation that features an actual sinewave if they want to.
> 
> I know it's a silly thing to rant about. But the Google front page has a lot of reach (how many millions of hits a day?), and it gives me deep nerd pain to think about something so fundamental and so beautiful -- yes, there's a deep connection between a circle and a sinewave! -- being botched.
> 
> I'll stop ranting now!
> 
> douglas
> 
> On 2/23/12 9:53 AM, Didier Dambrin wrote:
>> There's also the fact that it's not easy to draw a sinewave in existing
>> tools out there.
>> Those who have drawn GUIs here and had to show waveforms know what I
>> mean, I remember I've ended up with google-like non-sines as I was
>> trying to draw a sine using 2 half ellipses. It may be what happened to
>> the guy who drew that.
>> Ask yourself how you'd do it.. the most accurate would be to use a real
>> plot of a sine, but now good luck converting that to vectors in a proper
>> image editing tool, for a nice antialiased display.
>> 
> 
> 
> -- 
> ............................................... http://artbots.org
> .....douglas.....irving........................ http://dorkbot.org
> .......................... http://music.columbia.edu/cmc/music-dsp
> ...........repetto............. http://music.columbia.edu/organism
> ............................... http://music.columbia.edu/~douglas
> 
> --

--
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 emanuel.landeholm at gmail.com  Fri Feb 24 06:22:03 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Fri, 24 Feb 2012 12:22:03 +0100
Subject: [music-dsp] google's non-sine
In-Reply-To: <CAK1FW3W56q_sTdkbc8tAmRUnbcC+a0HUFhyTi60+CJZCbgZQJg@mail.gmail.com>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<CAML4ZX42bJF76JcpRBbd6dQ8Wibm5BGkRGyJ_YqmtxdoT94fyQ@mail.gmail.com>
	<CAK1FW3W56q_sTdkbc8tAmRUnbcC+a0HUFhyTi60+CJZCbgZQJg@mail.gmail.com>
Message-ID: <CAML4ZX5jdpPohYesSiZkJTDfyFBu9c1QR4Uce27LHo1Jtpsovg@mail.gmail.com>

Non-uniform rational B-splines. WP has a good page on them.
http://en.wikipedia.org/wiki/Non-uniform_rational_B-spline

On Thu, Feb 23, 2012 at 4:58 PM, Adam Puckett <adotsdothmusic at gmail.com> wrote:
> What is NURBS?
>
> On 2/23/12, Emanuel Landeholm <emanuel.landeholm at gmail.com> wrote:
>> NURBS should do the trick.

From vze26m98 at optonline.net  Fri Feb 24 06:45:35 2012
From: vze26m98 at optonline.net (Charles Turner)
Date: Fri, 24 Feb 2012 06:45:35 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F474979.1090307@audiomulch.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
Message-ID: <F12E3844-4183-4FAB-9C9F-C1A88FC1568E@optonline.net>

On Feb 24, 2012, at 3:25 AM, Ross Bencina wrote:

> To me this is real runtime synthesis. You get this in C/C++ too -- your program can make signal dependent runtime decisions about what synthesis code to execute.
> 
> Anything else is just plugging unit generators together, which is limiting in many situations (one reason I abandoned these kind of environments and started writing my algorithms in C++).

Hi Ross-

Has it escaped me that Audio Mulch supports this kind of interpretation?

Best wishes, Charles



From adotsdothmusic at gmail.com  Fri Feb 24 07:52:25 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Fri, 24 Feb 2012 07:52:25 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <F12E3844-4183-4FAB-9C9F-C1A88FC1568E@optonline.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<F12E3844-4183-4FAB-9C9F-C1A88FC1568E@optonline.net>
Message-ID: <CAK1FW3X2VJ5ODGhh_28OdEZF5PhfJDBZjeiKY-rpmsPrMaKftg@mail.gmail.com>

My biggest concern with audio programming languages is the audio
callback. I wonder if there is a way on Windows with the classic
mmsystem.h and winmm to get low latency? Maybe call the function more
times? I'm not sure how they really work though, I'd just like a way
to render audio in realtime without "dropped calls," if you will. It
seems eSpeak does a pretty good job of this (NVDA's speech
synthesizer). I'll have a look at Csound's winmm realtime code to try
to understand how it works.

On 2/24/12, Charles Turner <vze26m98 at optonline.net> wrote:
> On Feb 24, 2012, at 3:25 AM, Ross Bencina wrote:
>
>> To me this is real runtime synthesis. You get this in C/C++ too -- your
>> program can make signal dependent runtime decisions about what synthesis
>> code to execute.
>>
>> Anything else is just plugging unit generators together, which is limiting
>> in many situations (one reason I abandoned these kind of environments and
>> started writing my algorithms in C++).
>
> Hi Ross-
>
> Has it escaped me that Audio Mulch supports this kind of interpretation?
>
> Best wishes, Charles
>
>
> --
> 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  Fri Feb 24 08:49:12 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Fri, 24 Feb 2012 13:49:12 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3X2VJ5ODGhh_28OdEZF5PhfJDBZjeiKY-rpmsPrMaKftg@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>	<4F43A490.5030309@audioimagination.com>	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>	<4F43A92D.2070407@audioimagination.com>	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<F12E3844-4183-4FAB-9C9F-C1A88FC1568E@optonline.net>
	<CAK1FW3X2VJ5ODGhh_28OdEZF5PhfJDBZjeiKY-rpmsPrMaKftg@mail.gmail.com>
Message-ID: <4F479558.2020002@blueyonder.co.uk>

On 24/02/2012 12:52, Adam Puckett wrote:
> My biggest concern with audio programming languages is the audio
> callback. I wonder if there is a way on Windows with the classic
> mmsystem.h and winmm to get low latency?


This is borderline obsolete these days. It was never possible to get 
what musicians would call low latency (i.e. below 10msecs) using MME; it 
was not really designed for "real-time" use anyway, but to support 
simple file playback and recording. You needed at least DirectSound 
(which nominally gives you direct access to  hardware buffers, at the 
cost of having to manage double-buffering yourself). With the emergence 
of Windows2000, you were also limited by the overhead of the Kernel 
Mixer engine, which sits between the application and the audio hardware, 
and adds some 30ms of latency (this was introduced partly to support 
multi-clent access, but mostly to handle as transparently as possible 
the rendering of multi-channel streams such as 5.1 to stereo or 
otherwise unmatched hardware). Developers (e.g. Cakewalk for "Sonar") 
worked around the KM layer by using very low-level IOCTL calls to the 
hardware (some undocumented), generally called "Kernel Streaming". This 
eventually became a more or less public and documented API, and 
portaudio for example supports both Kernel Streaming and the even more 
recent WASAPI API for Vista onwards.

An added problem, once these newer systems became more generally 
adopted, was that soundcard manufacturers sometimes only provided a 
skeleton and far from optimised MME driver, purely to support "legacy" 
applications, while everyone needing low-latency interactive audio knew 
that DirectSound or Kernel Streaming (or ASIO, of course) were the only 
systems to use, especially in full-duplex conditions.


Richard Dobson


From michael.gogins at gmail.com  Fri Feb 24 09:34:30 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Fri, 24 Feb 2012 09:34:30 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F474979.1090307@audiomulch.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
Message-ID: <CAFswGP2TDHAoU-0EP=_Hrq89eR6a3jT_kinzOVYk4ajRxrixVQ@mail.gmail.com>

Ross is correct. I know that RTcmix supports real-time audio - I was
using it that way just last week. What I meant is that before you run
a new synthesis routine in RTcmix, you have to compile its C++ source
code.

I was trying to get LuaJIT to do this (run DSP code immediately). I
created the infrastructure for this and it works. Unfortunately, it
only works reliably for simple test cases. Complex code causes LuaJIT
to crash. Not sure why. This kind of thing works much better in
Csound.

That's one reason I'm taking a closer look at working directly in C++.
That, in turn, makes RTcmix itself more attractive in some ways.

Best,
Mike

On Fri, Feb 24, 2012 at 3:25 AM, Ross Bencina
<rossb-lists at audiomulch.com> wrote:
> Hi Brad,
>
>
> On 24/02/2012 3:01 PM, Brad Garton wrote:
>>
>> Joining this conversation a little late, but what the heck...
>
>
> Me too...
>
>
>> On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote:
>>
>>> I got my start in computer music in 1986 or 1987 at the woof group at
>>> Columbia University using cmix on a Sun workstation.
>>
>>
>> Michael was a stalwart back in those wild Ancient Days!
>>
>>> cmix has never
>>> had a runtime synthesis language; even now instrument code has to be
>>> written in C++.
>>
>>
>> One possible misconception -- by "runtime synthesis language" I'm sure
>> Michael
>> means a design language for instantiating synthesis/DSP algorithms *in
>> real time*
>> as the language/synth-engine is running. ?I tend to think of languages
>> like ChucK
>> or Supercollider more in that sense than Csound, and even SC
>> differentiates between
>> the language and then sending the synth-code to the server.
>
>
> My reading would be that Michael may be implying that there is a difference
> between interpretation and compilation.
>
> CSound does not have a runtime synthesis language either. It's a compiler
> with a VM. There is no way to re-write the code while it's running.
>
> SC3 is very limited in this regard too (you can restructure the synth graph
> but there's no way to edit a synthdef except by replacing it, and there's no
> language code running sample synchronously in the server). So you have a
> kind of runtime compilation model.
>
> I didn't get much of a chance to play with SC1 but my understanding is that
> you could actually process samples in the synthesis loop (like you can with
> cmix). To me this is real runtime synthesis. You get this in C/C++ too --
> your program can make signal dependent runtime decisions about what
> synthesis code to execute.
>
> Anything else is just plugging unit generators together, which is limiting
> in many situations (one reason I abandoned these kind of environments and
> started writing my algorithms in C++).
>
>
>
>> RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has
>> now for almost
>> two decades. ?The trade-off in writing C/C++ code is that it is one of the
>> most
>> efficient languages currently in use. ?We've also taken a route which
>> allows it
>> to be 'imbedded' in other environments. ?rtcmix~ was the first of the
>> 'language
>> objects' I did for max/msp. ?iRTcmix (RTcmix in iOS) even passes muster at
>> the
>> clamped App Store, check out iLooch for fun:
>> ?http://music.columbia.edu/~brad/ilooch/
>> (almost 2 years old now).
>>
>> For me the deeper issue is how these various languages/environments shape
>> creative thinking. ?I tend to like the way I think about music, especially
>> algorthmic
>> composityon, using the RTcmix parse language than I do in, say SC. ?Each
>> system
>> has things 'it likes to do', and i think it important to be aware of
>> these.
>
>
> Indeed.
>
> The problem with "plug unit generators languages" for me is that they
> privilege the process (network of unit generators) over the content (the
> signal). Programming in C++ makes the signal efficiently accessible. Nothing
> wrong with patchable environments of course :) just that their not the whole
> story.
>
> 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



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

From adotsdothmusic at gmail.com  Fri Feb 24 12:50:42 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Fri, 24 Feb 2012 12:50:42 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP2TDHAoU-0EP=_Hrq89eR6a3jT_kinzOVYk4ajRxrixVQ@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<CAFswGP2TDHAoU-0EP=_Hrq89eR6a3jT_kinzOVYk4ajRxrixVQ@mail.gmail.com>
Message-ID: <CAK1FW3XC02TqX4z7bT_=LVvCutZ-Z380xV3YesfPR=rpdvNoOw@mail.gmail.com>

Thanks for the explanation of winmm.

Is there a minimal example of a complete working program that renders
a sine wave in realtime using Kernel Streaming that will compile with
just a bare MinGW install? (I have the latest GCC 4.5 on Windows XP
Service Pack 3). Which DirectX SDK do I need, the one from Microsoft,
or the one from http://libsdl.org/extras/win32?

Thanks,

Adam

On 2/24/12, Michael Gogins <michael.gogins at gmail.com> wrote:
> Ross is correct. I know that RTcmix supports real-time audio - I was
> using it that way just last week. What I meant is that before you run
> a new synthesis routine in RTcmix, you have to compile its C++ source
> code.
>
> I was trying to get LuaJIT to do this (run DSP code immediately). I
> created the infrastructure for this and it works. Unfortunately, it
> only works reliably for simple test cases. Complex code causes LuaJIT
> to crash. Not sure why. This kind of thing works much better in
> Csound.
>
> That's one reason I'm taking a closer look at working directly in C++.
> That, in turn, makes RTcmix itself more attractive in some ways.
>
> Best,
> Mike
>
> On Fri, Feb 24, 2012 at 3:25 AM, Ross Bencina
> <rossb-lists at audiomulch.com> wrote:
>> Hi Brad,
>>
>>
>> On 24/02/2012 3:01 PM, Brad Garton wrote:
>>>
>>> Joining this conversation a little late, but what the heck...
>>
>>
>> Me too...
>>
>>
>>> On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote:
>>>
>>>> I got my start in computer music in 1986 or 1987 at the woof group at
>>>> Columbia University using cmix on a Sun workstation.
>>>
>>>
>>> Michael was a stalwart back in those wild Ancient Days!
>>>
>>>> cmix has never
>>>> had a runtime synthesis language; even now instrument code has to be
>>>> written in C++.
>>>
>>>
>>> One possible misconception -- by "runtime synthesis language" I'm sure
>>> Michael
>>> means a design language for instantiating synthesis/DSP algorithms *in
>>> real time*
>>> as the language/synth-engine is running. ?I tend to think of languages
>>> like ChucK
>>> or Supercollider more in that sense than Csound, and even SC
>>> differentiates between
>>> the language and then sending the synth-code to the server.
>>
>>
>> My reading would be that Michael may be implying that there is a
>> difference
>> between interpretation and compilation.
>>
>> CSound does not have a runtime synthesis language either. It's a compiler
>> with a VM. There is no way to re-write the code while it's running.
>>
>> SC3 is very limited in this regard too (you can restructure the synth
>> graph
>> but there's no way to edit a synthdef except by replacing it, and there's
>> no
>> language code running sample synchronously in the server). So you have a
>> kind of runtime compilation model.
>>
>> I didn't get much of a chance to play with SC1 but my understanding is
>> that
>> you could actually process samples in the synthesis loop (like you can
>> with
>> cmix). To me this is real runtime synthesis. You get this in C/C++ too --
>> your program can make signal dependent runtime decisions about what
>> synthesis code to execute.
>>
>> Anything else is just plugging unit generators together, which is limiting
>> in many situations (one reason I abandoned these kind of environments and
>> started writing my algorithms in C++).
>>
>>
>>
>>> RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has
>>> now for almost
>>> two decades. ?The trade-off in writing C/C++ code is that it is one of
>>> the
>>> most
>>> efficient languages currently in use. ?We've also taken a route which
>>> allows it
>>> to be 'imbedded' in other environments. ?rtcmix~ was the first of the
>>> 'language
>>> objects' I did for max/msp. ?iRTcmix (RTcmix in iOS) even passes muster
>>> at
>>> the
>>> clamped App Store, check out iLooch for fun:
>>> ?http://music.columbia.edu/~brad/ilooch/
>>> (almost 2 years old now).
>>>
>>> For me the deeper issue is how these various languages/environments shape
>>> creative thinking. ?I tend to like the way I think about music,
>>> especially
>>> algorthmic
>>> composityon, using the RTcmix parse language than I do in, say SC. ?Each
>>> system
>>> has things 'it likes to do', and i think it important to be aware of
>>> these.
>>
>>
>> Indeed.
>>
>> The problem with "plug unit generators languages" for me is that they
>> privilege the process (network of unit generators) over the content (the
>> signal). Programming in C++ makes the signal efficiently accessible.
>> Nothing
>> wrong with patchable environments of course :) just that their not the
>> whole
>> story.
>>
>> 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
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot 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  Fri Feb 24 13:05:47 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Fri, 24 Feb 2012 18:05:47 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F474979.1090307@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
Message-ID: <20120224180547.GA19742@sapphire.lan>


> The problem with "plug unit generators languages" for me is that they
> privilege the process (network of unit generators) over the content

Some really interesting thoughts here Ross. At what level of
granularity does the trade-off of control, flexibility and
efficiency reach its sweet spot?

In some ways the unit generator or patchable code-block
model is to be considered a compromise between the overhead
of calling functions on single samples and being able
to process chunks. It comes bottom up, out of implementation needs
rather than being a top down shorthand. On the other hand,
because familiar structures like the filter, oscillator and so forth
make sense as basic units of design the VM + Ugen model makes
a lot of sense to practitioners coming from the studio.

Plenty of analogous structures in general computer science
have similar rationales, like pipelines, SIMD, with the 
question being at what level of granularity can you lump a 
bunch of stuff together and process it all without sacrificing 
flexibility? Even apparently atomic instructions are, from the
microprocessors point of view, collections of more atomic 
register operations that we never consider unless programming 
in machine code. 

> Anything else is just plugging unit generators together, which is
> limiting in many situations (one reason I abandoned these kind of
> environments and started writing my algorithms in C++).

As linguists and writers note (Wittgenstein, Orwell, Ayer, Chomsky etc)
language defines the modes of thought and facilitates or limits what
we can do more or less easily. I guess plenty of studies have been
done of the "expressibility" of computer languages, since they are
strictly formal and amenable to analysis. Though we tend to invoke
"Turing completeness" and assume all roads lead to Rome, clearly some
languages are much better for certain things than others. 

Grist for the mill in computing philosophy, but as musicians or
sound designers it takes on a freshness. For example, the ease with
which polyphony can be conceived in Supercollider and Chuck is 
amazing compared to Pure Data/Max, which makes it an awkward hack 
at the best of times. Csound is somewhere between. And of course, 
though Csound is clearly conceived as a _composers_ language where 
large scale structures are easy to build, abstraction is very obtuse.

I remember Gunter Geiger's thesis being a good comparative
treatment of different computer music languages, but that was
mainly from a computational rather than expressibility angle.
Maybe there's a good doctoral project for someone lurking in this
question. 


> Programming in C++ makes the signal efficiently accessible.

Getting down to the metal with C/++ is more than just a departure from
the VM plus UGEN  model, it allows, as you say, complete reconfiguration
of the signal processing structure on a sample by sample basis, and
departures from strictly causal models using look ahead computation
etcetera. But at the same time it lays the signal bare, it
seems to bury the larger process (unless you are an extremely methodical
hacker and already working with quite robust and well used libraries).

Is there is a fundamental trade off here that we just cannot get around?


best
Andy




On Fri, Feb 24, 2012 at 07:25:29PM +1100, Ross Bencina wrote:
> Hi Brad,
> 
> On 24/02/2012 3:01 PM, Brad Garton wrote:
> >Joining this conversation a little late, but what the heck...
> 
> Me too...
> 
> >On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote:
> >
> >>I got my start in computer music in 1986 or 1987 at the woof group at
> >>Columbia University using cmix on a Sun workstation.
> >
> >Michael was a stalwart back in those wild Ancient Days!
> >
> >>cmix has never
> >>had a runtime synthesis language; even now instrument code has to be
> >>written in C++.
> >
> >One possible misconception -- by "runtime synthesis language" I'm sure Michael
> >means a design language for instantiating synthesis/DSP algorithms *in real time*
> >as the language/synth-engine is running.  I tend to think of languages like ChucK
> >or Supercollider more in that sense than Csound, and even SC differentiates between
> >the language and then sending the synth-code to the server.
> 
> My reading would be that Michael may be implying that there is a
> difference between interpretation and compilation.
> 
> CSound does not have a runtime synthesis language either. It's a
> compiler with a VM. There is no way to re-write the code while it's
> running.
> 
> SC3 is very limited in this regard too (you can restructure the
> synth graph but there's no way to edit a synthdef except by
> replacing it, and there's no language code running sample
> synchronously in the server). So you have a kind of runtime
> compilation model.
> 
> I didn't get much of a chance to play with SC1 but my understanding
> is that you could actually process samples in the synthesis loop
> (like you can with cmix). To me this is real runtime synthesis. You
> get this in C/C++ too -- your program can make signal dependent
> runtime decisions about what synthesis code to execute.
> 
> Anything else is just plugging unit generators together, which is
> limiting in many situations (one reason I abandoned these kind of
> environments and started writing my algorithms in C++).
> 
> 
> >RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has now for almost
> >two decades.  The trade-off in writing C/C++ code is that it is one of the most
> >efficient languages currently in use.  We've also taken a route which allows it
> >to be 'imbedded' in other environments.  rtcmix~ was the first of the 'language
> >objects' I did for max/msp.  iRTcmix (RTcmix in iOS) even passes muster at the
> >clamped App Store, check out iLooch for fun:  http://music.columbia.edu/~brad/ilooch/
> >(almost 2 years old now).
> >
> >For me the deeper issue is how these various languages/environments shape
> >creative thinking.  I tend to like the way I think about music, especially algorthmic
> >composityon, using the RTcmix parse language than I do in, say SC.  Each system
> >has things 'it likes to do', and i think it important to be aware of these.
> 
> Indeed.
> 
> The problem with "plug unit generators languages" for me is that
> they privilege the process (network of unit generators) over the
> content (the signal). Programming in C++ makes the signal
> efficiently accessible. Nothing wrong with patchable environments of
> course :) just that their not the whole story.
> 
> 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

From theover at tiscali.nl  Fri Feb 24 13:20:58 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Fri, 24 Feb 2012 19:20:58 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <mailman.1178.1330105862.148.music-dsp@music.columbia.edu>
References: <mailman.1178.1330105862.148.music-dsp@music.columbia.edu>
Message-ID: <4F47D50A.8090401@tiscali.nl>

Hi,
   Thinking about the whole idea of (D)igital (S)ignal (P)rocessing I'm 
afraid that even using modern compiler technology and the huge increases 
in bus bandwidth, memory sizes and computation power, along curves even 
better than the Moore curve, much remains to be desired on PCs, even 
when running real time Linux and forgetting about the DA converter 
reconstruction issues (no matter how real those are).

Using my DSP based analog synth model  and other dsp experiments I've 
kept abreast of the electronic world interpretation of the difference 
between the rather supercomputer and somewhat video processing oriented 
PC-processor line and their (our) interpretation of what specific 
digital signal processing, like of course useful for audio applications, 
should be about. The DSP (in terms of the processor kind, like a "sharc" 
or a TI 8 core TMS 320 67 series, wink wink :) ) architectures are more 
aimed at creating all kinds of filters (Fir taps and all kinds of IIRs) 
with efficiently accessible tables and possibly speedups for FFT type of 
computations (like e.g. SSE2 for the intel can do, too) and the 
compilers can handle things like long-convolution complicated wavelet 
type of transform, too.

The PC (also the Intel macs) is more aimed at scientific computing 
nowadays with it's multilevel caching, parallel computing graphics cards 
(e.g. Nvidia's cuda) and all kind of long pipeline accelerations. Fast 
short memory reads, freedom from the conditional execution pipeline and 
cache-strategies, and raw computing power with small granularity aren't 
really the main mix of the PC hardware, at all.

So I like the idea of creating FPGA power for audio purposes: fast 
memories with short access times, parallel data paths and computation 
power at will, and in the case of he "hotter" chips, computation power 
for sensible and subtle (not brute force sample mangling non-sense) 
audio processing rivaled only by the fastest of DSPs and well-working 
of-line or long-latency top PC programs. I look forward to using AD and 
DA converters in the MHz range with only a few samples delay in between, 
that'll bring back the fun in synthesizers and effects, for sure!


  Ir. M. Theo Verelst
  http://www.theover.org/Synth
  http://www.theover.org/Fpgasynth

From vze26m98 at optonline.net  Fri Feb 24 13:21:05 2012
From: vze26m98 at optonline.net (Charles Turner)
Date: Fri, 24 Feb 2012 13:21:05 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <20120224180547.GA19742@sapphire.lan>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <20120224180547.GA19742@sapphire.lan>
Message-ID: <36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>

On Feb 24, 2012, at 1:05 PM, Andy Farnell wrote:

> Some really interesting thoughts here Ross. At what level of
> granularity does the trade-off of control, flexibility and
> efficiency reach its sweet spot?

?I understand that the dialectic of composition better contents itself with neutral objects, not easily identifiable ones, like pure tones or simple tone aggregates, having no inner profile of dynamics, duration or timbre. As soon as one shapes elaborated figures, assembles them into ?formed? complexes, and uses them as first-order objects for composition, one is not to forget [...] that they have lost all neutrality and acquired a personality, an individuality which makes them quite unfit for a generalized dialectics of sonic relations.?

Pierre Boulez: p.45, _Penser la musique aujourd?hui_, (1994)


From michael.gogins at gmail.com  Fri Feb 24 14:21:34 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Fri, 24 Feb 2012 14:21:34 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
Message-ID: <CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>

The two "languages" hidden under the single name "unit generators" are:

(1) An efficient way to implement a runtime compiler for block-based
audio DSP chains (these are what are in software synthesizers)...
which usually are based on

(2) A metaphor for signal processing operators as being linear time
invariant operations inside "little black boxes" (these are what are
inside analog synthesizers such as the original modular Moog or the
Buchla).

Both (1) and (2) assume linear time invariance which guarantees that
you can wire up blocks any old way you like and still understand what
the result will be, because it will all be linear addition and
multiplication. But, in practice, when you open up a block from level
(1) you don't usually find smaller more primitive blocks from level
(2), with the possible partial exception of Pure Data or Reaktor. What
you usually find is gnarly, hard to read procedural C code with loops,
arithmetic, and some functions operating in a linear time invariant
way on arrays of samples.

What stands in the way of adopting plain old C++ for software synthesizers is:

(a) The metaphor behind (2) is very useful for helping the
non-technical musician get a handle on what is going on, especially if
they have spent hours fooling around with a Buchla or something like
that.

(c) It is easy to write and, more importantly, to read C++ signal
processing code that processes one sample at a time, but only code
that processes blocks of at least 20 to 200 samples at a time is
really efficient enough to use; unfortunately this kind of code is
significantly harder to write, and, more importantly, to understand -
the metaphor of (2), and other metaphors, inevitably becomes obscured.

That said, I still believe that properly written C++ unit generators
could be easy to implement, easy to write with, easy to understand,
and efficient. But this would be a great deal of work and the very
first steps have to be just right or the rest all goes astray. I think
it would be important to use blocks that would "look like" individual
samples, it would be important to use smart pointers or garbage
collection so the composer never has to worry about memory management,
and the overall naming conventions would have to be at once concise,
elegant, easy to read, and remind one of those old Music N blocks...
recent changes in the C++ standard, including r-value references, move
semantics, closures and lambdas, and language-based concurrency would
make this significantly easier to do. If someone wants to spend years
rewriting something that already works quite well, like Csound.

Regards,
Mike

On Fri, Feb 24, 2012 at 1:21 PM, Charles Turner <vze26m98 at optonline.net> wrote:
> On Feb 24, 2012, at 1:05 PM, Andy Farnell wrote:
>
>> Some really interesting thoughts here Ross. At what level of
>> granularity does the trade-off of control, flexibility and
>> efficiency reach its sweet spot?
>
> ?I understand that the dialectic of composition better contents itself with neutral objects, not easily identifiable ones, like pure tones or simple tone aggregates, having no inner profile of dynamics, duration or timbre. As soon as one shapes elaborated figures, assembles them into ?formed? complexes, and uses them as first-order objects for composition, one is not to forget [...] that they have lost all neutrality and acquired a personality, an individuality which makes them quite unfit for a generalized dialectics of sonic relations.?
>
> Pierre Boulez: p.45, _Penser la musique aujourd?hui_, (1994)
>
> --
> 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 tom at electricdruid.net  Fri Feb 24 16:06:59 2012
From: tom at electricdruid.net (Tom Wiltshire)
Date: Fri, 24 Feb 2012 21:06:59 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
	<E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>
Message-ID: <B031857C-C0D0-48B6-84C9-A38E79E16F4C@electricdruid.net>

I agree as well. Why should it have to be a sine wave? Hertz didn't invent the sine wave! A square wave has 'frequency' just as much as a sine does, and presumably 'frequency' was the point of the googledoodle. Put the odd harmonics in and get a circular waveform, it's fine by me.

The amplitude and frequency modulation is a bit weird though!

T.

On 24 Feb 2012, at 07:56, Nigel Redmon wrote:

> Eh, I still say they weren't going for a sine wave at all. Look at their other doodles. I'm sure that their designers would have felt that a sine wave would have missed the point for them.
> 
> http://www.zazzle.com/robert_schumanns_200th_birthday_tshirt-235517387819488097


From piccoli.dan at gmail.com  Fri Feb 24 18:23:30 2012
From: piccoli.dan at gmail.com (Daniel Piccoli)
Date: Sat, 25 Feb 2012 07:23:30 +0800
Subject: [music-dsp] music-dsp Digest, Vol 98, Issue 61
Message-ID: <5awkj2x346grhk0abrnbrycq.1330125810542@email.android.com>



music-dsp-request at music.columbia.edu wrote:

>Send music-dsp mailing list submissions to
>	music-dsp at music.columbia.edu
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://music.columbia.edu/mailman/listinfo/music-dsp
>or, via email, send a message with subject or body 'help' to
>	music-dsp-request at music.columbia.edu
>
>You can reach the person managing the list at
>	music-dsp-owner at music.columbia.edu
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of music-dsp digest..."
>
>
>Today's Topics:
>
>   1. Re: a little about myself (Andy Farnell)
>   2. Re: a little about myself (Theo Verelst)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 24 Feb 2012 18:05:47 +0000
>From: Andy Farnell <padawan12 at obiwannabe.co.uk>
>To: A discussion list for music-related DSP
>	<music-dsp at music.columbia.edu>
>Subject: Re: [music-dsp] a little about myself
>Message-ID: <20120224180547.GA19742 at sapphire.lan>
>Content-Type: text/plain; charset=us-ascii
>
>
>> The problem with "plug unit generators languages" for me is that they
>> privilege the process (network of unit generators) over the content
>
>Some really interesting thoughts here Ross. At what level of
>granularity does the trade-off of control, flexibility and
>efficiency reach its sweet spot?
>
>In some ways the unit generator or patchable code-block
>model is to be considered a compromise between the overhead
>of calling functions on single samples and being able
>to process chunks. It comes bottom up, out of implementation needs
>rather than being a top down shorthand. On the other hand,
>because familiar structures like the filter, oscillator and so forth
>make sense as basic units of design the VM + Ugen model makes
>a lot of sense to practitioners coming from the studio.
>
>Plenty of analogous structures in general computer science
>have similar rationales, like pipelines, SIMD, with the 
>question being at what level of granularity can you lump a 
>bunch of stuff together and process it all without sacrificing 
>flexibility? Even apparently atomic instructions are, from the
>microprocessors point of view, collections of more atomic 
>register operations that we never consider unless programming 
>in machine code. 
>
>> Anything else is just plugging unit generators together, which is
>> limiting in many situations (one reason I abandoned these kind of
>> environments and started writing my algorithms in C++).
>
>As linguists and writers note (Wittgenstein, Orwell, Ayer, Chomsky etc)
>language defines the modes of thought and facilitates or limits what
>we can do more or less easily. I guess plenty of studies have been
>done of the "expressibility" of computer languages, since they are
>strictly formal and amenable to analysis. Though we tend to invoke
>"Turing completeness" and assume all roads lead to Rome, clearly some
>languages are much better for certain things than others. 
>
>Grist for the mill in computing philosophy, but as musicians or
>sound designers it takes on a freshness. For example, the ease with
>which polyphony can be conceived in Supercollider and Chuck is 
>amazing compared to Pure Data/Max, which makes it an awkward hack 
>at the best of times. Csound is somewhere between. And of course, 
>though Csound is clearly conceived as a _composers_ language where 
>large scale structures are easy to build, abstraction is very obtuse.
>
>I remember Gunter Geiger's thesis being a good comparative
>treatment of different computer music languages, but that was
>mainly from a computational rather than expressibility angle.
>Maybe there's a good doctoral project for someone lurking in this
>question. 
>
>
>> Programming in C++ makes the signal efficiently accessible.
>
>Getting down to the metal with C/++ is more than just a departure from
>the VM plus UGEN  model, it allows, as you say, complete reconfiguration
>of the signal processing structure on a sample by sample basis, and
>departures from strictly causal models using look ahead computation
>etcetera. But at the same time it lays the signal bare, it
>seems to bury the larger process (unless you are an extremely methodical
>hacker and already working with quite robust and well used libraries).
>
>Is there is a fundamental trade off here that we just cannot get around?
>
>
>best
>Andy
>
>
>
>
>On Fri, Feb 24, 2012 at 07:25:29PM +1100, Ross Bencina wrote:
>> Hi Brad,
>> 
>> On 24/02/2012 3:01 PM, Brad Garton wrote:
>> >Joining this conversation a little late, but what the heck...
>> 
>> Me too...
>> 
>> >On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote:
>> >
>> >>I got my start in computer music in 1986 or 1987 at the woof group at
>> >>Columbia University using cmix on a Sun workstation.
>> >
>> >Michael was a stalwart back in those wild Ancient Days!
>> >
>> >>cmix has never
>> >>had a runtime synthesis language; even now instrument code has to be
>> >>written in C++.
>> >
>> >One possible misconception -- by "runtime synthesis language" I'm sure Michael
>> >means a design language for instantiating synthesis/DSP algorithms *in real time*
>> >as the language/synth-engine is running.  I tend to think of languages like ChucK
>> >or Supercollider more in that sense than Csound, and even SC differentiates between
>> >the language and then sending the synth-code to the server.
>> 
>> My reading would be that Michael may be implying that there is a
>> difference between interpretation and compilation.
>> 
>> CSound does not have a runtime synthesis language either. It's a
>> compiler with a VM. There is no way to re-write the code while it's
>> running.
>> 
>> SC3 is very limited in this regard too (you can restructure the
>> synth graph but there's no way to edit a synthdef except by
>> replacing it, and there's no language code running sample
>> synchronously in the server). So you have a kind of runtime
>> compilation model.
>> 
>> I didn't get much of a chance to play with SC1 but my understanding
>> is that you could actually process samples in the synthesis loop
>> (like you can with cmix). To me this is real runtime synthesis. You
>> get this in C/C++ too -- your program can make signal dependent
>> runtime decisions about what synthesis code to execute.
>> 
>> Anything else is just plugging unit generators together, which is
>> limiting in many situations (one reason I abandoned these kind of
>> environments and started writing my algorithms in C++).
>> 
>> 
>> >RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has now for almost
>> >two decades.  The trade-off in writing C/C++ code is that it is one of the most
>> >efficient languages currently in use.  We've also taken a route which allows it
>> >to be 'imbedded' in other environments.  rtcmix~ was the first of the 'language
>> >objects' I did for max/msp.  iRTcmix (RTcmix in iOS) even passes muster at the
>> >clamped App Store, check out iLooch for fun:  http://music.columbia.edu/~brad/ilooch/
>> >(almost 2 years old now).
>> >
>> >For me the deeper issue is how these various languages/environments shape
>> >creative thinking.  I tend to like the way I think about music, especially algorthmic
>> >composityon, using the RTcmix parse language than I do in, say SC.  Each system
>> >has things 'it likes to do', and i think it important to be aware of these.
>> 
>> Indeed.
>> 
>> The problem with "plug unit generators languages" for me is that
>> they privilege the process (network of unit generators) over the
>> content (the signal). Programming in C++ makes the signal
>> efficiently accessible. Nothing wrong with patchable environments of
>> course :) just that their not the whole story.
>> 
>> 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
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 24 Feb 2012 19:20:58 +0100
>From: Theo Verelst <theover at tiscali.nl>
>To: music-dsp at music.columbia.edu
>Subject: Re: [music-dsp] a little about myself
>Message-ID: <4F47D50A.8090401 at tiscali.nl>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Hi,
>   Thinking about the whole idea of (D)igital (S)ignal (P)rocessing I'm 
>afraid that even using modern compiler technology and the huge increases 
>in bus bandwidth, memory sizes and computation power, along curves even 
>better than the Moore curve, much remains to be desired on PCs, even 
>when running real time Linux and forgetting about the DA converter 
>reconstruction issues (no matter how real those are).
>
>Using my DSP based analog synth model  and other dsp experiments I've 
>kept abreast of the electronic world interpretation of the difference 
>between the rather supercomputer and somewhat video processing oriented 
>PC-processor line and their (our) interpretation of what specific 
>digital signal processing, like of course useful for audio applications, 
>should be about. The DSP (in terms of the processor kind, like a "sharc" 
>or a TI 8 core TMS 320 67 series, wink wink :) ) architectures are more 
>aimed at creating all kinds of filters (Fir taps and all kinds of IIRs) 
>with efficiently accessible tables and possibly speedups for FFT type of 
>computations (like e.g. SSE2 for the intel can do, too) and the 
>compilers can handle things like long-convolution complicated wavelet 
>type of transform, too.
>
>The PC (also the Intel macs) is more aimed at scientific computing 
>nowadays with it's multilevel caching, parallel computing graphics cards 
>(e.g. Nvidia's cuda) and all kind of long pipeline accelerations. Fast 
>short memory reads, freedom from the conditional execution pipeline and 
>cache-strategies, and raw computing power with small granularity aren't 
>really the main mix of the PC hardware, at all.
>
>So I like the idea of creating FPGA power for audio purposes: fast 
>memories with short access times, parallel data paths and computation 
>power at will, and in the case of he "hotter" chips, computation power 
>for sensible and subtle (not brute force sample mangling non-sense) 
>audio processing rivaled only by the fastest of DSPs and well-working 
>of-line or long-latency top PC programs. I look forward to using AD and 
>DA converters in the MHz range with only a few samples delay in between, 
>that'll bring back the fun in synthesizers and effects, for sure!
>
>
>  Ir. M. Theo Verelst
>  http://www.theover.org/Synth
>  http://www.theover.org/Fpgasynth
>
>
>------------------------------
>
>--
>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
>
>End of music-dsp Digest, Vol 98, Issue 61
>*****************************************

From david at olofson.net  Fri Feb 24 19:35:51 2012
From: david at olofson.net (David Olofson)
Date: Sat, 25 Feb 2012 01:35:51 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <20120224180547.GA19742@sapphire.lan>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
Message-ID: <201202250135.51146.david@olofson.net>

On Friday 24 February 2012, at 19.05.47, Andy Farnell 
<padawan12 at obiwannabe.co.uk> wrote:
> > The problem with "plug unit generators languages" for me is that they
> > privilege the process (network of unit generators) over the content
> 
> Some really interesting thoughts here Ross. At what level of
> granularity does the trade-off of control, flexibility and
> efficiency reach its sweet spot?

For ChipSound, I decided on subsample accuracy - which basically means you can 
script your own waveforms, hardsync effects, AM, FM etc without explicit 
support from the engine.

Of course, this is an extreme case, as ChipSound started out as an attempt at 
doing something seriously useful in less than 2k lines of code - but the point 
is, I don't think there is any way around subsample accurate control if you 
want to do anything much interesting without relying on a massive set of unit 
generators. Even single sample accuracy is totally insufficient if you want to 
do chromatic granular, hardsync and similar.

<tired, headache induced tech rant>

There is indeed a bit of complexity involved (timestamped events mixed with VM 
execution + buffer splitting), but the advantage is that one can pretty much 
eliminate LFOs, envelope generators, granular-ish synthesis methods and all 
that - and still have the functionality right there! Just script whatever you 
need when you need it.

Of course, high density granular synthesis, FM etc is never going to run as 
fast this way as with dedicated, optimized unity generators, but then again, 
there is LLVM, if one really wants to push it... :-) Or just throw in a 
peephole optimizer + "multi-instructions" for starters; 50-100% speedup right 
there. (Expensive instruction dispatching; the plague of non-JIT VMs, making 
it extremely worthwhile to keep the instruction count down...)

However, I'm doing sort of ok already, with some 1k voices running "average" 
VM code on a single core of a 2.4 GHz Core 2 CPU. (90% of my target customers 
have at least dual core CPUs, and the game already runs ok with sfx + music on 
a single core P4, despite lots of physics and graphics optimization left to 
do.)

I haven't even bothered with the render-to-waveform feature yet; that could 
cut voice count to a fraction and/or improve quality drastically. It just 
feels like... cheating! "All pure realtime synthesis using only basic 
geometric waveforms!" sounds much cooler. Not that 95% of gamers would have 
any idea what that means anyway. :-D

</tech rant>


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From douglas at music.columbia.edu  Fri Feb 24 21:47:08 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Fri, 24 Feb 2012 21:47:08 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <B031857C-C0D0-48B6-84C9-A38E79E16F4C@electricdruid.net>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
	<E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>
	<B031857C-C0D0-48B6-84C9-A38E79E16F4C@electricdruid.net>
Message-ID: <4F484BAC.20206@music.columbia.edu>


I assumed they were trying to suggest something about Hertz's work on 
electromagnetism. After all, that's what he's actually known for!



On 2/24/12 4:06 PM, Tom Wiltshire wrote:
> I agree as well. Why should it have to be a sine wave? Hertz didn't
> invent the sine wave! A square wave has 'frequency' just as much as a
> sine does, and presumably 'frequency' was the point of the
> googledoodle. Put the odd harmonics in and get a circular waveform,
> it's fine by me.
>
> The amplitude and frequency modulation is a bit weird though!
>
> T.
>
> On 24 Feb 2012, at 07:56, Nigel Redmon wrote:
>
>> Eh, I still say they weren't going for a sine wave at all. Look at
>> their other doodles. I'm sure that their designers would have felt
>> that a sine wave would have missed the point for them.
>>
>> http://www.zazzle.com/robert_schumanns_200th_birthday_tshirt-235517387819488097
>
>>
> -- 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://music.columbia.edu/~douglas


From rossb-lists at audiomulch.com  Fri Feb 24 22:32:46 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sat, 25 Feb 2012 14:32:46 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <F12E3844-4183-4FAB-9C9F-C1A88FC1568E@optonline.net>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<F12E3844-4183-4FAB-9C9F-C1A88FC1568E@optonline.net>
Message-ID: <4F48565E.3010500@audiomulch.com>

Hi Charles,

On 24/02/2012 10:45 PM, Charles Turner wrote:
>> >  Anything else is just plugging unit generators together, which is limiting in many situations
>
> Has it escaped me that Audio Mulch supports this kind of interpretation?

Hi Charles,

I'm not exactly sure what you think has escaped you. But I wasn't really 
bringing AudioMulch into this :)

AudioMulch is a high level environment for patching pre-built modules 
together. The modules are high level (at the level of musical effects, 
drum machines etc) and patching at this level makes sense (to me at 
least). It's a kind of component assembly model and isn't really related 
to programming per-se.

There are a couple of levels of abstraction below this (which aren't 
directly available to the user of AudioMulch unless they start writing 
plugins):

1. The "plugging unit generators together" which you get with Reaktor, 
Csound, Pd, etc.

2. The sample-manipulation level that you get with C/C++/Assembley 
language.

My point above being that level level (2) is distinct from level (1), 
and in my view, too much emphasis is placed on level (1). Cmix is one of 
the few systems I've used that provides access to level (1) and (2) in a 
relatively seamless way.

Ross.

From rossb-lists at audiomulch.com  Fri Feb 24 22:34:20 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sat, 25 Feb 2012 14:34:20 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3XC02TqX4z7bT_=LVvCutZ-Z380xV3YesfPR=rpdvNoOw@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<CAFswGP2TDHAoU-0EP=_Hrq89eR6a3jT_kinzOVYk4ajRxrixVQ@mail.gmail.com>
	<CAK1FW3XC02TqX4z7bT_=LVvCutZ-Z380xV3YesfPR=rpdvNoOw@mail.gmail.com>
Message-ID: <4F4856BC.3090609@audiomulch.com>



On 25/02/2012 4:50 AM, Adam Puckett wrote:
> Is there a minimal example of a complete working program that renders
> a sine wave in realtime using Kernel Streaming that will compile with
> just a bare MinGW install? (I have the latest GCC 4.5 on Windows XP
> Service Pack 3). Which DirectX SDK do I need, the one from Microsoft,
> or the one fromhttp://libsdl.org/extras/win32?

On WDM-KS note that portaudio (portaudio.com) recently merged WDK-KS 
with WaveRT to trunk. It might be an easier option than doing it from 
scratch with Microsoft SDKs.

Not sure whether it builds with MinGW though.

Ross.

From adotsdothmusic at gmail.com  Fri Feb 24 22:38:49 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Fri, 24 Feb 2012 22:38:49 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4856BC.3090609@audiomulch.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<CAFswGP2TDHAoU-0EP=_Hrq89eR6a3jT_kinzOVYk4ajRxrixVQ@mail.gmail.com>
	<CAK1FW3XC02TqX4z7bT_=LVvCutZ-Z380xV3YesfPR=rpdvNoOw@mail.gmail.com>
	<4F4856BC.3090609@audiomulch.com>
Message-ID: <CAK1FW3Wc1YFje4EBms78VJK7+Gq23o_vutRzpYQmyUVpdsLUZA@mail.gmail.com>

What is WaveRT? I don't see it in the tarball.

On 2/24/12, Ross Bencina <rossb-lists at audiomulch.com> wrote:
>
>
> On 25/02/2012 4:50 AM, Adam Puckett wrote:
>> Is there a minimal example of a complete working program that renders
>> a sine wave in realtime using Kernel Streaming that will compile with
>> just a bare MinGW install? (I have the latest GCC 4.5 on Windows XP
>> Service Pack 3). Which DirectX SDK do I need, the one from Microsoft,
>> or the one fromhttp://libsdl.org/extras/win32?
>
> On WDM-KS note that portaudio (portaudio.com) recently merged WDK-KS
> with WaveRT to trunk. It might be an easier option than doing it from
> scratch with Microsoft SDKs.
>
> Not sure whether it builds with MinGW though.
>
> 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
>

From padawan12 at obiwannabe.co.uk  Sat Feb 25 04:40:23 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sat, 25 Feb 2012 09:40:23 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <B031857C-C0D0-48B6-84C9-A38E79E16F4C@electricdruid.net>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
	<E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>
	<B031857C-C0D0-48B6-84C9-A38E79E16F4C@electricdruid.net>
Message-ID: <20120225094023.GA22087@sapphire.lan>


When the lovely people at MIT added some extra cool graphics to my book cover
I was initially dismayed to see the usual "funky oscilloscope trace" with a 
blue tint, looking like an electric spark. But everyone I showed it to, my 
friends and family all thought it was amazing and futuristic! So I quickly 
got over my pedantry and embraced a new found ability to create signals that
go backwards in time as well as forwards. Graphic designers create their 
worlds, we create ours.

On the subject of creating worlds, I've missed this conversation entirely
because of a courageous attempt to degooglify my life and get out of the 
scrutinised bubble. Since switching to the Duck search engine I discovered
a whole internet out there. Maybe takes longer to find exact thing, but if 
you're that desperate to save half a second here and there your life is in 
trouble anyway, and the plus side is rediscovering the colourful, trashy 
landscape not interpreted through an individual bourgeois materialist lens. 
Turns out DSP stands for many different things, so by making more focussed 
searches and pausing for a moment to think instead of lean on the mental 
crutch, things actually work out better. On the weird side, LaTeX is more 
than a document processor. There's even a perfume called Philosophy.


On Fri, Feb 24, 2012 at 09:06:59PM +0000, Tom Wiltshire wrote:
> I agree as well. Why should it have to be a sine wave? Hertz didn't invent
> the sine wave! A square wave has 'frequency' just as much as a sine does, 
> and presumably 'frequency' was the point of the googledoodle. Put the odd 
> harmonics in and get a circular waveform, it's fine by me.
> 
> The amplitude and frequency modulation is a bit weird though!
> 
> T.

From richarddobson at blueyonder.co.uk  Sat Feb 25 05:58:52 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Sat, 25 Feb 2012 10:58:52 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <20120225094023.GA22087@sapphire.lan>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>	<4F463C9B.6030205@tiscali.nl>	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>	<4F46CB49.307@music.columbia.edu>	<E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>	<B031857C-C0D0-48B6-84C9-A38E79E16F4C@electricdruid.net>
	<20120225094023.GA22087@sapphire.lan>
Message-ID: <4F48BEEC.5060206@blueyonder.co.uk>

On 25/02/2012 09:40, Andy Farnell wrote:
..
> On the subject of creating worlds, I've missed this conversation entirely
> because of a courageous attempt to degooglify my life

great word! I wonder though if it should be more like "degooglise", as 
you are changing or reducing state, rather than actively making 
something, which is what the 'ify' suffix would suggest. Such questions 
are of great importance, as once enshrined in the OED words are frozen 
for all time.

And the harsh truth is that no competing search engine will succeeed 
unless its name works well as a verb.

I heard only the other day on a news bulletin the reference to James 
Dyson as someone who had "invented a new hoover".

Richard Dobson



From padawan12 at obiwannabe.co.uk  Sat Feb 25 06:34:27 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sat, 25 Feb 2012 11:34:27 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
Message-ID: <20120225113427.GA22352@sapphire.lan>

On Fri, Feb 24, 2012 at 01:21:05PM -0500, Charles Turner wrote:
> On Feb 24, 2012, at 1:05 PM, Andy Farnell wrote:
> 
> > Some really interesting thoughts here Ross. At what level of
> > granularity does the trade-off of control, flexibility and
> > efficiency reach its sweet spot?
> 
> ?I understand that the dialectic of composition better contents itself 
> with neutral objects, not easily identifiable ones, like pure tones or 
> simple tone aggregates, having no inner profile of dynamics, duration 
> or timbre. As soon as one shapes elaborated figures, assembles them 
> into ?formed? complexes, and uses them as first-order objects for 
> composition, one is not to forget [...] that they have lost all 
> neutrality and acquired a personality, an individuality which makes 
> them quite unfit for a generalized dialectics of sonic relations.?
> 
> Pierre Boulez: p.45, _Penser la musique aujourd?hui_, (1994)
> 


For me it's strange to see that written in 1994, close to the time 
I was behind the lines of British pop culture, where the precise 
opposite was true. Superstar DJs, music media moguls and influential 
producers romped and rollicked in an entirely sample based, second 
order culture. The symbols and currency of composition were drum 
loops, pre-made chord sounds or "stabs and hits", a cappella vocal 
hooks. 

Of course that had a profound influence on my own music making,
my approach and understanding of what composition is. Pop is
precisely about rearranging second order symbols.

But as a computer guy, I also noticed how culture influenced
the software, how marketing and the values of those deemed
successful manipulated the tools, and the tools in turn manipulated
the possibilities of new music makers. To this day I love to
show my students this funny ad as a warning...

http://obiwannabe.co.uk/temp/software.jpg

And whereas I do agree with Pierre Boulez here, maybe it
is misguided to turn to reductionism and simplicity for
their own sake. It may be equally hopeless to embark
on a quest for authenticity this way. 

Composition is just very hard work, time consuming and 
needs diverse human capacities like poetic skills. It's 
fundamentally at odds with the values of "making things easy". 
The danger then, in a world where products dominate principles, 
is to fall into the trap of deliberately making things difficult
for yourself.

To quote a cohort, Chris McCormick

"Making boring techno music is really easy with modern tools, but 
with live coding, boring techno is much harder."

http://news.bbc.co.uk/1/hi/technology/8244003.stm

The actual sweet spot is surely different for each person.
But you certainly will not find it if you either start with a
very strong idea of how music must be made, or are constrained
by tools that impose other peoples strong ideas upon you.

best,
Andy

From padawan12 at obiwannabe.co.uk  Sat Feb 25 06:38:44 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sat, 25 Feb 2012 11:38:44 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F48BEEC.5060206@blueyonder.co.uk>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
	<E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>
	<B031857C-C0D0-48B6-84C9-A38E79E16F4C@electricdruid.net>
	<20120225094023.GA22087@sapphire.lan>
	<4F48BEEC.5060206@blueyonder.co.uk>
Message-ID: <20120225113844.GB22352@sapphire.lan>

On Sat, Feb 25, 2012 at 10:58:52AM +0000, Richard Dobson wrote:
> On 25/02/2012 09:40, Andy Farnell wrote:
> ..

> And the harsh truth is that no competing search engine will succeeed
> unless its name works well as a verb.

Astute. Maybe the duck is doomed already. Unless it becomes normative
that doing some research is "Ducking the question". Yes degooglize
is much better, particularly with the American z.
best
Andy

From douglas at music.columbia.edu  Sat Feb 25 08:21:23 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 08:21:23 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <20120225094023.GA22087@sapphire.lan>
References: <mailman.1091.1329973503.148.music-dsp@music.columbia.edu>
	<4F463C9B.6030205@tiscali.nl>
	<D22AC5EFC0A4433A92176571208A7E28@ProprietairePC>
	<4F46CB49.307@music.columbia.edu>
	<E17AA371-32C2-47C5-BCF5-5FAA59FC564C@earlevel.com>
	<B031857C-C0D0-48B6-84C9-A38E79E16F4C@electricdruid.net>
	<20120225094023.GA22087@sapphire.lan>
Message-ID: <4F48E053.3020409@music.columbia.edu>


Of course, I know I'm being didactic, creative design is great and I'm 
100% in favor of doing things "wrong". I just thought doing a wacky 
sinewave animation would have been more interesting than doing a wacky 
non-sinewave animation. Maybe I've just seen too many non-sines drawn by 
students who aren't being creative, they just don't get the difference 
(yet!) between two half-circles and a sinewave.

douglas

On 2/25/12 4:40 AM, Andy Farnell wrote:
>
> When the lovely people at MIT added some extra cool graphics to my book cover
> I was initially dismayed to see the usual "funky oscilloscope trace" with a
> blue tint, looking like an electric spark. But everyone I showed it to, my
> friends and family all thought it was amazing and futuristic! So I quickly
> got over my pedantry and embraced a new found ability to create signals that
> go backwards in time as well as forwards. Graphic designers create their
> worlds, we create ours.
>



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


From theover at tiscali.nl  Sat Feb 25 08:43:49 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Sat, 25 Feb 2012 14:43:49 +0100
Subject: [music-dsp] music-dsp Digest, Vol 98, Issue 66
In-Reply-To: <mailman.1212.1330169941.148.music-dsp@music.columbia.edu>
References: <mailman.1212.1330169941.148.music-dsp@music.columbia.edu>
Message-ID: <4F48E595.7080908@tiscali.nl>

douglas repetto wrote Sat Feb 25 08:21:23 EST 2012:
 > non-sinewave animation. Maybe I've just seen too many non-sines drawn by
 > students who aren't being creative, they just don't get the 
difference (yet!) between two half-circles and a sinewave.

Serious engineering students (who else wouldbe the future leaders of the 
technology of software ?) shouldn't find it hard to do some simple 
analysis like a Taylor expansion, or rather simplistic trigonometric 
considerations. More advanced ones shouldn't even find it impossible to 
qualitatively or quantitatively transform their curves or the circular 
considerations into a (repeated wave) frequency analysis, either by 
formalisms of the Fourier type or by using an FFT library/program!

It wouldn't hurt to consider the variations of such wave with times and 
trying to characterize those, and considering how those waves come 
across through "normal" reverberation effects, or at least some singular 
sound sheeres along a wall.

Theo V.

From vze26m98 at optonline.net  Sat Feb 25 09:23:33 2012
From: vze26m98 at optonline.net (Charles Turner)
Date: Sat, 25 Feb 2012 09:23:33 -0500
Subject: [music-dsp] Boulez
In-Reply-To: <20120225113427.GA22352@sapphire.lan>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<20120225113427.GA22352@sapphire.lan>
Message-ID: <CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>

On Feb 25, 2012, at 6:34 AM, Andy Farnell wrote:

> And whereas I do agree with Pierre Boulez here, maybe it
> is misguided to turn to reductionism and simplicity for
> their own sake. It may be equally hopeless to embark
> on a quest for authenticity this way. 

Hi Andy-

I should apologize for hastily listing the publication date of the book. The book collects his Darmstadt lectures from 1954-56, so it comes from a much earlier time. I don't think Boulez would have changed his mind on things though. Sounds like you come from a much more "Schaefferian" era.

Isn't the point not to take sides, but recognize the tension? Cultures that are busily exploring harmonic relations, haven't simultaneously plunged deep into the world of rhythm. Music is just too big a subject, and some of its properties exist in a dialectical relation to others. Although we all enjoy a sweet dessert, we don't put sugar in everything. (Unless you're the Nestle company!)

My point was that the checkpoint raised by callbacks feeding a sample buffer may come from resistances outside the technical world. Boulez sees timbre as the enemy of harmony. Could very well be that the callback is the result of a cultural outlook, and not the result of engineering design?

Best, Charles


From adotsdothmusic at gmail.com  Sat Feb 25 09:40:59 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Sat, 25 Feb 2012 09:40:59 -0500
Subject: [music-dsp] Boulez
In-Reply-To: <CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<20120225113427.GA22352@sapphire.lan>
	<CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
Message-ID: <CAK1FW3WQ0Sn0vq7ikDFpEcy=S09NNxXoFVJ18S0MZdQ4S2RLww@mail.gmail.com>

Would it be possible to design a callback that dynamically filled the
buffer as it was being called, or if the buffer didn't exist, create
it and put one sample in it? that way there wouldn't be any "dropped
calls" in the process. Or am I missing something?

On 2/25/12, Charles Turner <vze26m98 at optonline.net> wrote:
> On Feb 25, 2012, at 6:34 AM, Andy Farnell wrote:
>
>> And whereas I do agree with Pierre Boulez here, maybe it
>> is misguided to turn to reductionism and simplicity for
>> their own sake. It may be equally hopeless to embark
>> on a quest for authenticity this way.
>
> Hi Andy-
>
> I should apologize for hastily listing the publication date of the book. The
> book collects his Darmstadt lectures from 1954-56, so it comes from a much
> earlier time. I don't think Boulez would have changed his mind on things
> though. Sounds like you come from a much more "Schaefferian" era.
>
> Isn't the point not to take sides, but recognize the tension? Cultures that
> are busily exploring harmonic relations, haven't simultaneously plunged deep
> into the world of rhythm. Music is just too big a subject, and some of its
> properties exist in a dialectical relation to others. Although we all enjoy
> a sweet dessert, we don't put sugar in everything. (Unless you're the Nestle
> company!)
>
> My point was that the checkpoint raised by callbacks feeding a sample buffer
> may come from resistances outside the technical world. Boulez sees timbre as
> the enemy of harmony. Could very well be that the callback is the result of
> a cultural outlook, and not the result of engineering design?
>
> Best, Charles
>
> --
> 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  Sat Feb 25 12:07:19 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 12:07:19 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F48E595.7080908@tiscali.nl>
References: <mailman.1212.1330169941.148.music-dsp@music.columbia.edu>
	<4F48E595.7080908@tiscali.nl>
Message-ID: <4F491547.3080107@music.columbia.edu>



On 2/25/12 8:43 AM, Theo Verelst wrote:
> douglas repetto wrote Sat Feb 25 08:21:23 EST 2012:
>  > non-sinewave animation. Maybe I've just seen too many non-sines drawn by
>  > students who aren't being creative, they just don't get the
> difference (yet!) between two half-circles and a sinewave.
>
> Serious engineering students (who else wouldbe the future leaders of the
> technology of software ?) shouldn't find it hard to do some simple
> analysis like a Taylor expansion, or rather simplistic trigonometric
> considerations.

My students tend to be musicians and artists who often think they're 
"bad at math" or "hate math". So when I start talking about unit circles 
and sinewaves or Ohm's Law and basic algebra, they're often a bit 
worried... But usually they get really excited when they realize that a 
lot of this stuff is pretty simple even if you don't have much/any 
math/engineering background. To me that's the most exciting thing, 
getting non-experts to realize that their non-expertise is not a barrier 
to them doing creative things with something like DSP or electronics.

So maybe it's dumb/ironic that I'm complaining about Google doing 
something wacky with an animation, since my students and I certainly do 
wacky/unconventional things with code and electronics!

Anywho, I went back and looked at the animation some more and I agree 
that it's pretty charming and that there's really no reason why it 
should be a sinewave. Sorry for wasting bandwidth!

douglas


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


From theover at tiscali.nl  Sat Feb 25 12:38:02 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Sat, 25 Feb 2012 18:38:02 +0100
Subject: [music-dsp] google's non-sine
In-Reply-To: <mailman.1219.1330179825.148.music-dsp@music.columbia.edu>
References: <mailman.1219.1330179825.148.music-dsp@music.columbia.edu>
Message-ID: <4F491C7A.9020607@tiscali.nl>

> douglas repetto douglas wrote Sat Feb 25 12:07:19 EST 2012:
> Sorry for wasting bandwidth!

I'll be darned if I'd have to call a serious discussion a waste of a 
couple of milliseconds router-time, so by no means do I prefer to be 
accused of saying that !

I should like to think more than a few conservatory students (both male 
and female) have sufficient interest in these subjects, so maybe you're 
right it's a good calling to alleviate some of the need for mathematics.

And concerning Andy's point about boringness, I recall that when drum 
computer were invented they too were called boring, and producing music 
with them as spawning headaches...

Theo V.

From adotsdothmusic at gmail.com  Sat Feb 25 13:22:04 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Sat, 25 Feb 2012 13:22:04 -0500
Subject: [music-dsp] google's non-sine
In-Reply-To: <4F491C7A.9020607@tiscali.nl>
References: <mailman.1219.1330179825.148.music-dsp@music.columbia.edu>
	<4F491C7A.9020607@tiscali.nl>
Message-ID: <CAK1FW3W2ijFxv=T1SJZU14-Ha4srPftzkeovWA3mBVgaeoCa5w@mail.gmail.com>

I rather enjoy math and programming. That's why I read Csound opcodes
in source form.

On 2/25/12, Theo Verelst <theover at tiscali.nl> wrote:
>> douglas repetto douglas wrote Sat Feb 25 12:07:19 EST 2012:
>> Sorry for wasting bandwidth!
>
> I'll be darned if I'd have to call a serious discussion a waste of a
> couple of milliseconds router-time, so by no means do I prefer to be
> accused of saying that !
>
> I should like to think more than a few conservatory students (both male
> and female) have sufficient interest in these subjects, so maybe you're
> right it's a good calling to alleviate some of the need for mathematics.
>
> And concerning Andy's point about boringness, I recall that when drum
> computer were invented they too were called boring, and producing music
> with them as spawning headaches...
>
> Theo V.
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp
> links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>

From garton at columbia.edu  Sat Feb 25 13:29:41 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 13:29:41 -0500
Subject: [music-dsp] test
Message-ID: <5BDEFC3A-2D4A-439E-8A44-033E9FDE303A@columbia.edu>

sorry... posts not going through for some reason.

brad
http://music.columbia.edu/~brad


From garton at columbia.edu  Sat Feb 25 13:38:05 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 13:38:05 -0500
Subject: [music-dsp] list postings
Message-ID: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>

Hey music-dsp-ers --

Has anyone else experienced troubles getting posts to show up on our list?  I've sent (and re-sent) several this morning and they just vanished.  I've checked with douglas about it, but was wondering if anyone else has had problems.

brad
http://music.columbia.edu/~brad


From garton at columbia.edu  Sat Feb 25 13:38:55 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 13:38:55 -0500
Subject: [music-dsp] list postings
In-Reply-To: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
Message-ID: <A224E3D7-2220-4A11-B473-5781732D8A15@columbia.edu>

and some go through, some don't...

I don't see anything clearly spam-like in the posts that got dropped.

brad

On Feb 25, 2012, at 1:38 PM, Brad Garton wrote:

> Hey music-dsp-ers --
> 
> Has anyone else experienced troubles getting posts to show up on our list?  I've sent (and re-sent) several this morning and they just vanished.  I've checked with douglas about it, but was wondering if anyone else has had problems.
> 
> brad
> http://music.columbia.edu/~brad
> 
> --
> 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  Sat Feb 25 13:40:52 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 13:40:52 -0500
Subject: [music-dsp] list postings
In-Reply-To: <A224E3D7-2220-4A11-B473-5781732D8A15@columbia.edu>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<A224E3D7-2220-4A11-B473-5781732D8A15@columbia.edu>
Message-ID: <4F492B34.8000408@music.columbia.edu>


I wonder if your ISP is eating them somehow. Usually when posts don't go 
through a bounce message is generated.

BTW, several people have had trouble posting recently because they were 
sending HTML mail to the list. Please remember that you can only send 
plaintext and no attachments.

best,
douglas

On 2/25/12 1:38 PM, Brad Garton wrote:
> and some go through, some don't...
>
> I don't see anything clearly spam-like in the posts that got dropped.
>
> brad
>
> On Feb 25, 2012, at 1:38 PM, Brad Garton wrote:
>
>> Hey music-dsp-ers --
>>
>> Has anyone else experienced troubles getting posts to show up on our list?  I've sent (and re-sent) several this morning and they just vanished.  I've checked with douglas about it, but was wondering if anyone else has had problems.
>>
>> brad
>> http://music.columbia.edu/~brad
>>
>> --
>> 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://artbots.org
.....douglas.....irving........................ http://dorkbot.org
.......................... http://music.columbia.edu/cmc/music-dsp
...........repetto............. http://music.columbia.edu/organism
............................... http://music.columbia.edu/~douglas


From garton at columbia.edu  Sat Feb 25 13:47:52 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 13:47:52 -0500
Subject: [music-dsp] boulez
Message-ID: <A446B71A-0416-4D66-813D-1CF0A9C3AA12@columbia.edu>

Oh that Boulez!  Such a comedian!

On Feb 25, 2012, at 9:23 AM, Charles Turner wrote:

> Could very well be that the callback is the result of a cultural outlook, and not the result of engineering design?

I would invert this -- being more of a techno-determinist I tend to locate contemporary "cultural outlooks" as the result of engineering, or perhaps more specifically 'interface', design.  Well, maybe not the whole "cultural outlook" thing, more perhaps the kinds of creativity that arise from our interaction with the tools we use for our creative work.  If you'll allow an old[er] guy to indulge in some reminiscing, here's a couple of paragraphs from a paper I wrote back in 1986:

----------------------------
"Working with computers to create music during the past several years has made me recognize the integral role played by the interface between my sonic imaginings and their realization. When I pick up a pencil and paper to write a "conventional" piece of music, I automatically adopt a self-established set of assumptions that will fundamentally affect what I compose. Sitting at the keyboard of a terminal does the same thing -- different assumptions, of course. Throw in a mouse and I guarantee that the "set of pieces I might compose" will shift. Different tools make certain activities easier, certain other activities more difficult. This is bound to have at least a subtle effect on what the tools are being used to create.

"Throwing in a mouse" points to an aspect of computers that makes them rather unique as musical tools. The interface between myself and computer sound synthesis can be changed with minor hardware changes or (more significantly) by changing the software used to interpret my commands. I find this quite intriguing; being able to control the interface I use to create music gives me a very high-level "conceptual knob" that I can use to change the way I interact with my music making. I might choose to control sound production with a set of stochastic procedures, or I might use graphics software to interpret curves I draw in certain ways, or I might even write an algorithm to translate the words and letters of this paper into sound. In each case, the shape of the resulting piece (and the way I think about it as I produce it) will be different."
----------------------------

I know, kind of obvious in a "well, duh..." way, but I still believe this stuff.  I do find it slightly dismaying that many of my students now take what is given them (in terms of music-creation tools) without thinking about how those tools alter their view of musical possibility  (exhibit A:  Abelton).  But on the other hand, they now enjoy the luxury of an almost meta-position, when many different approaches are all available.  What then becomes important is a heightened awareness of what these tools are doing to creative imaginings.  And when they become overly-constraining, explore the potential of altering/designing-your-own system.

And I am really excited by the work people are doing in physical computing, new interfaces, new installation-type thingies, the whole NIME approach.  I'm just a spectator, being a software guy myself.  But it sure is fun!

brad
http://music.columbia.edu/~brad


From garton at columbia.edu  Sat Feb 25 13:49:04 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 13:49:04 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <6925EEFA-FC29-42EA-988B-E9D53A577C65@columbia.edu>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<2425D162-2EA8-41D7-A93D-4F02158AC16C@qwest.net>
	<CAK1FW3UH_rhxDb5DknC4x9XQgyPkiMxwmjPQCONoB7Oyvz2=Yg@mail.gmail.com>
	<4F43A490.5030309@audioimagination.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!
	p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <6925E!
	EFA-FC29-42EA-988B-E9D53A577C65@columbia.edu>
Message-ID: <DD96B1DD-5086-4613-9F77-4AFA857CAEBE@columbia.edu>

On Feb 24, 2012, at 3:25 AM, Ross Bencina wrote:

> CSound does not have a runtime synthesis language either. It's a compiler with a VM. There is no way to re-write the code while it's running.

Exactly.  I've been messing with the idea of rolling up our RTcmix dynamic-loader into a text-edtitor with compilation capabilities to allow direct coding in C/C++ that can then be immediately instantiated in a running audio process, but it still has that separation.  And at some point it just gets kind of silly.

> SC3 is very limited in this regard too (you can restructure the synth graph but there's no way to edit a synthdef except by replacing it, and there's no language code running sample synchronously in the server). So you have a kind of runtime compilation model.
> 
> I didn't get much of a chance to play with SC1 but my understanding is that you could actually process samples in the synthesis loop (like you can with cmix). To me this is real runtime synthesis. You get this in C/C++ too -- your program can make signal dependent runtime decisions about what synthesis code to execute.
> 
> Anything else is just plugging unit generators together, which is limiting in many situations (one reason I abandoned these kind of environments and started writing my algorithms in C++).

The only language I'm aware of that allows the design of direct sample-massaging code in the language itself is chuck.  But it also has a healthy set of unit-generators, because when you reduce the script-execution loop to a sample it becomes *extremely* inefficient.  Chuck ugens are coded in C/C++.

brad
http://music.columbia.edu/~brad



From garton at columbia.edu  Sat Feb 25 13:50:02 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 13:50:02 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CC972854-25B1-4072-AD11-4A927D3C8995@columbia.edu>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<CC972854-25B1-4072-AD11-4A927D3C8995@columbia.edu>
Message-ID: <19377769-8A10-4F5F-9CCB-9BA47DA8AB72@columbia.edu>

On Feb 24, 2012, at 1:05 PM, Andy Farnell wrote:

>> 
>> The problem with "plug unit generators languages" for me is that they
>> privilege the process (network of unit generators) over the content
> 
> Some really interesting thoughts here Ross. At what level of
> granularity does the trade-off of control, flexibility and
> efficiency reach its sweet spot?

Plus the abstracting to levels 'above' plug-ugens allows for different
kinds of musical thinking.  I love RTcmix's parse language (score language)
because of the algorithmic-composition capabilities it opens up.  It would
be much more difficult if it also had to encompass lower-level DSP specification
along with larger 'musical shape' abstractions.

brad
http://music.columbia.edu/~brad



From garton at columbia.edu  Sat Feb 25 13:55:00 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 13:55:00 -0500
Subject: [music-dsp] list postings
In-Reply-To: <mailman.1230.1330195985.148.music-dsp@music.columbia.edu>
References: <mailman.1230.1330195985.148.music-dsp@music.columbia.edu>
Message-ID: <50F3EC5D-6A33-41B4-B008-EAF6E28DD061@columbia.edu>

Ok, my default Apple mail was set to "rich text format" in my preferences (not HTML, which I know is a no-no).  With that as default, somehow some postings go through but others don't (and no, I wasn't doing any fancy italics or nothin').  I switched my default to "plain text" and it seems to work now.

brad
http://music.columbia.edu/~brad


Hi Charlie!  :-)


On Feb 25, 2012, at 1:48 PM, charles morrow wrote:

> Yes, Brad.
> I have been flummoxed by the gods of music-dsp for a week now 
> 
> 
> On Feb 25, 2012, at 8:38 PM, Brad Garton wrote:
> 
>> Hey music-dsp-ers --
>> 
>> Has anyone else experienced troubles getting posts to show up on our list?  I've sent (and re-sent) several this morning and they just vanished.  I've checked with douglas about it, but was wondering if anyone else has had problems.
>> 
>> brad
>> http://music.columbia.edu/~brad
>> 
>> --
>> 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
> 
> charlie morrow
> Charles Morrow Productions LLC
> New York  Helsinki  LA  Barton VT
> www.cmorrow.com
> +1646 235 7228
> 
> 
> 
> 





From contact at quikquak.com  Sat Feb 25 14:01:01 2012
From: contact at quikquak.com (Dave Hoskins)
Date: Sat, 25 Feb 2012 19:01:01 +0000
Subject: [music-dsp] google's non-sine
In-Reply-To: <CAK1FW3W2ijFxv=T1SJZU14-Ha4srPftzkeovWA3mBVgaeoCa5w@mail.gmail.com>
References: <mailman.1219.1330179825.148.music-dsp@music.columbia.edu>	<4F491C7A.9020607@tiscali.nl>
	<CAK1FW3W2ijFxv=T1SJZU14-Ha4srPftzkeovWA3mBVgaeoCa5w@mail.gmail.com>
Message-ID: <4F492FED.3090501@quikquak.com>

"The waves form a repeating pattern: There's a large blue curve, 
followed by a shallow red, shallow yellow, deep blue, skinny green, and 
one final red curve. Those lines match the general shape of Google's 
traditional logo: Uppercase blue G, small Os, a lowercase g, a skinny 
green L, and a red E. It's not the most difficult code to decipher, but 
Google's doodle serves as a lovely metaphor for Hertz's work."

http://www.csmonitor.com/Innovation/Horizons/2012/0222/How-Heinrich-Rudolf-Hertz-revealed-the-invisible-world


Dave.


From earlevel at earlevel.com  Sat Feb 25 14:02:59 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Sat, 25 Feb 2012 11:02:59 -0800
Subject: [music-dsp] list postings
In-Reply-To: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
Message-ID: <AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>

I've had problems in the past when html-style font tags make their way into the email. For instance, this happens in Apple's Mail.app. Even though it's not an html email, per se, they sometimes get rejected (but not always). If I do Make Plain Text from the Format menu before sedning, then they always get through?there is no visible change to the email either (because they are just some default font tags?I'm not really formatting the text).


On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
> Hey music-dsp-ers --
> 
> Has anyone else experienced troubles getting posts to show up on our list?  I've sent (and re-sent) several this morning and they just vanished.  I've checked with douglas about it, but was wondering if anyone else has had problems.
> 
> brad
> http://music.columbia.edu/~brad


From douglas at music.columbia.edu  Sat Feb 25 14:07:27 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 14:07:27 -0500
Subject: [music-dsp] list postings
In-Reply-To: <AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
Message-ID: <4F49316F.5000703@music.columbia.edu>


It may be that Apple is adding something to the header indicating rich 
text/html even though you don't end up with offending characters in the 
email. The list software rejects email based on the headers, not on the 
actual content.

There's no fundamental reason why the list can't accept html mail, btw. 
So if people really want it we can make a change. In the past it's been 
about spam control and saving bandwidth, but those issues aren't such 
big concerns anymore, I think. Although I personally find that reading a 
list like this in different fonts/colors/styles can be unpleasant.

douglas

On 2/25/12 2:02 PM, Nigel Redmon wrote:
> I've had problems in the past when html-style font tags make their
> way into the email. For instance, this happens in Apple's Mail.app.
> Even though it's not an html email, per se, they sometimes get
> rejected (but not always). If I do Make Plain Text from the Format
> menu before sedning, then they always get through?there is no visible
> change to the email either (because they are just some default font
> tags?I'm not really formatting the text).
>
>
> On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
>> Hey music-dsp-ers --
>>
>> Has anyone else experienced troubles getting posts to show up on
>> our list?  I've sent (and re-sent) several this morning and they
>> just vanished.  I've checked with douglas about it, but was
>> wondering if anyone else has had problems.
>>
>> brad http://music.columbia.edu/~brad
>
> -- 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://music.columbia.edu/~douglas


From douglas at music.columbia.edu  Sat Feb 25 14:14:40 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 14:14:40 -0500
Subject: [music-dsp] [OT] Re:  google's non-sine
In-Reply-To: <4F492FED.3090501@quikquak.com>
References: <mailman.1219.1330179825.148.music-dsp@music.columbia.edu>	<4F491C7A.9020607@tiscali.nl>
	<CAK1FW3W2ijFxv=T1SJZU14-Ha4srPftzkeovWA3mBVgaeoCa5w@mail.gmail.com>
	<4F492FED.3090501@quikquak.com>
Message-ID: <4F493320.6010703@music.columbia.edu>


Wow, some of the comments on that article are pretty wacky!

+++

Thomas:
Another wack job job scientist.  His research has lead to 100,000 + 
deaths in the modern day era, all of these kinds people are sociopaths 
and murders.

+++

Funny that he's so conservative with his conspiracy theory numbers. 
Surely millions have died as a result of various electromagnetic phenomena!


douglas


On 2/25/12 2:01 PM, Dave Hoskins wrote:
> "The waves form a repeating pattern: There's a large blue curve,
> followed by a shallow red, shallow yellow, deep blue, skinny green, and
> one final red curve. Those lines match the general shape of Google's
> traditional logo: Uppercase blue G, small Os, a lowercase g, a skinny
> green L, and a red E. It's not the most difficult code to decipher, but
> Google's doodle serves as a lovely metaphor for Hertz's work."
>
> http://www.csmonitor.com/Innovation/Horizons/2012/0222/How-Heinrich-Rudolf-Hertz-revealed-the-invisible-world
>
>
>
> Dave.
>
> --
> 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://music.columbia.edu/~douglas


From bjorn at xowave.com  Sat Feb 25 14:14:48 2012
From: bjorn at xowave.com (Bjorn Roche)
Date: Sat, 25 Feb 2012 14:14:48 -0500
Subject: [music-dsp] list postings
In-Reply-To: <4F49316F.5000703@music.columbia.edu>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
Message-ID: <F4CBB67F-8B8A-4907-972C-367AE7DCDEF6@xowave.com>

I've never had an email get through to this list, and I've never gotten a rejection notice, which is sad b/c once or twice I've actually had something constructive to say. (on two occasions, I've just email the original posters) With this email, I am explicitly setting the format to plain, as suggested, and we'll see.

It's annoying because gmail filters out sent mail from received mail, so it doesn't show you list mail that you sent, and since I don't get a bounce for some reason, there's no way to know the email is missed! The best I can do is check the archives after its sent :-P

	bjorn

On Feb 25, 2012, at 2:07 PM, douglas repetto wrote:

> 
> It may be that Apple is adding something to the header indicating rich text/html even though you don't end up with offending characters in the email. The list software rejects email based on the headers, not on the actual content.
> 
> There's no fundamental reason why the list can't accept html mail, btw. So if people really want it we can make a change. In the past it's been about spam control and saving bandwidth, but those issues aren't such big concerns anymore, I think. Although I personally find that reading a list like this in different fonts/colors/styles can be unpleasant.
> 
> douglas
> 
> On 2/25/12 2:02 PM, Nigel Redmon wrote:
>> I've had problems in the past when html-style font tags make their
>> way into the email. For instance, this happens in Apple's Mail.app.
>> Even though it's not an html email, per se, they sometimes get
>> rejected (but not always). If I do Make Plain Text from the Format
>> menu before sedning, then they always get through?there is no visible
>> change to the email either (because they are just some default font
>> tags?I'm not really formatting the text).
>> 
>> 
>> On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
>>> Hey music-dsp-ers --
>>> 
>>> Has anyone else experienced troubles getting posts to show up on
>>> our list?  I've sent (and re-sent) several this morning and they
>>> just vanished.  I've checked with douglas about it, but was
>>> wondering if anyone else has had problems.
>>> 
>>> brad http://music.columbia.edu/~brad
>> 
>> -- 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://music.columbia.edu/~douglas
> 
> --
> 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

-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
http://blog.bjornroche.com





From douglas at music.columbia.edu  Sat Feb 25 14:20:42 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 14:20:42 -0500
Subject: [music-dsp] list postings
In-Reply-To: <F4CBB67F-8B8A-4907-972C-367AE7DCDEF6@xowave.com>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
	<F4CBB67F-8B8A-4907-972C-367AE7DCDEF6@xowave.com>
Message-ID: <4F49348A.8030307@music.columbia.edu>


Well it looks like the problem was that you were sending non-plaintext!

The reason that you don't receive a rejection notice when sending 
non-plaintext is that the messages aren't bounced, they're held for 
moderation. In the old days I'd go in and approve such messages. Today 
we get THOUSANDS of spam messages a day, so the server just deletes all 
held messages each day. SPAM bots have really made mailing lists, wiki 
maintenance, etc., annoying.

best,
douglas


On 2/25/12 2:14 PM, Bjorn Roche wrote:
> I've never had an email get through to this list, and I've never
> gotten a rejection notice, which is sad b/c once or twice I've
> actually had something constructive to say. (on two occasions, I've
> just email the original posters) With this email, I am explicitly
> setting the format to plain, as suggested, and we'll see.
>
> It's annoying because gmail filters out sent mail from received mail,
> so it doesn't show you list mail that you sent, and since I don't get
> a bounce for some reason, there's no way to know the email is missed!
> The best I can do is check the archives after its sent :-P
>
> bjorn
>
> On Feb 25, 2012, at 2:07 PM, douglas repetto wrote:
>
>>
>> It may be that Apple is adding something to the header indicating
>> rich text/html even though you don't end up with offending
>> characters in the email. The list software rejects email based on
>> the headers, not on the actual content.
>>
>> There's no fundamental reason why the list can't accept html mail,
>> btw. So if people really want it we can make a change. In the past
>> it's been about spam control and saving bandwidth, but those issues
>> aren't such big concerns anymore, I think. Although I personally
>> find that reading a list like this in different fonts/colors/styles
>> can be unpleasant.
>>
>> douglas
>>
>> On 2/25/12 2:02 PM, Nigel Redmon wrote:
>>> I've had problems in the past when html-style font tags make
>>> their way into the email. For instance, this happens in Apple's
>>> Mail.app. Even though it's not an html email, per se, they
>>> sometimes get rejected (but not always). If I do Make Plain Text
>>> from the Format menu before sedning, then they always get
>>> through?there is no visible change to the email either (because
>>> they are just some default font tags?I'm not really formatting
>>> the text).
>>>
>>>
>>> On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
>>>> Hey music-dsp-ers --
>>>>
>>>> Has anyone else experienced troubles getting posts to show up
>>>> on our list?  I've sent (and re-sent) several this morning and
>>>> they just vanished.  I've checked with douglas about it, but
>>>> was wondering if anyone else has had problems.
>>>>
>>>> brad http://music.columbia.edu/~brad
>>>
>>> -- 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://music.columbia.edu/~douglas
>>
>> -- 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
>
> ----------------------------- Bjorn Roche http://www.xonami.com Audio
> Collaboration http://blog.bjornroche.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://music.columbia.edu/~douglas


From douglas at music.columbia.edu  Sat Feb 25 14:21:31 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 14:21:31 -0500
Subject: [music-dsp] list postings
In-Reply-To: <4F49348A.8030307@music.columbia.edu>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
	<F4CBB67F-8B8A-4907-972C-367AE7DCDEF6@xowave.com>
	<4F49348A.8030307@music.columbia.edu>
Message-ID: <4F4934BB.1060602@music.columbia.edu>


And btw, you should receive a message from the list software with links 
to the list FAQs, which detail various reasons why your messages might 
not make it through.

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


best,
douglas

On 2/25/12 2:20 PM, douglas repetto wrote:
>
> Well it looks like the problem was that you were sending non-plaintext!
>
> The reason that you don't receive a rejection notice when sending
> non-plaintext is that the messages aren't bounced, they're held for
> moderation. In the old days I'd go in and approve such messages. Today
> we get THOUSANDS of spam messages a day, so the server just deletes all
> held messages each day. SPAM bots have really made mailing lists, wiki
> maintenance, etc., annoying.
>
> best,
> douglas
>
>
> On 2/25/12 2:14 PM, Bjorn Roche wrote:
>> I've never had an email get through to this list, and I've never
>> gotten a rejection notice, which is sad b/c once or twice I've
>> actually had something constructive to say. (on two occasions, I've
>> just email the original posters) With this email, I am explicitly
>> setting the format to plain, as suggested, and we'll see.
>>
>> It's annoying because gmail filters out sent mail from received mail,
>> so it doesn't show you list mail that you sent, and since I don't get
>> a bounce for some reason, there's no way to know the email is missed!
>> The best I can do is check the archives after its sent :-P
>>
>> bjorn
>>
>> On Feb 25, 2012, at 2:07 PM, douglas repetto wrote:
>>
>>>
>>> It may be that Apple is adding something to the header indicating
>>> rich text/html even though you don't end up with offending
>>> characters in the email. The list software rejects email based on
>>> the headers, not on the actual content.
>>>
>>> There's no fundamental reason why the list can't accept html mail,
>>> btw. So if people really want it we can make a change. In the past
>>> it's been about spam control and saving bandwidth, but those issues
>>> aren't such big concerns anymore, I think. Although I personally
>>> find that reading a list like this in different fonts/colors/styles
>>> can be unpleasant.
>>>
>>> douglas
>>>
>>> On 2/25/12 2:02 PM, Nigel Redmon wrote:
>>>> I've had problems in the past when html-style font tags make
>>>> their way into the email. For instance, this happens in Apple's
>>>> Mail.app. Even though it's not an html email, per se, they
>>>> sometimes get rejected (but not always). If I do Make Plain Text
>>>> from the Format menu before sedning, then they always get
>>>> through?there is no visible change to the email either (because
>>>> they are just some default font tags?I'm not really formatting
>>>> the text).
>>>>
>>>>
>>>> On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
>>>>> Hey music-dsp-ers --
>>>>>
>>>>> Has anyone else experienced troubles getting posts to show up
>>>>> on our list? I've sent (and re-sent) several this morning and
>>>>> they just vanished. I've checked with douglas about it, but
>>>>> was wondering if anyone else has had problems.
>>>>>
>>>>> brad http://music.columbia.edu/~brad
>>>>
>>>> -- 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://music.columbia.edu/~douglas
>>>
>>> -- 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
>>
>> ----------------------------- Bjorn Roche http://www.xonami.com Audio
>> Collaboration http://blog.bjornroche.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://music.columbia.edu/~douglas


From tom at electricdruid.net  Sat Feb 25 14:22:00 2012
From: tom at electricdruid.net (Tom Wiltshire)
Date: Sat, 25 Feb 2012 19:22:00 +0000
Subject: [music-dsp] list postings
In-Reply-To: <4F49316F.5000703@music.columbia.edu>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
Message-ID: <95EECE5B-D2BB-45EC-9DF3-813B88B76D92@electricdruid.net>

Here's an example of a basic RTF document:

	{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf360
	{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
	{\colortbl;\red255\green255\blue255;}
	\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
	\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural

	\f0\fs24 \cf0 This is a basic rtf document\
	}

I don't know what headers Apple's Mail.app sends out with this, but I can see why you wouldn't want to read that as plain text. Even if it got through (eg if the headers were ok) we'd still struggle to read it.

(The file was saved from Apple's TextEdit.app, in case anyone wants to know where the example came from)

T.


On 25 Feb 2012, at 19:07, douglas repetto wrote:

> 
> It may be that Apple is adding something to the header indicating rich text/html even though you don't end up with offending characters in the email. The list software rejects email based on the headers, not on the actual content.
> 
> There's no fundamental reason why the list can't accept html mail, btw. So if people really want it we can make a change. In the past it's been about spam control and saving bandwidth, but those issues aren't such big concerns anymore, I think. Although I personally find that reading a list like this in different fonts/colors/styles can be unpleasant.
> 
> douglas
> 
> On 2/25/12 2:02 PM, Nigel Redmon wrote:
>> I've had problems in the past when html-style font tags make their
>> way into the email. For instance, this happens in Apple's Mail.app.
>> Even though it's not an html email, per se, they sometimes get
>> rejected (but not always). If I do Make Plain Text from the Format
>> menu before sedning, then they always get through?there is no visible
>> change to the email either (because they are just some default font
>> tags?I'm not really formatting the text).
>> 
>> 
>> On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
>>> Hey music-dsp-ers --
>>> 
>>> Has anyone else experienced troubles getting posts to show up on
>>> our list?  I've sent (and re-sent) several this morning and they
>>> just vanished.  I've checked with douglas about it, but was
>>> wondering if anyone else has had problems.
>>> 
>>> brad http://music.columbia.edu/~brad
>> 
>> -- 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://music.columbia.edu/~douglas
> 
> --
> 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 bil at ccrma.Stanford.EDU  Sat Feb 25 14:23:57 2012
From: bil at ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Sat, 25 Feb 2012 11:23:57 -0800
Subject: [music-dsp] a little about myself
In-Reply-To: <mailman.1229.1330195746.148.music-dsp@music.columbia.edu>
References: <mailman.1229.1330195746.148.music-dsp@music.columbia.edu>
Message-ID: <20120225191327.M93094@ccrma.Stanford.EDU>

> The only language I'm aware of that allows the design of direct 
> sample-massaging code in the language itself is chuck.  

CLM?  Or do I misunderstand something?  When I put on my old
and battered composer's hat, I'd say "the GUI made me do it"
is not very persuasive.  In linguistics, it's known as
the Great Eskimo Vocabulary Hoax.  I wrote the same basic kinds
of music whether by hand ("Daily Life"), using SCORE ("Sandcastle"),
using Pla + Samson box (many tunes), etc.  By the way, 
if you're interested in "closures and lambdas", Snd+CLM+s7
has a ton; or check out Rick Taube's work.


From douglas at music.columbia.edu  Sat Feb 25 14:24:55 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 14:24:55 -0500
Subject: [music-dsp] list postings
In-Reply-To: <95EECE5B-D2BB-45EC-9DF3-813B88B76D92@electricdruid.net>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
	<95EECE5B-D2BB-45EC-9DF3-813B88B76D92@electricdruid.net>
Message-ID: <4F493587.7070902@music.columbia.edu>


Reading rich text email is email client dependent. Modern clients look 
at the headers and interpret the email accordingly.

I guess that's another argument against allowing non-plaintext -- it 
makes it really difficult to read the list in old school email clients 
that have no rich text parsing.

douglas

On 2/25/12 2:22 PM, Tom Wiltshire wrote:
> Here's an example of a basic RTF document:
>
> {\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf360
> {\fonttbl\f0\fswiss\fcharset0 Helvetica;}
> {\colortbl;\red255\green255\blue255;}
> \paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
>
>
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
>
> \f0\fs24 \cf0 This is a basic rtf document\ }
>
> I don't know what headers Apple's Mail.app sends out with this, but I
> can see why you wouldn't want to read that as plain text. Even if it
> got through (eg if the headers were ok) we'd still struggle to read
> it.
>
> (The file was saved from Apple's TextEdit.app, in case anyone wants
> to know where the example came from)
>
> T.
>
>
> On 25 Feb 2012, at 19:07, douglas repetto wrote:
>
>>
>> It may be that Apple is adding something to the header indicating
>> rich text/html even though you don't end up with offending
>> characters in the email. The list software rejects email based on
>> the headers, not on the actual content.
>>
>> There's no fundamental reason why the list can't accept html mail,
>> btw. So if people really want it we can make a change. In the past
>> it's been about spam control and saving bandwidth, but those issues
>> aren't such big concerns anymore, I think. Although I personally
>> find that reading a list like this in different fonts/colors/styles
>> can be unpleasant.
>>
>> douglas
>>
>> On 2/25/12 2:02 PM, Nigel Redmon wrote:
>>> I've had problems in the past when html-style font tags make
>>> their way into the email. For instance, this happens in Apple's
>>> Mail.app. Even though it's not an html email, per se, they
>>> sometimes get rejected (but not always). If I do Make Plain Text
>>> from the Format menu before sedning, then they always get
>>> through?there is no visible change to the email either (because
>>> they are just some default font tags?I'm not really formatting
>>> the text).
>>>
>>>
>>> On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
>>>> Hey music-dsp-ers --
>>>>
>>>> Has anyone else experienced troubles getting posts to show up
>>>> on our list?  I've sent (and re-sent) several this morning and
>>>> they just vanished.  I've checked with douglas about it, but
>>>> was wondering if anyone else has had problems.
>>>>
>>>> brad http://music.columbia.edu/~brad
>>>
>>> -- 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://music.columbia.edu/~douglas
>>
>> -- 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://artbots.org
.....douglas.....irving........................ http://dorkbot.org
.......................... http://music.columbia.edu/cmc/music-dsp
...........repetto............. http://music.columbia.edu/organism
............................... http://music.columbia.edu/~douglas


From bjorn at xowave.com  Sat Feb 25 14:42:51 2012
From: bjorn at xowave.com (Bjorn Roche)
Date: Sat, 25 Feb 2012 14:42:51 -0500
Subject: [music-dsp] list postings
In-Reply-To: <4F4934BB.1060602@music.columbia.edu>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
	<F4CBB67F-8B8A-4907-972C-367AE7DCDEF6@xowave.com>
	<4F49348A.8030307@music.columbia.edu>
	<4F4934BB.1060602@music.columbia.edu>
Message-ID: <96103578-3F1E-4961-90F2-31A87C857E59@xowave.com>


On Feb 25, 2012, at 2:21 PM, douglas repetto wrote:

> 
> And btw, you should receive a message from the list software with links to the list FAQs, which detail various reasons why your messages might not make it through.
> 
> http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.admin.html

Nothing there about rtf. just html. It also says I should have received a bounce. Perhaps that should be clarified.


> Reading rich text email is email client dependent. Modern clients look at the headers and interpret the email accordingly.
> 
> I guess that's another argument against allowing non-plaintext -- it makes it really difficult to read the list in old school email clients that have no rich text parsing.


I used to use mutt and pine and I never had a problem with this. Even if they can't parse the formatted text, most clients send a plain text version along with the formatted version as alternative views, but maybe things have changed.

bjorn

-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
http://blog.bjornroche.com





From garton at columbia.edu  Sat Feb 25 14:57:47 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 14:57:47 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <20120225191327.M93094@ccrma.Stanford.EDU>
References: <mailman.1229.1330195746.148.music-dsp@music.columbia.edu>
	<20120225191327.M93094@ccrma.Stanford.EDU>
Message-ID: <BC45D7C4-CE92-41B8-A8DF-DE5399C9C84F@columbia.edu>

On Feb 25, 2012, at 2:23 PM, Bill Schottstaedt wrote:

>> The only language I'm aware of that allows the design of direct 
>> sample-massaging code in the language itself is chuck.  
> 
> CLM?  Or do I misunderstand something?

Aha -- my 'weasel-wording' was "aware of".  Of course CLM!  My
awareness ain't what it used to be.  Sorry Bill!

> When I put on my old
> and battered composer's hat, I'd say "the GUI made me do it"
> is not very persuasive.  In linguistics, it's known as
> the Great Eskimo Vocabulary Hoax.  I wrote the same basic kinds
> of music whether by hand ("Daily Life"), using SCORE ("Sandcastle"),
> using Pla + Samson box (many tunes), etc.

For me it's more the point of what kind of music is more 'enabled' by
particular design decisions.  The 50000 words for "snow" notwithstanding,
I bet that people using a software instrument with the pitch specification
in Hz will generally do different musics than people who use one with
a 12-tone ET specification.  Yeah, I know you can get around these
specifications, but still...

brad
http://music.columbia.edu/~brad


From douglas at music.columbia.edu  Sat Feb 25 15:19:31 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 15:19:31 -0500
Subject: [music-dsp] list postings
In-Reply-To: <96103578-3F1E-4961-90F2-31A87C857E59@xowave.com>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
	<F4CBB67F-8B8A-4907-972C-367AE7DCDEF6@xowave.com>
	<4F49348A.8030307@music.columbia.edu>
	<4F4934BB.1060602@music.columbia.edu>
	<96103578-3F1E-4961-90F2-31A87C857E59@xowave.com>
Message-ID: <4F494253.7090804@music.columbia.edu>


Thanks, Bjorn, I've updated the FAQ with more current info.

douglas

On 2/25/12 2:42 PM, Bjorn Roche wrote:
>
> On Feb 25, 2012, at 2:21 PM, douglas repetto wrote:
>
>>
>> And btw, you should receive a message from the list software with links to the list FAQs, which detail various reasons why your messages might not make it through.
>>
>> http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.admin.html
>
> Nothing there about rtf. just html. It also says I should have received a bounce. Perhaps that should be clarified.
>
>
>> Reading rich text email is email client dependent. Modern clients look at the headers and interpret the email accordingly.
>>
>> I guess that's another argument against allowing non-plaintext -- it makes it really difficult to read the list in old school email clients that have no rich text parsing.
>
>
> I used to use mutt and pine and I never had a problem with this. Even if they can't parse the formatted text, most clients send a plain text version along with the formatted version as alternative views, but maybe things have changed.
>
> bjorn
>
> -----------------------------
> Bjorn Roche
> http://www.xonami.com
> Audio Collaboration
> http://blog.bjornroche.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://music.columbia.edu/~douglas


From earlevel at earlevel.com  Sat Feb 25 15:39:04 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Sat, 25 Feb 2012 12:39:04 -0800
Subject: [music-dsp] list postings
In-Reply-To: <4F49316F.5000703@music.columbia.edu>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
Message-ID: <16E8CDB2-D1EB-46C0-8A0B-93BE16E183AC@earlevel.com>

Even without forcing the message with Make Plain Text (with rich text default), the message gets sent as text/plain?normally. I guess what might happen is some formatting gets bumped in during typing by accident, in which case the message is send as multipart/alternative, with text and html parts, and those messages definitely get rejected.

In past versions of mail?years ago?I know I've also seen situations where the font tags were embedded without other html tags, and those were rejected by the list. Mail doesn't seem to behave that way currently, though.


On Feb 25, 2012, at 11:07 AM, douglas repetto wrote:
> 
> It may be that Apple is adding something to the header indicating rich text/html even though you don't end up with offending characters in the email. The list software rejects email based on the headers, not on the actual content.
> 
> There's no fundamental reason why the list can't accept html mail, btw. So if people really want it we can make a change. In the past it's been about spam control and saving bandwidth, but those issues aren't such big concerns anymore, I think. Although I personally find that reading a list like this in different fonts/colors/styles can be unpleasant.
> 
> douglas
> 
> On 2/25/12 2:02 PM, Nigel Redmon wrote:
>> I've had problems in the past when html-style font tags make their
>> way into the email. For instance, this happens in Apple's Mail.app.
>> Even though it's not an html email, per se, they sometimes get
>> rejected (but not always). If I do Make Plain Text from the Format
>> menu before sedning, then they always get through?there is no visible
>> change to the email either (because they are just some default font
>> tags?I'm not really formatting the text).
>> 
>> 
>> On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
>>> Hey music-dsp-ers --
>>> 
>>> Has anyone else experienced troubles getting posts to show up on
>>> our list?  I've sent (and re-sent) several this morning and they
>>> just vanished.  I've checked with douglas about it, but was
>>> wondering if anyone else has had problems.
>>> 
>>> brad http://music.columbia.edu/~brad
>> 
>> -- 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://music.columbia.edu/~douglas
> 
> --
> 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 earlevel at earlevel.com  Sat Feb 25 15:42:22 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Sat, 25 Feb 2012 12:42:22 -0800
Subject: [music-dsp] list postings
In-Reply-To: <95EECE5B-D2BB-45EC-9DF3-813B88B76D92@electricdruid.net>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
	<95EECE5B-D2BB-45EC-9DF3-813B88B76D92@electricdruid.net>
Message-ID: <A442FC9D-83A1-4B09-8A72-D13BB352A1A8@earlevel.com>

Tom?when Apple says "rich text", they mean that in the generic sense, not rtf. I don't think Mail has ever sent message in rtf.


On Feb 25, 2012, at 11:22 AM, Tom Wiltshire wrote:

> Here's an example of a basic RTF document:
> 
> 	{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf360
> 	{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
> 	{\colortbl;\red255\green255\blue255;}
> 	\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
> 	\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
> 
> 	\f0\fs24 \cf0 This is a basic rtf document\
> 	}
> 
> I don't know what headers Apple's Mail.app sends out with this, but I can see why you wouldn't want to read that as plain text. Even if it got through (eg if the headers were ok) we'd still struggle to read it.
> 
> (The file was saved from Apple's TextEdit.app, in case anyone wants to know where the example came from)
> 
> T.
> 
> 
> On 25 Feb 2012, at 19:07, douglas repetto wrote:
> 
>> 
>> It may be that Apple is adding something to the header indicating rich text/html even though you don't end up with offending characters in the email. The list software rejects email based on the headers, not on the actual content.
>> 
>> There's no fundamental reason why the list can't accept html mail, btw. So if people really want it we can make a change. In the past it's been about spam control and saving bandwidth, but those issues aren't such big concerns anymore, I think. Although I personally find that reading a list like this in different fonts/colors/styles can be unpleasant.
>> 
>> douglas
>> 
>> On 2/25/12 2:02 PM, Nigel Redmon wrote:
>>> I've had problems in the past when html-style font tags make their
>>> way into the email. For instance, this happens in Apple's Mail.app.
>>> Even though it's not an html email, per se, they sometimes get
>>> rejected (but not always). If I do Make Plain Text from the Format
>>> menu before sedning, then they always get through?there is no visible
>>> change to the email either (because they are just some default font
>>> tags?I'm not really formatting the text).
>>> 
>>> 
>>> On Feb 25, 2012, at 10:38 AM, Brad Garton wrote:
>>>> Hey music-dsp-ers --
>>>> 
>>>> Has anyone else experienced troubles getting posts to show up on
>>>> our list?  I've sent (and re-sent) several this morning and they
>>>> just vanished.  I've checked with douglas about it, but was
>>>> wondering if anyone else has had problems.
>>>> 
>>>> brad http://music.columbia.edu/~brad
>>> 
>>> -- 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://music.columbia.edu/~douglas
>> 
>> --
>> 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 tom at electricdruid.net  Sat Feb 25 16:33:26 2012
From: tom at electricdruid.net (Tom Wiltshire)
Date: Sat, 25 Feb 2012 21:33:26 +0000
Subject: [music-dsp] list postings
In-Reply-To: <A442FC9D-83A1-4B09-8A72-D13BB352A1A8@earlevel.com>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
	<95EECE5B-D2BB-45EC-9DF3-813B88B76D92@electricdruid.net>
	<A442FC9D-83A1-4B09-8A72-D13BB352A1A8@earlevel.com>
Message-ID: <13D7141F-A2A8-4681-9820-32D5BF353DD2@electricdruid.net>

Oh, ok. I assumed that when they said "Rich text" in Mail.app, they meant the same as when they say "rich text format" in TextEdit. My mistake.

Checking more carefully, I find you're right. Mail sends "rich text" messages as "Content-Type: multipart/alternative;" and includes the "rich text" part in an html attachment

Like this:

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This is a <i>rich</i> text email</body></html>

But presumably it's the fact that it's sent as an attachment that kills delivery to the list since otherwise we'd be reading raw html, as we can above.

T.

On 25 Feb 2012, at 20:42, Nigel Redmon wrote:

> Tom?when Apple says "rich text", they mean that in the generic sense, not rtf. I don't think Mail has ever sent message in rtf.
> 
> 
> On Feb 25, 2012, at 11:22 AM, Tom Wiltshire wrote:
> 
>> Here's an example of a basic RTF document:
>> 
>> 	{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf360
>> 	{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
>> 	{\colortbl;\red255\green255\blue255;}
>> 	\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
>> 	\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
>> 
>> 	\f0\fs24 \cf0 This is a basic rtf document\
>> 	}
>> 
>> I don't know what headers Apple's Mail.app sends out with this, but I can see why you wouldn't want to read that as plain text. Even if it got through (eg if the headers were ok) we'd still struggle to read it.
>> 
>> (The file was saved from Apple's TextEdit.app, in case anyone wants to know where the example came from)
>> 
>> T.
>> 


From douglas at music.columbia.edu  Sat Feb 25 16:40:07 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 16:40:07 -0500
Subject: [music-dsp] list postings
In-Reply-To: <13D7141F-A2A8-4681-9820-32D5BF353DD2@electricdruid.net>
References: <5720DCED-0CFA-4E12-8E2B-EFBF9A4DBDFB@columbia.edu>
	<AD433F12-B90F-4988-AF81-0C342E29F8E0@earlevel.com>
	<4F49316F.5000703@music.columbia.edu>
	<95EECE5B-D2BB-45EC-9DF3-813B88B76D92@electricdruid.net>
	<A442FC9D-83A1-4B09-8A72-D13BB352A1A8@earlevel.com>
	<13D7141F-A2A8-4681-9820-32D5BF353DD2@electricdruid.net>
Message-ID: <4F495537.8080901@music.columbia.edu>


It's the contents of the headers that triggers bounces/rejections, not 
the content of the message. At least for non-plaintext mail. Spam 
filtering, of course, also works on message content.

best,
douglas

On 2/25/12 4:33 PM, Tom Wiltshire wrote:
> Oh, ok. I assumed that when they said "Rich text" in Mail.app, they
> meant the same as when they say "rich text format" in TextEdit. My
> mistake.
>
> Checking more carefully, I find you're right. Mail sends "rich text"
> messages as "Content-Type: multipart/alternative;" and includes the
> "rich text" part in an html attachment
>
> Like this:
>
> <html><head></head><body style="word-wrap: break-word;
> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;
> ">This is a<i>rich</i>  text email</body></html>
>
> But presumably it's the fact that it's sent as an attachment that
> kills delivery to the list since otherwise we'd be reading raw html,
> as we can above.
>
> T.
>
> On 25 Feb 2012, at 20:42, Nigel Redmon wrote:
>
>> Tom?when Apple says "rich text", they mean that in the generic
>> sense, not rtf. I don't think Mail has ever sent message in rtf.
>>
>>
>> On Feb 25, 2012, at 11:22 AM, Tom Wiltshire wrote:
>>
>>> Here's an example of a basic RTF document:
>>>
>>> {\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf360
>>> {\fonttbl\f0\fswiss\fcharset0 Helvetica;}
>>> {\colortbl;\red255\green255\blue255;}
>>> \paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
>>>
>>>
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
>>>
>>> \f0\fs24 \cf0 This is a basic rtf document\ }
>>>
>>> I don't know what headers Apple's Mail.app sends out with this,
>>> but I can see why you wouldn't want to read that as plain text.
>>> Even if it got through (eg if the headers were ok) we'd still
>>> struggle to read it.
>>>
>>> (The file was saved from Apple's TextEdit.app, in case anyone
>>> wants to know where the example came from)
>>>
>>> T.
>>>
>
> -- dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book
> reviews, dsp links http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>

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


From padawan12 at obiwannabe.co.uk  Sat Feb 25 17:31:41 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sat, 25 Feb 2012 22:31:41 +0000
Subject: [music-dsp] Boulez
In-Reply-To: <CAK1FW3WQ0Sn0vq7ikDFpEcy=S09NNxXoFVJ18S0MZdQ4S2RLww@mail.gmail.com>
References: <CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<20120225113427.GA22352@sapphire.lan>
	<CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
	<CAK1FW3WQ0Sn0vq7ikDFpEcy=S09NNxXoFVJ18S0MZdQ4S2RLww@mail.gmail.com>
Message-ID: <20120225223141.GD23667@sapphire.lan>



Hopefully I am not misunderstanding here. I think the big influence
on the low level design of music software, viz callbacks &c is that
the modern desktop and operating system is such a fiendishly complicated
system callback (interrupt led) buffering is essential to mediate the producer
consumer problem in this unpredictable runtime.

With simpler hardware, and total control over it (as for FPGA),
radically different things are possible. I understand why some 
here like that approach and prefer the idea of a synth or 
processor being a dedicated _device_.

best
Andy



On Sat, Feb 25, 2012 at 09:40:59AM -0500, Adam Puckett wrote:
> Would it be possible to design a callback that dynamically filled the
> buffer as it was being called, or if the buffer didn't exist, create
> it and put one sample in it? that way there wouldn't be any "dropped
> calls" in the process. Or am I missing something?
> 
> On 2/25/12, Charles Turner <vze26m98 at optonline.net> wrote:
> > On Feb 25, 2012, at 6:34 AM, Andy Farnell wrote:
> >
> >> And whereas I do agree with Pierre Boulez here, maybe it
> >> is misguided to turn to reductionism and simplicity for
> >> their own sake. It may be equally hopeless to embark
> >> on a quest for authenticity this way.
> >
> > Hi Andy-
> >
> > I should apologize for hastily listing the publication date of the book. The
> > book collects his Darmstadt lectures from 1954-56, so it comes from a much
> > earlier time. I don't think Boulez would have changed his mind on things
> > though. Sounds like you come from a much more "Schaefferian" era.
> >
> > Isn't the point not to take sides, but recognize the tension? Cultures that
> > are busily exploring harmonic relations, haven't simultaneously plunged deep
> > into the world of rhythm. Music is just too big a subject, and some of its
> > properties exist in a dialectical relation to others. Although we all enjoy
> > a sweet dessert, we don't put sugar in everything. (Unless you're the Nestle
> > company!)
> >
> > My point was that the checkpoint raised by callbacks feeding a sample buffer
> > may come from resistances outside the technical world. Boulez sees timbre as
> > the enemy of harmony. Could very well be that the callback is the result of
> > a cultural outlook, and not the result of engineering design?
> >
> > Best, Charles
> >
> > --
> > 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 padawan12 at obiwannabe.co.uk  Sat Feb 25 17:43:06 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sat, 25 Feb 2012 22:43:06 +0000
Subject: [music-dsp] Boulez
In-Reply-To: <CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
References: <CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<20120225113427.GA22352@sapphire.lan>
	<CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
Message-ID: <20120225224306.GE23667@sapphire.lan>

Hi Charles,

> The book collects his Darmstadt lectures from 1954-56

Yes, that era fits better with the ideas conveyed. thanks
for the clear up.

> Isn't the point not to take sides, but recognize the tension? 

Definitely. You are absolutely right. That was where I was headed
with my remarks.


> Could very well be that the callback is the result of a cultural 
> outlook, and not the result of engineering design?

Embellishing my reply to Adam, it's not so much engineering design
as engineering circumstance. We find ourselves writing code on
general purpose desktop computers with multi-tasking operating
systems and a quite unpredictable kernel schedule. Starting
from a certain necessity the rest of the design seems to follow
quite naturally. 

cheers,
Andy


From adotsdothmusic at gmail.com  Sat Feb 25 17:53:16 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Sat, 25 Feb 2012 17:53:16 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <BC45D7C4-CE92-41B8-A8DF-DE5399C9C84F@columbia.edu>
References: <mailman.1229.1330195746.148.music-dsp@music.columbia.edu>
	<20120225191327.M93094@ccrma.Stanford.EDU>
	<BC45D7C4-CE92-41B8-A8DF-DE5399C9C84F@columbia.edu>
Message-ID: <CAK1FW3VMqSfwMdp6famVtq1+DEPJUhGtX0HN1jdfuQhVJ4O73A@mail.gmail.com>

I get around the Hz spec by calculating

440*2^((x-69)/12)

to get MIDI notes.

On 2/25/12, Brad Garton <garton at columbia.edu> wrote:
> On Feb 25, 2012, at 2:23 PM, Bill Schottstaedt wrote:
>
>>> The only language I'm aware of that allows the design of direct
>>> sample-massaging code in the language itself is chuck.
>>
>> CLM?  Or do I misunderstand something?
>
> Aha -- my 'weasel-wording' was "aware of".  Of course CLM!  My
> awareness ain't what it used to be.  Sorry Bill!
>
>> When I put on my old
>> and battered composer's hat, I'd say "the GUI made me do it"
>> is not very persuasive.  In linguistics, it's known as
>> the Great Eskimo Vocabulary Hoax.  I wrote the same basic kinds
>> of music whether by hand ("Daily Life"), using SCORE ("Sandcastle"),
>> using Pla + Samson box (many tunes), etc.
>
> For me it's more the point of what kind of music is more 'enabled' by
> particular design decisions.  The 50000 words for "snow" notwithstanding,
> I bet that people using a software instrument with the pitch specification
> in Hz will generally do different musics than people who use one with
> a 12-tone ET specification.  Yeah, I know you can get around these
> specifications, but still...
>
> brad
> http://music.columbia.edu/~brad
>
> --
> 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 david at olofson.net  Sat Feb 25 18:07:06 2012
From: david at olofson.net (David Olofson)
Date: Sun, 26 Feb 2012 00:07:06 +0100
Subject: [music-dsp] Boulez
In-Reply-To: <CAK1FW3WQ0Sn0vq7ikDFpEcy=S09NNxXoFVJ18S0MZdQ4S2RLww@mail.gmail.com>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
	<CAK1FW3WQ0Sn0vq7ikDFpEcy=S09NNxXoFVJ18S0MZdQ4S2RLww@mail.gmail.com>
Message-ID: <201202260007.06096.david@olofson.net>

On Saturday 25 February 2012, at 15.40.59, Adam Puckett 
<adotsdothmusic at gmail.com> wrote:
> Would it be possible to design a callback that dynamically filled the
> buffer as it was being called, or if the buffer didn't exist, create
> it and put one sample in it? that way there wouldn't be any "dropped
> calls" in the process. Or am I missing something?

Well, no matter how you go about implementing it, what it comes down to is 
that every sample MUST be in place when the sound card needs it. There's just 
no way around that. :-)

There is one "trick" along those lines, though, often used in video games: Use 
a shared memory DMA buffer of "substantial" size (half a second or so), and 
split the mixing code into two parts;

	1) one that mixes playing sounds/streams in somewhere
	   down the buffer, for minimal risk of drop-outs, and

	2) one that mixes in the initial parts of newly started
	   sounds from pretty the current DMA position (that is,
	   near zero latency), and down to where the other mixer
	   part will take over.

However, this won't really eliminate the drop-out problem. All it does is 
reduce the damage caused by scheduling latency peaks. Instead of the whole 
stream (soundscape, music, playing effects - everything) glitching or having a 
dubstep moment, the first few moments of newly started sounds will be lost, 
while the "old" streams keep playing as usual.

I'd say this method is just a complicated band-aid with lots of issues, and 
not even suitable for musical applications - but if all else fails...


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From emanuel.landeholm at gmail.com  Sat Feb 25 19:30:48 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Sun, 26 Feb 2012 01:30:48 +0100
Subject: [music-dsp] Boulez
In-Reply-To: <201202260007.06096.david@olofson.net>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
	<CAK1FW3WQ0Sn0vq7ikDFpEcy=S09NNxXoFVJ18S0MZdQ4S2RLww@mail.gmail.com>
	<201202260007.06096.david@olofson.net>
Message-ID: <CAML4ZX4fUSHhNdjHK6gNcPZ9qxdQHh_kWcw-HxeZFbpH=mfyHQ@mail.gmail.com>

In the future, people will be able to emulate our OS:s in real time.
(Kind of like how I am able to emulate a C-64 with minimum latency
right now) So even if we are not quite there yet, our descendants will
know how to run our code,

> Well, no matter how you go about implementing it, what it comes down to is
> that every sample MUST be in place when the sound card needs it. There's just
> no way around that. :-)

From david at olofson.net  Sat Feb 25 19:45:08 2012
From: david at olofson.net (David Olofson)
Date: Sun, 26 Feb 2012 01:45:08 +0100
Subject: [music-dsp] Boulez
In-Reply-To: <CAML4ZX4fUSHhNdjHK6gNcPZ9qxdQHh_kWcw-HxeZFbpH=mfyHQ@mail.gmail.com>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<201202260007.06096.david@olofson.net>
	<CAML4ZX4fUSHhNdjHK6gNcPZ9qxdQHh_kWcw-HxeZFbpH=mfyHQ@mail.gmail.com>
Message-ID: <201202260145.08912.david@olofson.net>


While raw speed does reduce the risk of missing deadlines, you need an 
infinitely fast computer to guarantee hard realtime performance with code that 
isn't designed for it. Also, theoretically, not even that helps, unless you 
also have a realtime OS. And then there's I/O, synchronization and blocking 
calls...

It's not really about raw speed.


On Sunday 26 February 2012, at 01.30.48, Emanuel Landeholm 
<emanuel.landeholm at gmail.com> wrote:
> In the future, people will be able to emulate our OS:s in real time.
> (Kind of like how I am able to emulate a C-64 with minimum latency
> right now) So even if we are not quite there yet, our descendants will
> know how to run our code,
> 
> > Well, no matter how you go about implementing it, what it comes down to
> > is that every sample MUST be in place when the sound card needs it.
> > There's just no way around that. :-)
> 
> --
> 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

-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From emanuel.landeholm at gmail.com  Sat Feb 25 19:53:49 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Sun, 26 Feb 2012 01:53:49 +0100
Subject: [music-dsp] Boulez
In-Reply-To: <201202260145.08912.david@olofson.net>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<201202260007.06096.david@olofson.net>
	<CAML4ZX4fUSHhNdjHK6gNcPZ9qxdQHh_kWcw-HxeZFbpH=mfyHQ@mail.gmail.com>
	<201202260145.08912.david@olofson.net>
Message-ID: <CAML4ZX40F-qrQOBBckfN-Ekm-VVFZERv2uxMqYjLq01pcOR8eQ@mail.gmail.com>

> While raw speed does reduce the risk of missing deadlines, you need an
> infinitely fast computer to guarantee hard realtime performance with code that
> isn't designed for it. Also, theoretically, not even that helps, unless you
> also have a realtime OS. And then there's I/O, synchronization and blocking
> calls...

True.
Real time is certainly something we might approach asymptotically, but
exceptionally bad code we cannot really do anything about. But I
remain optimistic. Our descendants should be able to emulate most of
our endeavours with high enough degree of accuracy.

From adotsdothmusic at gmail.com  Sat Feb 25 20:19:25 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Sat, 25 Feb 2012 20:19:25 -0500
Subject: [music-dsp] guitar physical model
Message-ID: <CAK1FW3UTfQk8sDL9n5pM0jc9zQvB7y914P_rG6oaALnkHL_Z3A@mail.gmail.com>

I've seen code for string physical modeling, so I have a (somewhat)
good idea of what all is involved in it. However, I haven't seen any
code that accounts for frets, as are on a guitar or banjo. How would
one go about implementing the fret sounds/gestures like slide,
hammer-on/pull-off? Seems to me like there would be rounding somewhere
in the code, as the finger never is supposed to actually touch the
fret, or you will get a "buzzing" sound. Also how is the "squeak" of
the sliding finger implemented? What is the relationship of the frets
to one another, as they get shorter the further down the neck you go?

From rbj at audioimagination.com  Sat Feb 25 20:26:28 2012
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Sat, 25 Feb 2012 20:26:28 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F426681.2090802@music.columbia.edu>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<4F426681.2090802@music.columbia.edu>
Message-ID: <4F498A44.3040809@audioimagination.com>

On 2/20/12 10:28 AM, douglas repetto wrote:
>
> Hi Adam,
>
> Welcome to the list. It's slow right now, but no doubt it'll flare up 
> again soon!

no shit


-- 

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




From douglas at music.columbia.edu  Sat Feb 25 20:43:04 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Sat, 25 Feb 2012 20:43:04 -0500
Subject: [music-dsp] Boulez
In-Reply-To: <CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<20120225113427.GA22352@sapphire.lan>
	<CEFC6C83-20B0-4F56-A0D5-C69DCF860AD4@optonline.net>
Message-ID: <4F498E28.1020105@music.columbia.edu>


On 2/25/12 9:23 AM, Charles Turner wrote:
> My point was that the checkpoint raised by callbacks feeding a sample
> buffer may come from resistances outside the technical world. Boulez
> sees timbre as the enemy of harmony. Could very well be that the
> callback is the result of a cultural outlook, and not the result of
> engineering design?


I think there's an interesting analogy to things that happened with 
Western musical notation in the 20th century. Standard Western notation 
treats measures a bit like buffers -- they need to be there whether 
there's anything happening or not. A full orchestral score can be 
largely made of up thousands of rests. Measures mark time in a more or 
less linear way. A measure can be subdivided up into a certain number of 
chunks and all of those chunks need to be accounted for in every 
measure. Etc.

But lots of composers have resisted these things, and the 20th century 
saw many experiments with either tweaking traditional notation or just 
inventing totally new ways of describing music on a page. A curious 
aspect of both filling buffers with samples and putting notes and rests 
on a page is that there's an assumption that the musicians (or the 
algorithms or whatever) are always "on", but that sometimes they're just 
not making any sound.

But that's not really how live musicians tend to think of it. It's not 
like a violinist keeps her bow moving at all times and only touches it 
to the strings when there's a note to be played. But that's kinda what 
sending zeros to a buffer when there's no sound is like.

On the other hand, if you work directly in hardware (say using an analog 
synth, hooking up logical oscillators, or programming a microcontroller) 
you can take a very different approach. You twiddle some output pins 
when you want sound and when you don't want sound you can just go off 
and do other things. In many ways I think that's a lot more like what 
many musicians do -- when you're not playing (either because you've got 
a bunch of rests, or maybe you're playing improvised music and you're 
just sitting out for awhile, or whatever) you don't really sit there 
counting off the beats. You stop playing. You might think about other 
things. After awhile hopefully you'll notice that the conductor is about 
to cue you in, or you get an idea and decide to join the improvisation, 
etc. I've seen people reading books in Broadway orchestra pits...

I don't know that there's a useful connection to different ways of 
thinking about writing DSP routines, but I think the analogy is interesting.


douglas




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


From david at olofson.net  Sat Feb 25 20:55:55 2012
From: david at olofson.net (David Olofson)
Date: Sun, 26 Feb 2012 02:55:55 +0100
Subject: [music-dsp] Boulez
In-Reply-To: <CAML4ZX40F-qrQOBBckfN-Ekm-VVFZERv2uxMqYjLq01pcOR8eQ@mail.gmail.com>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<201202260145.08912.david@olofson.net>
	<CAML4ZX40F-qrQOBBckfN-Ekm-VVFZERv2uxMqYjLq01pcOR8eQ@mail.gmail.com>
Message-ID: <201202260255.56017.david@olofson.net>

On Sunday 26 February 2012, at 01.53.49, Emanuel Landeholm 
<emanuel.landeholm at gmail.com> wrote:
> > While raw speed does reduce the risk of missing deadlines, you need an
> > infinitely fast computer to guarantee hard realtime performance with code
> > that isn't designed for it. Also, theoretically, not even that helps,
> > unless you also have a realtime OS. And then there's I/O,
> > synchronization and blocking calls...
> 
> True.
> Real time is certainly something we might approach asymptotically, but
> exceptionally bad code we cannot really do anything about. But I
> remain optimistic. Our descendants should be able to emulate most of
> our endeavours with high enough degree of accuracy.

It certainly helps when you can do interesting stuff in suboptimal ways, and 
still end up using only a few percent of one of your many CPU cores. :-)


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

From garton at columbia.edu  Sat Feb 25 22:01:03 2012
From: garton at columbia.edu (Brad Garton)
Date: Sat, 25 Feb 2012 22:01:03 -0500
Subject: [music-dsp] guitar physical model
In-Reply-To: <CAK1FW3UTfQk8sDL9n5pM0jc9zQvB7y914P_rG6oaALnkHL_Z3A@mail.gmail.com>
References: <CAK1FW3UTfQk8sDL9n5pM0jc9zQvB7y914P_rG6oaALnkHL_Z3A@mail.gmail.com>
Message-ID: <D000F604-2066-474A-9385-C6494E8A9985@columbia.edu>

Yikes, I'm just posting up a storm here today.  Sorry!

You might enjoy some older stuff I did back in 1989 -- 1991:

	http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3
	http://music.columbia.edu/~brad/music/mp3/Almost_Real.mp3

notes:

	http://music.columbia.edu/~brad/music/commentary/Rough_Raga_Riffs.html
	http://music.columbia.edu/~brad/music/notes/Rough_Raga_Riffs.html
	http://music.columbia.edu/~brad/music/notes/Almost_Real.html
	http://music.columbia.edu/~brad/music/commentary/Almost_Real.html

Both pieces were pretty much entirely algorithmically-generated, using
the Charlie Sullivan variant of the Karplus-Strong plucked string model and
a whole buncha lisp code.  A lot of what you describe (fretting, hammer-ons,
etc.) happen in my models at a level above the 'instrument' making the sound.
Here's an early paper describing some of it:

	http://music.columbia.edu/~brad/writing/papes/performance_model.pdf
		(1992 ICMC)

and a slightly later one I wrote with Matthew Suttor about style/performance
modeling in general:

	http://music.columbia.edu/~brad/writing/papes/Sense_of_Style.pdf

The lisp code I used is also on-line somewhere in my web pages.  Or if
you have max/msp, check out the help-patcher for my lisp interpreter
object [maxlisp]:  http://music.columbia.edu/~brad/maxlispj/  It does the
'electric guitar' performance model simulation in real-time (and all
the code is there, too).

c. 8' 30" in "Rough Raga Riffs" is when I taught it the "halenize" function
(Eddie Van!).  I like that part a lot...

brad
http://music.columbia.edu/~brad


On Feb 25, 2012, at 8:19 PM, Adam Puckett wrote:

> I've seen code for string physical modeling, so I have a (somewhat)
> good idea of what all is involved in it. However, I haven't seen any
> code that accounts for frets, as are on a guitar or banjo. How would
> one go about implementing the fret sounds/gestures like slide,
> hammer-on/pull-off? Seems to me like there would be rounding somewhere
> in the code, as the finger never is supposed to actually touch the
> fret, or you will get a "buzzing" sound. Also how is the "squeak" of
> the sliding finger implemented? What is the relationship of the frets
> to one another, as they get shorter the further down the neck you go?
> --
> 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 rossb-lists at audiomulch.com  Sun Feb 26 00:07:33 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sun, 26 Feb 2012 16:07:33 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <20120224180547.GA19742@sapphire.lan>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
Message-ID: <4F49BE15.8050008@audiomulch.com>

Hi Andy,

On 25/02/2012 5:05 AM, Andy Farnell wrote:
>
>> The problem with "plug unit generators languages" for me is that they
>> privilege the process (network of unit generators) over the content
>
> Some really interesting thoughts here Ross. At what level of
> granularity does the trade-off of control, flexibility and
> efficiency reach its sweet spot?

Part of my argument is that ther's a problem if your synthesis language 
is not turing complete. C/C++ and MP4-SAOL are two options here. I'm not 
sure Faust gives you that.


> In some ways the unit generator or patchable code-block
> model is to be considered a compromise between the overhead
> of calling functions on single samples and being able
> to process chunks. It comes bottom up, out of implementation needs
> rather than being a top down shorthand. On the other hand,
> because familiar structures like the filter, oscillator and so forth
> make sense as basic units of design the VM + Ugen model makes
> a lot of sense to practitioners coming from the studio.

Agreed.

As an aside: studio equipment (typically, not always) has this property 
that all couplings are impedence matched, or buffered. What something is 
plugged into doesn't affect what it does (to a first order 
approximation). This is not how acoustic systems nor electronic circuits 
work. So that's one problem with the abstraction. Indeed increasingly 
audio software is incorporating iterative solvers for this kind of 
thing, although we don't yet see computer music languages with full 
solving capabilities like QUCS or SPICE.



> Plenty of analogous structures in general computer science
> have similar rationales, like pipelines, SIMD, with the
> question being at what level of granularity can you lump a
> bunch of stuff together and process it all without sacrificing
> flexibility? Even apparently atomic instructions are, from the
> microprocessors point of view, collections of more atomic
> register operations that we never consider unless programming
> in machine code.

Right. But unless you're programming in assembley language these 
constraints (and benefits) don't usually impact the outcome. The 
compiler provides a generalised model of computation and optimises to 
these low level structures.

The problem in something like Music-N-with-control-rate derived 
languages is that the optimisation surfaces as a strict constraint in 
the structure of the high level language.

Faust is one example that gets away from this. Although I'm pretty sure 
it is not usefully turing complete.

MP4-SAOL is the best thing I've seen so far that allows control-rate 
semantics/optimisations but doesn't force them (you can write a single 
sample delay and the compiler will recognise it as such).


>> Anything else is just plugging unit generators together, which is
>> limiting in many situations (one reason I abandoned these kind of
>> environments and started writing my algorithms in C++).
>
> As linguists and writers note (Wittgenstein, Orwell, Ayer, Chomsky etc)
> language defines the modes of thought and facilitates or limits what
> we can do more or less easily. I guess plenty of studies have been
> done of the "expressibility" of computer languages, since they are
> strictly formal and amenable to analysis. Though we tend to invoke
> "Turing completeness" and assume all roads lead to Rome, clearly some
> languages are much better for certain things than others.

I don't think we have to resort to the Saphir-Whorph hypothesis here. 
(there was a great thread on that on the POTAC list last year btw.)

I think you're right about turing completeness though: in my view, you 
need something that is expressively turing complete that can operate on 
individual samples within that language framework. C/C++ and MP4-SAOL 
give you this. CSound doesn't, at least not easily, perhaps if ksamps=1 
you can get close, neither do any of the split synthesis graph/control 
language systems (SC3, LuaAV, pd, maxmsp).



> Grist for the mill in computing philosophy, but as musicians or
> sound designers it takes on a freshness. For example, the ease with
> which polyphony can be conceived in Supercollider and Chuck is
> amazing compared to Pure Data/Max, which makes it an awkward hack
> at the best of times. Csound is somewhere between. And of course,
> though Csound is clearly conceived as a _composers_ language where
> large scale structures are easy to build, abstraction is very obtuse.

Well I would question whether CSound is a composers language. To me it's 
an audio rendering language. Whenever I used CSound in my composition 
workflow I would write Python scripts or C programs to generate scores, 
so the composition didn't happen in CSound per-se.


> I remember Gunter Geiger's thesis being a good comparative
> treatment of different computer music languages, but that was
> mainly from a computational rather than expressibility angle.
> Maybe there's a good doctoral project for someone lurking in this
> question.

Ah didn't realise he ever finished, I should look it up.


>> Programming in C++ makes the signal efficiently accessible.
>
> Getting down to the metal with C/++ is more than just a departure from
> the VM plus UGEN  model, it allows, as you say, complete reconfiguration
> of the signal processing structure on a sample by sample basis, and
> departures from strictly causal models using look ahead computation
> etcetera. But at the same time it lays the signal bare, it
> seems to bury the larger process (unless you are an extremely methodical
> hacker and already working with quite robust and well used libraries).

Nothing stopping you developing your own frameowork. Based on personal 
experience I'd say it takes around 10 years to learn enough to get 
started with that.


> Is there is a fundamental trade off here that we just cannot get around?

I don't think so.

I don't see any fundamental reason why a synthesis language can't 
incorporate efficient block-level optimisations and allow sample level 
access in an easy to use turing complete environment. It's possible 
extempore does this, although I havn't looked into it deeply enough to 
comment. Michael's experiments with LuaJIT point in this direction too. 
And MP4-SAOL does it, although it has some other limitations (it's 
turing complete, but maybe not a very user friendly programming language).


Cheers,

Ross.










From rossb-lists at audiomulch.com  Sun Feb 26 00:48:48 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sun, 26 Feb 2012 16:48:48 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
Message-ID: <4F49C7C0.9020702@audiomulch.com>

Hi Michael,

I agree with you on the below within the "dominant paradigm", but there 
are a few problematic assumptions that are central to this dicussion. 
What follows is a somewhat controversial rant, apologies in advance...


On 25/02/2012 6:21 AM, Michael Gogins wrote:
> The two "languages" hidden under the single name "unit generators" are:
>
> (1) An efficient way to implement a runtime compiler for block-based
> audio DSP chains (these are what are in software synthesizers)...
> which usually are based on

As if block-based DSP chains are the only way to make sound with a computer.


> (2) A metaphor for signal processing operators as being linear time
> invariant operations inside "little black boxes" (these are what are
> inside analog synthesizers such as the original modular Moog or the
> Buchla).

The whole LTI thing is incredibly problematic. We've known for a long 
time that time invarience was just a convenient lie. Things like BIBO 
stability have been relevant to audio-rate modulation for at least 10 
years. Then there is the issue with linearity -- almost nothing 
"musical" is linear. As I think I said in my previous post, non-linear 
solvers are now becoming common in analog modelling.


> Both (1) and (2) assume linear time invariance which guarantees that
> you can wire up blocks any old way you like and still understand what
> the result will be, because it will all be linear addition and
> multiplication. But, in practice, when you open up a block from level
> (1) you don't usually find smaller more primitive blocks from level
> (2), with the possible partial exception of Pure Data or Reaktor. What
> you usually find is gnarly, hard to read procedural C code with loops,
> arithmetic, and some functions operating in a linear time invariant
> way on arrays of samples.

I don't really agree with you on this "gnarly, hard to read procedural C 
code" business, except in the case of CSound which is truly gnarly. I 
always found Cmix ugens to be very clear for example. SuperCollider 
ugens are pretty good too.

In any case, part of the point is, if you want to control the individual 
samples, and you know C++ then it's not that big a deal.


> What stands in the way of adopting plain old C++ for software synthesizers is:
>
> (a) The metaphor behind (2) is very useful for helping the
> non-technical musician get a handle on what is going on, especially if
> they have spent hours fooling around with a Buchla or something like
> that.

The assumption here is that the target audience is the "non technical 
musician". I think this is completely spurious. Talking about 
limitations or capabilities of computer programming languages is kind of 
pointless if you allow for the novice user who doesn't even know what a 
turing complete language can do.

In my view, anyone who cares about being a composer of *computer music* 
(in the context of this dicussion) needs at least the following (or 
equivalent) undergraduate knowledge:

1) music composition degree
2) computer science and/or software engineering degree
3) electrical engineering degree

Maybe even this is required:
4) Tonmeister/ sound engineering degree

I only have (1) and maybe a I could pass some of (2) based on industry 
experience, and I'm starting to study (3).. so I don't yet consider 
myself qualified. But I know enough about composing and writing software 
to know that if you want algorithms to be part of your compositional 
palette (and why else use a computer?) then LTI signal flow is not enough.

Of course there are composers who use computers in different ways, say 
more along the lines of a traditional musical instruments, or as a kind 
of musical word processor, in this case the pre-requisites are of course 
different.


> (c) It is easy to write and, more importantly, to read C++ signal
> processing code that processes one sample at a time, but only code
> that processes blocks of at least 20 to 200 samples at a time is
> really efficient enough to use; unfortunately this kind of code is
> significantly harder to write, and, more importantly, to understand -
> the metaphor of (2), and other metaphors, inevitably becomes obscured.

I think this can be mostly resolved with a good vectorising compiler 
(which may or may not exist).

That said, I think the runtime environment is also important. A 
livecoding runtime like extempore is preferable to the traditional C++ 
toolchain.


> That said, I still believe that properly written C++ unit generators
> could be easy to implement, easy to write with, easy to understand,
> and efficient. But this would be a great deal of work and the very
> first steps have to be just right or the rest all goes astray. I think
> it would be important to use blocks that would "look like" individual
> samples, it would be important to use smart pointers or garbage
> collection so the composer never has to worry about memory management,
> and the overall naming conventions would have to be at once concise,
> elegant, easy to read, and remind one of those old Music N blocks...
> recent changes in the C++ standard, including r-value references, move
> semantics, closures and lambdas, and language-based concurrency would
> make this significantly easier to do. If someone wants to spend years
> rewriting something that already works quite well, like Csound.

Depends if you think CSound works quite well. I think it is deeply 
flawed. I propose a simple test:

If you can't synchronously execute a procedural algorithm at the exact 
sample location of every zero crossing in an arbitrary input signal then 
there is a problem with your synthesis language.

It's not the only thing that i'd find difficult in CSound but is one. I 
also miss proper control flow, typed variables, and data structures.

Cheers,

Ross

>
> Regards,
> Mike
>
> On Fri, Feb 24, 2012 at 1:21 PM, Charles Turner<vze26m98 at optonline.net>  wrote:
>> On Feb 24, 2012, at 1:05 PM, Andy Farnell wrote:
>>
>>> Some really interesting thoughts here Ross. At what level of
>>> granularity does the trade-off of control, flexibility and
>>> efficiency reach its sweet spot?
>>
>> ?I understand that the dialectic of composition better contents itself with neutral objects, not easily identifiable ones, like pure tones or simple tone aggregates, having no inner profile of dynamics, duration or timbre. As soon as one shapes elaborated figures, assembles them into ?formed? complexes, and uses them as first-order objects for composition, one is not to forget [...] that they have lost all neutrality and acquired a personality, an individuality which makes them quite unfit for a generalized dialectics of sonic relations.?
>>
>> Pierre Boulez: p.45, _Penser la musique aujourd?hui_, (1994)
>>
>> --
>> 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 rossb-lists at audiomulch.com  Sun Feb 26 00:50:52 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sun, 26 Feb 2012 16:50:52 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3Wc1YFje4EBms78VJK7+Gq23o_vutRzpYQmyUVpdsLUZA@mail.gmail.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<CAK1FW3Ub6qP9XH-6tsoBzx3_0w71XkMLR0TwGKC=+iuNcQQJKA@mail.gmail.com>
	<4F43A92D.2070407@audioimagination.com>
	<CAK1FW3XqXTF9wz1JxqhYPc=BOsQH-xNNJZzBx=N-bYmgmHWeEA@mail.gmail.com>
	<CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<CAFswGP2TDHAoU-0EP=_Hrq89eR6a3jT_kinzOVYk4ajRxrixVQ@mail.gmail.com>
	<CAK1FW3XC02TqX4z7bT_=LVvCutZ-Z380xV3YesfPR=rpdvNoOw@mail.gmail.com>
	<4F4856BC.3090609@audiomulch.com>
	<CAK1FW3Wc1YFje4EBms78VJK7+Gq23o_vutRzpYQmyUVpdsLUZA@mail.gmail!
	.com>
Message-ID: <4F49C83C.6090008@audiomulch.com>

On 25/02/2012 2:38 PM, Adam Puckett wrote:
> What is WaveRT? I don't see it in the tarball.

WaveRT is a recent WDM-KS driver sub-model that was introduced in 
Windows Vista. It is the version of WDM-KS that people seem to get 
excited about as offering the lowest latency and efficiency. I can't 
remember the details but at its core I think it's similar to the ASIO 
driver model.

In any case, in PortAudio it's part of the wdmks host API.

Ross.

From emanuel.landeholm at gmail.com  Sun Feb 26 01:17:39 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Sun, 26 Feb 2012 07:17:39 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <4F498A44.3040809@audioimagination.com>
References: <CAK1FW3UbFWXPSNLVqH6=JsMoX_VAShBjKeU1-XOuYLLxYm3_Eg@mail.gmail.com>
	<4F426681.2090802@music.columbia.edu>
	<4F498A44.3040809@audioimagination.com>
Message-ID: <CAML4ZX6N5B96tVJXwk2zba81=cRpfhVbPHi6oRoWaM=7iNCDhg@mail.gmail.com>

Yeah, no shit just hit the fan... When you least expect it...

On Sun, Feb 26, 2012 at 2:26 AM, robert bristow-johnson
<rbj at audioimagination.com> wrote:
> On 2/20/12 10:28 AM, douglas repetto wrote:
>>
>>
>> Hi Adam,
>>
>> Welcome to the list. It's slow right now, but no doubt it'll flare up
>> again soon!
>
>
> no shit

From rossb-lists at audiomulch.com  Sun Feb 26 01:25:40 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sun, 26 Feb 2012 17:25:40 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <20120225191327.M93094@ccrma.Stanford.EDU>
References: <mailman.1229.1330195746.148.music-dsp@music.columbia.edu>
	<20120225191327.M93094@ccrma.Stanford.EDU>
Message-ID: <4F49D064.3000103@audiomulch.com>

On 26/02/2012 6:23 AM, Bill Schottstaedt wrote:
> In linguistics, it's known as
> the Great Eskimo Vocabulary Hoax.

It's also known as the Sapir-Whorph Hypothesis. There are strong and 
weak versions of the hypothesis. The whole thing isn't necessarily 
completely a hoax.

http://en.wikipedia.org/wiki/Linguistic_relativity

(see Present status section).


Here's a short excerpt from a discussion on the POTAC list last year. I 
really liked Dan Stowell's introduction of the idea of long-term bias 
effects [1]:

Ross Bencina wrote:
 >> In any case I am not reverting to strong-SW here.. just suggesting
 >> that the notation system biases what we think of as music. It
 >> doesn't mean we can't think of other things as music, or even work
 >> out ways of notating them with CMN or programming languages.

In reply, Dan S wrote:
 > Nicely put. I agree with all this. You don't need strong-SW, since
 > mild biasing factors can have strong effects over an extended period
 > of time (that's one of the mainstays of evolution by natural
 > selection, of course, but in other types of system too). I've always
 > thought that western music notation colours a lot of people's musical
 > expression in ways I don't like. Perhaps because I'm into timbral
 > gestures; or perhaps I'd think that anyway, whatever was the dominant
 > representation.


> I wrote the same basic kinds
> of music whether by hand ("Daily Life"), using SCORE ("Sandcastle"),
> using Pla + Samson box (many tunes), etc.

I'm not sure whether you want to unpack that, but a couple of obvious 
issues are that (1) I would think it's difficult for a composer to judge 
the effects of the tools they use on their compositional output, (2) you 
wrote Pla so it is really part of the composition, (3) just because you 
wrote the same "basic kind of music" independent of tool used I'm not 
sure that says much about the broad impact of tool structure on practice.

On the other hand, I'd agree that most of what actually consitutes music 
is not directly captured by the tools. By which I mean, what musical 
expression really is is mostly outside the domain of the directly 
encoded in programs, languages, algorithms, much in the same way as most 
human communication is non-verbal (and hence not encoded in words).


Ross.

[1] http://lists.lurk.org/pipermail/potac/2011-July/000107.html

From emanuel.landeholm at gmail.com  Sun Feb 26 01:44:07 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Sun, 26 Feb 2012 07:44:07 +0100
Subject: [music-dsp] Boulez
In-Reply-To: <201202260255.56017.david@olofson.net>
References: <4F43C0FC.1070802@blueyonder.co.uk>
	<201202260145.08912.david@olofson.net>
	<CAML4ZX40F-qrQOBBckfN-Ekm-VVFZERv2uxMqYjLq01pcOR8eQ@mail.gmail.com>
	<201202260255.56017.david@olofson.net>
Message-ID: <CAML4ZX6pnxcawK7Ey8HP1MKysH_0u1od9vkFJzx9byHSEMb1Cw@mail.gmail.com>

> It certainly helps when you can do interesting stuff in suboptimal ways, and
> still end up using only a few percent of one of your many CPU cores. :-)

Actually, this is my routine for determining whether or not I'm living
in the future: look up "suboptimal" in the dictionary. If it isn't
there, I'm living in the future. Another check is: does my personal
computing device have orders of magnitude more RAM than the major
image processing research main frame at Link?ping Tech had back when I
studied there. (check!)

From rrsounds at aol.com  Sun Feb 26 04:24:50 2012
From: rrsounds at aol.com (David Reaves)
Date: Sun, 26 Feb 2012 10:24:50 +0100
Subject: [music-dsp] Boulez
In-Reply-To: <mailman.1252.1330220586.148.music-dsp@music.columbia.edu>
References: <mailman.1252.1330220586.148.music-dsp@music.columbia.edu>
Message-ID: <3DC59587-2A4A-4BBB-A37E-626ACACAFB9A@aol.com>

Douglas,
I think my wife Ariane, who plays First Violin in the Neue Philharmonie Westfalen, can relate to your description of the activities of an orchestra musician.
A few years back she was reprimanded when an audience member told management they had seen (from up in a balcony) a female violinist playing Sudoku during a slow section of a musical. Ari had hoped no one would notice her, tucked away down in the pit, LOL. Better to just put a book on the music stand. ;-)

Kind Regards,
David Reaves


On Sat, 25 Feb 2012 20:43:04, douglas repetto <douglas at music.columbia.edu> wrote:
<snip>
> 
> But that's not really how live musicians tend to think of it. It's not 
> like a violinist keeps her bow moving at all times and only touches it 
> to the strings when there's a note to be played. But that's kinda what 
> sending zeros to a buffer when there's no sound is like.
> 
> On the other hand, if you work directly in hardware (say using an analog 
> synth, hooking up logical oscillators, or programming a microcontroller) 
> you can take a very different approach. You twiddle some output pins 
> when you want sound and when you don't want sound you can just go off 
> and do other things. In many ways I think that's a lot more like what 
> many musicians do -- when you're not playing (either because you've got 
> a bunch of rests, or maybe you're playing improvised music and you're 
> just sitting out for awhile, or whatever) you don't really sit there 
> counting off the beats. You stop playing. You might think about other 
> things. After awhile hopefully you'll notice that the conductor is about 
> to cue you in, or you get an idea and decide to join the improvisation, 
> etc. I've seen people reading books in Broadway orchestra pits...
<snip>


From akbutler at tiscali.co.uk  Sun Feb 26 04:44:52 2012
From: akbutler at tiscali.co.uk (andy butler)
Date: Sun, 26 Feb 2012 09:44:52 +0000
Subject: [music-dsp] guitar physical model
In-Reply-To: <mailman.1261.1330232863.148.music-dsp@music.columbia.edu>
References: <mailman.1261.1330232863.148.music-dsp@music.columbia.edu>
Message-ID: <4F49FF14.5020900@tiscali.co.uk>

http://music.columbia.edu/~brad/music/commentary/Almost_Real.html

'Gentle Giant'?  -70's band

influence,
or coincidence?

andy

From emanuel.landeholm at gmail.com  Sun Feb 26 04:52:12 2012
From: emanuel.landeholm at gmail.com (Emanuel Landeholm)
Date: Sun, 26 Feb 2012 10:52:12 +0100
Subject: [music-dsp] guitar physical model
In-Reply-To: <D000F604-2066-474A-9385-C6494E8A9985@columbia.edu>
References: <CAK1FW3UTfQk8sDL9n5pM0jc9zQvB7y914P_rG6oaALnkHL_Z3A@mail.gmail.com>
	<D000F604-2066-474A-9385-C6494E8A9985@columbia.edu>
Message-ID: <CAML4ZX7aR8Mri6PpD=1FwJ7e2EJSkWzS4KcDxc5wqQ51Lejj4w@mail.gmail.com>

> ? ? ? ?http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3

This. I just listened to it and it put me in a good mood!

From richarddobson at blueyonder.co.uk  Sun Feb 26 05:13:33 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Sun, 26 Feb 2012 10:13:33 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F49C7C0.9020702@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
Message-ID: <4F4A05CD.9070505@blueyonder.co.uk>

On 26/02/2012 05:48, Ross Bencina wrote:
...
>> make this significantly easier to do. If someone wants to spend years
>> rewriting something that already works quite well, like Csound.
>
> Depends if you think CSound works quite well. I think it is deeply
> flawed. I propose a simple test:
>
> If you can't synchronously execute a procedural algorithm at the exact
> sample location of every zero crossing in an arbitrary input signal then
> there is a problem with your synthesis language.
>
> It's not the only thing that i'd find difficult in CSound but is one. I
> also miss proper control flow, typed variables, and data structures.
>


Well, no system or language is "perfect", but anyway: Csound has had the 
possibility to do per-sample processing for years, using ksmps = 1, and 
in addition it now supports user-defined opcodes which can run at 
ksmps=1 internally, so I see no reason at all why you could not do your 
zero-crossing thing if you want to. Whether in practice you really want 
to do something every zero-crossing when you could get those every three 
or four samples (or less, in principle) when the audio stream consists 
of dither, is another question. How would you do it in AM? I am sure you 
know that there is usually no such thing as "the exact sample location 
of every zero crossing" as most of the time the actual crossing point is 
between samples, so the best you can do is watch for a sign change. If 
that is the only thing Csound can't do, it is a limitation I can easily 
live with!

We have rather a lot of control flow opcodes these days (remembering 
that all control flow idioms after the first are in principle syntactic 
sugar), including "else" and "until".

Bearing in mind that conceptually, Csound is and always has been closer 
to assembly code than to a "normal" HLL, and that attempts to turn it 
into C or C++ (or Supercollider) are doomed to failure as they 
completely miss the point (as are attempts to criticise it for not being 
a HLL), the lack of data structures is somewhat moot; and with the 
development of the new parser such things are actively and regularly 
discussed. Csound will always be somewhat apart from a conventional 
procedural language because its working semantic unit is not a single 
operation but the audio-rate vector running at krate. It is rather more 
flexible than Max/MSP, say, because you can if you want to run a 
single-sample vector, whereas MSP has always been fixed to a 64-sample 
block size. It is not claiming to be an HLL, has never so claimed, and 
is not a HLL, much as some people would wish it to be, so criticsing it 
for not being something it is not trying to be is, well, missing the point.

The reason for systems such as Max/MSP, AM, Csound, PD, Reaktor et al, 
is simply that, rather than people having to learn the perils of a 
high-level language, they can do what they really want to do, which is 
to patch standard objects such as oscillators, filters and envelope 
generators together, have access to a lot of exotic and/or powerful 
unusual objects, and perhaps have enough lower-level objects such as 
table lookup and phasors so they can occasionally roll their own. One 
way or another, every user is limited by what those systems do not 
enable; and I would argue that of all of them, Csound offers the fewest 
limitations. But you do inevitably have to learn more to take advantage 
of it.

The developer community for Csound is very active, and is starting to 
consider what to have in Csound 6; all constructive contributions are of 
course welcome!



Richard Dobson

From rossb-lists at audiomulch.com  Sun Feb 26 06:33:11 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Sun, 26 Feb 2012 22:33:11 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A05CD.9070505@blueyonder.co.uk>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
Message-ID: <4F4A1877.9050906@audiomulch.com>

On 26/02/2012 9:13 PM, Richard Dobson wrote:
> On 26/02/2012 05:48, Ross Bencina wrote:
> ...
>>> make this significantly easier to do. If someone wants to spend years
>>> rewriting something that already works quite well, like Csound.
>>
>> Depends if you think CSound works quite well. I think it is deeply
>> flawed. I propose a simple test:
>>
>> If you can't synchronously execute a procedural algorithm at the exact
>> sample location of every zero crossing in an arbitrary input signal then
>> there is a problem with your synthesis language.
>>
>> It's not the only thing that i'd find difficult in CSound but is one. I
>> also miss proper control flow, typed variables, and data structures.
>
> Well, no system or language is "perfect", but anyway: Csound has had the
> possibility to do per-sample processing for years, using ksmps = 1, and
> in addition it now supports user-defined opcodes which can run at
> ksmps=1 internally, so I see no reason at all why you could not do your
> zero-crossing thing if you want to.

Perhaps I'm not being clear. My point is about being able to execute 
arbitrary code at an arbitrary time based on the value of some 
signal(s). The zero crossing thing was a simple example. You could also 
think of algorithms that are not strictly signal based such as 
multi-rate counters etc etc. Without a full-blown programming language 
the compromises become unacceptable once you know how to program in a 
"normal" language, whether that be C, C++, Java, Haskel, Scheme or Lisp.

Of course you can counter with "use the best tool for the job" -- which 
I agree with.


> Whether in practice you really want
> to do something every zero-crossing when you could get those every three
> or four samples (or less, in principle) when the audio stream consists
> of dither, is another question.

Sure, it was a simple example of something that's hard to do when you're 
dealing with a block-based system.


> How would you do it in AM?

I wouldn't. I'd write some C++ code. As I said earlier I'm leaving 
AudioMulch out of it because I don't think it has relevance here. I will 
happily admit that AM is much less capable than CSound of being a 
general purpose programming language.


> I am sure you
> know that there is usually no such thing as "the exact sample location
> of every zero crossing" as most of the time the actual crossing point is
> between samples, so the best you can do is watch for a sign change. If
> that is the only thing Csound can't do, it is a limitation I can easily
> live with!

Are you being a pedant on purpose or did you miss my point? It was just 
an example. Anything that needs to efficiently to execute signal aware 
logic triggered at arbitrary locations in the sample stream. 
Implementing transient masked WSOLA might be another example.


> We have rather a lot of control flow opcodes these days (remembering
> that all control flow idioms after the first are in principle syntactic
> sugar), including "else" and "until".

Can you provide a concrete example/link please? My knowledge is clearly 
out of date here. Last time I knew there was just the convoluted re-init 
mechanism to do control flow.

Are CSound control flow opcodes sufficient for me to implement a 
quicksort? That's the kind of control flow I'm thinking of -- something 
that can be used with data structures to implement algorithms.


> Bearing in mind that conceptually, Csound is and always has been closer
> to assembly code than to a "normal" HLL,

I think it's much closer to SPICE or synchronous dataflow languages than 
it is to assembley.


> and that attempts to turn it
> into C or C++ (or Supercollider) are doomed to failure

Sure. To be clear: I'm not trying to change CSound. I'm not suggesting 
it should be fixed to address the issues I'm raising. I'm happy enough 
using C++. I would love to use something runtime interpreted, but so far 
nothing has emerged that is both efficient and usable (extempore may be 
a possible exception but I havn't had a chance to explore it yet).


> as they
> completely miss the point (as are attempts to criticise it for not being
> a HLL), the lack of data structures is somewhat moot;

It might be moot for CSound but it is not moot for actually getting 
anything useful done. Which is my point. The whole paradigm is limited. 
If it works for you, great. But you seem to be arguing that CSound is 
great for all the reasons I'm arguing that it's lacking (lack of ability 
to implement arbitrary algorithms and data structures, at the control 
and signal level, basically).


> and with the development of the new parser such things are actively
> and regularly discussed.
> Csound will always be somewhat apart from a conventional
> procedural language because its working semantic unit is not a single
> operation but the audio-rate vector running at krate.

Which is exactly my point.


> It is rather more
> flexible than Max/MSP, say, because you can if you want to run a
> single-sample vector, whereas MSP has always been fixed to a 64-sample
> block size. It is not claiming to be an HLL, has never so claimed, and
> is not a HLL, much as some people would wish it to be, so criticsing it
> for not being something it is not trying to be is, well, missing the point.

The point is that for many musical tasks, the limitations are unacceptable.


> The reason for systems such as Max/MSP, AM, Csound, PD, Reaktor et al,
> is simply that, rather than people having to learn the perils of a
> high-level language,

> they can do what they really want to do, which is
> to patch standard objects such as oscillators, filters and envelope
> generators together, have access to a lot of exotic and/or powerful
> unusual objects, and perhaps have enough lower-level objects such as
> table lookup and phasors so they can occasionally roll their own.

I actually don't buy this "the reason for these systems existing" 
business. I think you're oversimplifying things.

For a start, all of the systems you've mentioned have different reasons 
for coming into existence.

You've defined their reasons for existing in terms of what they do -- 
which is not their reason for exisiting at all. That might be *how* 
people use them, but for the most part that wasn't why they were created.

Some of them were designed as full blown visual programming systems, 
some were developed as platforms for sound synthesis research (in the 
broad and general sense of what that means, I'd put CSound tehre). And 
yes, some were conceived as simply platforms for patching together 
pre-built stuff (e.g. AudioMulch). But I think ultimately the vision of 
many of these environments (especially the lower level ones) is to 
provide universal platforms for computer music/dsp computation -- not 
just platforms for people to do what they "really want to do" -- which, 
at least the way you've described it, is pretty mundane and 
uninteresting stuff imho.


> One
> way or another, every user is limited by what those systems do not
> enable; and I would argue that of all of them, Csound offers the fewest
> limitations. But you do inevitably have to learn more to take advantage
> of it.

I agree with you here, except that in spite of it being the least 
limited, it is still way too limited to be useful for many things (As 
you've admitted yourself by acknowledging that people who want CSound to 
be Supercollider are missing the point).


Ross

From garton at columbia.edu  Sun Feb 26 09:11:10 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 09:11:10 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A05CD.9070505@blueyonder.co.uk>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
Message-ID: <D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>

On Feb 26, 2012, at 5:13 AM, Richard Dobson wrote:

> It is rather more flexible than Max/MSP, say, because you can if you want to run a single-sample vector, whereas MSP has always been fixed to a 64-sample block size.

I don't think that's actually true...

We're fooling around with the new Max/MSP gen~ stuff in class, it seems an interesting alternative model for low-level DSP coding.  Once they figure out how to do proper conditionals it will be really powerful.

brad
http://music.columbia.edu/~brad


From garton at columbia.edu  Sun Feb 26 09:22:49 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 09:22:49 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F49C7C0.9020702@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
Message-ID: <658D8A59-B3D1-4191-B16A-CEB46572F9DA@columbia.edu>

On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote:

> In my view, anyone who cares about being a composer of *computer music* (in the context of this dicussion) needs at least the following (or equivalent) undergraduate knowledge:
> 
> 1) music composition degree
> 2) computer science and/or software engineering degree
> 3) electrical engineering degree
> 
> Maybe even this is required:
> 4) Tonmeister/ sound engineering degree

I would like to agree with you, because I also value all these things (and am pretty much a dilettante in all four).  But I see an analog with the "is a DJ *really* a [computer music]  composer?" question that floats around (or in an earlier generation, "is a collage artist...").  Most DJ things I find just annoying, but lately I've heard a few that are quite interesting, and also operating independent of the categories 1-4 above that I know and love.  I guess it's the "in the context of this discussion" qualifier that makes the difference here.

brad
http://music.columbia.edu/~brad


From rossb-lists at audiomulch.com  Sun Feb 26 09:25:45 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Mon, 27 Feb 2012 01:25:45 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
Message-ID: <4F4A40E9.8050801@audiomulch.com>

On 27/02/2012 1:11 AM, Brad Garton wrote:
> We're fooling around with the new Max/MSP gen~ stuff in class, it
> seems an interesting alternative model for low-level DSP coding.
> Once they figure out how to do proper conditionals it will be really
> powerful.

Why anyone would want to use a visual patcher to write low level code is 
beyond me though. Managing complexity in Max is already a nightmare 
compared to using text-based development methods and tools. Not to 
mention how quickly you can type code compared to patching it.
They should have just added an object for live coding assembly language 
(only half kidding).

Ross.

From garton at columbia.edu  Sun Feb 26 09:27:24 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 09:27:24 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A05CD.9070505@blueyonder.co.uk>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
Message-ID: <2D060F12-C374-42A9-9B61-4926493626C4@columbia.edu>

On Feb 26, 2012, at 5:13 AM, Richard Dobson wrote:

> One way or another, every user is limited by what those systems do not enable;

Yes!

> and I would argue that of all of them, Csound offers the fewest limitations. 

Nooooooooo!!!!!!!!!!  :-)

(and the "nooooo" refers doubly to 'let's not have that argument")

brad
http://music.columbia.edu/~brad


From garton at columbia.edu  Sun Feb 26 09:31:48 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 09:31:48 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A40E9.8050801@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
	<4F4A40E9.8050801@audiomulch.com>
Message-ID: <B3682239-3457-4209-9490-8E74F1D7204A@columbia.edu>

On Feb 26, 2012, at 9:25 AM, Ross Bencina wrote:

> Why anyone would want to use a visual patcher to write low level code is beyond me though. Managing complexity in Max is already a nightmare compared to using text-based development methods and tools. Not to mention how quickly you can type code compared to patching it.
> They should have just added an object for live coding assembly language (only half kidding).

I completely agree.  However, I find myself exploring aspects of an implemented DSP algorithm in ways that I wouldn't using a text-based approach.  It's kind of like trying to write poetry in a second language, you occasionally find yourself constructing things you would not have otherwise.  All these various languages facilitate different kinds of 'tweakiness', and for me a lot of the fun is seeing where a particular approach might lead...

brad (who really is a text-based kinda guy)
http://music.columbia.edu/~brad


From garton at columbia.edu  Sun Feb 26 09:35:12 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 09:35:12 -0500
Subject: [music-dsp] guitar physical model
In-Reply-To: <4F49FF14.5020900@tiscali.co.uk>
References: <mailman.1261.1330232863.148.music-dsp@music.columbia.edu>
	<4F49FF14.5020900@tiscali.co.uk>
Message-ID: <7649B9EB-BFBF-447A-BAE0-0F525BB7AC72@columbia.edu>

On Feb 26, 2012, at 4:44 AM, andy butler wrote:

> http://music.columbia.edu/~brad/music/commentary/Almost_Real.html
> 
> 'Gentle Giant'?  -70's band
> 
> influence,
> or coincidence?

Oh no!  Unmasked, I am!  :-)

(actually, a lot of the above piece came from listening to Irish folk guitarist Patrick Kilbride).

I was a major prog-rock fan back in the 70's.  Then I discovered Devo and slid down the slippery-slope to TG, Einsturzende Neubauten, PIL...

brad
http://music.columbia.edu/~brad


From padawan12 at obiwannabe.co.uk  Sun Feb 26 09:38:46 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sun, 26 Feb 2012 14:38:46 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
References: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
Message-ID: <20120226143846.GA25614@sapphire.lan>

On Sun, Feb 26, 2012 at 09:11:10AM -0500, Brad Garton wrote:
> On Feb 26, 2012, at 5:13 AM, Richard Dobson wrote:
> 
> > It is rather more flexible than Max/MSP, say, because you can if you want
> > to run a single-sample vector, whereas MSP has always been fixed to a 
> > 64-sample block size.
> 
> I don't think that's actually true...
> 
> We're fooling around with the new Max/MSP gen~ stuff in class, it seems an 
> interesting alternative model for low-level DSP coding.  Once they figure out 
> how to do proper conditionals it will be really powerful.
> 
> brad


For a long time, there has been the equivalent trick to that which Michael 
mentions for Csound, setting ksamps = 1, only in Pd/Max you set blocksize =1.
While these seem superficially similar, and both have the same outcome that
you can do control calculations on a per sample basis, they are conceptually
different, in the same sense that multi-rate and "pull" dataflow differ.

cheers,
Andy



From garton at columbia.edu  Sun Feb 26 09:47:45 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 09:47:45 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <20120226143846.GA25614@sapphire.lan>
References: <CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
	<20120226143846.GA25614@sapphire.lan>
Message-ID: <ACDB1A69-2A3E-4195-AFC4-3A51BDF13F36@columbia.edu>

On Feb 26, 2012, at 9:38 AM, Andy Farnell wrote:

> For a long time, there has been the equivalent trick to that which Michael 
> mentions for Csound, setting ksamps = 1, only in Pd/Max you set blocksize =1.
> While these seem superficially similar, and both have the same outcome that
> you can do control calculations on a per sample basis, they are conceptually
> different, in the same sense that multi-rate and "pull" dataflow differ.

Andy -- could you unpack this a little for me?  Are you referring to the independence
between the 'control rate' and the underlying blocksize that you get in Csound (and
others)?  if so, what are the some of the "real" effects that this might have?

I'm not being pejorative with these questions, I honestly don't understand what you mean.

brad
http://music.columbia.edu/~brad


From rossb-lists at audiomulch.com  Sun Feb 26 09:48:57 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Mon, 27 Feb 2012 01:48:57 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <658D8A59-B3D1-4191-B16A-CEB46572F9DA@columbia.edu>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<658D8A59-B3D1-4191-B16A-CEB46572F9DA@columbia.edu>
Message-ID: <4F4A4659.6000309@audiomulch.com>

On 27/02/2012 1:22 AM, Brad Garton wrote:
> I would like to agree with you, because I also value all these things
> (and am pretty much a dilettante in all four).  But I see an analog
> with the "is a DJ*really*  a [computer music]  composer?" question
> that floats around (or in an earlier generation, "is a collage
> artist...").

Other analogous questions include "Should the artist be a programmer?", 
"Must creative engagement with computers involve programming?"

Then there is the whole schtick of composer as Auteur directing the 
technical minions to do the programming for him/her. A variant might be 
Composer buying pre-made tools to use to make their music.

I liked Andy's reference to "second order culture" earlier. This is one 
way of looking at software reuse by composers. Another is the 
instrument-builder <-> instrument <-> composer-performer relation.


> Most DJ things I find just annoying, but lately I've
> heard a few that are quite interesting, and also operating
> independent of the categories 1-4 above that I know and love.

Of course you don't need all the aforementioned computer skills to use a 
computer to make *music*, and I wouldn't dare to ascribe relative value 
to the different areas of musical engagement with computers. Great music 
is being made in all sorts of different ways -- and a computer is 
sometimes part of that. But I think it's when the composer engages with 
the computer *as a computer* (whatever that means, but I think it 
involves programming, or algorithmic processes, or some uniquely digital 
manipulation methods, not as a virtual "real" thing) that it becomes 
computer music composition in the specialised sense meant here.


> I guess it's the "in the context of this discussion" qualifier that
> makes the difference here.

Yeah. There is such a thing as specialised "computer music" composition 
that takes in all those disciplines -- and in my view, the limits of the 
tools we are discussing are especially relevant within that context.

If you come at it from a "found object" perspective, the tools have 
certain affordances -- they're good at certain things. My impression is 
that Richard has suggested that "what they are good at" and "what they 
are intended for" is the same thing.. but I'm not convinced.

Ross.



From padawan12 at obiwannabe.co.uk  Sun Feb 26 09:50:58 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sun, 26 Feb 2012 14:50:58 +0000
Subject: [music-dsp] guitar physical model
In-Reply-To: <CAML4ZX7aR8Mri6PpD=1FwJ7e2EJSkWzS4KcDxc5wqQ51Lejj4w@mail.gmail.com>
References: <CAK1FW3UTfQk8sDL9n5pM0jc9zQvB7y914P_rG6oaALnkHL_Z3A@mail.gmail.com>
	<D000F604-2066-474A-9385-C6494E8A9985@columbia.edu>
	<CAML4ZX7aR8Mri6PpD=1FwJ7e2EJSkWzS4KcDxc5wqQ51Lejj4w@mail.gmail.com>
Message-ID: <20120226145058.GB25614@sapphire.lan>


Me too, Some great Steve Hillage like moments in that.

On Sun, Feb 26, 2012 at 10:52:12AM +0100, Emanuel Landeholm wrote:
> > ? ? ? ?http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3
> 
> This. I just listened to it and it put me in a good mood!
> --
> 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 garton at columbia.edu  Sun Feb 26 09:57:55 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 09:57:55 -0500
Subject: [music-dsp] guitar physical model
In-Reply-To: <20120226145058.GB25614@sapphire.lan>
References: <CAK1FW3UTfQk8sDL9n5pM0jc9zQvB7y914P_rG6oaALnkHL_Z3A@mail.gmail.com>
	<D000F604-2066-474A-9385-C6494E8A9985@columbia.edu>
	<CAML4ZX7aR8Mri6PpD=1FwJ7e2EJSkWzS4KcDxc5wqQ51Lejj4w@mail.gmail.com>
	<20120226145058.GB25614@sapphire.lan>
Message-ID: <2EF04F95-88C3-429D-96E2-CB184D36B91E@columbia.edu>

Thanks!

I always wanted to play the guitar, but I wasn't any good.  LISP to the rescue!

brad
http://music.columbia.edu/~brad


On Feb 26, 2012, at 9:50 AM, Andy Farnell wrote:

> 
> Me too, Some great Steve Hillage like moments in that.
> 
> On Sun, Feb 26, 2012 at 10:52:12AM +0100, Emanuel Landeholm wrote:
>>>        http://music.columbia.edu/~brad/music/mp3/Rough_Raga_Riffs.mp3
>> 
>> This. I just listened to it and it put me in a good mood!
>> --
>> 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 garton at columbia.edu  Sun Feb 26 09:59:07 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 09:59:07 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A4659.6000309@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<658D8A59-B3D1-4191-B16A-CEB46572F9DA@columbia.edu>
	<4F4A4659.6000309@audiomulch.com>
Message-ID: <403D43CB-FA86-44A2-B2CE-3DA72B7A0380@columbia.edu>

On Feb 26, 2012, at 9:48 AM, Ross Bencina wrote:

> Then there is the whole schtick of composer as Auteur directing the technical minions to do the programming for him/her.

Oh my *favorite* paradigm!  Ya just gotta love the cultural model that puts forward, too.

brad
http://music.columbia.edu/~brad


From padawan12 at obiwannabe.co.uk  Sun Feb 26 10:20:16 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sun, 26 Feb 2012 15:20:16 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <ACDB1A69-2A3E-4195-AFC4-3A51BDF13F36@columbia.edu>
References: <698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
	<20120226143846.GA25614@sapphire.lan>
	<ACDB1A69-2A3E-4195-AFC4-3A51BDF13F36@columbia.edu>
Message-ID: <20120226152016.GC25614@sapphire.lan>


Of course Brad, and maybe my trying to formalise it myself some people will
jump in with helpful corrections, because it _is_ a bit tricky to understand
and took me a long time and maybe still have some misconceptions. Anyhoo I 
think it's very helpful to understand the differences in these designs
and by implication other ways of considering music signal programming.


IIRC, most Music-N line of systems are multi-rate. That means we have a 
fast computation rate, on which audio signals are calculated, and a slower
rate (obviously some integer factor of the audio rate), usually called
the control rate, at which things like slow moving envelopes, MIDI inputs
and suchlike are calculated.

Of course the slow rates can be interpolated, and the fast rates decimated
to be compatible, to smooth envelopes, or extract signal features into
the control rate, but the facts remain that:

Two rates always exist

On each step some audio signal samples (As) are calculated

Every ksamps step (the ratio of audio to control steps) some control
signals Ks are calculated

They are effectively interleved not threaded, so all Ks must complete
before the next burst of As can, and vice versa...

            ----

Contrast this with Dataflow (* general dataflow has a wider more formal 
interpretation so I am really talking about Miller Puckette's music DSP 
environments here)

In dataflow there is no control rate or signal rate. It is better to think of them
as "control domain" and "signal domain". They are based on a _pull_ (or demand)
and _push_ (or availability) driven idea. So the calls to pull audio blocks come 
synchronously from the soundcard (interrupt + callback model), and calls are passed 
further up the chain of audio type functions until they reach a terminal node
that is either an oscillator or constant source or somesuch. Meanwhile control
data is effectively "pushed" into the system and causes a chain of messages
to propagate (the exact evaluation is more complex, but this illustrates
the central idea). The essential facts of this dataflow might be

There is _always_ an audio signal but there are sometimes no control messages

Control messages are computed on a block boundary

The audio signal is hard real time, so failure of the control to complete
before the next interrupt will result in a drop out.

              ------


Okay, given these two approaches we can see that setting kr = ar 
alternatively expressed as (ksamps = 1) in the former system seems to
be the same as setting the blocksize to 1 in the latter.

BUT:

In Csound we will still get an interleved series

[As_0, Ks_0, As_1, Ks_1, As_2, Ks_2 ... As_n, Ks_n]

wheras in Miller's dataflow we have As, the audio stream running
constantly, with the possibility for Ks to intervene _anywhere_
within the stream so long as they can complete before the next
As is demanded

[As_0, As_1, As_2, As_3 ...As_20, As_21, Ks_0, As_22 ...As_100, Ks_1, Ks_2, As_101]

Obviously this requires one to think about difficult problems where
control and signals are closely coupled in subtly different ways for
each language.

best,
Andy




On Sun, Feb 26, 2012 at 09:47:45AM -0500, Brad Garton wrote:
> On Feb 26, 2012, at 9:38 AM, Andy Farnell wrote:
> 
> > For a long time, there has been the equivalent trick to that which Michael 
> > mentions for Csound, setting ksamps = 1, only in Pd/Max you set blocksize =1.
> > While these seem superficially similar, and both have the same outcome that
> > you can do control calculations on a per sample basis, they are conceptually
> > different, in the same sense that multi-rate and "pull" dataflow differ.
> 
> Andy -- could you unpack this a little for me?  Are you referring to the independence
> between the 'control rate' and the underlying blocksize that you get in Csound (and
> others)?  if so, what are the some of the "real" effects that this might have?
> 
> I'm not being pejorative with these questions, I honestly don't understand what you mean.
> 
> brad
> http://music.columbia.edu/~brad
> 
> --
> 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 garton at columbia.edu  Sun Feb 26 10:29:46 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 10:29:46 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <20120226152016.GC25614@sapphire.lan>
References: <698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
	<20120226143846.GA25614@sapphire.lan>
	<ACDB1A69-2A3E-4195-AFC4-3A51BDF13F36@columbia.edu>
	<20120226152016.GC25614@sapphire.lan>
Message-ID: <7D1C48F8-DE8A-4A9F-B637-5A2DD22DDEB4@columbia.edu>

On Feb 26, 2012, at 10:20 AM, Andy Farnell wrote:

> wheras in Miller's dataflow we have As, the audio stream running
> constantly, with the possibility for Ks to intervene _anywhere_

aha -- this makes sense now.   It also uncovers a problem I've had
with dataflow languages, an "indeterminacy" that occasionally drives
me crazy when working with them.  I had always assumed it was
a misunderstanding on my part of how the execution-graph was
being constructed (it's especially tangled in pd), but this seems
more like what I was encountering.

brad
http://music.columbia.edu/~brad


From theover at tiscali.nl  Sun Feb 26 10:46:19 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Sun, 26 Feb 2012 16:46:19 +0100
Subject: [music-dsp] a little about myself
Message-ID: <4F4A53CB.2000607@tiscali.nl>

Ross Bencina wrote at
Sun Feb 26 06:33:11 EST 2012:
 > signal(s). The zero crossing thing was a simple example. You could also
 > think of algorithms that are not strictly signal based such as
 > multi-rate counters etc etc. Without a full-blown programming language
 > the compromises become unacceptable once you know how to program in a 
 > "normal" language, whether that be C, C++, Java, Haskel, Scheme or Lisp.
 >
 > Of course you can counter with "use the best tool for the job" -- which
 > I agree with.

Of course most all computer languages have serious limitations, too: 
none allow explicit parallel programming concepts, "native" associative 
behaviour, and even simple mathematical reasoning takes a heavy LISP 
program to begin with (Like Maxima), and a lot of "programming" skills 
are essentially a training in the feasibility of a certain amount of 
efficiency with a language, either to express an idea in the language, 
or to make the language when compiled/interpreted and run on a machine 
to work efficient enough on it to achive the programming purpose.

What I mean to emphasize is that I too am aware of why (engineering 
alike language or music kinds) students learn formal programming models, 
like what are procedures with formal parameters, what's a sequenctial 
program versus a inherently parallel traveling salesman network problem, 
etc, and that the whole of the well know set of decent computer 
programming languages to let's say bachelor or master of science level 
people, do not tell the story of learning to speak assembly in LISP, or 
using Unix shell scripts for guided missile control with great accuracy 
and reliability.

Some hardware is more like the physical reality musical isntruments are 
made of (a parallel plane of repeated computations like a guitar 
resonance board) than most computer language ever get, and perception of 
"countable" events is a normality in the human brain, isn't it?

I think that for many musical education purposes the general audience 
for isntance of the Open Source music software/hardware efforts is still 
more served by a good MSX computer with a nice working FM synthesis chip 
in it, than some badly sampled drum-blurps with a program to sequence 
those. Of course I prefer a new Fairlight with a SY99, but that's beside 
the point. I mean the whole of the software boys and gals ideas aren't 
going to make either the new Marshall or Les Paul ever. I doubt 
seriously if the collective software world without external guidance 
could sit together and finish a random electrical engineering exam from 
the first year if they'd have a week time, and their lives depended on 
it. Seriously.
Greetings
Theo V.


From theover at tiscali.nl  Sun Feb 26 10:52:52 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Sun, 26 Feb 2012 16:52:52 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <mailman.1286.1330267874.148.music-dsp@music.columbia.edu>
References: <mailman.1286.1330267874.148.music-dsp@music.columbia.edu>
Message-ID: <4F4A5554.4010105@tiscali.nl>

On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote:
 >..
 > 1) music composition degree
 > 2) computer science and/or software engineering degree
 > 3) electrical engineering degree
 >..

Hmm, software engineering would preferably be covered by EE, but of 
course there are differences in emphasis.

And I doubt it's better to have a conservatory degree than be called 
"Ludwig von"in some joint of history, though a good degree wouldn't stop 
the Commodores from making interesting music, of course. Let's not 
comfuse the desires of a "New Age" talking about "movements" with decent 
leadership, and proper academic or even universal definitions of subject 
boundaries, please ?

Theo

From richarddobson at blueyonder.co.uk  Sun Feb 26 11:01:52 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Sun, 26 Feb 2012 16:01:52 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A1877.9050906@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
Message-ID: <4F4A5770.5030103@blueyonder.co.uk>

On 26/02/2012 11:33, Ross Bencina wrote:
..
>
> Perhaps I'm not being clear. My point is about being able to execute
> arbitrary code at an arbitrary time based on the value of some
> signal(s). The zero crossing thing was a simple example.

In which case it is a trivial test. Way back when I first used Csound on 
the Atari ST, the documentation cited the single-sample mode for 
implementing audio feedback and recursion. Not as efficient as using 
dedicated opcodes, but far from impossible. Conditional tests at krate 
effectively become conditional tests per sample.

A language is defined not simply by what it enables, but by what it 
~supports~. Csound supports and is optimised for fast audio vector 
processing, but it can do scalar processing too if you really need it. 
And on modern machines it is not even all that slow. Some recently added 
processes such as the Sliding DFT are defined as single-sample processing.

You could also
> think of algorithms that are not strictly signal based such as
> multi-rate counters etc etc. Without a full-blown programming language
> the compromises become unacceptable once you know how to program in a
> "normal" language, whether that be C, C++, Java, Haskel, Scheme or Lisp.
>


All your points centre on the last - that Csound is not a "full-blown 
programming language". This is only stating the obvious, and is not a 
Csound "flaw". ~Of course~ it isn't, never was and has never claimed to 
be - it is a scripted interpreter specialised for audio processing. It 
is a "domain-specific" language, and as such is one among many - Matlab, 
SQL, HTML and so on.

In short, this is a completely straw-man argument, as you are comparing 
apples to oranges.  Indeed, the single biggest issue I have with some on 
the Csound list is precisely that they want to add more general-purpose 
procedural idioms to Csound, in a misguided attempt to turn into it an 
audio version of C++. Even the addition of opcodes to embed Python or 
Lua code within the orchestra was something I had great misgivings about 
(i.e. a whole opcode and even effectively a whole instrument can be 
written in Python or Lua), as to me it is the wrong way around - Csound 
is a low-level language most suited to being embedded within 
higher-level ones. Still, they work (as far as I know), and I suppose if 
I try them one day I might feel differently! So we can probably have the 
slightly surreal spectacle of a Python script running Csound which in 
turn runs a Python-defined opcode.

..
>
> Are you being a pedant on purpose or did you miss my point? It was just
> an example. Anything that needs to efficiently to execute signal aware
> logic triggered at arbitrary locations in the sample stream.
> Implementing transient masked WSOLA might be another example.
>


Actually, probably you can do it in Csound; it would just take a lot of 
code and be very slow. And in its most common use (time-scaling) it is 
not a good fit to the primary real-time streaming paradigm. Assuming a 
streaming form of WSOLA is possible, the standard approach is to ask 
someone to make an opcode for it, and if necessary a new signal type; 
and given the level of expertise available, it would probably take the 
right person just a week. But yes I am at least partly being a pedant, 
as you have cited processes such as quicksort that are outside the 
domain of audio streaming processing to which Csound is expressly, and 
virtually exclusively, targetted.  It is a wonder you do not criticise 
Csound for not providing templates, virtual functions and exceptions.


>
>> We have rather a lot of control flow opcodes these days (remembering
>> that all control flow idioms after the first are in principle syntactic
>> sugar), including "else" and "until".
>
> Can you provide a concrete example/link please? My knowledge is clearly
> out of date here. Last time I knew there was just the convoluted re-init
> mechanism to do control flow.

Reinit is arguably not a component of control flow. It does exactly what 
it says, momentarily suspending the audio stream while opcodes with 
internal state are reinitialised. It is associated primarily with 
handling tied notes in the score, but can be used for general iterative 
processes too. I understand "control flow" to apply to conditional tests 
and loops. Csound had "if" and "goto" from the outset, and many more 
have been added since. See for example:

http://www.csounds.com/journal/2006spring/controlFlow.html


>
> Are CSound control flow opcodes sufficient for me to implement a
> quicksort? That's the kind of control flow I'm thinking of -- something
> that can be used with data structures to implement algorithms.
>

The classic algorithm uses recursion, and I would have to defer to 
higher authorities to confirm if Csound can do that directly in the way 
quicksort requires. But on the principle that any terminating recursive 
algorithm can be recast in iterative form, I would say yes Csound can be 
used to implement a numeric quicksort. You would use ftables for 
storage, and the table access opcodes for element manipulations. I 
suspect technically Csound does (just) quality as a Turing Machine. 
Sorting is very relevant to score processing, but much less so to audio 
processing (I can't even think of an application example), so clearly 
the instrument syntax is not optimised for such things. I doubt anyone 
would seriously want to try it.

Very probably you can use the embeded Python or Lua facilities to do it, 
though I accept that may be the exception that proves the rule. In the 
same vein, perhaps you might similarly accept that the idea of embedding 
one language within another (or calling one language from another) is 
also, at the very least, interesting, worth considering, and takes the 
discussion a little away from a simple and misleading comparison of 
Csound with C++.

There are many many people (some on this list) using Csound for realtime 
algorithmic composition and performance. Yes it can be done to a degree 
purely within Csound, but the typical use is to use the "language of 
choice" e.g. Python to handle the algorithmic side, and then issue 
dynamic note events to the Csound engine. Since version 5 Csound has 
been built as a library, complete with API accessible from many 
languages including C++, and offering a high degree of access to the 
Csound internals if you need it. Which is how it can be implemented as a 
Max/MSP or PD external, and within Ableton using "CsoundForLive".  There 
is also much discussion of running it on iOS and Android.

So you can in fact have the best of both worlds by using C++ for all 
your quick-sorting, you can access the Csound audio buffers directly for 
all your zero-crossing tasks (you can even quicksort the audio samples 
if you want to!), and then call "perf" or whatever you need to do for 
the fast optimised audio processing. Just as you would automatically do 
for intensive graphics processing, where you really would not want to do 
it in raw C++ when you have a nice fast GPU and optimised libraries to 
do the demanding bits.

Requiring any one language to do everything can lead to unnecessary 
restrictions and difficulties, and seems an increasingly old-fashioned 
approach these days. Understandable enough if one only knows the one 
language, and the more so if one believes it is the best for everything. 
Common sense surely says to use all available languages for what they 
are most optimised to do. Of course for proprietary solutions publicly 
readable scripts are not appropriate, but that is a whole separate issue.

For my sonification work for LHCsound, I used Perl to parse data files 
and generate Csound scores, simply because it is a task Perl is 
canonically optimised to do and scripts can be run up very quickly. 
Others would use Python, as I may do myself in due course, once I know 
Python better. I have done it in C++ too, but it was never my first 
choice - I used C++ because wxWidgets is written in it. And for running 
up instruments Csound is so obviously the choice it barely needs 
explanation. Indeed the ability of the score parser to sort note lists 
not already written in time order was critical both to getting results 
quickly, keeping the score-writing code itself simple and modular, and 
ensuring the generated score can be easily checked against the input 
data. Yes, I could implement all that in C++ (or Python, or...), but it 
is already implemented in Csound so I use Csound.

YMMV...


Richard Dobson













From richarddobson at blueyonder.co.uk  Sun Feb 26 11:06:36 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Sun, 26 Feb 2012 16:06:36 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
Message-ID: <4F4A588C.3040607@blueyonder.co.uk>

On 26/02/2012 14:11, Brad Garton wrote:
> On Feb 26, 2012, at 5:13 AM, Richard Dobson wrote:
>
>> It is rather more flexible than Max/MSP, say, because you can if
>> you want to run a single-sample vector, whereas MSP has always been
>> fixed to a 64-sample block size.
>
> I don't think that's actually true...
>

It used to be; maybe it is more flexible in version 6. I have never 
owned it, so my knowledge is somewhat sparse and anecdotal.


Richard Dobson



From jpff at cs.bath.ac.uk  Sun Feb 26 11:11:23 2012
From: jpff at cs.bath.ac.uk (jpff at cs.bath.ac.uk)
Date: Sun, 26 Feb 2012 16:11:23 -0000
Subject: [music-dsp] a little about myself
In-Reply-To: <658D8A59-B3D1-4191-B16A-CEB46572F9DA@columbia.edu>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<658D8A59-B3D1-4191-B16A-CEB46572F9DA@columbia.edu>
Message-ID: <4a254780bbe31db44a9a7c510953d49e.squirrel@www.cs.bath.ac.uk>

> On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote:
>
>> In my view, anyone who cares about being a composer of *computer music*
>> (in the context of this discussion) needs at least the following (or
>> equivalent) undergraduate knowledge:
>>
>> 1) music composition degree
>> 2) computer science and/or software engineering degree
>> 3) electrical engineering degree
>>
>> Maybe even this is required:
>> 4) Tonmeister/ sound engineering degree

Guess that means I should not be here.  No musical qualification beyond a
poor 'O' level, no Computer SCience degree, no knowledge of electrical
engineering (and very little of electrical science) and certainly not
sound engineering.

So perhaps I will return to grubbing in the dirt and clashing rocks together

==John ff



From contact at quikquak.com  Sun Feb 26 11:46:42 2012
From: contact at quikquak.com (Dave Hoskins)
Date: Sun, 26 Feb 2012 16:46:42 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4a254780bbe31db44a9a7c510953d49e.squirrel@www.cs.bath.ac.uk>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>	<658D8A59-B3D1-4191-B16A-CEB46572F9DA@columbia.edu>
	<4a254780bbe31db44a9a7c510953d49e.squirrel@www.cs.bath.ac.uk>
Message-ID: <4F4A61F2.8000705@quikquak.com>


On 26/02/2012 16:11, jpff at cs.bath.ac.uk wrote:
>> On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote:
>>
>>> In my view, anyone who cares about being a composer of *computer music*
>>> (in the context of this discussion) needs at least the following (or
>>> equivalent) undergraduate knowledge:
>>>
>>> 1) music composition degree
>>> 2) computer science and/or software engineering degree
>>> 3) electrical engineering degree
>>>
>>> Maybe even this is required:
>>> 4) Tonmeister/ sound engineering degree
> Guess that means I should not be here.  No musical qualification beyond a
> poor 'O' level, no Computer SCience degree, no knowledge of electrical
> engineering (and very little of electrical science) and certainly not
> sound engineering.
>
> So perhaps I will return to grubbing in the dirt and clashing rocks together
>
> ==John ff
I'm self-taught, so I'll join you in the mud. We can look up and watch 
the 'great meat mincer' churn out identical degree clones, all wound up 
and ready to go - in the same direction.
Something like this:-
http://www.geraldscarfe.com/wp-content/uploads/pfteachernew.jpg
:)
*sarcasm mode off*








From garton at columbia.edu  Sun Feb 26 11:50:15 2012
From: garton at columbia.edu (Brad Garton)
Date: Sun, 26 Feb 2012 11:50:15 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A61F2.8000705@quikquak.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>	<658D8A59-B3D1-4191-B16A-CEB46572F9DA@columbia.edu>
	<4a254780bbe31db44a9a7c510953d49e.squirrel@www.cs.bath.ac.uk>
	<4F4A61F2.8000705@quikquak.com>
Message-ID: <CFA3BB05-CD12-477C-BA46-57C70DFA916C@columbia.edu>

On Feb 26, 2012, at 11:46 AM, Dave Hoskins wrote:

> http://www.geraldscarfe.com/wp-content/uploads/pfteachernew.jpg

Darn, I guess that makes me another brick in the wall.  :-)

"We don't need no education"  ==  !(!education)

brad
http://music.columbia.edu/~brad


From thomas at pdp7.org  Sun Feb 26 11:51:49 2012
From: thomas at pdp7.org (Thomas Strathmann)
Date: Sun, 26 Feb 2012 17:51:49 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A53CB.2000607@tiscali.nl>
References: <4F4A53CB.2000607@tiscali.nl>
Message-ID: <4F4A6325.8090401@pdp7.org>

On 26.02.12 16:46, Theo Verelst wrote:
> Of course most all computer languages have serious limitations, too:
> none allow explicit parallel programming concepts, "native" associative
> behaviour, and even simple mathematical reasoning takes a heavy LISP
> program to begin with (Like Maxima), and a lot of "programming" skills
> are essentially a training in the feasibility of a certain amount of
> efficiency with a language, either to express an idea in the language,
> or to make the language when compiled/interpreted and run on a machine
> to work efficient enough on it to achive the programming purpose.

Without a clear definition of what "explicit parallel programming 
concepts" or "native associative behaviour" is supposed to mean it is 
impossible to say whether any given programming language supports either 
one. Simple mathematical reasoning does not take the whole of Maxima, 
Reduce or the like. Simple mathematical reasoning can be done by 
relatively short programs that in some courses students create as part 
of their homework assignments. But again it is impossible to judge this 
without a clear definition of "simple mathematical reasoning."

> I mean the whole of the software boys and gals ideas aren't
> going to make either the new Marshall or Les Paul ever. I doubt
> seriously if the collective software world without external guidance
> could sit together and finish a random electrical engineering exam from
> the first year if they'd have a week time, and their lives depended on
> it. Seriously.

I seriously doubt that this is true. Seriously. But perhaps it depends 
on some very specific idea of what the "collective software world" is.
A little bit of scientific thinking can go a long way when trying to 
explain some point of view such that other people can actually 
understand what is or is not meant by any given statement.

	Thomas

From padawan12 at obiwannabe.co.uk  Sun Feb 26 11:58:42 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Sun, 26 Feb 2012 16:58:42 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A5770.5030103@blueyonder.co.uk>
References: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
Message-ID: <20120226165842.GA27368@sapphire.lan>

On Sun, Feb 26, 2012 at 04:01:52PM +0000, Richard Dobson wrote:

 
> For my sonification work for LHCsound, I used Perl to parse data
> files and generate Csound scores, simply because it is a task Perl
> is canonically optimised to do and scripts can be run up very
> quickly. 

Just a quick +1 for Perl as an event generator in cooperation
with Csound, especially if the project involves any kind of
network processing.

Andy



From richarddobson at blueyonder.co.uk  Sun Feb 26 12:11:33 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Sun, 26 Feb 2012 17:11:33 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F49C7C0.9020702@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
Message-ID: <4F4A67C5.7070306@blueyonder.co.uk>

On 26/02/2012 05:48, Ross Bencina wrote:
..
>> (1) An efficient way to implement a runtime compiler for block-based
>> audio DSP chains (these are what are in software synthesizers)...
>> which usually are based on
>
> As if block-based DSP chains are the only way to make sound with a
> computer.
>

Indeed they are not; but they are often the most efficient way to do it 
while retaining flexibility of configuration. For much the same reason 
that block-based access to a disk file is so much more efficient than 
single-word access that the latter never happens. Most audio devices for 
general-purpose computers have no choice but to deliver audio to the 
host in bursts of, say, 32 samples, so the audio is already being 
supplied as a block rather than single samples. Given the choice of one 
function call on a vector, or 32 function calls on a sample, there can 
still be many reasons to choose the former.

..
>
..
>
> The assumption here is that the target audience is the "non technical
> musician". I think this is completely spurious. Talking about
> limitations or capabilities of computer programming languages is kind of
> pointless if you allow for the novice user who doesn't even know what a
> turing complete language can do.
>

Exactly true. It is only relevant to programmers. We can drive a car 
pefectly well, and even do or direct basic maintenance on them, without 
knowing the minutiae of metallurgy or chemistry, and we can light and 
enjoy a firework without knowing anything about Newton's laws (or 
chemistry, again). Maybe just a bit about health and safety. And we can 
enjoy a film and use a GPS system without having to know anything about 
the interactions of photons and electrons or the relativistic 
compensation of satellite signals. All these things are interesting, and 
for those whose business is building them, essential. But carbon-based 
life forms have managed to jump, swim, fly, throw and catch for 
millennia without having any idea how gravity really works, or what 
momentum really is.


People (UK-based) concerned about the public's level of education with 
respect to computing may be interested to join the Computing At School 
community, dealing with the newly announced UK initiative to all but 
replace the existing ICT curriculum with a computer science one 
involving real programming. One tool widely used at primary level is 
called "Scratch", developed at MIT:

http://scratch.mit.edu/

It supports some music programming, but arguably could do very much more 
in that area.



> In my view, anyone who cares about being a composer of *computer music*
> (in the context of this dicussion) needs at least the following (or
> equivalent) undergraduate knowledge:
>

Although I go along with the collective and use the term, I do not 
believe there is actually such a thing as "computer music", outside the 
usual limitations of the language myth. At the very least, I would 
question if everyone using that term means it in the same way. There is 
music (or "sound art") that has been composed or performed using 
computers, and in practice there are sounds which we either know or 
assume depended on computers (or tape, or strange electronics) to make 
them. There is also music composed using algorithmic techniques, but 
these do not all need computers, unless in the old meaning of "one who 
computes". The vast majority of what is popularly called "computer 
music" is well within the classical paradigm of instruments and notes, 
rhythms and harmonies, drones and moments, active performers and passive 
listeners, and can be listened to and enjoyed with no more than the 
corrsponding vernacular musical listening skills. A basic definition of 
"electro-acoustic" is no more than "music/sound presented using 
loudspeakers". The somewhat astonishing but also understandable 
enthusiasm for all things analogue and retro suggests that for most 
people computers are best seen but not heard!

Computers, in the end, are used because comparatively speaking they are 
either cheaper and/or faster than the available alternatives of 
comparable scale. This is not to trivialise them at all (most of my life 
and work involves them, after all), but it is not to over-romanticise 
them either. They remain strictly a means to an end (unless your thing 
is designing them).  However, it is clear that composers of "computer 
music" very intensely and understandably want their skills to be 
recognised and appreciated; easy enough with a physical instrument, a 
printed score and ready comparisons, but not so much when all you have 
to show for it is hunched shoulders over a laptop, or a CD and brief 
programme note. So, the more informed the public is about computing, the 
more they will appreciate those who are adepts. The only other way is if 
the programming seems truly "impossible" or mould-breaking - witness the 
admiration given to the Melodyne developers, for example. Sadly the 
public is so used to breakthroughs on a yearly basis, that soon enough 
they will be taken for granted along with GPS, mobile phones, wash 
cycles and cash dispensers.

Of course, to write programs requires relevant skills; but that is true 
for all computing subjects. Much depends on one's ambition. An 
arpeggiator is an algorithmically defined thing, as is a drum machine; 
but they hardly need a CS degree to use. I suspect the key difference 
that takes one into "real" computing is the rare desire  to deal with 
hard precise numbers rather than with intuitive/random twiddling and 
fiddling. That desire remains the exception rather than the rule, as I 
soon found out the one time I got to teach Csound to an undergraduate 
CMT group for a semester: "We don't have to learn any maths, do we?".

Richard Dobson











From theover at tiscali.nl  Sun Feb 26 12:14:13 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Sun, 26 Feb 2012 18:14:13 +0100
Subject: [music-dsp] music-dsp Digest, Vol 98, Issue 92
In-Reply-To: <mailman.1303.1330274728.148.music-dsp@music.columbia.edu>
References: <mailman.1303.1330274728.148.music-dsp@music.columbia.edu>
Message-ID: <4F4A6865.7010408@tiscali.nl>


I meant to speak in a slight scientific philosophical way as in to 
determine what the "direction of the research" in this specific group of 
people might be, referring to the more general "logic of research" or 
"systematic IT behaviour" I have often observed.

 > But perhaps it depends
 > on some very specific idea of what the "collective software world" is.

Preferably a perfectly random sample of java-applet builders (I enjoy a 
few of those, no misunderstanding), C and other serious and fundamental 
language programmers in hobby, industrial and government/defense worlds, 
and perhaps script maintainers for a various types of education 
institutes, and what else there is in the great wide world of 
"programmers", and all of which of course was hopelessly "tempted" or 
whatever appropriate term by groups of people aspiring for more power in 
there than their merits or reasonable ambitions warrant.

I meant that the thought "programming is power because.." has (at least 
by me) been found to be seldom all too correct, and that that pertains 
to philosophical and scientific general truths, too.

I mean, if I'd leave it to and IT type of "programmer" fellow human 
being to come up with a manner to solve for all the currents and 
voltages in an electrical circuit, the outcomes wouldn't very exhilarate 
me, already before the attempt would start...

And if I then would inspect the progress of such a project, I'd find 
that the IT-ish programmers have little sense of personal hono(u)r and 
lofty thoughts about life in general, and certainly therefore not about 
music. Thus, I cannot imagine a decent software DSP discussion without 
people feeling their private musical tastes half raped to death unless 
the participants observe such issue, or everybody has a very 
constitution and stomach.

It's like discussing Open Source software with mr R. Stallman: there are 
few people who contributed more, but few people inthe "wrong" IT corner 
will even respect that fact.

So I'm all for a "G?del, Escher, Bach"- type of discussion, but it's 
hard to believe whole groups of people wouldn't dearly love to monkey a 
specific feedback mathematical equation to create more disputable music 
with, and I'm against that because I know those same people will have 
little self control. That doesn't stop me from observing the whole world 
of Open Suorse appears to reside under a cloud of challenges for even 
small type of jobs to be done, which cloud contains huge 
skill-challenges normally only justified in a heavy engineering 
education (which I did follow). I don't like that situation.

Theo V.

From rbj at audioimagination.com  Sun Feb 26 18:58:56 2012
From: rbj at audioimagination.com (robert bristow-johnson)
Date: Sun, 26 Feb 2012 18:58:56 -0500
Subject: [music-dsp] high-level vs. low-level coding of algs
In-Reply-To: <B3682239-3457-4209-9490-8E74F1D7204A@columbia.edu>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>	<4F4A40E9.8050801@audiomulch.com>
	<B3682239-3457-4209-9490-8E74F1D7204A@columbia.edu>
Message-ID: <4F4AC740.8080302@audioimagination.com>


changed the subject line to something more accurate...

On 2/26/12 9:25 AM, Ross Bencina wrote:
> On 27/02/2012 1:11 AM, Brad Garton wrote:
>> We're fooling around with the new Max/MSP gen~ stuff in class, it
>> seems an interesting alternative model for low-level DSP coding.
>> Once they figure out how to do proper conditionals it will be really
>> powerful.
>
> Why anyone would want to use a visual patcher to write low level code 
> is beyond me though. Managing complexity in Max is already a nightmare 
> compared to using text-based development methods and tools. Not to 
> mention how quickly you can type code compared to patching it.
> They should have just added an object for live coding assembly 
> language (only half kidding).

On 2/26/12 9:31 AM, Brad Garton wrote:
> I completely agree.  However, I find myself exploring aspects of an implemented DSP algorithm in ways that I wouldn't using a text-based approach.  It's kind of like trying to write poetry in a second language, you occasionally find yourself constructing things you would not have otherwise.  All these various languages facilitate different kinds of 'tweakiness', and for me a lot of the fun is seeing where a particular approach might lead...

i have never used Max.  i have programmed algs at pretty much the lowest 
level using either C or the asm for some particular chip.

in my opinion, the optimal division of labor becomes obvious if your 
system modularizes specific low-level algs.  when i worked at Eventide 2 
decades ago, i thought that division of high level vs. low level was 
pretty much natural and optimal.

on the low level we programmed blocks where the sample processing was in 
the 56K assembly and the "coefficient cooking" was in C.  they wrote 
some pretty good tools that fished the symbols outa the linkable object 
code that came outa the assembler and the coefficient cooking code could 
write to specific DSP variables as symbols.  you didn't need to note 
where the DSP address was, it would find it for you.  the coefficient 
cooking code was executed only when a knob was twisted, but the sample 
processing code was running all the time after it was loaded.  a typical 
example would be an EQ filter where user parameters (like resonant 
frequency, Q, boost/cut gain) would go into the block from the outside 
and the coefficient cooking code would cook those parameters and send 
the coefficients to the DSP where the DSP was expecting them to go.

but patching these blocks together was (eventually) done with a visual 
patch editor.  if, to create an overall "effect", you're laying down a 
modulatable delay line here, a modulatable filter there, and some other 
algorithms that have already been written and tested, with definable 
inputs and outputs, why not use a visual editor for that?

but, if you need a block that does not yet exist, you need to be able to 
write hard-core sample processing code in a general purpose language 
like C (or the natural asm for a particular chip).  then turn that into 
a block, then hook it up with a visual editor like all of the other blocks.

-- 

r b-j                  rbj at audioimagination.com

"Imagination is more important than knowledge."




From dan.stowell at eecs.qmul.ac.uk  Mon Feb 27 05:13:22 2012
From: dan.stowell at eecs.qmul.ac.uk (Dan Stowell)
Date: Mon, 27 Feb 2012 10:13:22 +0000
Subject: [music-dsp] Reminder: SuperCollider Symposium early-bird tickets
	this week
Message-ID: <4F4B5742.9080602@eecs.qmul.ac.uk>

---------- Forwarded message ----------
From: SuperCollider Symposium London <info at sc2012.org.uk>


Dear all,

A reminder that earlybird tickets for the SuperCollider Symposium 2012
are available until THIS WEDNESDAY - get your tickets before the price
goes up!

If you need any incentive, here's the preview video featuring guest
keynote Takeko Akematsu <http://www.youtube.com/watch?v=JlI8XlI6XrM>

More info: <http://www.sc2012.org.uk/>

Best
sc2012

From theover at tiscali.nl  Mon Feb 27 10:54:05 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Mon, 27 Feb 2012 16:54:05 +0100
Subject: [music-dsp] high-level vs. low-level coding of algs
In-Reply-To: <mailman.1307.1330276460.148.music-dsp@music.columbia.edu>
References: <mailman.1307.1330276460.148.music-dsp@music.columbia.edu>
Message-ID: <4F4BA71D.7070503@tiscali.nl>


robert bristow-johnson wrote at Sun Feb 26 18:58:56 EST 2012:

 > ...
 > in my opinion, the optimal division of labor becomes obvious if your
 > system modularizes specific low-level algs.  when i worked at
 > Eventide 2 decades ago, i thought that division of high level vs.
 > level was pretty much natural and optimal.
 >...

I had a Rev-7 (Yamaha reverb/effect) halfway 80s with nice 16 bit AD and 
DA converters and I stil think that even interacting with the parameters 
was already fine in that time, though I suppose when one dails some 
complicated parameters, slowness and hickups are harder to prevent. The 
diea of a "running" DSP part (even a thread or a whole core) and a 
shared memory or decent rpc interrupts integrated properly with that is 
nice, and intuitive neough.

That also leaves the interesting question where the Artificial 
Intelligence, or the advanced cooking like pitch follow tricks and 
complicated modulation might be coded, I mean the CISC based PC's in a 
way might be most suited to do not-too-low latency recognition of 
intelligent phenomena like reflection types and amp feedback optimizations.

Maybe I'll make a nice TOS in TOS out Open Source FPGA design for a 
bunch of equalizer channels while I'm at it: such basic building blocks 
always come in handy!

I havent't played with the equipment (I wouldn't mind recording some 
tracks with an H8000 and I've heared the blackhole being used for nice 
effects) but from the demos I could gather your departure hasn't made 
for that much of an exciting new company from Eventide...

Theo V.

From rossb-lists at audiomulch.com  Mon Feb 27 13:59:49 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Tue, 28 Feb 2012 05:59:49 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <20120226152016.GC25614@sapphire.lan>
References: <698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
	<20120226143846.GA25614@sapphire.lan>
	<ACDB1A69-2A3E-4195-AFC4-3A51BDF13F36@columbia.edu>
	<20120226152016.GC25614@sapphire.lan>
Message-ID: <4F4BD2A5.7040208@audiomulch.com>

Hi Andy,

Some comments, and questions for clarification...

 > IIRC, most Music-N line of systems are multi-rate. That means we
 > have a fast computation rate, on which audio signals are calculated,
 > and a slower rate (obviously some integer factor of the audio rate),
 > usually called the control rate, at which things like slow moving
 > envelopes, MIDI inputs and suchlike are calculated.

That's my understanding too. I'm not sure when in the lineage the 
"control rate" was introduced.

Note that there is another wrinkle: some variants support 
sample-accurate event scheduling by slicing the audio period into 
multiple sub-blocks at event boundaries. I believe this was around from 
the early days.


Then, considering (Pd) message dataflow:

On 27/02/2012 2:20 AM, Andy Farnell wrote:
 > The essential facts of this dataflow might be
 >
> There is_always_  an audio signal but there are sometimes no control messages
>
> Control messages are computed on a block boundary

Given this formulation, that the control message scheduler is only 
pumped on the block boundary, isn't this equivalent to having a control 
rate available? Presumably there is a way to get a bang (evaluation) 
every block. From a signal processing angle this still allows the same 
semantics as Music-N multirate? (but see below).

Also note that at least in max, the scheduler doesn't always run 
block-synchronously with the audio thread. I think there are different 
scheduling modes. See "Scheduler in Audio Interrupt (SAI)" here for example:

http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/

This actually makes your point clearer -- if the scheduler is *not* in 
the audio interrupt then clearly it is asynchronous and is quite 
different from the Music-N multirate approach.


> The audio signal is hard real time, so failure of the control to complete
> before the next interrupt will result in a drop out.

Assuming SAI, which is maybe the only option in Pd, but not in Max.


> Okay, given these two approaches we can see that setting kr = ar
> alternatively expressed as (ksamps = 1) in the former system seems to
> be the same as setting the blocksize to 1 in the latter.
>
> BUT:
>
> In Csound we will still get an interleved series
>
> [As_0, Ks_0, As_1, Ks_1, As_2, Ks_2 ... As_n, Ks_n]
>
> wheras in Miller's dataflow we have As, the audio stream running
> constantly, with the possibility for Ks to intervene_anywhere_
> within the stream so long as they can complete before the next
> As is demanded
>
> [As_0, As_1, As_2, As_3 ...As_20, As_21, Ks_0, As_22 ...As_100, Ks_1, Ks_2, As_101]

This description doesn't strike me as completely consistent with what 
you said above. Are you saying that scheduler dispatch is triggered by 
the audio block rate but doesn't happen synchronously with it (ie it is 
still in a separate thread?) I'm not sure I understand what you mean by 
"Ks to intervene_anywhere_ within the stream" -- presumably (in the 
model you described) they only intervene at block boundaries? If the 
scheduler could be invoked at any sample location (ie sample accurate 
callbacks) then things could get interesting.


> Obviously this requires one to think about difficult problems where
> control and signals are closely coupled in subtly different ways for
> each language.

Right, so for example, you don't implicitly have a "control sample rate" 
for doing control rate filtering etc.

Ross

P.S. Your post was in response to Brad's comment about ~gen, which I 
think is more like implementing audio-rate code in a max object, than 
any of the above methods.



From rossb-lists at audiomulch.com  Mon Feb 27 15:23:16 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Tue, 28 Feb 2012 07:23:16 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A5770.5030103@blueyonder.co.uk>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
Message-ID: <4F4BE634.5060701@audiomulch.com>

Hi Richard,

On 27/02/2012 3:01 AM, Richard Dobson wrote:
> On 26/02/2012 11:33, Ross Bencina wrote:
> ..
>>
>> Perhaps I'm not being clear. My point is about being able to execute
>> arbitrary code at an arbitrary time based on the value of some
>> signal(s). The zero crossing thing was a simple example.
>
> In which case it is a trivial test. Way back when I first used Csound on
> the Atari ST, the documentation cited the single-sample mode for
> implementing audio feedback and recursion. Not as efficient as using
> dedicated opcodes, but far from impossible. Conditional tests at krate
> effectively become conditional tests per sample.

If running at ksamps=1 is acceptable, then I agree. But in my view this 
is an inefficient hack. Some people are happy with that.


> A language is defined not simply by what it enables, but by what it
> ~supports~. Csound supports and is optimised for fast audio vector
> processing, but it can do scalar processing too if you really need it.
> And on modern machines it is not even all that slow. Some recently added
> processes such as the Sliding DFT are defined as single-sample processing.
>
> You could also
>> think of algorithms that are not strictly signal based such as
>> multi-rate counters etc etc. Without a full-blown programming language
>> the compromises become unacceptable once you know how to program in a
>> "normal" language, whether that be C, C++, Java, Haskel, Scheme or Lisp.
>>
>
>
> All your points centre on the last - that Csound is not a "full-blown
> programming language". This is only stating the obvious, and is not a
> Csound "flaw".

My basic contention is that it is an insurmountable shortcoming and 
obstacle to future human creative progress for any environment that 
employs this restrictive DSL-like paradigm for creative expression in 
the domain of computer music (as previously described). This is what I 
mean by "flaw".

This is not stating the obvious, it is a position on the design of 
software tools for "computer music", as previously defined. [and yes, 
AudioMulch fails the test far more than CSound].


> ~Of course~ it isn't, never was and has never claimed to
> be - it is a scripted interpreter specialised for audio processing. It
> is a "domain-specific" language, and as such is one among many - Matlab,
> SQL, HTML and so on.

Right. Although Matlab, SQL and HTML are all very different in their 
relation to a "domain" so I'm not exactly sure what your point is here.

The bulk of this argument is what are the boundaries of the domain of a 
DSL for musical audio processing. You would like to define that domain 
as "what Csound does" whereas I conjecture that it is essentially no 
smaller than the domain of generalised computation. Which, lest I be 
misinterpreted, does *not* require C++, templates or exceptions, but it 
*does* require efficient sample-by-sample computation, support for data 
structures, etc.


> In short, this is a completely straw-man argument,

If you think that, you are missing my point. The point being that 
musical DSLs that do not provide full blown programming features present 
undesirable limitations to the current state of practice in computer 
music. This may be a marginal view, but it is not a straw man.

Further, the fact that you cite the use of Python and Lua embedded in 
CSound suggests that there already exists support for this requirement.


> as you are comparing apples to oranges.

Well yes, I am saying that apples are not a nutritional option.


> Indeed, the single biggest issue I have with some on
> the Csound list is precisely that they want to add more general-purpose
> procedural idioms to Csound, in a misguided attempt to turn into it an
> audio version of C++.

No need to group my opinions with your Csound list buddies. I'm quite 
happy for CSound to continue in its limited scope. I just think that 
scope is too limited and I for one would prefer a tool that 
*efficiently* combines all levels (from sample computation to 
algorithmic composition). To some degree, ironically, Max with ~gen 
approaches this, although it is still a multi-language approach which 
to me has its problems (the problems being with where and how the 
boundaries get drawn at the interfaces between languages).


> Even the addition of opcodes to embed Python or
> Lua code within the orchestra was something I had great misgivings about
> (i.e. a whole opcode and even effectively a whole instrument can be
> written in Python or Lua), as to me it is the wrong way around - Csound
> is a low-level language most suited to being embedded within
> higher-level ones. Still, they work (as far as I know), and I suppose if
> I try them one day I might feel differently! So we can probably have the
> slightly surreal spectacle of a Python script running Csound which in
> turn runs a Python-defined opcode.
>
> ..
>>
>> Are you being a pedant on purpose or did you miss my point? It was just
>> an example. Anything that needs to efficiently to execute signal aware
>> logic triggered at arbitrary locations in the sample stream.
>> Implementing transient masked WSOLA might be another example.
>>
>
>
> Actually, probably you can do it in Csound; it would just take a lot of
> code and be very slow.

And that's part of my argument. If a tool makes something that is (to 
me) obviously desirable (ie composing at the level of algorithms that 
are structurally similar to WSOLA, *for example*) "very slow" then it 
biases against that kind of composition.

But I fear that you will once again focus on WSOLA as my single example, 
and pull it apart and criticise it.. when I am using it as one example 
of a general class of things that is not easy to do in CSound. And 
before you accuse me of coming up with straw men again, I will say that 
from the first weeks I used CSound I had problems achieving various 
compositional goals that are in the family of tasks I am raising here -- 
things that are almost trivial in C (and which I ended up using cmix 
for, as it happens). Perhaps I am alone in this, and I can't deny that 
for "plugging unit generators together" Csound is a fine thing, but I 
just can't agree that this is a reasonable place to draw the line for 
functionality to support composition involving sound synthesis (and the 
same criticisms can be directed at many if not all of the other systems 
named in this thread).


> And in its most common use (time-scaling) it is
> not a good fit to the primary real-time streaming paradigm. Assuming a
> streaming form of WSOLA is possible, the standard approach is to ask
> someone to make an opcode for it, and if necessary a new signal type;
> and given the level of expertise available, it would probably take the
> right person just a week.

And here we have another problem... no longer is everything possible in 
the language and culture.. we have to turn to "the right person" to 
spend "just a week" to do something that should be possible to create 
*in the language* so that all can share and modify it. Admittedly 
perhaps no current system easily supports this for WSOLA.. but that is 
part of my criticism of present systems.


> But yes I am at least partly being a pedant,
> as you have cited processes such as quicksort that are outside the
> domain of audio streaming processing to which Csound is expressly, and
> virtually exclusively, targetted. It is a wonder you do not criticise
> Csound for not providing templates, virtual functions and exceptions.

Being able to implement a quicksort is a pretty fundamental programming 
task compared to requiring the language features you mention.


>>> We have rather a lot of control flow opcodes these days (remembering
>>> that all control flow idioms after the first are in principle syntactic
>>> sugar), including "else" and "until".
>>
>> Can you provide a concrete example/link please? My knowledge is clearly
>> out of date here. Last time I knew there was just the convoluted re-init
>> mechanism to do control flow.
>
> Reinit is arguably not a component of control flow. It does exactly what
> it says, momentarily suspending the audio stream while opcodes with
> internal state are reinitialised. It is associated primarily with
> handling tied notes in the score, but can be used for general iterative
> processes too. I understand "control flow" to apply to conditional tests
> and loops. Csound had "if" and "goto" from the outset, and many more
> have been added since. See for example:
>
> http://www.csounds.com/journal/2006spring/controlFlow.html

Thanks. Hadn't seen that.


>> Are CSound control flow opcodes sufficient for me to implement a
>> quicksort? That's the kind of control flow I'm thinking of -- something
>> that can be used with data structures to implement algorithms.
>>
>
> The classic algorithm uses recursion, and I would have to defer to
> higher authorities to confirm if Csound can do that directly in the way
> quicksort requires. But on the principle that any terminating recursive
> algorithm can be recast in iterative form, I would say yes Csound can be
> used to implement a numeric quicksort. You would use ftables for
> storage, and the table access opcodes for element manipulations. I
> suspect technically Csound does (just) quality as a Turing Machine.
> Sorting is very relevant to score processing, but much less so to audio
> processing (I can't even think of an application example), so clearly
> the instrument syntax is not optimised for such things. I doubt anyone
> would seriously want to try it.

It was just an example of normal algorithm that we both know. My point 
being that as a composer one might want to code an algorithm *at any 
level of the temporal abstraction chain from single sample to 
multi-minute form*, and the language should support that.


> Very probably you can use the embeded Python or Lua facilities to do it,
> though I accept that may be the exception that proves the rule. In the
> same vein, perhaps you might similarly accept that the idea of embedding
> one language within another (or calling one language from another) is
> also, at the very least, interesting, worth considering, and takes the
> discussion a little away from a simple and misleading comparison of
> Csound with C++.

Well I think there are two dimensions to this:

1) at the upper level, we have algorithmic control, which as you say can 
probably be done in Python or Lua. This is similar to the current SC3 
Lang/synth split, similar also to LuaAV, and really, not so different to 
having separate dataflow and audio schedulers in Pd and MaxMSP.

2) at the lower level, one may want to "go down to the sample level" 
which you find to be something not particularly relevant. Clearly we 
disagree here. Perhaps an analog will help: one may like to "prepare the 
piano." With a piano, it is arguably easier to prepare it than to play 
it normally, with CSound you have to go and learn C to "prepare" it.


> There are many many people (some on this list) using Csound for realtime
> algorithmic composition and performance. Yes it can be done to a degree
> purely within Csound, but the typical use is to use the "language of
> choice" e.g. Python to handle the algorithmic side, and then issue
> dynamic note events to the Csound engine. Since version 5 Csound has
> been built as a library, complete with API accessible from many
> languages including C++, and offering a high degree of access to the
> Csound internals if you need it. Which is how it can be implemented as a
> Max/MSP or PD external, and within Ableton using "CsoundForLive". There
> is also much discussion of running it on iOS and Android.
>
> So you can in fact have the best of both worlds by using C++ for all
> your quick-sorting, you can access the Csound audio buffers directly for
> all your zero-crossing tasks (you can even quicksort the audio samples
> if you want to!), and then call "perf" or whatever you need to do for
> the fast optimised audio processing.

Sure, you can use C++. That's not a solution, that's a problem. I accept 
that it is an immutable fact in Csound. I am not siding with your list 
friends who want to turn Csound into C++, but I do see it as a problem 
that should be solved by some system somewhere.


> Just as you would automatically do
> for intensive graphics processing, where you really would not want to do
> it in raw C++ when you have a nice fast GPU and optimised libraries to
> do the demanding bits.

You are equating an arbitrary language-imposed separation (Csound/C++) 
with a hardware-imposed separation (CPU/GPU). This is not a reasonable 
comparison and does not support your argument.


> Requiring any one language to do everything can lead to unnecessary
> restrictions and difficulties, and seems an increasingly old-fashioned
> approach these days.

Have you looked at extempore? That's hardly old fashioned. It supports 
live coding of audio algorithms and full system recompilation at runtime.

The multi-level language argument is a couple of decades old (see John 
Osterhout). I think the question is not so much whether multi-language 
systems are a valid paradigm, but whether the lines are drawn in the 
right places in current systems.


> Understandable enough if one only knows the one
> language, and the more so if one believes it is the best for everything.

The issue may not be so much the requirement for a single language, but 
rather the lack of easy, fluid and efficient access to the different 
levels (which in CSound, you've identified as being available via 
Python,Lua -> CSound -> C/C++, in SC3 are available via SCLang -> 
SCSynth -> C++, and which in max.msp are available via Max -> msp -> 
C++/~gen). Notably of those three only max.msp provides access to all 
levels within the one environment. Extempore on the other hand does 
everything in one language.


> Common sense surely says

[[weasel-words]]

> to use all available languages for what they
> are most optimised to do.

In general terms, perhaps. However, you seem to be using this as an 
argument for maintenance of the status quo in the definition of what 
consititues the correct structure for a musical DSL.

Sometimes it is desirable not to have to switch languages. My contention 
is that the whole structure of CSound (and related unit generator type 
approaches, whether implemented in whatever language or environment) 
draw the lines in the wrong places.

Aside from the aformentioned extempore, another supporting data point is 
Phil Burk's migration of the JSyn synthesis engine to pure Java -- 
removal of the multi-language split has reportedly made things much 
easier according to Phil.


> Of course for proprietary solutions publicly
> readable scripts are not appropriate, but that is a whole separate issue.

Yeah that's an interesting, but separate issue.


> For my sonification work for LHCsound, I used Perl to parse data files
> and generate Csound scores, simply because it is a task Perl is
> canonically optimised to do and scripts can be run up very quickly.
> Others would use Python, as I may do myself in due course, once I know
> Python better. I have done it in C++ too, but it was never my first
> choice - I used C++ because wxWidgets is written in it. And for running
> up instruments Csound is so obviously the choice it barely needs
> explanation. Indeed the ability of the score parser to sort note lists
> not already written in time order was critical both to getting results
> quickly, keeping the score-writing code itself simple and modular, and
> ensuring the generated score can be easily checked against the input
> data. Yes, I could implement all that in C++ (or Python, or...), but it
> is already implemented in Csound so I use Csound.
>
> YMMV...
>
>
> Richard Dobson


Ross.

From padawan12 at obiwannabe.co.uk  Mon Feb 27 15:26:09 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Mon, 27 Feb 2012 20:26:09 +0000
Subject: [music-dsp] Scheduling (rate vs event) was: a little about myself
Message-ID: <20120227202609.GA19691@sapphire.lan>

Hi Ross

> Hi Andy,
> Some comments, and questions for clarification...

> > There is_always_  an audio signal but there are sometimes no control messages
> >
> > Control messages are computed on a block boundary

> Given this formulation, that the control message scheduler is only 
> pumped on the block boundary, isn't this equivalent to having a control 
> rate available? 

It may be the case that there are no control messages queued.
What I hoped to highlight here is that there isn't necessarily
a control cycle on which something _must/always_ happen.
On the next cycle, a whole burst of stuff may happen that got
queued during the previos 1/44100th second.

> Presumably there is a way to get a bang (evaluation) 
> every block. 

Yes, there is actually a [bang~] object, which I think
outputs a message bang immediately after the previous audio
block has been completed. I rarely use it myself.


> Also note that at least in max, the scheduler doesn't always run 
> block-synchronously with the audio thread. I think there are different 
> scheduling modes. See "Scheduler in Audio Interrupt (SAI)" here for example:
> http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/

Very interesting. I ought to reread the Pd source more closely before
attempting to comment further, I suspect this is is a subtle but significant
difference. AFAIK there is only one scheduling mode in Pd and it is closer
to the referenced SAI, but with a queue of time tagged control messages.

> I'm not sure I understand what you mean by "Ks to intervene_anywhere_ within 
> the stream" -- presumably (in the model you described) they only intervene at 
> block boundaries? 

Exactly that.

> Right, so for example, you don't implicitly have a "control sample rate" 
> for doing control rate filtering etc.

Timing can be very accurately set (sub millisecond now I think) with a [metro]
and all calculations work for message filtering, but yes, strictly you are right,
the notion of message "samplerate" is meaningless in Pd.


PS I am enjoying the recent threads immensely. Having used Eventides in the studio
for countless hundreds of hours its amazing to read Robert's revelation and
know what was behind all those knob twiddles. And the little audio VM that David 
Olofson posted the other day is still amusing me.

best
Andy

From rossb-lists at audiomulch.com  Mon Feb 27 15:35:35 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Tue, 28 Feb 2012 07:35:35 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <20120226165842.GA27368@sapphire.lan>
References: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<20120226165842.GA27368@sapphire.lan>
Message-ID: <4F4BE917.6050107@audiomulch.com>



On 27/02/2012 3:58 AM, Andy Farnell wrote:
>> For my sonification work for LHCsound, I used Perl to parse data
>> >  files and generate Csound scores, simply because it is a task Perl
>> >  is canonically optimised to do and scripts can be run up very
>> >  quickly.
> Just a quick +1 for Perl as an event generator in cooperation
> with Csound, especially if the project involves any kind of
> network processing.

Just a quick -1 for the whole idea of orchestra vs. score and using text 
as an intermediate encoding for high-bandwidth control data.

Ross.

From jamie at postlude.co.uk  Mon Feb 27 15:39:25 2012
From: jamie at postlude.co.uk (Jamie Bullock)
Date: Mon, 27 Feb 2012 20:39:25 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4BD2A5.7040208@audiomulch.com>
References: <698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>
	<20120226143846.GA25614@sapphire.lan>
	<ACDB1A69-2A3E-4195-AFC4-3A51BDF13F36@columbia.edu>
	<20120226152016.GC25614@sapphire.lan>
	<4F4BD2A5.7040208@audiomulch.com>
Message-ID: <516F03E2-0E3D-42DC-B058-F4118D6CAEA9@postlude.co.uk>


Hi Ross,


On 27 Feb 2012, at 18:59, Ross Bencina wrote:

> 
> On 27/02/2012 2:20 AM, Andy Farnell wrote:
> > The essential facts of this dataflow might be
> >
>> There is_always_  an audio signal but there are sometimes no control messages
>> 
>> Control messages are computed on a block boundary
> 
> Given this formulation, that the control message scheduler is only pumped on the block boundary, isn't this equivalent to having a control rate available? Presumably there is a way to get a bang (evaluation) every block. From a signal processing angle this still allows the same semantics as Music-N multirate? (but see below).
> 
>> 
>> wheras in Miller's dataflow we have As, the audio stream running
>> constantly, with the possibility for Ks to intervene_anywhere_
>> within the stream so long as they can complete before the next
>> As is demanded
>> 
>> [As_0, As_1, As_2, As_3 ...As_20, As_21, Ks_0, As_22 ...As_100, Ks_1, Ks_2, As_101]
> 
> This description doesn't strike me as completely consistent with what you said above. Are you saying that scheduler dispatch is triggered by the audio block rate but doesn't happen synchronously with it (ie it is still in a separate thread?) I'm not sure I understand what you mean by "Ks to intervene_anywhere_ within the stream" -- presumably (in the model you described) they only intervene at block boundaries? If the scheduler could be invoked at any sample location (ie sample accurate callbacks) then things could get interesting.

Pd provides the possibility for sub-sample accurate message scheduling, but not all objects make use of it. The classic example is [line~] (a linear ramp generator), which only checks for new control messages once per DSP block, whereas [vline~], checks for control messages once per sample.  When vline~ starts processing each block of samples, it takes a clock reference. It then iterates over each sample in the block, and for each sample computes the elapsed time from block start (based on samplerate), and checks whether any messages are scheduled for that sample and varies it's output accordingly.

best,

Jamie

--
http://www.jamiebullock.com

From rossb-lists at audiomulch.com  Mon Feb 27 16:00:25 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Tue, 28 Feb 2012 08:00:25 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4A67C5.7070306@blueyonder.co.uk>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A67C5.7070306@blueyonder.co.uk>
Message-ID: <4F4BEEE9.2010104@audiomulch.com>

On 27/02/2012 4:11 AM, Richard Dobson wrote:
> On 26/02/2012 05:48, Ross Bencina wrote:
> ..
>>> (1) An efficient way to implement a runtime compiler for block-based
>>> audio DSP chains (these are what are in software synthesizers)...
>>> which usually are based on
>>
>> As if block-based DSP chains are the only way to make sound with a
>> computer.
>>
>
> Indeed they are not; but they are often the most efficient way to do it
> while retaining flexibility of configuration. For much the same reason
> that block-based access to a disk file is so much more efficient than
> single-word access that the latter never happens.

Thing is, most of the time you can do word-level i/o, even if this is 
not how it's implemented. Same thing with processor cache's, they 
(mostly) transparently support word-level access.

This is not the same as being (effectively) forced to do page or block 
level access.


> Most audio devices for
> general-purpose computers have no choice but to deliver audio to the
> host in bursts of, say, 32 samples, so the audio is already being
> supplied as a block rather than single samples.

I don't really see how the functioning of the hardware sample delivery 
mechanism has any bearing on the required functional capabilities of a 
computer music programming system that (fundamentally) generates sound 
sample by sample.


> Given the choice of one
> function call on a vector, or 32 function calls on a sample, there can
> still be many reasons to choose the former.

Agreed. And one would like to do so whenever possible, and not do so 
whenever required. Setting ksamps=1 may be sufficient in some 
circumstances, whereas I would say the option needs to be available at 
any moment (for each subexpression or statement say). This is more or 
less what Faust or MP4-SAOL give you for example.


>> The assumption here is that the target audience is the "non technical
>> musician". I think this is completely spurious. Talking about
>> limitations or capabilities of computer programming languages is kind of
>> pointless if you allow for the novice user who doesn't even know what a
>> turing complete language can do.
>>
>
> Exactly true. It is only relevant to programmers.

And as I have already said. Computer musicians, must be programmers *by 
definition*. Otherwise they are musicians, using computers. That's where 
I stand. If you want to take a different point of view that's fine, but 
know that this is the position from which all of my arguments in this 
thread stem.


> We can drive a car
> pefectly well, and even do or direct basic maintenance on them, without
> knowing the minutiae of metallurgy or chemistry, and we can light and
> enjoy a firework without knowing anything about Newton's laws (or
> chemistry, again). Maybe just a bit about health and safety. And we can
> enjoy a film and use a GPS system without having to know anything about
> the interactions of photons and electrons or the relativistic
> compensation of satellite signals. All these things are interesting, and
> for those whose business is building them, essential. But carbon-based
> life forms have managed to jump, swim, fly, throw and catch for
> millennia without having any idea how gravity really works, or what
> momentum really is.

Agreed. Indeed the skills required for driving may even be orthogonal to 
those required for metalurgy.


> People (UK-based) concerned about the public's level of education with
> respect to computing may be interested to join the Computing At School
> community, dealing with the newly announced UK initiative to all but
> replace the existing ICT curriculum with a computer science one
> involving real programming. One tool widely used at primary level is
> called "Scratch", developed at MIT:
>
> http://scratch.mit.edu/
>
> It supports some music programming, but arguably could do very much more
> in that area.
>
>
>
>> In my view, anyone who cares about being a composer of *computer music*
>> (in the context of this dicussion) needs at least the following (or
>> equivalent) undergraduate knowledge:
>>
>
> Although I go along with the collective and use the term, I do not
> believe there is actually such a thing as "computer music", outside the
> usual limitations of the language myth. At the very least, I would
> question if everyone using that term means it in the same way. There is
> music (or "sound art") that has been composed or performed using
> computers, and in practice there are sounds which we either know or
> assume depended on computers (or tape, or strange electronics) to make
> them. There is also music composed using algorithmic techniques, but
> these do not all need computers, unless in the old meaning of "one who
> computes". The vast majority of what is popularly called "computer
> music" is well within the classical paradigm of instruments and notes,
> rhythms and harmonies, drones and moments, active performers and passive
> listeners, and can be listened to and enjoyed with no more than the
> corrsponding vernacular musical listening skills. A basic definition of
> "electro-acoustic" is no more than "music/sound presented using
> loudspeakers". The somewhat astonishing but also understandable
> enthusiasm for all things analogue and retro suggests that for most
> people computers are best seen but not heard!

Yes there is a lot of this. I make my living making software that 
addresses this "retro" non-computational use of computers to make music. 
You could see it as part of the trend towards virtualisation of 
pre-existing paradigms.

To a large degree I am sympathetic to non-computational music, and have, 
lately been avoiding computers for my own composition and sound making.


> Computers, in the end, are used because comparatively speaking they are
> either cheaper and/or faster than the available alternatives of
> comparable scale. This is not to trivialise them at all (most of my life
> and work involves them, after all), but it is not to over-romanticise
> them either. They remain strictly a means to an end (unless your thing
> is designing them). However, it is clear that composers of "computer
> music" very intensely and understandably want their skills to be
> recognised and appreciated; easy enough with a physical instrument, a
> printed score and ready comparisons, but not so much when all you have
> to show for it is hunched shoulders over a laptop, or a CD and brief
> programme note. So, the more informed the public is about computing, the
> more they will appreciate those who are adepts.

I'm not sure this is relevant. Ultimately it is the musical result that 
is important, not recognition of other, necessary skills, or achievement 
of previously unachieved technical feats. Ultimately the requirements I 
am arguing for are relevant (I belive) to achieving desired musical ends.


> The only other way is if
> the programming seems truly "impossible" or mould-breaking - witness the
> admiration given to the Melodyne developers, for example. Sadly the
> public is so used to breakthroughs on a yearly basis, that soon enough
> they will be taken for granted along with GPS, mobile phones, wash
> cycles and cash dispensers.
>
> Of course, to write programs requires relevant skills; but that is true
> for all computing subjects. Much depends on one's ambition. An
> arpeggiator is an algorithmically defined thing, as is a drum machine;
> but they hardly need a CS degree to use. I suspect the key difference
> that takes one into "real" computing is the rare desire to deal with
> hard precise numbers rather than with intuitive/random twiddling and
> fiddling. That desire remains the exception rather than the rule, as I
> soon found out the one time I got to teach Csound to an undergraduate
> CMT group for a semester: "We don't have to learn any maths, do we?".

Reminds me of an argument I heard about between a classroom music 
teacher and a composer friend. The music teacher was adamant that 
mathematics has nothing to do with music.

Ross.





From Victor.Lazzarini at nuim.ie  Mon Feb 27 16:14:40 2012
From: Victor.Lazzarini at nuim.ie (Victor)
Date: Mon, 27 Feb 2012 21:14:40 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4BE634.5060701@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com> <4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com> <4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
Message-ID: <EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>

well that is not exactly a hack, because you can write parts of Csound code as user-defined opcodes that run at different rates than the main code, including ksmps=1. That is quite efficient. In fact, as a I have shown in more than half a dozen scientific papers, Csound is a good language to demonstrate or prototype new synthesis algorithms, as we can have acess to sample-level audio, and its variables are actually holding signals, not some reference to something on a synth running somewhere else.

Csound is an evolving language, still after more than 25 years, and there are many features you might not be aware of. The recently-introduced new parser has opened up a bunch of new possibilities, including that of new languages to control the engine. 

We are in active discussion regarding the development of Csound 6, which will include more new features and possibilities. The community has been very active and engaged in telling us what they would like to see there.

This, coupled with developments towards a ubiquitous Csound (on mobile platforms and online deployment) makes it very exciting to work with the system at this point. 

Victor
On 27 Feb 2012, at 20:23, Ross Bencina <rossb-lists at audiomulch.com> wrote:

> If running at ksamps=1 is acceptable, then I agree. But in my view this is an inefficient hack. Some people are happy with that.

From rossb-lists at audiomulch.com  Mon Feb 27 16:33:08 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Tue, 28 Feb 2012 08:33:08 +1100
Subject: [music-dsp] high-level vs. low-level coding of algs
In-Reply-To: <4F4AC740.8080302@audioimagination.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>	<D95A81DC-BE81-44BD-B6F2-B21B56E7EB07@columbia.edu>	<4F4A40E9.8050801@audiomulch.com>
	<B3682239-3457-4209-9490-8E74F1D7204A@columbia.edu>
	<4F4AC740.8080302@audioimagination.com>
Message-ID: <4F4BF694.4050500@audiomulch.com>


On 27/02/2012 10:58 AM, robert bristow-johnson wrote:
> in my opinion, the optimal division of labor becomes obvious if your
> system modularizes specific low-level algs.

I'm not sure it's what you meant, but I would say: if your system 
modularizes specific low-level algs there is perhaps an optimal division 
of labour.

If you're writing in a single-language system on a single instruction 
architecture the options for modularisation will be different than on a 
MPU+DSP architecture.

If you look at the modularisation in something like Apple's vDSP, the 
operations are low level, and make total sense as basic building blocks, 
but they (mostly) don't look anything like what go by the name of unit 
generators in computer music DSLs.


> when i worked at Eventide 2
> decades ago, i thought that division of high level vs. low level was
> pretty much natural and optimal.
>
> on the low level we programmed blocks where the sample processing was in
> the 56K assembly and the "coefficient cooking" was in C. they wrote some
> pretty good tools that fished the symbols outa the linkable object code
> that came outa the assembler and the coefficient cooking code could
> write to specific DSP variables as symbols. you didn't need to note
> where the DSP address was, it would find it for you. the coefficient
> cooking code was executed only when a knob was twisted, but the sample
> processing code was running all the time after it was loaded. a typical
> example would be an EQ filter where user parameters (like resonant
> frequency, Q, boost/cut gain) would go into the block from the outside
> and the coefficient cooking code would cook those parameters and send
> the coefficients to the DSP where the DSP was expecting them to go.

A couple of interesting things here:

- The coefficients are recomputed using a push architecture ("when a 
knob was twisted"). This can be correlated to Pd's dataflow message passing.

- The structure of the "dsp building blocks" is actually a bit different 
from the Csound "unit generator" model where all the processing 
(typically, although not always, including the coefficient cooking) is 
bundled up into the unit generator. Notably, in the Eventide, 
coefficients become a kind of first class data type.


> but patching these blocks together was (eventually) done with a visual
> patch editor. if, to create an overall "effect", you're laying down a
> modulatable delay line here, a modulatable filter there, and some other
> algorithms that have already been written and tested, with definable
> inputs and outputs, why not use a visual editor for that?
>
> but, if you need a block that does not yet exist, you need to be able to
> write hard-core sample processing code in a general purpose language
> like C (or the natural asm for a particular chip). then turn that into a
> block, then hook it up with a visual editor like all of the other blocks.

That works up to the point that you encounter algorithms that can't be 
easily implemented by combining blocks, and are at the same time too 
complex to be "simple building blocks" at the hard-core sample 
processing level (by which I mean that they end up requiring additional 
modularisation internally within a block). Then you end up with a bunch 
of "monster blocks" that kind of break the elegance and obviousness of 
the presumed optimal division of labour. I'm not sure about the 
Eventide, but many unit generator based systems seem to have acquired 
monster blocks -- Reaktor has grain objects with a bazillion paramaters, 
CSound has ugens for entire physical models, even though the bulk of the 
language is low-level unit generators MP4-SAOL defines a few effects 
opcodes (chorus, dynamics processors).

Ross.

From richarddobson at blueyonder.co.uk  Mon Feb 27 16:00:10 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Mon, 27 Feb 2012 21:00:10 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4BE917.6050107@audiomulch.com>
References: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>	<4F4A1877.9050906@audiomulch.com>	<4F4A5770.5030103@blueyonder.co.uk>	<20120226165842.GA27368@sapphire.lan>
	<4F4BE917.6050107@audiomulch.com>
Message-ID: <4F4BEEDA.7000602@blueyonder.co.uk>

On 27/02/2012 20:35, Ross Bencina wrote:
>
>
> On 27/02/2012 3:58 AM, Andy Farnell wrote:
>>> For my sonification work for LHCsound, I used Perl to parse data
>>> > files and generate Csound scores, simply because it is a task Perl
>>> > is canonically optimised to do and scripts can be run up very
>>> > quickly.
>> Just a quick +1 for Perl as an event generator in cooperation
>> with Csound, especially if the project involves any kind of
>> network processing.
>
> Just a quick -1 for the whole idea of orchestra vs. score and using text
> as an intermediate encoding for high-bandwidth control data.
>
  Any particular reason why? It's not so far removed from the idea of 
one synthesis patch + many different MIDI inputs to use it. Of course 
some people deplore the whole idea of MIDI, but they probably also 
deplore 12-note octaves and indeed the whole concept of notes. It may be 
as reasonable a position as any other; but that means that employing 
MIDi is a reasonable position too.

Most score text isn't used "as an intermediate encoding for 
high-bandwidth control data" but as a note list.It is really pretty 
object-oriented.  MIDI has an upper limit of approx one event per 
millisecond. A Csound score has no such limit - it's granularity is 
ultimately set by the value of ksmps. There is also nothing "special" 
about text - it is a possible representation of a stream of values. In 
the old days, all audio processes in (say) the CARL system piped audio 
data as text values from one program to another; i.e. at the sample 
rate. It just happened to use text. I think we also need to know what 
you classify as "high-bandwidth control data", if (presumably) something 
other than a stream at the audio sample rate.

I am getting the sense that these are philosophical principles rather 
than heuristic technical ones.

Richard Dobson

From richarddobson at blueyonder.co.uk  Mon Feb 27 16:55:31 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Mon, 27 Feb 2012 21:55:31 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4BEEE9.2010104@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A67C5.7070306@blueyonder.co.uk>
	<4F4BEEE9.2010104@audiomulch.com>
Message-ID: <4F4BFBD3.6020204@blueyonder.co.uk>

On 27/02/2012 21:00, Ross Bencina wrote:
..
>
> And as I have already said. Computer musicians, must be programmers *by
> definition*. Otherwise they are musicians, using computers.

But there is no single universally agreed definition of "Computer 
musician". It is very likely a super-category. You have your definition, 
but it is not the only one out there. In English we tend to aggregate 
nouns, so we say "computer musician". What you really mean is "computing 
musician". How about "music informaticist"? It may catch on. In the 
meantime, people working intensely with DAW such as Pro Tools or Cubase 
call themselves "programmers". And there is of course, I hope you will 
agree, nothing wrong or inferior about being a musician who uses 
computers. And there are many many levels of "computing". What 
equivalent two-word name would you give them? There are musicians who do 
not use a computer but who think and compose algorithmically. What do we 
call them? For nobody really exists until we can call them something.



Richard Dobson




From michael.gogins at gmail.com  Mon Feb 27 17:05:58 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Mon, 27 Feb 2012 17:05:58 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4BEEDA.7000602@blueyonder.co.uk>
References: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<20120226165842.GA27368@sapphire.lan>
	<4F4BE917.6050107@audiomulch.com>
	<4F4BEEDA.7000602@blueyonder.co.uk>
Message-ID: <CAFswGP3X3ncC7PsTJjzqfrWAxt4cZqRc7nVqdnSGFxem-wqavA@mail.gmail.com>

I think there is a real issue. Ultimately, it's all typing out some
stream of commands written in some language that a computer will
execute. Everything goes more smoothly if you can stay in one language
and think in one language. There's no difficulty expressing different
levels of processing, control, or abstraction with just one language.

I feel the MUSIC N design (wire together unit generator blocks) is a
reasonable solution to the problem that, although it is possible to
write a general-purpose music programming system in one language or AS
one language, because of the way hardware interfaces with software
(especially virtual memory), single-language systems are not that
fast.

I think that as computer power increases and programming languages
evolve, the efficiency advantage of the MUSIC N design will fade. That
could either be because of great just in time compilers for dynamic
languages (LuaJIT seems headed in that direction) or because of
radically faster compile times and simpler build systems for C++ or
other statically compiled languages.

The actual blocks of audio samples will probably still be there... but
it would be nice if one didn't have to think about them.

Come to think of it, what with a-rate and k-rate variables in Csound
orchestra language, WE don't have to think about them -- much.

Regards,
Mike

On Mon, Feb 27, 2012 at 4:00 PM, Richard Dobson
<richarddobson at blueyonder.co.uk> wrote:
> On 27/02/2012 20:35, Ross Bencina wrote:
>>
>>
>>
>> On 27/02/2012 3:58 AM, Andy Farnell wrote:
>>>>
>>>> For my sonification work for LHCsound, I used Perl to parse data
>>>> > files and generate Csound scores, simply because it is a task Perl
>>>> > is canonically optimised to do and scripts can be run up very
>>>> > quickly.
>>>
>>> Just a quick +1 for Perl as an event generator in cooperation
>>> with Csound, especially if the project involves any kind of
>>> network processing.
>>
>>
>> Just a quick -1 for the whole idea of orchestra vs. score and using text
>> as an intermediate encoding for high-bandwidth control data.
>>
> ?Any particular reason why? It's not so far removed from the idea of one
> synthesis patch + many different MIDI inputs to use it. Of course some
> people deplore the whole idea of MIDI, but they probably also deplore
> 12-note octaves and indeed the whole concept of notes. It may be as
> reasonable a position as any other; but that means that employing MIDi is a
> reasonable position too.
>
> Most score text isn't used "as an intermediate encoding for high-bandwidth
> control data" but as a note list.It is really pretty object-oriented. ?MIDI
> has an upper limit of approx one event per millisecond. A Csound score has
> no such limit - it's granularity is ultimately set by the value of ksmps.
> There is also nothing "special" about text - it is a possible representation
> of a stream of values. In the old days, all audio processes in (say) the
> CARL system piped audio data as text values from one program to another;
> i.e. at the sample rate. It just happened to use text. I think we also need
> to know what you classify as "high-bandwidth control data", if (presumably)
> something other than a stream at the audio sample rate.
>
> I am getting the sense that these are philosophical principles rather than
> heuristic technical ones.
>
> Richard Dobson
>
> --
> 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 rossb-lists at audiomulch.com  Mon Feb 27 17:15:28 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Tue, 28 Feb 2012 09:15:28 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4BFBD3.6020204@blueyonder.co.uk>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A67C5.7070306@blueyonder.co.uk>
	<4F4BEEE9.2010104@audiomulch.com>
	<4F4BFBD3.6020204@blueyonder.co.uk>
Message-ID: <4F4C0080.3090909@audiomulch.com>

On 28/02/2012 8:55 AM, Richard Dobson wrote:
> On 27/02/2012 21:00, Ross Bencina wrote:
> ..
>>
>> And as I have already said. Computer musicians, must be programmers *by
>> definition*. Otherwise they are musicians, using computers.
>
> But there is no single universally agreed definition of "Computer
> musician".

As previously posted this is my definition, like it or lump it:

On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote:
 > In my view, anyone who cares about being a composer of
 > *computer music*
 > (in the context of this discussion) needs at least the following (or
 > equivalent) undergraduate knowledge:
 >
 > 1) music composition degree
 > 2) computer science and/or software engineering degree
 > 3) electrical engineering degree
 >
 > Maybe even this is required:
 > 4) Tonmeister/ sound engineering degree

If you feel that my use of terminology is distracting from the central 
purpose of the discussion I would be quite happy to call them "User X". 
They are, I belive, the primary audience for "use-case Y" that is "DSL's 
for User X to create music."


> It is very likely a super-category. You have your definition,
> but it is not the only one out there.

Sure, but we don't need to further argue semantics, I've specifically 
qualified my usage as relevant to this discussion about limitations of 
some exisiting tools / paradigms.


> In English we tend to aggregate
> nouns, so we say "computer musician". What you really mean is "computing
> musician". How about "music informaticist"? It may catch on. In the
> meantime, people working intensely with DAW such as Pro Tools or Cubase
> call themselves "programmers". And there is of course, I hope you will
> agree, nothing wrong or inferior about being a musician who uses
> computers.

Somewhere else in the thread I already explicitly said that I wouldn't 
dream of casting any aspersions or associate any relative merit or value 
to different approaches. However, just as their are better and worse 
violins for violinists, there are better and worse programming systems 
for User X.


> And there are many many levels of "computing". What
> equivalent two-word name would you give them?
> There are musicians who do
> not use a computer but who think and compose algorithmically. What do we
> call them? For nobody really exists until we can call them something.

I am afraid you have lost me here. I have tried to provide you with 
sufficient description to contextualise my argument. If you don't like 
my use of two letter words that is fine. I'm not attached to them, 
especially since it appears that all they have done is distracted you. 
On the other hand, I am attached to the underlying notions that I used 
the two letter word to denote (perhaps modulo my omission of mathematics 
to the mix).

Ross.



From richarddobson at blueyonder.co.uk  Mon Feb 27 17:38:55 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Mon, 27 Feb 2012 22:38:55 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4BE634.5060701@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>	<4F4A1877.9050906@audiomulch.com>	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
Message-ID: <4F4C05FF.9040408@blueyonder.co.uk>

On 27/02/2012 20:23, Ross Bencina wrote:
..
>
> My basic contention is that it is an insurmountable shortcoming and
> obstacle to future human creative progress for any environment that
> employs this restrictive DSL-like paradigm for creative expression in
> the domain of computer music (as previously described). This is what I
> mean by "flaw".
>

"Obstacle to future human creative progress" is a bit heavy for me! If 
csound was the only language out there, you might have a case. But it 
isn't. People choose the language that suits them, according to their 
needs. We must all of use be careful not to tell other people what we 
think they should need, except in the most generous of spirits.


..
>
> If you think that, you are missing my point. The point being that
> musical DSLs that do not provide full blown programming features present
> undesirable limitations to the current state of practice in computer
> music. This may be a marginal view, but it is not a straw man.
>

A text editor presents "undesirable limitations" if what you actually 
want is a word processor or DTP package. The reverse is also true. 
nobody compels you, or anyone, to use Csound. There is no conspiracy 
theory operating here! Csound doesn't do it for you; you have C++ and 
SuperCollider. Fine!

..
>> as you are comparing apples to oranges.
>
> Well yes, I am saying that apples are not a nutritional option.
>
>

?? How about comparing potatoes with rice?


>> Indeed, the single biggest issue I have with some on
>> the Csound list is precisely that they want to add more general-purpose
>> procedural idioms to Csound, in a misguided attempt to turn into it an
>> audio version of C++.
>
> No need to group my opinions with your Csound list buddies. I'm quite
> happy for CSound to continue in its limited scope. I just think that
> scope is too limited

By definition, for those users it is not; at least not to the degree you 
insist on. I accept that it is too limited for you, but not yet clear on 
what wouldn't be, other than a fully general-purpose programming 
language (which we all assume to be C++, but for others might be Lisp)


and I for one would prefer a tool that
> *efficiently* combines all levels (from sample computation to
> algorithmic composition).

It sounds like a fine aspiration, but may also be a counsel of 
perfection, i.e. quite possibly impossible. Whatever you or I can 
imagine, someone will find a limitation or inefficiency in it.


..
>
> And that's part of my argument. If a tool makes something that is (to
> me) obviously desirable (ie composing at the level of algorithms that
> are structurally similar to WSOLA, *for example*) "very slow" then it
> biases against that kind of composition.
>

Sure. it's a statement of a fairly obvious principle, universally 
applicable. A bicycle is slower than a car, but is faster than walking. 
A plane is faster than all of them but costs a lot more. To go 100 yards 
to the local shop, using a plane really isn't the best option, however 
powerful it is. But this is not any more about the language, it is about 
the hardware. I have a process (sliding pvoc) that is ~horribly~ slow on 
conventional hardware; nobody would sanely give it the time of day. But 
on the right hardware, with a matching implementation, it runs easily in 
real time.  And if a process is unique and powerful enough, people will 
wait. I still remember leaving a pvoc process to run overnight on an 
8MHz Atari ST in the hope that the 5-second result was worth the wait. 
The code was already as efficient as it could be - that wasn't the issue.


..
>
> And here we have another problem... no longer is everything possible in
> the language and culture.. we have to turn to "the right person" to
> spend "just a week" to do something that should be possible to create
> *in the language*


All I mean by "the right person" is "someone who already understands 
WSOLA", perhaps because they have already implemented it in other 
contexts. One could be forgiven for thinking that the mere posssion of 
this uber-language makes everything "possible". The only things that are 
ever possible are the things at least one person knows how to do, and is 
ready to share the knowledge. Owning a scalpel does not make me a surgeon!

All modesty aside - I implemented the streaming pvoc opcodes in Csound, 
complete with new "fsig" signal type, pretty quickly (IMO), because I 
had already done the work in other contexts (variously in both C and 
C++). Any number of other people might have thought of it, but I was at 
least one of the "right people" to do it as I had prior experience of 
the same thing and so, crucially, knew it was possible and how to do it. 
Similarly, I knew Csound well enough to know it was possible to define a 
new signal type and integrate it into the language in such a way as to 
make it as easy as possible for people to use - not least because the 
mechanism for defining signal types was already there. Under the hood, 
Csound is really very object-oriented. many lanmguages set efficienty so 
high that they exclude things that may be useful. Not so many years ago 
(indeed it was around the time I did the streaming pvoc opcodes) 
someone did try to convert Csound into an all-modern OOP C++based 
language using all the tricks of templates et al, eliminating stuff 
thought to be unimportant or a drag on performance, and ultra-optimising 
the audio; but in such a way that it would have been impossible for me 
to add the new signal types. Efficiency is important, but not the only 
criterion.

..
> It was just an example of normal algorithm that we both know. My point
> being that as a composer one might want to code an algorithm *at any
> level of the temporal abstraction chain from single sample to
> multi-minute form*, and the language should support that.
>

This is essentially where we differ, it seems to me. You speak in terms 
of "the language", which I might rewrite as "The Language"; I speak in 
terms of "there are many languages each with its particular balance of 
functionality, ease of use and scope".

..
>
> 2) at the lower level, one may want to "go down to the sample level"
> which you find to be something not particularly relevant.


Not true! There many ways of doing it. People are doing it in Csound all 
the time. Don't base your criticism on how Csound was like 20 years ago!

Clearly we
> disagree here. Perhaps an analog will help: one may like to "prepare the
> piano." With a piano, it is arguably easier to prepare it than to play
> it normally, with CSound you have to go and learn C to "prepare" it.
>

And The Language you have in mind will not also need to be learned?


..
> You are equating an arbitrary language-imposed separation (Csound/C++)
> with a hardware-imposed separation (CPU/GPU). This is not a reasonable
> comparison and does not support your argument.
>


The comparison is reasonable because it is an example of delegation - we 
delegate some part of the work to a specialised system. Composers use 
Csound becasue they in effect delegate the design of processes to the 
opcodes, so they can concentrate on what is most important to them. If 
you use C++ you (I assume) do exactly the same delegating stuff to the 
Standard Library. In years to come, composer will not be writing 
algorithms, they will be using Intelligent Agents to write them for 
them. And the CPU/GPU separation is also arbitrary - there are many 
possible ways to combine heterogeneous hardware components, and we have 
no reason to suppose the current paradigm is in any way optimal. Already 
we are seeing dedicated parallel FIR blocks in silicon in DSP chips, and 
of course multiple devices on a single die.

>
...
>> to use all available languages for what they
>> are most optimised to do.
>
> In general terms, perhaps. However, you seem to be using this as an
> argument for maintenance of the status quo in the definition of what
> consititues the correct structure for a musical DSL.
>

Not at all. I do not pitch things as high as you do. All I say is that 
it offers "a" structure for a musical DSL. In its own terms, it works, 
and works for more than a handful of people. There are many other 
languages and systems, which we all know about. People choose the one 
(or more) that suits or appeals to them the most. Csound is a particular 
thing, which "does exactly what it says on the tin".  There are no moral 
imperatives here; but that for me includes not calling Csound 'fatally 
flawed" for not being something it is not trying to be.



> Sometimes it is desirable not to have to switch languages. My contention
> is that the whole structure of CSound (and related unit generator type
> approaches, whether implemented in whatever language or environment)
> draw the lines in the wrong places.
>

The classic moral imperative is to translate "it is wrong for me" into 
"it is wrong for everyone". We see it every day in politics and 
religion. To some C++ is the world; to others it is a monster to be 
fought. There is a philosophical case to discuss, sure, and new ideas 
and paradigms for design are always to be welcomed, but the world will 
never arise in which one super-language (or one super-computer come to 
that) does everything. Apart from anything else, life would be far too dull.


Richard Doson


From richarddobson at blueyonder.co.uk  Mon Feb 27 17:42:50 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Mon, 27 Feb 2012 22:42:50 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP3X3ncC7PsTJjzqfrWAxt4cZqRc7nVqdnSGFxem-wqavA@mail.gmail.com>
References: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>	<4F4A1877.9050906@audiomulch.com>	<4F4A5770.5030103@blueyonder.co.uk>	<20120226165842.GA27368@sapphire.lan>	<4F4BE917.6050107@audiomulch.com>	<4F4BEEDA.7000602@blueyonder.co.uk>
	<CAFswGP3X3ncC7PsTJjzqfrWAxt4cZqRc7nVqdnSGFxem-wqavA@mail.gmail.com>
Message-ID: <4F4C06EA.3020909@blueyonder.co.uk>

On 27/02/2012 22:05, Michael Gogins wrote:
..
>
> The actual blocks of audio samples will probably still be there... but
> it would be nice if one didn't have to think about them.
>
> Come to think of it, what with a-rate and k-rate variables in Csound
> orchestra language, WE don't have to think about them -- much.
>
  Quite. We don't have to think about them at all, except for the times 
when we do!

Richard Dobson

From Victor.Lazzarini at nuim.ie  Mon Feb 27 18:03:40 2012
From: Victor.Lazzarini at nuim.ie (Victor)
Date: Mon, 27 Feb 2012 23:03:40 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4C06EA.3020909@blueyonder.co.uk>
References: <CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com> <4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com> <4F4A5770.5030103@blueyonder.co.uk>
	<20120226165842.GA27368@sapphire.lan> <4F4BE917.6050107@audiomulch.com>
	<4F4BEEDA.7000602@blueyonder.co.uk>
	<CAFswGP3X3ncC7PsTJjzqfrWAxt4cZqRc7nVqdnSGFxem-wqavA@mail.gmail.com>
	<4F4C06EA.3020909@blueyonder.co.uk>
Message-ID: <051BE164-CB9E-48E5-BBCE-A484AD6BF016@nuim.ie>

and with the same k and a variables we can still think about each sample of the signal, if we need to.



On 27 Feb 2012, at 22:42, Richard Dobson <richarddobson at blueyonder.co.uk> wrote:

> On 27/02/2012 22:05, Michael Gogins wrote:
> ..
>> 
>> The actual blocks of audio samples will probably still be there... but
>> it would be nice if one didn't have to think about them.
>> 
>> Come to think of it, what with a-rate and k-rate variables in Csound
>> orchestra language, WE don't have to think about them -- much.
>> 
> Quite. We don't have to think about them at all, except for the times when we do!
> 
> Richard Dobson
> --
> 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 risto.holopainen at imv.uio.no  Mon Feb 27 18:11:53 2012
From: risto.holopainen at imv.uio.no (Risto Holopainen)
Date: Tue, 28 Feb 2012 00:11:53 +0100
Subject: [music-dsp] a little about myself
In-Reply-To: <EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com> <4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com> <4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
Message-ID: <1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>


I must say I'm happy to have learnt the rudiments of Csound in 1996 and
not today. The problem is not so much its shortcomings (I partly agree
with Ross on them) but its "longcoming" list of opcodes and ever-expanding
list of new features. Searching the manual for the correct name for a
one-pole filter and whatnot becomes a distraction. But I still find it
excellent for throwing together a custom effect and sometimes for
algorithmic composition. At least in cases when I'm too lazy or too
ignorant to do it in C++.

> Csound is an evolving language, still after more than 25 years, and there
> are many features you might not be aware of. The recently-introduced new
> parser has opened up a bunch of new possibilities, including that of new
> languages to control the engine.
>
> We are in active discussion regarding the development of Csound 6, which
> will include more new features and possibilities. The community has been
> very active and engaged in telling us what they would like to see there.
>
> Victor

Looking forward to the new version, nevertheless!


Risto
[ != computer musician by the strictest of standards]




From Victor.Lazzarini at nuim.ie  Mon Feb 27 18:27:49 2012
From: Victor.Lazzarini at nuim.ie (Victor)
Date: Mon, 27 Feb 2012 23:27:49 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com> <4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com> <4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
Message-ID: <B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>

yes, I guess this is a side effect of backwards compatibility, which has been the only absolute in development of Csound (it still runs even Music11 compositions). However, it can be improved with better formatting of documentation. While it can be off-putting, it has been a clear decision by the community not to break with this principle. No matter how good a system is, in my view, it is not worth much without a user community.

Victor

On 27 Feb 2012, at 23:11, Risto Holopainen <risto.holopainen at imv.uio.no> wrote:

> 
> I must say I'm happy to have learnt the rudiments of Csound in 1996 and
> not today. The problem is not so much its shortcomings (I partly agree
> with Ross on them) but its "longcoming" list of opcodes and ever-expanding
> list of new features. Searching the manual for the correct name for a
> one-pole filter and whatnot becomes a distraction. But I still find it
> excellent for throwing together a custom effect and sometimes for
> algorithmic composition. At least in cases when I'm too lazy or too
> ignorant to do it in C++.
> 
>> Csound is an evolving language, still after more than 25 years, and there
>> are many features you might not be aware of. The recently-introduced new
>> parser has opened up a bunch of new possibilities, including that of new
>> languages to control the engine.
>> 
>> We are in active discussion regarding the development of Csound 6, which
>> will include more new features and possibilities. The community has been
>> very active and engaged in telling us what they would like to see there.
>> 
>> Victor
> 
> Looking forward to the new version, nevertheless!
> 
> 
> Risto
> [ != computer musician by the strictest of standards]
> 
> 
> 
> --
> 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 theover at tiscali.nl  Mon Feb 27 19:06:55 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Tue, 28 Feb 2012 01:06:55 +0100
Subject: [music-dsp] music-dsp Digest, Vol 98, Issue 102
In-Reply-To: <mailman.1381.1330384321.148.music-dsp@music.columbia.edu>
References: <mailman.1381.1330384321.148.music-dsp@music.columbia.edu>
Message-ID: <4F4C1A9F.1040301@tiscali.nl>



 > Timing can be very accurately set (sub millisecond now I think) with 
a [metro]
 > and all calculations work for message filtering, but yes, strictly 
you are right,
 > the notion of message "samplerate" is meaningless in Pd.

Some ideas: it is also of importance to be able to abstract from samples 
in ways useful for musicians and sonologists and such. I mean, making a 
one 440 or 441 herz in 44.1 sample rate is the difference between say a 
99 sample long "sample" or wave or whatever, and a 100 long "thing". If 
you want to be even more accurate, like in a symphony or some instrument 
going through a reverb, you may have to consider up to a significant 
part of a second to get a good idea of the actual pitch.

For the higher frequencies it is even harder: the less samples per 
"sample"or wave, the harder it is to set or estimate the exact pitch. 
And remember, to upsample or determine values between samples, or, even 
worse, integrals of the signal like in filters or for creating control 
signals from (like compressor side chains), the only correct way is to 
use a sinc function with a considerable window at least.

On another note, the idea of the progression of sinals through blocks, 
or the definition of an algorithm using connected blocks with wires in 
between easily borders on a serious EE PhD subject for sure, I'm affraid 
a master and certainly bachelor level in EE will not do to understand 
the theories behind this and the various loopholes and subtleties, and 
on the other hand the possibilities (like serious multi path integral 
computations probably very useful in reverberation, too).

In short: using many bits and good signal and control sample path is a 
good idea, of course, but even 96kz sample frequency and similar control 
rate frequency is going to give you sampling issues and problems in no 
time for even the simplest example of a sweeped note, determining a 
decent derivative with some accuracy limiting frequency modulation 
bandwidth, or computing a decent sampled version of a signal made by 
applying well dosed and timed vibrato to a 1kHz pure sine wave, or a 
theremin simulation.

So a lot of te things I've read from petri nets in audio scheduling to 
considering language constructs versus graphical signal block schedules 
are subjects I have (albeit in graphics) seen more than a few PhD 
presentation about (of course regularly a rather boring event often for 
EEs, with exceptions), and honestly, the whole discussion cannot begin 
to touch most of the real subjects, like I've just outlined again, and 
will therefore remain at the level of gadgets, some tools and some 
bigotting about in the area of compilation and what that according to 
some people should mean for music. Not wihtout result or interesting 
considerations, but absolutely nothing new or interesting in the very 
intelligent field of compiler building, scientific computing, 
synthesizer or effect design, or even terribly interesting in terms of 
novel user interfaces or state-progression machinery for music purposes, 
even though in all those fields a serious university (or other people) 
progress is completely possible IMO.

Theo V.


From michael.gogins at gmail.com  Mon Feb 27 19:43:17 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Mon, 27 Feb 2012 19:43:17 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
Message-ID: <CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>

This has become a somewhat interesting and relevant discussion, in
that we are preparing to rewrite the internals of Csound to at least
some extent.

I have been using Csound since the late 1980s, I have contributed a
number of features and opcodes to Csound, and I have influenced the
current design of Csound. I have also made attempts to learn and use
other programmable synthesizers, starting with analog electronic
modular synthesizers, and cmix (now RTcmix), Pure Data, and Reaktor. I
have also created working prototypes of software synthesizers of my
own design.

I do algorithmic composition almost exclusively. I have designed a few
Csound instruments from scratch, but more often adapt other peoples'.

What I'm looking for is simple. I want sit down, write code quickly,
hear it right away, figure out how to make it better fast, and do this
over and over as quickly as possible. And I need to be able to express
any musical or acoustical concept or image in code. General purpose
languages are better than domain specific languages for this.

The reason I use Csound after all these years is then, obviously, not
because I haven't learned other systems or approaches, it is because
it facilities the workflow I have described best of all. Your mileage,
style, and taste may vary. I would really prefer to do everything in
one, widely used, efficient, standard language such as C++. I would
use Java or Lisp or whatever if thought they would do the job. But the
fact of the matter is that I have been able to get more done with
Csound, facilitated by other languages such as Python or Lua for which
I have created the wrappers. And I am now trying to see how the
workflow goes if I do my composing in straight C++ with Csound
embedded as an engine.

To a considerable extent this musical productivity I am able to
express with Csound is due to its having been around a long time and
having grown with a community of composers, musicians, and programmers
who have created something like a tradition within which I find it
easier to make music. As with the adapted Csound instruments,
definitely. Certainly a major reason why I have not proposed my own
design for a software synthesizer is I recognize the titanic amount of
work required to get the functionality, the opcode set, and so on up
to the level of Csound or any other widely used programmable
synthesizer.

But it is also because, for all its flaws, the Csound orchestra
language concisely and relatively clearly expresses what is going on
in the sound synthesis.

What I would dearly love to hear in this discussion is how Csound can
be improved to facilitate the creation of music, from people who do
use software to compose and create their music. Or how some other
software might be better, for that matter.

On Mon, Feb 27, 2012 at 6:27 PM, Victor <Victor.Lazzarini at nuim.ie> wrote:
> yes, I guess this is a side effect of backwards compatibility, which has been the only absolute in development of Csound (it still runs even Music11 compositions). However, it can be improved with better formatting of documentation. While it can be off-putting, it has been a clear decision by the community not to break with this principle. No matter how good a system is, in my view, it is not worth much without a user community.
>
> Victor
>
> On 27 Feb 2012, at 23:11, Risto Holopainen <risto.holopainen at imv.uio.no> wrote:
>
>>
>> I must say I'm happy to have learnt the rudiments of Csound in 1996 and
>> not today. The problem is not so much its shortcomings (I partly agree
>> with Ross on them) but its "longcoming" list of opcodes and ever-expanding
>> list of new features. Searching the manual for the correct name for a
>> one-pole filter and whatnot becomes a distraction. But I still find it
>> excellent for throwing together a custom effect and sometimes for
>> algorithmic composition. At least in cases when I'm too lazy or too
>> ignorant to do it in C++.
>>
>>> Csound is an evolving language, still after more than 25 years, and there
>>> are many features you might not be aware of. The recently-introduced new
>>> parser has opened up a bunch of new possibilities, including that of new
>>> languages to control the engine.
>>>
>>> We are in active discussion regarding the development of Csound 6, which
>>> will include more new features and possibilities. The community has been
>>> very active and engaged in telling us what they would like to see there.
>>>
>>> Victor
>>
>> Looking forward to the new version, nevertheless!
>>
>>
>> Risto
>> [ != computer musician by the strictest of standards]
>>
>>
>>
>> --
>> 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  Mon Feb 27 20:06:32 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Tue, 28 Feb 2012 01:06:32 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>	<4F4A1877.9050906@audiomulch.com>	<4F4A5770.5030103@blueyonder.co.uk>	<4F4BE634.5060701@audiomulch.com>	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
Message-ID: <4F4C2898.1070706@blueyonder.co.uk>

On 28/02/2012 00:43, Michael Gogins wrote:
..
>
> What I would dearly love to hear in this discussion is how Csound can
> be improved to facilitate the creation of music, from people who do
> use software to compose and create their music. Or how some other
> software might be better, for that matter.
>


This in the end is one of the "big" questions. "music" of course is a 
super-category second only to "art", so anything sufficiently defined to 
be implementable is going to have to narrow  things down considerably. 
This is broadly how Csound has evolved - individual composers asking for 
specific things, and this or that developer saying "I can do that". I 
doubt that Csound is unique in this respect, but it must be close to the 
top. And of course with a number of "musical developers" around, one or 
other of them takes up the initiative to add some new element in the 
firm belief it is important or useful, e.g. in the creation of their 
music. Asking for something to "facilitate the creation of music" begs 
the question, as given a room with 100 people, you will get 200+ ideas 
as to what "music" is, and 400+ ideas as to what sorts of tools 
facilitate their creation. Given that, I think the number of opcodes in 
Csound can be commended for its economy!

Richard Dobson







From richarddobson at blueyonder.co.uk  Mon Feb 27 17:56:40 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Mon, 27 Feb 2012 22:56:40 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4C0080.3090909@audiomulch.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>	<4F43C0FC.1070802@blueyonder.co.uk>	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A67C5.7070306@blueyonder.co.uk>	<4F4BEEE9.2010104@audiomulch.com>	<4F4BFBD3.6020204@blueyonder.co.uk>
	<4F4C0080.3090909@audiomulch.com>
Message-ID: <4F4C0A28.5040505@blueyonder.co.uk>

On 27/02/2012 22:15, Ross Bencina wrote:
..
> On Feb 26, 2012, at 12:48 AM, Ross Bencina wrote:
>  > In my view, anyone who cares about being a composer of
>  > *computer music*
>  > (in the context of this discussion) needs at least the following (or
>  > equivalent) undergraduate knowledge:
>  >
>  > 1) music composition degree
>  > 2) computer science and/or software engineering degree
>  > 3) electrical engineering degree
>  >
>  > Maybe even this is required:
>  > 4) Tonmeister/ sound engineering degree
>

As noted elsewhere, that probably excludes almost everyone in the field. 
I would be tempted to say the top of the iceberg, except that it seems 
to be all tip and no iceberg.  My own view is that there is no such 
thing as "computer music". There is music composed one way or another 
using computers, but I suspect that is not the same. There is music 
composed algorithmically, but all using pencil, eraser, and paper. That 
is not the same thing either. We have a habit in the West of seeing the 
thing as defining the person. I prefer to approach it the other way 
around, I see what the person does, and ~if appropriate~ find a 
description for them. The simplest of all is to call them musicians; 
which is how I describe myself, because all the activities I engage in 
are related to music one way and another. It remains to be seen, of 
course, to what extent my sonifications amount to "music" - but they 
have at least been used by musicians to make music with, so that makes 
it OK.

Richard Dobson

From michael.gogins at gmail.com  Mon Feb 27 20:13:28 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Mon, 27 Feb 2012 20:13:28 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4C2898.1070706@blueyonder.co.uk>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
	<4F4C2898.1070706@blueyonder.co.uk>
Message-ID: <CAFswGP23mWdFVLhO-LfdjemoQ0HtvL2_KE5zd0X5YtGiyXZaTg@mail.gmail.com>

Well, I wanted to add my two cents to the definition of computer music, as well.

There's piano music -- you play it on a piano. There's jazz piano,
classical piano, etc., etc. There's fiddle music -- you play it on a
fiddle. There's jazz fiddle, classical fiddle, country fiddle, North
Indian fiddle, and so on.

There's computer music -- you play it on a computer. But's not like
other instruments because (a) it plays bits not sound and (b) it's
programmable. So it's one more step removed from the audience, and one
more step closer to the mind of the composer.

Many arts are being computerized and are approximating to the
condition of computer music. One more veil of illusion in front of the
audience, and one more step into the mind of the creator.

So while piano music is not a style of music, computer music has
elements of a style because of the programmability.

Regards,
Mike

On Mon, Feb 27, 2012 at 8:06 PM, Richard Dobson
<richarddobson at blueyonder.co.uk> wrote:
> On 28/02/2012 00:43, Michael Gogins wrote:
> ..
>>
>>
>> What I would dearly love to hear in this discussion is how Csound can
>> be improved to facilitate the creation of music, from people who do
>> use software to compose and create their music. Or how some other
>> software might be better, for that matter.
>>
>
>
> This in the end is one of the "big" questions. "music" of course is a
> super-category second only to "art", so anything sufficiently defined to be
> implementable is going to have to narrow ?things down considerably. This is
> broadly how Csound has evolved - individual composers asking for specific
> things, and this or that developer saying "I can do that". I doubt that
> Csound is unique in this respect, but it must be close to the top. And of
> course with a number of "musical developers" around, one or other of them
> takes up the initiative to add some new element in the firm belief it is
> important or useful, e.g. in the creation of their music. Asking for
> something to "facilitate the creation of music" begs the question, as given
> a room with 100 people, you will get 200+ ideas as to what "music" is, and
> 400+ ideas as to what sorts of tools facilitate their creation. Given that,
> I think the number of opcodes in Csound can be commended for its economy!
>
> Richard Dobson
>
>
>
>
>
>
>
> --
> 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 philburk at mobileer.com  Mon Feb 27 21:31:53 2012
From: philburk at mobileer.com (Phil Burk)
Date: Mon, 27 Feb 2012 18:31:53 -0800
Subject: [music-dsp] what is computer music, was "a little about myself"
In-Reply-To: <CAFswGP23mWdFVLhO-LfdjemoQ0HtvL2_KE5zd0X5YtGiyXZaTg@mail.gmail.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
	<4F4C2898.1070706@blueyonder.co.uk>
	<CAFswGP23mWdFVLhO-LfdjemoQ0HtvL2_KE5zd0X5YtGiyXZaTg@mail.gmail.com>
Message-ID: <4F4C3C99.6040104@mobileer.com>


On 2/27/12 5:13 PM, Michael Gogins wrote:
 > There's computer music -- you play it on a computer.

That may be too broad. It used to mean music composed by writing 
software. It often involved novel algorithmic composition and/or custom 
synthesis techniques. Computer music sounded fundamentally different 
than other types of music.

But it is complicated now because the people who write computer music 
software started sharing their tools with the public. That is a good 
thing. But then non-programmers starting calling their creations 
"computer music" just because they used a computer with a MIDI sequencer.

Perhaps we need some additional terms. How about:

"Software music" is music created by writing software in languages such 
as C++, Java, DSP assembly.

"Programmed music" is music created using specialized music languages 
such as SuperCollider, Max, Pd, CSound, Chuck.

"Computer music" refers to either "software music" or "programmed music".

Music created using computer productivity tools such as sequencers, 
sample editors, etc. can just be called "music".

Phil Burk

From garton at columbia.edu  Tue Feb 28 00:22:55 2012
From: garton at columbia.edu (Brad Garton)
Date: Tue, 28 Feb 2012 00:22:55 -0500
Subject: [music-dsp] improvements to csound
In-Reply-To: <CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com>
	<20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b67019! 29.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
Message-ID: <D9B0D12A-C3C2-48DB-8994-21AE165C3ECB@columbia.edu>

On Feb 27, 2012, at 7:43 PM, Michael Gogins wrote:

> What I would dearly love to hear in this discussion is how Csound can
> be improved to facilitate the creation of music, from people who do
> use software to compose and create their music. Or how some other
> software might be better, for that matter.

Ok, one observation (but qualified by the fact that I'm not totally up-to-date
on the latest Csound5.app):  more and more I find that documentation --
and not just a good manual, but the *integration* of the manual into
the development environment -- is a really big factor in how usable a
language can be.  SC3 does this kind-of well, and Cycling has done
a remarkable job of joining the docs into the environment.  Like most
every sentient being who codes, I have a real love/hate relationship
with Apple, but I have to confess that XCode does have some good
features for finding coding info  I'll also have to confess the RTcmix doesn't
do well on this front, although we're working to build a decent documentation
interface for our iRTcmix project.

Maybe the new csound has nice, clickable-access for the opcodes?  That
would be a great start.

brad
http://music.columbia.edu/~brad


From Victor.Lazzarini at nuim.ie  Tue Feb 28 03:11:04 2012
From: Victor.Lazzarini at nuim.ie (Victor)
Date: Tue, 28 Feb 2012 08:11:04 +0000
Subject: [music-dsp] improvements to csound
In-Reply-To: <D9B0D12A-C3C2-48DB-8994-21AE165C3ECB@columbia.edu>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>
	<298C4BE236F7481AA28B8C2B1565F6D2@ProprietairePC>
	<4F43C0FC.1070802@blueyonder.co.uk>
	<01D3F10E-36F1-4548-8505-97D82B35D2BB@nuim.ie>
	<CAML4ZX5XbB_OFDL9XSijqijsbuVWqdmNzu7XatsBGH1esbqhPA@mail.gmail.com>
	<CAFswGP325=tJ0_UQQKk+MhFTUhiV7qxpBij9GPHAZF8iKWozFg@mail.gmail.com>
	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>
	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>
	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>
	<4F474979.1090307@audiomulch.com> <20120224180547.GA19742@sapphire.lan>
	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>
	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>
	<4F49C7C0.9020702@audiomulch.com> <4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com> <4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
Message-ID: <6A1C6BB0-37BB-47A1-A8FB-A5EFC3508170@nuim.ie>

That is a good point, however it is not within the scope of Csound. In fact, there is no Csound5.app per se, but various frontends, most of them third party. So, it is something that needs to be implemented at that level.

In fact, it already exists in at least one frontend, CsoundQt, where if you place a cursor beside an opcode in the editor, you can bring its manual page. It also has autocompletion and framebar syntax hints. Their developers did not make a bad job of it, imo.


Victor
On 28 Feb 2012, at 05:22, Brad Garton <garton at columbia.edu> wrote:

> On Feb 27, 2012, at 7:43 PM, Michael Gogins wrote:
> 
>> What I would dearly love to hear in this discussion is how Csound can
>> be improved to facilitate the creation of music, from people who do
>> use software to compose and create their music. Or how some other
>> software might be better, for that matter.
> 
> Ok, one observation (but qualified by the fact that I'm not totally up-to-date
> on the latest Csound5.app):  more and more I find that documentation --
> and not just a good manual, but the *integration* of the manual into
> the development environment -- is a really big factor in how usable a
> language can be.  SC3 does this kind-of well, and Cycling has done
> a remarkable job of joining the docs into the environment.  Like most
> every sentient being who codes, I have a real love/hate relationship
> with Apple, but I have to confess that XCode does have some good
> features for finding coding info  I'll also have to confess the RTcmix doesn't
> do well on this front, although we're working to build a decent documentation
> interface for our iRTcmix project.
> 
> Maybe the new csound has nice, clickable-access for the opcodes?  That
> would be a great start.
> 
> brad
> http://music.columbia.edu/~brad
> 
> --
> 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 Feb 28 06:04:45 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Tue, 28 Feb 2012 11:04:45 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP23mWdFVLhO-LfdjemoQ0HtvL2_KE5zd0X5YtGiyXZaTg@mail.gmail.com>
References: <CAML4ZX5RJH0x+hbGrME3ZwTz3Mkv8y7_4ZSeqaEugAFxQsvxgA@mail.gmail.com>	<CAK1FW3WDgN2wxs9Csitr7i5yvs7zO56cQQ7kvvo-bCF!p-YpjzA@mail.gmail.com>	<CAFswGP0M82wGg4jQ0OTqpz2NiKF4bfbLnsJE0G6Fm0fX3U+ptQ@mail.gmail.com>	<698BB18C-A9D0-4BAD-9CEA-68BEE55F8140@columbia.edu>	<4F474979.1090307@audiomulch.com>	<20120224180547.GA19742@sapphire.lan>	<36FF0A7F-FAB6-4745-AEB4-1051DF1C96DF@optonline.net>	<CAFswGP1faboJckBbEOMhB836QH=-HLhTbDLoCd+5DeY4VJqddA@mail.gmail.com>	<4F49C7C0.9020702@audiomulch.com>	<4F4A05CD.9070505@blueyonder.co.uk>	<4F4A1877.9050906@audiomulch.com>	<4F4A5770.5030103@blueyonder.co.uk>	<4F4BE634.5060701@audiomulch.com>	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>	<4F4C2898.1070706@blueyonder.co.uk>
	<CAFswGP23mWdFVLhO-LfdjemoQ0HtvL2_KE5zd0X5YtGiyXZaTg@mail.gmail.com>
Message-ID: <4F4CB4CD.1060709@blueyonder.co.uk>

On 28/02/2012 01:13, Michael Gogins wrote:
> Well, I wanted to add my two cents to the definition of computer music, as well.
>
> There's piano music -- you play it on a piano. There's jazz piano,
> classical piano, etc., etc. There's fiddle music -- you play it on a
> fiddle. There's jazz fiddle, classical fiddle, country fiddle, North
> Indian fiddle, and so on.
>
> There's computer music -- you play it on a computer. But's not like
> other instruments because (a) it plays bits not sound and (b) it's
> programmable. So it's one more step removed from the audience, and one
> more step closer to the mind of the composer.
>

There is quite a big difference in meaning between "programmed" and 
"programmable". A computer is programmable, but in the majority of cases 
the results are just to be listened to, not, um, interfered with. 
"Programmable" refers to someone doing the programming, which is 
nominally the composer (subsumed in our definition of what a composer 
does), but not most of the time the performer or listener. The nearest 
the listener will get to "programmable music" is the shuffle option on 
their player, or the interactivity and direction-changing of a computer 
game. More rarely, the interactive reactions of a live installation, 
where the composer has not so much written a piece as designed a system. 
Otherwise they are directly interacting with the software and becoming 
either the composer or the player according to the choice of definition. 
Many have argued that the whole concept of a composer creating a piece 
which is then fixed for all time, and which represents the vision of the 
composer, is old-fashioned and even obsolete; certainly not very 
democratic. Nevertheless, a large number of composers still want to make 
music that way, and a lot of listeners still want to hear music written 
that way.

Pieces have been composed that are programmable in live performance - 
aleatoric works; the simple device of allowing the performers to decide 
the order of sections. even "In C" is in a sense programmable by the 
performers (and long ago I managed to render the opening sections using 
Forthg on a BBC model B).

Years ago, computer music did for most people mean things like the 
Illiac Suite - music generated at the note level using algorithms. 
Unfortunately, because of our severed limited vocabulary, that same term 
has expanded to include just about everything involving a computer, even 
if it is digital emulation of analogue synthesizsers  and processes, or 
anything written using a digital sequencer.  Clearly there is already an 
uncertainty between whether "computer msuic" is as you say "played on a 
computer", or "composed by a computer" or "composed using a computer" 
(which is an important distinction for Ross as we have seen), or even 
"composed using algorithms"; all further confused by the fact that the 
performance medium for all music for most people is the same - a DVD, a 
CD or the mp3 player, where the listener can choose what and when to 
play something, but not much else.

There is a conception of "computer music" as being something like 
hypertext as distinct from a fixed book; it is  a system created by 
someone, through which the "listeners" navigate more or less freely (not 
every note is a hyperlink!); and at a lower level there is the concept 
of an automata, which has perhaps more compositional input but is still 
predicated on user/listener interaction. This might include the 
"generative music' works of Brian Eno, including "Bloom". It rather begs 
the question however as to whether the user can really be said to be 
"programming" it.

So, one way and another, "Computer music" is so laden with definitions 
and qualifications as to have lost all definition - using it gives the 
listener no real information.

Richard Dobson



From renato.fabbri at gmail.com  Tue Feb 28 07:13:50 2012
From: renato.fabbri at gmail.com (Renato Fabbri)
Date: Tue, 28 Feb 2012 09:13:50 -0300
Subject: [music-dsp] very cheap synthesis techniques
Message-ID: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>

Lookup table in python code:

######### Lookup table ############
def lookup(table, dur, freq):
    """X Hz Y segundos ---- Y*44100 amostras X senoides
    X*T*n.arange(Y*44100)/(Y*44100)"""

    T=len(table)
    SI= freq * T / samprate
    ap=0
    samples=[]
    for i in xrange(int(dur*samprate)): # n_de_amostras = dur * ramprate
	samples.append(table[int(ap)])
	ap = (SI + ap)%T
    return samples

any more favourites? :-)

btw: http://wiki.nosdigitais.teia.org.br/FIGGUS http://paste.org/45689


-- 
GNU/Linux User #479299
labmacambira.sf.net

From stefan.hallen at gmail.com  Tue Feb 28 07:51:04 2012
From: stefan.hallen at gmail.com (=?ISO-8859-1?Q?Stefan_H=E5ll=E9n?=)
Date: Tue, 28 Feb 2012 13:51:04 +0100
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
Message-ID: <CAEn3FUtubcF=YbFb-Akz5Nfy729edmf_+nfr9nLg7O0emE1VSA@mail.gmail.com>

Well, this is a favorite :)

http://www.youtube.com/watch?v=tCRPUv8V22o#t=5m14s

2012/2/28 Renato Fabbri <renato.fabbri at gmail.com>
>
> Lookup table in python code:
>
> ######### Lookup table ############
> def lookup(table, dur, freq):
> ? ?"""X Hz Y segundos ---- Y*44100 amostras X senoides
> ? ?X*T*n.arange(Y*44100)/(Y*44100)"""
>
> ? ?T=len(table)
> ? ?SI= freq * T / samprate
> ? ?ap=0
> ? ?samples=[]
> ? ?for i in xrange(int(dur*samprate)): # n_de_amostras = dur * ramprate
> ? ? ? ?samples.append(table[int(ap)])
> ? ? ? ?ap = (SI + ap)%T
> ? ?return samples
>
> any more favourites? :-)
>
> btw: http://wiki.nosdigitais.teia.org.br/FIGGUS http://paste.org/45689
>
>
> --
> GNU/Linux User #479299
> labmacambira.sf.net
> --
> 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 Feb 28 08:01:51 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Tue, 28 Feb 2012 13:01:51 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4C2898.1070706@blueyonder.co.uk>
References: <4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk>
	<4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
	<4F4C2898.1070706@blueyonder.co.uk>
Message-ID: <20120228130151.GA22843@sapphire.lan>

> On 28/02/2012 00:43, Michael Gogins wrote:
> ..
> >
> >What I would dearly love to hear in this discussion is how Csound can
> >be improved to facilitate the creation of music, from people who do
> >use software to compose and create their music. Or how some other
> >software might be better, for that matter.


For the beginner and experienced user alike, a rough spot in Csound is
resource management. Perhaps because Csound comes from an offline
lineage and was not conceived as a real-time system it's very easy
to create monsterous things. Things that unexpectedly use all the CPU
and drop out. Things that unexpectedly eat memory very fast.

Of course, to paraphrase Stroustrup,  you can shoot yourself in the foot
with all audio DSP languages, but with Csound you absolutely
positively kill every last mo_______ker in the room.

Better polyphony and CPU monitoring/management, with some kind resource
limited subprocess concept would make it much safer.

Just 2c



From padawan12 at obiwannabe.co.uk  Tue Feb 28 08:05:46 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Tue, 28 Feb 2012 13:05:46 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4CB4CD.1060709@blueyonder.co.uk>
References: <4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
	<4F4C2898.1070706@blueyonder.co.uk>
	<CAFswGP23mWdFVLhO-LfdjemoQ0HtvL2_KE5zd0X5YtGiyXZaTg@mail.gmail.com>
	<4F4CB4CD.1060709@blueyonder.co.uk>
Message-ID: <20120228130546.GB22843@sapphire.lan>

On Tue, Feb 28, 2012 at 11:04:45AM +0000, Richard Dobson wrote:

> So, one way and another, "Computer music" is so laden with
> definitions and qualifications as to have lost all definition -
> using it gives the listener no real information.

And yet, if I were to say to you about such and such a piece
of music "Oh, it's computer music", you would know exactly what
I mean, and what to expect.

It has a certain cultural centroid, a locus amongst groups
of people, historical events, practices, icons. There are
certain expectations of form, performance, milieu.

You will sit in a room with a high quality sound system of
no less than four loudspeakers, many of the audience will sport
impressive beards, and you will nod your head through excruciating
expanses of silence and high frequency buzzing. At times you
will feel quite dizzy. And mistake your own tinnitus for the finale.
At the end there will be a presentation of some quite opaque equations,
and afterwards cheese, wine and cordial conversation as we
roam Paris or Vienna devouring haute cuisine paid for by some 
impossibly selective European grant money, and all reminisce over 
VCS3s and our first homebuild oscillators using germainium transistors 
and bitch about how crap everything digital really is.

That's computer music.


From jpff at cs.bath.ac.uk  Tue Feb 28 08:21:05 2012
From: jpff at cs.bath.ac.uk (jpff at cs.bath.ac.uk)
Date: Tue, 28 Feb 2012 13:21:05 -0000
Subject: [music-dsp] a little about myself
In-Reply-To: <20120228130151.GA22843@sapphire.lan>
References: <4F49C7C0.9020702@audiomulch.com>
	<4F4A05CD.9070505@blueyonder.co.uk> <4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk> <4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
	<4F4C2898.1070706@blueyonder.co.uk>
	<20120228130151.GA22843@sapphire.lan>
Message-ID: <00c81bcd35d5518a8140e61a13aa2069.squirrel@www.cs.bath.ac.uk>


>
> For the beginner and experienced user alike, a rough spot in Csound is
> resource management. Perhaps because Csound comes from an offline
> lineage and was not conceived as a real-time system it's very easy
> to create monsterous things. Things that unexpectedly use all the CPU
> and drop out. Things that unexpectedly eat memory very fast.
>
> Of course, to paraphrase Stroustrup,  you can shoot yourself in the foot
> with all audio DSP languages, but with Csound you absolutely
> positively kill every last mo_______ker in the room.
>
> Better polyphony and CPU monitoring/management, with some kind resource
> limited subprocess concept would make it much safer.
>

cpumeter ? Reports the usage of cpu either total or per core.

maxalloc ? Limits the number of allocations of an instrument.

prealloc ? Creates space for instruments but does not run them.

clockon ? Starts one of a number of internal clocks.
clockoff ? Stops one of a number of internal clocks.
readclock ? Reads the value of an internal clock.

If you have clear suggestions as what you want/need let us know and we
will investigate -- just like all suggestions.




From richarddobson at blueyonder.co.uk  Tue Feb 28 08:24:18 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Tue, 28 Feb 2012 13:24:18 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <20120228130546.GB22843@sapphire.lan>
References: <4F4A1877.9050906@audiomulch.com>	<4F4A5770.5030103@blueyonder.co.uk>	<4F4BE634.5060701@audiomulch.com>	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>	<4F4C2898.1070706@blueyonder.co.uk>	<CAFswGP23mWdFVLhO-LfdjemoQ0HtvL2_KE5zd0X5YtGiyXZaTg@mail.gmail.com>	<4F4CB4CD.1060709@blueyonder.co.uk>
	<20120228130546.GB22843@sapphire.lan>
Message-ID: <4F4CD582.8000308@blueyonder.co.uk>

On 28/02/2012 13:05, Andy Farnell wrote:
> On Tue, Feb 28, 2012 at 11:04:45AM +0000, Richard Dobson wrote:
>
>> So, one way and another, "Computer music" is so laden with
>> definitions and qualifications as to have lost all definition -
>> using it gives the listener no real information.
>
> And yet, if I were to say to you about such and such a piece
> of music "Oh, it's computer music", you would know exactly what
> I mean, and what to expect.
>

Er...

> You will sit in a room with a high quality sound system of
> no less than four loudspeakers, many of the audience will sport
> impressive beards,

Actually, I see more pony-tails these days (mine is getting somewhat thin).


  and you will nod your head through excruciating
> expanses of silence and high frequency buzzing.


Sounds like some night-clubs I used to go to.

At times you
> will feel quite dizzy. And mistake your own tinnitus for the finale.


Done that. Most recently, the performance faded out to the 
air-conditioning noise, which (not having particularly noticed it 
previously) I was convinced was the piece still fading away. The very 
illustrious composer had to stand up and say "that's it".

> At the end there will be a presentation of some quite opaque equations,
> and afterwards cheese, wine and cordial conversation as we
> roam Paris or Vienna devouring haute cuisine paid for by some
> impossibly selective European grant money,


If only!

..
> That's computer music.
>


Richard Dobson

From padawan12 at obiwannabe.co.uk  Tue Feb 28 08:37:18 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Tue, 28 Feb 2012 13:37:18 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <00c81bcd35d5518a8140e61a13aa2069.squirrel@www.cs.bath.ac.uk>
References: <4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
	<4F4C2898.1070706@blueyonder.co.uk>
	<20120228130151.GA22843@sapphire.lan>
	<00c81bcd35d5518a8140e61a13aa2069.squirrel@www.cs.bath.ac.uk>
Message-ID: <20120228133718.GA22931@sapphire.lan>




Thanks John,

These are all very useful. Some of them, the last three, I have
used before to create timeouts, The others I should pay more
attention to.

Apparently not covered by these: 

I would like a mechanism, not sure whether this would be an opcode or
a general (global) language feature, that would keep track 
of how many instances of an instrument are allocated, so if one were
to call that numalloc


kcelloVoicesPlaying numalloc cello1

would give me an integer in kcelloVoicesPlaying

This is necseaary when you are using dynamic runtime
composition using scoreline and suchlike.

best

Andy


On Tue, Feb 28, 2012 at 01:21:05PM -0000, jpff at cs.bath.ac.uk wrote:
> 
> >
> > For the beginner and experienced user alike, a rough spot in Csound is
> > resource management. Perhaps because Csound comes from an offline
> > lineage and was not conceived as a real-time system it's very easy
> > to create monsterous things. Things that unexpectedly use all the CPU
> > and drop out. Things that unexpectedly eat memory very fast.
> >
> > Of course, to paraphrase Stroustrup,  you can shoot yourself in the foot
> > with all audio DSP languages, but with Csound you absolutely
> > positively kill every last mo_______ker in the room.
> >
> > Better polyphony and CPU monitoring/management, with some kind resource
> > limited subprocess concept would make it much safer.
> >
> 
> cpumeter ? Reports the usage of cpu either total or per core.
> 
> maxalloc ? Limits the number of allocations of an instrument.
> 
> prealloc ? Creates space for instruments but does not run them.
> 
> clockon ? Starts one of a number of internal clocks.
> clockoff ? Stops one of a number of internal clocks.
> readclock ? Reads the value of an internal clock.
> 
> If you have clear suggestions as what you want/need let us know and we
> will investigate -- just like all suggestions.
> 
> 
> 
> --
> 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 mcbinc at panix.com  Tue Feb 28 09:23:15 2012
From: mcbinc at panix.com (m brandenberg)
Date: Tue, 28 Feb 2012 09:23:15 -0500 (EST)
Subject: [music-dsp] a little about myself
In-Reply-To: <20120228130546.GB22843@sapphire.lan>
References: <4F4A1877.9050906@audiomulch.com>
	<4F4A5770.5030103@blueyonder.co.uk>
	<4F4BE634.5060701@audiomulch.com>
	<EA7B4FBD-0D45-432D-BF82-4EDF09EC2712@nuim.ie>
	<1204047f0601718524f87717b6701929.squirrel@webmail.uio.no>
	<B4413F77-3675-4853-ACE9-391584AE3E8A@nuim.ie>
	<CAFswGP060bF=qNvp5OGdcv0xZqjT0K6dS2Xte9F3JS8pRwEy3w@mail.gmail.com>
	<4F4C2898.1070706@blueyonder.co.uk>
	<CAFswGP23mWdFVLhO-LfdjemoQ0HtvL2_KE5zd0X5YtGiyXZaTg@mail.gmail.com>
	<4F4CB4CD.1060709@blueyonder.co.uk>
	<20120228130546.GB22843@sapphire.lan>
Message-ID: <Pine.NEB.4.64.1202280922320.26121@panix2.panix.com>

On Tue, 28 Feb 2012, Andy Farnell wrote:

> And mistake your own tinnitus for the finale.

Bwahaha!  I went to that concert.  :-)

--
Monty Brandenberg

From bil at ccrma.Stanford.EDU  Tue Feb 28 11:03:52 2012
From: bil at ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Tue, 28 Feb 2012 08:03:52 -0800
Subject: [music-dsp] a little about myself
Message-ID: <20120228155721.M59034@ccrma.Stanford.EDU>

I don't think this conversation is useful.  The only question I'd
ask is "did this person make good music?", and I don't care at all about
his degrees or grants.  One of the best mathematicians I've known 
does not even have a high-school diploma.  If I find such a person,
then it's interesting to ask how she did it.  But there are very few,
and no generalizations seem to come to mind.


From michael.gogins at gmail.com  Tue Feb 28 11:24:36 2012
From: michael.gogins at gmail.com (Michael Gogins)
Date: Tue, 28 Feb 2012 11:24:36 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <20120228155721.M59034@ccrma.Stanford.EDU>
References: <20120228155721.M59034@ccrma.Stanford.EDU>
Message-ID: <CAFswGP3qmFQP6LSVJRRsAjtLcUF2VcNcv3upRYK-OaWdzmkv+A@mail.gmail.com>

On the one hand, I completely agree with Bill, I'm only interested in
whether the music is good, and no, I don't think it's completely
subjective.

On the other hand, I do think there are many things it would be
advisable for a person who wants to write good music to know.

For someone who wants to write good computer music, what would be
useful to know is... bewildering and hard to define! But some
understanding of how good software is written, some understanding of
signal processing, some understanding of musical acoustics and
psychological acoustics, some understanding of music history and
theory, some understanding of musical form, and above all a deep,
personal immersion in music itself... deep listening.

On Tue, Feb 28, 2012 at 11:03 AM, Bill Schottstaedt
<bil at ccrma.stanford.edu> wrote:
> I don't think this conversation is useful. ?The only question I'd
> ask is "did this person make good music?", and I don't care at all about
> his degrees or grants. ?One of the best mathematicians I've known
> does not even have a high-school diploma. ?If I find such a person,
> then it's interesting to ask how she did it. ?But there are very few,
> and no generalizations seem to come to mind.
>
> --
> 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 douglas at music.columbia.edu  Tue Feb 28 13:20:12 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Tue, 28 Feb 2012 13:20:12 -0500
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <CAEn3FUtubcF=YbFb-Akz5Nfy729edmf_+nfr9nLg7O0emE1VSA@mail.gmail.com>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
	<CAEn3FUtubcF=YbFb-Akz5Nfy729edmf_+nfr9nLg7O0emE1VSA@mail.gmail.com>
Message-ID: <4F4D1ADC.6090306@music.columbia.edu>


A code-free oscillator!

http://www.youtube.com/watch?v=IdckHzEY-RI


On 2/28/12 7:51 AM, Stefan H?ll?n wrote:
> Well, this is a favorite :)
>
> http://www.youtube.com/watch?v=tCRPUv8V22o#t=5m14s
>
> 2012/2/28 Renato Fabbri<renato.fabbri at gmail.com>
>>
>> Lookup table in python code:
>>
>> ######### Lookup table ############
>> def lookup(table, dur, freq):
>>     """X Hz Y segundos ---- Y*44100 amostras X senoides
>>     X*T*n.arange(Y*44100)/(Y*44100)"""
>>
>>     T=len(table)
>>     SI= freq * T / samprate
>>     ap=0
>>     samples=[]
>>     for i in xrange(int(dur*samprate)): # n_de_amostras = dur * ramprate
>>         samples.append(table[int(ap)])
>>         ap = (SI + ap)%T
>>     return samples
>>
>> any more favourites? :-)
>>
>> btw: http://wiki.nosdigitais.teia.org.br/FIGGUS http://paste.org/45689
>>
>>
>> --
>> GNU/Linux User #479299
>> labmacambira.sf.net
>> --
>> 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://artbots.org
.....douglas.....irving........................ http://dorkbot.org
.......................... http://music.columbia.edu/cmc/music-dsp
...........repetto............. http://music.columbia.edu/organism
............................... http://music.columbia.edu/~douglas


From earlevel at earlevel.com  Tue Feb 28 15:00:54 2012
From: earlevel at earlevel.com (Nigel Redmon)
Date: Tue, 28 Feb 2012 12:00:54 -0800
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <4F4D1ADC.6090306@music.columbia.edu>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
	<CAEn3FUtubcF=YbFb-Akz5Nfy729edmf_+nfr9nLg7O0emE1VSA@mail.gmail.com>
	<4F4D1ADC.6090306@music.columbia.edu>
Message-ID: <04E925B0-EC09-4CDA-96E1-ECC2E07F149B@earlevel.com>

LOL?"M squared L" (aka M^2L, after TTL, "T squared L")?Mickey Mouse Logic, first encountered in Don Lancaster's CMOS Cookbook.

I discovered the wonders of M^2L back in the 70's, when I was trying to figure out how to control my analog synth building blocks from a 6502 board. Things like getting a bunch of cheap and high-density flip-flops by wiring CMOS buffer outputs to their own inputs (perhaps through a resistor, but it depends on your Mickey Mouse level :-)...


On Feb 28, 2012, at 10:20 AM, douglas repetto wrote:

> 
> A code-free oscillator!
> 
> http://www.youtube.com/watch?v=IdckHzEY-RI
> 
> ............................................... http://artbots.org
> .....douglas.....irving........................ http://dorkbot.org
> .......................... http://music.columbia.edu/cmc/music-dsp
> ...........repetto............. http://music.columbia.edu/organism
> ............................... http://music.columbia.edu/~douglas


From douglas at music.columbia.edu  Tue Feb 28 15:10:38 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Tue, 28 Feb 2012 15:10:38 -0500
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <04E925B0-EC09-4CDA-96E1-ECC2E07F149B@earlevel.com>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
	<CAEn3FUtubcF=YbFb-Akz5Nfy729edmf_+nfr9nLg7O0emE1VSA@mail.gmail.com>
	<4F4D1ADC.6090306@music.columbia.edu>
	<04E925B0-EC09-4CDA-96E1-ECC2E07F149B@earlevel.com>
Message-ID: <4F4D34BE.6090803@music.columbia.edu>


It's pretty amazing how much nice nasty noise you can get out of a few
logic ICs and some diodes for weird non-linear mixing effects!

This crackly sound is just four inverter-based, light-sensitive 
oscillators being diode-mixed into crunchy goodness:

http://music.columbia.edu/~douglas/portfolio/quad_light_victrola/

!

douglas



On 2/28/12 3:00 PM, Nigel Redmon wrote:
> LOL?"M squared L" (aka M^2L, after TTL, "T squared L")?Mickey Mouse
> Logic, first encountered in Don Lancaster's CMOS Cookbook.
>
> I discovered the wonders of M^2L back in the 70's, when I was trying
> to figure out how to control my analog synth building blocks from a
> 6502 board. Things like getting a bunch of cheap and high-density
> flip-flops by wiring CMOS buffer outputs to their own inputs (perhaps
> through a resistor, but it depends on your Mickey Mouse level :-)...
>
>
> On Feb 28, 2012, at 10:20 AM, douglas repetto wrote:
>
>>
>> A code-free oscillator!
>>
>> http://www.youtube.com/watch?v=IdckHzEY-RI
>>
>> ............................................... http://artbots.org
>> .....douglas.....irving........................ http://dorkbot.org
>> .......................... http://music.columbia.edu/cmc/music-dsp
>> ...........repetto............. http://music.columbia.edu/organism
>> ............................... http://music.columbia.edu/~douglas
>
> -- 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://music.columbia.edu/~douglas


From adotsdothmusic at gmail.com  Tue Feb 28 15:16:14 2012
From: adotsdothmusic at gmail.com (Adam Puckett)
Date: Tue, 28 Feb 2012 15:16:14 -0500
Subject: [music-dsp] a little about myself
In-Reply-To: <CAFswGP3qmFQP6LSVJRRsAjtLcUF2VcNcv3upRYK-OaWdzmkv+A@mail.gmail.com>
References: <20120228155721.M59034@ccrma.Stanford.EDU>
	<CAFswGP3qmFQP6LSVJRRsAjtLcUF2VcNcv3upRYK-OaWdzmkv+A@mail.gmail.com>
Message-ID: <CAK1FW3XZeWS-Wyr7wp0kLEgdbBTVVG4QAFPYphfCL4XRqX_d-A@mail.gmail.com>

Andy,

there's an opcode called active that does what you want 'numalloc' to do:

http://csounds.com/manual/html/active.html

On 2/28/12, Michael Gogins <michael.gogins at gmail.com> wrote:
> On the one hand, I completely agree with Bill, I'm only interested in
> whether the music is good, and no, I don't think it's completely
> subjective.
>
> On the other hand, I do think there are many things it would be
> advisable for a person who wants to write good music to know.
>
> For someone who wants to write good computer music, what would be
> useful to know is... bewildering and hard to define! But some
> understanding of how good software is written, some understanding of
> signal processing, some understanding of musical acoustics and
> psychological acoustics, some understanding of music history and
> theory, some understanding of musical form, and above all a deep,
> personal immersion in music itself... deep listening.
>
> On Tue, Feb 28, 2012 at 11:03 AM, Bill Schottstaedt
> <bil at ccrma.stanford.edu> wrote:
>> I don't think this conversation is useful. ?The only question I'd
>> ask is "did this person make good music?", and I don't care at all about
>> his degrees or grants. ?One of the best mathematicians I've known
>> does not even have a high-school diploma. ?If I find such a person,
>> then it's interesting to ask how she did it. ?But there are very few,
>> and no generalizations seem to come to mind.
>>
>> --
>> 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
> --
> 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 Feb 28 15:26:03 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Tue, 28 Feb 2012 20:26:03 +0000
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <04E925B0-EC09-4CDA-96E1-ECC2E07F149B@earlevel.com>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
	<CAEn3FUtubcF=YbFb-Akz5Nfy729edmf_+nfr9nLg7O0emE1VSA@mail.gmail.com>
	<4F4D1ADC.6090306@music.columbia.edu>
	<04E925B0-EC09-4CDA-96E1-ECC2E07F149B@earlevel.com>
Message-ID: <20120228202603.GA3747@sapphire.lan>

On Tue, Feb 28, 2012 at 12:00:54PM -0800, Nigel Redmon wrote:

> wiring CMOS buffer outputs to their own inputs (perhaps through a resistor

Using inverter gates is an old trick for making very cheap 
oscillators. With some cells arranged to give you 6v and a 
bit of wire attached to the output pin it will immediately 
start running at a few hundred megahertz, and work as a short 
lived tracking bug to stick to anything you want to be a beacon 
with loads of nasty harmonics that show up all over the dial.

Putting a capacitor and resistor makes it a more controllable
relaxation oscillator. Varying the supply voltage on CMOS
gates changes the switching threshold so you get a super
cheap VCO.

http://www.discovercircuits.com/DJ-Circuits/4584vco.htm



From padawan12 at obiwannabe.co.uk  Tue Feb 28 15:28:31 2012
From: padawan12 at obiwannabe.co.uk (Andy Farnell)
Date: Tue, 28 Feb 2012 20:28:31 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <CAK1FW3XZeWS-Wyr7wp0kLEgdbBTVVG4QAFPYphfCL4XRqX_d-A@mail.gmail.com>
References: <20120228155721.M59034@ccrma.Stanford.EDU>
	<CAFswGP3qmFQP6LSVJRRsAjtLcUF2VcNcv3upRYK-OaWdzmkv+A@mail.gmail.com>
	<CAK1FW3XZeWS-Wyr7wp0kLEgdbBTVVG4QAFPYphfCL4XRqX_d-A@mail.gmail.com>
Message-ID: <20120228202831.GB3747@sapphire.lan>

On Tue, Feb 28, 2012 at 03:16:14PM -0500, Adam Puckett wrote:
> Andy,
> 
> there's an opcode called active that does what you want 'numalloc' to do:
> 
> http://csounds.com/manual/html/active.html


Thanks Adam! That's a big help to some of my projects, I'll
take a look at it.

cheers,
Andy

From tonyr at cantabResearch.com  Tue Feb 28 15:58:29 2012
From: tonyr at cantabResearch.com (Tony Robinson)
Date: Tue, 28 Feb 2012 20:58:29 +0000
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <mailman.1449.1330459839.148.music-dsp@music.columbia.edu>
References: <mailman.1449.1330459839.148.music-dsp@music.columbia.edu>
Message-ID: <4F4D3FF5.1030709@cantabResearch.com>


> Date: Tue, 28 Feb 2012 13:20:12 -0500
> From: douglas repetto<douglas at music.columbia.edu>
>
> A code-free oscillator!
>
> http://www.youtube.com/watch?v=IdckHzEY-R

Wimps, that should have been made from a couple of real transistors 
preferably with all parts scrounged from some dud bit of equipment and a 
metal stylus touching tin foil for keys attached to a resistor network 
for "notes".


Tony

-- 
Dr A J Robinson, Founder and Director of Cantab Research Limited
St Johns Innovation Centre, Cowley Road, Cambridge, CB4 0WS, UK
Company reg no 05697423 (England and Wales), VAT reg no 925606030


From douglas at music.columbia.edu  Tue Feb 28 16:00:19 2012
From: douglas at music.columbia.edu (douglas repetto)
Date: Tue, 28 Feb 2012 16:00:19 -0500
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <4F4D3FF5.1030709@cantabResearch.com>
References: <mailman.1449.1330459839.148.music-dsp@music.columbia.edu>
	<4F4D3FF5.1030709@cantabResearch.com>
Message-ID: <4F4D4063.3050006@music.columbia.edu>

On 2/28/12 3:58 PM, Tony Robinson wrote:
>
>> Date: Tue, 28 Feb 2012 13:20:12 -0500
>> From: douglas repetto<douglas at music.columbia.edu>
>>
>> A code-free oscillator!
>>
>> http://www.youtube.com/watch?v=IdckHzEY-R
>
> Wimps, that should have been made from a couple of real transistors
> preferably with all parts scrounged from some dud bit of equipment and a
> metal stylus touching tin foil for keys attached to a resistor network
> for "notes".

Oh, come on, transistors are for babies. Real composers roll their own 
diodes!

http://hackaday.com/2010/03/05/diy-diodes


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


From theover at tiscali.nl  Tue Feb 28 16:31:22 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Tue, 28 Feb 2012 22:31:22 +0100
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <mailman.1452.1330460928.148.music-dsp@music.columbia.edu>
References: <mailman.1452.1330460928.148.music-dsp@music.columbia.edu>
Message-ID: <4F4D47AA.8050207@tiscali.nl>


Hmm, A certain mr. Moog got pretty famous making oscillators out of
electronics, even though at the time microwave TV relais were a
reality, making an oscillator with "certain properties", and of course 
much better measurement type qualities. In fact, the voltage controlled 
schmitt trigger circuit with CMOS or TTL has all kinds of electronics 
properties, I think it might make a nice practicum assignment, even.

The advancement of chip technology made Radio Shack built synthesizer
chips which I considered easy to connect long ago, but I didn't feel it 
did more than making some fairly clean sounds. It's interesting though, 
amp chips are good, digital chips are good, there are even good volume 
control chips, but the old curtis filter chips are hard to get, and a 
real good hifi equalizer chip is not even around to my knowledge.

I suppose the world is lucky for being able to buy cheap FPGA chips..

Hmm, I got an idea here, oh no, wait, they were ideas I had already a 
decade ago!

Theo

From akoebel at rogers.com  Tue Feb 28 17:49:53 2012
From: akoebel at rogers.com (Alen Koebel)
Date: Tue, 28 Feb 2012 14:49:53 -0800 (PST)
Subject: [music-dsp] Good Tutorial on Modified FM?
Message-ID: <1330469393.25311.YahooMailNeo@web88514.mail.bf1.yahoo.com>

Can anyone point me to a good tutorial about or explanation?of?Modified FM? I am aware?of Victor's paper 'Theory and Practice of Modified Frequency Modulation Synthesis', which I assume?contains what I need,?but since it's an AES document I can't access it (or more correctly I refuse to pay the exhorbitant?fee?to download?it). A Google search hasn't turned up much other than Victor's paper 'A Modified FM synthesis approach to bandlimited signal generation?.?I?am looking for?a more complete explanation of the method.??

From o at iki.fi  Tue Feb 28 17:52:27 2012
From: o at iki.fi (Olli Niemitalo)
Date: Wed, 29 Feb 2012 00:52:27 +0200
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
Message-ID: <CAAKWUFHYyFPU_jSg7_7vvZ35nMW51HcU6BO+ZBgEkmzvhizibQ@mail.gmail.com>

Here are four "bytebeat" songs I made. They are all written in
Javascript. Each expression gives the 8-bit sample at discrete time t,
of audio sampled at 8 kHz.

u=t>>10,8*t*t*(t>>u%3+15)/(3+(u&(u>>5&3|4)))|t>>4

t>>4|t*t*(t>>6&8^8)*(t>>11^t/3>>12)/(7+(t>>10&t>>14&3))

v=t/2^(t&64?63:0),v=v>>v,v/(1+(v>>7))&t/32|(t>>11)%8%3*t*t&31

u=3*t>>t/4096%4&-t%(t>>16|16)*t>>14&8191,u/(u>>6|1)*4

You can input them here to play them:

  http://wurstcaptures.untergrund.net/music

Warning, it's addictive if you start experimenting. It is quite
interesting how musical such things as round-off errors of binary
arithmetic can sound if carefully crafted. Also try this one by
"xpansive", more in the true spirit of bytebeat as it is very short,
gives a complex song and doesn't seem rationally constructed:

t%(t/(t>>9|t>>13))

Now that's computer music for 'ya. :)

-olli

On Tue, Feb 28, 2012 at 2:13 PM, Renato Fabbri <renato.fabbri at gmail.com> wrote:
> any more favourites? :-)

From andrew.jerrim at gmail.com  Tue Feb 28 18:37:50 2012
From: andrew.jerrim at gmail.com (Andrew Jerrim)
Date: Wed, 29 Feb 2012 10:37:50 +1100
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <CAAKWUFHYyFPU_jSg7_7vvZ35nMW51HcU6BO+ZBgEkmzvhizibQ@mail.gmail.com>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
	<CAAKWUFHYyFPU_jSg7_7vvZ35nMW51HcU6BO+ZBgEkmzvhizibQ@mail.gmail.com>
Message-ID: <CAMx6-X07J8hhqaHu51sLvYjEkLqmQMZUqpZa64OXBsTwhU_Q=g@mail.gmail.com>

Oooh, Olli - that's fantastic! Wouldn't that make a great little phone app :)


On 29 February 2012 09:52, Olli Niemitalo <o at iki.fi> wrote:
>
> Here are four "bytebeat" songs I made. They are all written in
> Javascript. Each expression gives the 8-bit sample at discrete time t,
> of audio sampled at 8 kHz.
>
> u=t>>10,8*t*t*(t>>u%3+15)/(3+(u&(u>>5&3|4)))|t>>4
>
> t>>4|t*t*(t>>6&8^8)*(t>>11^t/3>>12)/(7+(t>>10&t>>14&3))
>
> v=t/2^(t&64?63:0),v=v>>v,v/(1+(v>>7))&t/32|(t>>11)%8%3*t*t&31
>
> u=3*t>>t/4096%4&-t%(t>>16|16)*t>>14&8191,u/(u>>6|1)*4
>
> You can input them here to play them:
>
> ?http://wurstcaptures.untergrund.net/music
>
> Warning, it's addictive if you start experimenting. It is quite
> interesting how musical such things as round-off errors of binary
> arithmetic can sound if carefully crafted. Also try this one by
> "xpansive", more in the true spirit of bytebeat as it is very short,
> gives a complex song and doesn't seem rationally constructed:
>
> t%(t/(t>>9|t>>13))
>
> Now that's computer music for 'ya. :)
>
> -olli
>
> On Tue, Feb 28, 2012 at 2:13 PM, Renato Fabbri <renato.fabbri at gmail.com>
> wrote:
> > any more favourites? :-)
> --
> 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 Feb 28 19:41:24 2012
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Wed, 29 Feb 2012 00:41:24 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <20120228155721.M59034@ccrma.Stanford.EDU>
References: <20120228155721.M59034@ccrma.Stanford.EDU>
Message-ID: <4F4D7434.6030605@blueyonder.co.uk>

On 28/02/2012 16:03, Bill Schottstaedt wrote:
> I don't think this conversation is useful.  The only question I'd
> ask is "did this person make good music?", and I don't care at all about
> his degrees or grants.  One of the best mathematicians I've known
> does not even have a high-school diploma.  If I find such a person,
> then it's interesting to ask how she did it.  But there are very few,
> and no generalizations seem to come to mind.
>

I agree, but I think such conversations can be useful. "Computer Music" 
does possibly suffer more than most from what I might mischievously call 
the "expertise problem" - how does the "typical" listener recognise all 
the skills that have been brought to bear in a piece? They presumably 
have to do that at least to some extent, to decide if the piece is 
"good".  The temptation I see is to focus more on the process than the 
product - understandable enough for a composer, but not necessarily 
practical for the listener. Ross, for example, stipulated that a 
"computer musician" not only needs to be a programmer, but also have 
undergraduate level EE expertise. The process is clearly paramount. I do 
wonder how that would be unambiguously apparent listening to a piece.

On the CEC mailing list, the proposal was made (Kevin Austin IIRC) that 
in what was called "High Acousmatic Art" (HAA) the piece will always 
involve the process of transformation. That may well be widely true, but 
as a matter of principle I would be disappointed if that was the only 
possible criterion of "goodness" of a piece for it to qualify as HAA 
(assuming of course HAA can itself be adequately defined). I am really 
interested in what other paradigms of the compositional process could 
also qualify for a HAA piece.

Richard Dobson


From rossb-lists at audiomulch.com  Tue Feb 28 22:04:01 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Wed, 29 Feb 2012 14:04:01 +1100
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4D7434.6030605@blueyonder.co.uk>
References: <20120228155721.M59034@ccrma.Stanford.EDU>
	<4F4D7434.6030605@blueyonder.co.uk>
Message-ID: <4F4D95A1.4000600@audiomulch.com>

On 29/02/2012 11:41 AM, Richard Dobson wrote:
> On 28/02/2012 16:03, Bill Schottstaedt wrote:
>> I don't think this conversation is useful. The only question I'd
>> ask is "did this person make good music?", and I don't care at all about
>> his degrees or grants. One of the best mathematicians I've known
>> does not even have a high-school diploma. If I find such a person,
>> then it's interesting to ask how she did it. But there are very few,
>> and no generalizations seem to come to mind.
>>
>
> I agree,

I'm not sure whether (or which) conversation is useful, but I totally 
agree with "good music" being the important thing in the end. That said, 
"result orientation" has been the subject of criticism in certain 
circles, and there exists a counter view that it's the process, not the 
result that matters.


> but I think such conversations can be useful. "Computer Music"
> does possibly suffer more than most from what I might mischievously call
> the "expertise problem" - how does the "typical" listener recognise all
> the skills that have been brought to bear in a piece?

(In my view) the listener need not recognise "all those skills." The 
audience is presented with acoustic stimulus and the first order 
experience is usually auditory. What happens beyond that depends, among 
other things, on the mode of listening, but in general it's safe to say 
it won't typically be an experience of thinking about expert-level 
technical production details.

The typical listener may not know much about late 19th century tonal 
harmony but can appreciate music that employs it. One knows when a 
seamstress/tailor/brain surgion/street cleaner/cabinet maker/film 
production team/ has done something "good" without needing to know about 
the specialised skills and tools involved.


 > They presumably have to do that at least to some extent, to decide if
 > the piece is "good".

They may recognise some of the skills, to some extent, perhaps -- but I 
think more often the "product" is experienced on its own terms, as 
sound. There's a genotype/phenotype relationship between skills and the 
musical result: maybe the skills and means are apparent, maybe they 
aren't -- maybe the composer has worked hard to conceal the techniques 
of production -- the appreciable skill might be the invisibility of the 
process (like the absence of visible brush strokes in the paintings of 
the Dutch masters.) Thuse the criteria for "good" music should not 
require recognition of "all the skills that have been brought to bear in 
a piece."

But such recognition can certainly be a component of music appreciation.
Art speaks into a context which comprises of some subset of knowledge of 
everything that has gone before, and this could, under some 
circumstances, include knowledge of production processes, organising 
principles and structuring techniques -- whether in general, or with 
respect to a particular composer or work.

There are forms of "computational art" (e.g. "net art", "software art", 
  perhaps also "live coding", and I mean these with reference to 
specific art movements) where the computational process has been 
aestheticised. (Perhaps analogous to the aestheticisation of "concept" 
in modern art.) One could also argue that in modern classical music, 
performance technique has become aestheticised. But this reification of 
"technitution" as Harry Partch called it, is by no means a universally 
accepted definition of what is or should be considered "good."


> The temptation I see is to focus more on the process than the
> product  - understandable enough for a composer, but not necessarily
> practical for the listener.

Agreed. It can sometimes be a problem when the aestheticisation of the 
internal (technical) structure of an artwork is considered key to the 
appreciation of the artwork. Perhaps this is what you're getting at?

These days I see computer practice with a strong focus on "proces over 
product" as a branch of the "software art" movement. Personally I think 
it is critical that music must be "good" on merits related to the domain 
of musical/auditory perception and cultural experience. But allowing for 
appreciation of computational aesthetics as an integral part of the work 
may also be valid -- some might even argue that computational aesthetics 
are more important than the musical result.. but at that point I think 
it ceases being music, which is why categories like "software art" are 
useful.


> Ross, for example, stipulated that a
> "computer musician" not only needs to be a programmer, but also have
> undergraduate level EE expertise. The process is clearly paramount.

The driving concern here is to be sufficiently prepared to engage with 
the computer in an act of composer/performer programmed computation that 
results in musical sound -- i.e. computation as a medium of musical 
expression. This isn't any more about "the process" as it is about 
having the requisite skills to create "the product."


 > I do wonder how that would be unambiguously apparent listening to a
 > piece.


Ross.

From rossb-lists at audiomulch.com  Tue Feb 28 22:20:17 2012
From: rossb-lists at audiomulch.com (Ross Bencina)
Date: Wed, 29 Feb 2012 14:20:17 +1100
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <4F4D4063.3050006@music.columbia.edu>
References: <mailman.1449.1330459839.148.music-dsp@music.columbia.edu>
	<4F4D3FF5.1030709@cantabResearch.com>
	<4F4D4063.3050006@music.columbia.edu>
Message-ID: <4F4D9971.5050404@audiomulch.com>

On 29/02/2012 8:00 AM, douglas repetto wrote:
> Oh, come on, transistors are for babies. Real composers roll their own
> diodes!
>
> http://hackaday.com/2010/03/05/diy-diodes


Etching your own transistors is still pretty cool:

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

Might take a while to make enough to bootstrap a C++ compiler though...

R.

P.S. Jerri Elsworth is a total legend.

From Victor.Lazzarini at nuim.ie  Wed Feb 29 03:46:39 2012
From: Victor.Lazzarini at nuim.ie (Victor)
Date: Wed, 29 Feb 2012 08:46:39 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <4F4D7434.6030605@blueyonder.co.uk>
References: <20120228155721.M59034@ccrma.Stanford.EDU>
	<4F4D7434.6030605@blueyonder.co.uk>
Message-ID: <0B7326B6-7887-420B-BD36-F4B10E7464EC@nuim.ie>

In my opinion, the process here is as important as in traditional music disciplines. So I think having a good knowledge of craft is essential for a composer. In the traditinal world, this meant mastering counterpoint and harmony, tonal and post-tonal, as well as being able to think new ways of structuring the material, etc. Here, I think we have an emerging set of crafts, maybe not yet completely defined, but things like synthesis and programming might well be part of it.

In the end, no one might be able to determine whether your music is worth anything, but having a 
good craft at least it will guarantee a certain level of structural quality (if you believe there is such a thing). In some quarters, it will be said to be professionally done. These are the things that can be taught and learned.

However, as in traditional music, there is also something beyond the craft, which is hard to define. 

Victor


On 29 Feb 2012, at 00:41, Richard Dobson <richarddobson at blueyonder.co.uk> wrote:

> On 28/02/2012 16:03, Bill Schottstaedt wrote:
>> I don't think this conversation is useful.  The only question I'd
>> ask is "did this person make good music?", and I don't care at all about
>> his degrees or grants.  One of the best mathematicians I've known
>> does not even have a high-school diploma.  If I find such a person,
>> then it's interesting to ask how she did it.  But there are very few,
>> and no generalizations seem to come to mind.
>> 
> 
> I agree, but I think such conversations can be useful. "Computer Music" does possibly suffer more than most from what I might mischievously call the "expertise problem" - how does the "typical" listener recognise all the skills that have been brought to bear in a piece? They presumably have to do that at least to some extent, to decide if the piece is "good".  The temptation I see is to focus more on the process than the product - understandable enough for a composer, but not necessarily practical for the listener. Ross, for example, stipulated that a "computer musician" not only needs to be a programmer, but also have undergraduate level EE expertise. The process is clearly paramount. I do wonder how that would be unambiguously apparent listening to a piece.
> 
> On the CEC mailing list, the proposal was made (Kevin Austin IIRC) that in what was called "High Acousmatic Art" (HAA) the piece will always involve the process of transformation. That may well be widely true, but as a matter of principle I would be disappointed if that was the only possible criterion of "goodness" of a piece for it to qualify as HAA (assuming of course HAA can itself be adequately defined). I am really interested in what other paradigms of the compositional process could also qualify for a HAA piece.
> 
> Richard Dobson
> 
> --
> 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  Wed Feb 29 05:15:21 2012
From: Victor.Lazzarini at nuim.ie (Victor Lazzarini)
Date: Wed, 29 Feb 2012 10:15:21 +0000
Subject: [music-dsp] Good Tutorial on Modified FM?
In-Reply-To: <1330469393.25311.YahooMailNeo@web88514.mail.bf1.yahoo.com>
References: <1330469393.25311.YahooMailNeo@web88514.mail.bf1.yahoo.com>
Message-ID: <D81D32D0-87F1-424A-BEBC-61F3F81519B8@nuim.ie>

Hi Alen,

I've sent you the ms off-list.

Regards

Victor
On 28 Feb 2012, at 22:49, Alen Koebel wrote:

> Can anyone point me to a good tutorial about or explanation of Modified FM? I am aware of Victor's paper 'Theory and Practice of Modified Frequency Modulation Synthesis', which I assume contains what I need, but since it's an AES document I can't access it (or more correctly I refuse to pay the exhorbitant fee to download it). A Google search hasn't turned up much other than Victor's paper 'A Modified FM synthesis approach to bandlimited signal generation?. I am looking for a more complete explanation of the method.  
> --
> 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

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




From Victor.Lazzarini at nuim.ie  Wed Feb 29 05:22:24 2012
From: Victor.Lazzarini at nuim.ie (Victor Lazzarini)
Date: Wed, 29 Feb 2012 10:22:24 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <0B7326B6-7887-420B-BD36-F4B10E7464EC@nuim.ie>
References: <20120228155721.M59034@ccrma.Stanford.EDU>
	<4F4D7434.6030605@blueyonder.co.uk>
	<0B7326B6-7887-420B-BD36-F4B10E7464EC@nuim.ie>
Message-ID: <BCD02DEF-59F9-4B46-9DE6-E0B884EE504C@nuim.ie>

Also, as in traditional music disciplines, intuitive (and partial) understanding of principles can also be enough to make music, and I expect this to be the same here. This is, again, generally independent of whether we find this music good or bad.

Victor
On 29 Feb 2012, at 08:46, Victor wrote:

> In my opinion, the process here is as important as in traditional music disciplines. So I think having a good knowledge of craft is essential for a composer. In the traditinal world, this meant mastering counterpoint and harmony, tonal and post-tonal, as well as being able to think new ways of structuring the material, etc. Here, I think we have an emerging set of crafts, maybe not yet completely defined, but things like synthesis and programming might well be part of it.
> 
> In the end, no one might be able to determine whether your music is worth anything, but having a 
> good craft at least it will guarantee a certain level of structural quality (if you believe there is such a thing). In some quarters, it will be said to be professionally done. These are the things that can be taught and learned.
> 
> However, as in traditional music, there is also something beyond the craft, which is hard to define. 
> 
> Victor
> 
> 
> On 29 Feb 2012, at 00:41, Richard Dobson <richarddobson at blueyonder.co.uk> wrote:
> 
>> On 28/02/2012 16:03, Bill Schottstaedt wrote:
>>> I don't think this conversation is useful.  The only question I'd
>>> ask is "did this person make good music?", and I don't care at all about
>>> his degrees or grants.  One of the best mathematicians I've known
>>> does not even have a high-school diploma.  If I find such a person,
>>> then it's interesting to ask how she did it.  But there are very few,
>>> and no generalizations seem to come to mind.
>>> 
>> 
>> I agree, but I think such conversations can be useful. "Computer Music" does possibly suffer more than most from what I might mischievously call the "expertise problem" - how does the "typical" listener recognise all the skills that have been brought to bear in a piece? They presumably have to do that at least to some extent, to decide if the piece is "good".  The temptation I see is to focus more on the process than the product - understandable enough for a composer, but not necessarily practical for the listener. Ross, for example, stipulated that a "computer musician" not only needs to be a programmer, but also have undergraduate level EE expertise. The process is clearly paramount. I do wonder how that would be unambiguously apparent listening to a piece.
>> 
>> On the CEC mailing list, the proposal was made (Kevin Austin IIRC) that in what was called "High Acousmatic Art" (HAA) the piece will always involve the process of transformation. That may well be widely true, but as a matter of principle I would be disappointed if that was the only possible criterion of "goodness" of a piece for it to qualify as HAA (assuming of course HAA can itself be adequately defined). I am really interested in what other paradigms of the compositional process could also qualify for a HAA piece.
>> 
>> Richard Dobson
>> 
>> --
>> 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

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




From jamie at postlude.co.uk  Wed Feb 29 05:46:55 2012
From: jamie at postlude.co.uk (Jamie Bullock)
Date: Wed, 29 Feb 2012 10:46:55 +0000
Subject: [music-dsp] a little about myself
In-Reply-To: <0B7326B6-7887-420B-BD36-F4B10E7464EC@nuim.ie>
References: <20120228155721.M59034@ccrma.Stanford.EDU>
	<4F4D7434.6030605@blueyonder.co.uk>
	<0B7326B6-7887-420B-BD36-F4B10E7464EC@nuim.ie>
Message-ID: <2E08DB0C-17E9-4ABD-B6DA-8EF93E7C74C6@postlude.co.uk>





On 29 Feb 2012, at 08:46, Victor wrote:

> In my opinion, the process here is as important as in traditional music disciplines. So I think having a good knowledge of craft is essential for a composer. In the traditinal world, this meant mastering counterpoint and harmony, tonal and post-tonal, as well as being able to think new ways of structuring the material, etc. Here, I think we have an emerging set of crafts, maybe not yet completely defined, but things like synthesis and programming might well be part of it.
> 

'not yet completely defined' is the key phrase for me. The craft of computer music, or indeed live electronic music may well currently require a working knowledge of programming, synthesis, acoustics, production (etc), but this is surely by necessity rather than design. 

A tradition of using textual programming languages to produce computer music has evolved because initially this was the only way to do it, and so computer music programming languages have become ubiquitous. I'm personally interested in new tools, interfaces and instruments that allow musicians to compose with (and for) computers without the requirement for years of study in DSP/programming. I guess UPIC, Fairlight and Kyma are earlier systems that hint towards this.

The current Western orchestra, notation and musical language(s) have resulted from 100's years of development. The equivalent for 'computer music' is IMO as yet unknown, and lies somewhere in the future. I'd like to see a situation where musicians can make computer music armed only with musical ideas for sounds and processes, and no programming or DSP knowledge at all, but we're still a long way from that.

Just my 2p.

best,

Jamie


--
http://www.jamiebullock.com



From o at iki.fi  Wed Feb 29 05:50:13 2012
From: o at iki.fi (Olli Niemitalo)
Date: Wed, 29 Feb 2012 12:50:13 +0200
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <CAMx6-X07J8hhqaHu51sLvYjEkLqmQMZUqpZa64OXBsTwhU_Q=g@mail.gmail.com>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
	<CAAKWUFHYyFPU_jSg7_7vvZ35nMW51HcU6BO+ZBgEkmzvhizibQ@mail.gmail.com>
	<CAMx6-X07J8hhqaHu51sLvYjEkLqmQMZUqpZa64OXBsTwhU_Q=g@mail.gmail.com>
Message-ID: <CAAKWUFG3owALk4=oHGpHQdk72M1wszMWpuE1X-ReUGO8koXtFw@mail.gmail.com>

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

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

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

-olli

From andrew.jerrim at gmail.com  Wed Feb 29 06:06:09 2012
From: andrew.jerrim at gmail.com (Andrew Jerrim)
Date: Wed, 29 Feb 2012 22:06:09 +1100
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <CAAKWUFG3owALk4=oHGpHQdk72M1wszMWpuE1X-ReUGO8koXtFw@mail.gmail.com>
References: <CALqdYOy=nq9iiCejPc_Gx7Stq3k=kPCe+t_aCv1pmVuWgmymrw@mail.gmail.com>
	<CAAKWUFHYyFPU_jSg7_7vvZ35nMW51HcU6BO+ZBgEkmzvhizibQ@mail.gmail.com>
	<CAMx6-X07J8hhqaHu51sLvYjEkLqmQMZUqpZa64OXBsTwhU_Q=g@mail.gmail.com>
	<CAAKWUFG3owALk4=oHGpHQdk72M1wszMWpuE1X-ReUGO8koXtFw@mail.gmail.com>
Message-ID: <CAMx6-X0XTGq1QpadmVmoh+Y+63ModKeSQqM1eGkqWb_-2JVVZw@mail.gmail.com>

Nice - thanks!

On 29 February 2012 21:50, Olli Niemitalo <o at iki.fi> wrote:
> On Wed, Feb 29, 2012 at 1:37 AM, Andrew Jerrim <andrew.jerrim at gmail.com> wrote:
>> [On bytebeat:] Oooh, Olli - that's fantastic! Wouldn't that make a great little phone app :)
>
> There's Glitch Machine for iPhone/iPad, does much the same but in
> reverse Polish notation.
>
> http://madgarden.net/apps/glitch-machine/
>
> -olli
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp

From theover at tiscali.nl  Wed Feb 29 14:14:34 2012
From: theover at tiscali.nl (Theo Verelst)
Date: Wed, 29 Feb 2012 20:14:34 +0100
Subject: [music-dsp] very cheap synthesis techniques
In-Reply-To: <mailman.1496.1330513576.148.music-dsp@music.columbia.edu>
References: <mailman.1496.1330513576.148.music-dsp@music.columbia.edu>
Message-ID: <4F4E791A.7030307@tiscali.nl>


I thought about the equivalence of a hobby or trained pianist having 
access to a Steinway (or fill in your own favorite brand(s)) grand piano 
in a nice music hall or maybe a small synthesizer with musically usable 
sounds. I mean a phone application can be nice, and I quite like the 
idea of for instance Bristol Synths available for pad computers, but 
probably in most realistic cases being able to make some comely music is 
more prevalent.

Of course "'vin' uh comepu'er" open possibilities in the traditional 
range of playing piano on it, and it allows people to "press a little 
key to place a little melody". That's nice but the progress-faith that 
goes with it could use some sense of realism, and the people lying their 
b*tt*cks of promoting their computer money streams instead of genuine 
interest in DSP and it's can and cannot do's aren't really going to make 
it nice.

My main observation about the scientific side of it all has to do with 
the "academic" (like being able to somewhat freely talk in an academic 
sense) versus the "Ivory Tower". Nowhere I've seen or heard much 
discussion about good music and the interaction of the musicians with 
computers in that music, except of course just about everybody nowadays 
will record digital and do some amount of producing on their computer or 
the studios' computer. But suppose a rock band wants a special DSP 
program to make their stuff sound great, or the guitar player wants a 
special notebook version of his or her favorite effect chain to work on 
the new CD. Or, the orchestra has recorded the film theme, but now they 
want a good sounding mix from the tracks. NOBODY, and mean NOBODY in 
such situation is then quite scientifically honest about the results. 
Nobody. I mean nobody will start by saying "but CDs still sound sterile" 
or, "can't I get get *real* tape saturation instead of this crappy 
plugin" or "these expensive production tools don't sound awesome at all, 
but rather crappy and weak". That's my problem with the idea of computer 
DSP and of course not nicely done synthesis.

Scientists should be the first to point out how cheap the plugins sound 
and what the technological reason for that is. Not the ones closing all 
discussion killings with a gloomy "amen" in the name of science.

Being not new to stage performances (in the sense of performing good 
jazz/fusion, funk etc.) I'd say for anyone from an avant garde scene or 
people "hip" enough not to have to define that in some nerdy way 
(nothing against that of course), I pretty certainly feel the discussion 
*could* deteriorate into some semi-leadership babblings without ever 
touching the real subjects, like what would 10CC (for the english and 
the USers in another way of course) think of "computer music" or what 
would modern scifi film score "composers" or producers think about the 
actual _new_ stuff going on. Probably most of the stuff out there is 
covering only a relatively small part of the possible audio space, and 
even recognizably so, but so what?

I like new technology based on th Moore curve or the advancement in 
electroncis and electro-mechanical parts, and actually enjoy a good new 
sounding Yamaha grand, too, but of course there is no need for a good 
composer with blank sheet music, a pencil and a Casio recording keyboard 
to feel extremely second to that. Searching for novel musical idiom in 
computer music in the context of the existing body of music from 
Kraftwerk to Moog commercials and given the interesting panteon of 
available computer and synthesizer sounds is surely not the domain of 
the faint hearted homeboy type, or the not-so-illuminated family 
leaders, but rather it is still the domain of quite crafty musicians 
with more than average technical skills/knowledge.

The computer and electro-mechanical performances I've seen in the flesh 
(I quicly recall Michel Waisvisz of Steim, various demonstration at 
Ircam, and some electro mechanical demos I forgot the artist names of, 
and various conservatory demonstrations) or from a computer screen with 
my extensive audio system, and maybe even from minimalist film scores, I 
think mostly talked about good teste and some not too ambitious theme, 
unless clearly theatrical, and that suits me fine. But scientifically 
speaking I think there must be serious attention for the deeper 
sonologic and music theories of the modern and traditional kind to do 
any science serious of taking much notice of. Of course promoting music 
is important for conservatories, but I'd rather see that happen by 
promoting good Midi renderings with advanced keyboards than many of the 
"contemporary" computer related "music", of course excepting a small 
numbers of tasteful works in their own niche and art domain. Possibly 
that can act as the same as art in a (public ?) gallery which certainly 
interests me.

Theo Verelst