CNMAT has released a brand new, clear & handy, download page where it 

appears that 99% of their externals are now compiled for Windows, 

*including* [SDIF-Buffer] & [SDIF-Tuples] ! It's awesome. Thanks to 

http://www.cnmat.berkeley.edu/MAX/downloads/

f.e chanfrault | aka | personal computer music

> >>>>>> |sublime music for a desperate people|

CNMAT has released a brand new, clear & handy, download page where it 
appears that 99% of their externals are now compiled for Windows, 
*including* [SDIF-Buffer] & [SDIF-Tuples] ! It's awesome. Thanks to 
CNMAT :-)

-- 
f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|


cnmat-new-download-page

Date: Wednesday, September 13, 2006 3:54 am

Subject: [maxmsp] CNMAT new download page

> CNMAT has released a brand new, clear & handy, download page where 

> appears that 99% of their externals are now compiled for Windows, 

> *including* [SDIF-Buffer] & [SDIF-Tuples] ! It's awesome. Thanks 

> f.e chanfrault | aka | personal computer music

> > >>>>>> |sublime music for a desperate people|

----- Original Message -----
From: "f.e" 
Date: Wednesday, September 13, 2006 3:54 am
Subject: [maxmsp] CNMAT new download page

> CNMAT has released a brand new, clear & handy, download page where 
> it 
> appears that 99% of their externals are now compiled for Windows, 
> *including* [SDIF-Buffer] & [SDIF-Tuples] ! It's awesome. Thanks 
> to 
> CNMAT :-)
>
> http://www.cnmat.berkeley.edu/MAX/downloads/
>
> cheers
>
> f.e
>
> -- 
> f.e chanfrault | aka | personal computer music
> > >>>>>> http://www.personal-computer-music.com
> > >>>>>> |sublime music for a desperate people|
>


> Date: Wednesday, September 13, 2006 3:54 am

> Subject: [maxmsp] CNMAT new download page

>> CNMAT has released a brand new, clear & handy, download page where 

>> appears that 99% of their externals are now compiled for Windows, 

>> *including* [SDIF-Buffer] & [SDIF-Tuples] ! It's awesome. Thanks 

>> f.e chanfrault | aka | personal computer music

>>>>>>>>> |sublime music for a desperate people|

f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|

apalomba@austin.rr.com wrote:
> The Windows zip file does not work.
>
>
>
> Anthony
>
>
>
> ----- Original Message -----
> From: "f.e" 
> Date: Wednesday, September 13, 2006 3:54 am
> Subject: [maxmsp] CNMAT new download page
>
>
>> CNMAT has released a brand new, clear & handy, download page where 
>> it 
>> appears that 99% of their externals are now compiled for Windows, 
>> *including* [SDIF-Buffer] & [SDIF-Tuples] ! It's awesome. Thanks 
>> to 
>> CNMAT :-)
>>
>> http://www.cnmat.berkeley.edu/MAX/downloads/
>>
>> cheers
>>
>> f.e
>>
>> -- 
>> f.e chanfrault | aka | personal computer music
>>
>>>>>>>>> http://www.personal-computer-music.com
>>>>>>>>> |sublime music for a desperate people|
>>>>>>>>>
>>
>>
>
>


Is mlp (multi-layer perceptron) now considered obsolete? Too bad, I'm 

> it appears that 99% of their externals are now compiled for 

> Windows, *including* [SDIF-Buffer] & [SDIF-Tuples] ! It's awesome. 

>> >>>>>> |sublime music for a desperate people|

Is mlp (multi-layer perceptron) now considered obsolete? Too bad, I'm  
still using it.

> CNMAT has released a brand new, clear & handy, download page where  
> it appears that 99% of their externals are now compiled for  
> Windows, *including* [SDIF-Buffer] & [SDIF-Tuples] ! It's awesome.  
> Thanks to CNMAT :-)
>
> http://www.cnmat.berkeley.edu/MAX/downloads/
>
> cheers
>
> f.e
>
> -- 
> f.e chanfrault | aka | personal computer music
>> >>>>>> http://www.personal-computer-music.com
>> >>>>>> |sublime music for a desperate people|


I'm prepearing a neural net external library with various families of 

nets. You'll have something soon. I just need to find the time to 

I'm prepearing a neural net external library with various families of  
nets. You'll have something soon. I just need to find the time to  
finish it.

This is very nice. Now there is no excuse to implement all those interesting resynthesis and morphing applications I've been wanting to make :)

 to look like the most promising analysis tool but there are not much references to it in the CNMAT circumference.. any idea why that is?

Anyone heard of an analyser external for max by any chance? ;)

Funny that I find SPEAR (http://www.klingbeil.com/spear/) to look like the most promising analysis tool but there are not much references to it in the CNMAT circumference.. any idea why that is?

You should be able to save SPDIF data with SPEAR

and then load it in Max using the CNMAT externals.

Subject: [maxmsp] Re: CNMAT new download page

> This is very nice. Now there is no excuse to implement all those

interesting resynthesis and morphing applications I've been wanting to make

most promising analysis tool but there are not much references to it in the

CNMAT circumference.. any idea why that is?

> Anyone heard of an analyser external for max by any chance? ;)

You should be able to save SPDIF data with SPEAR
and then load it in Max using the CNMAT externals.

----- Original Message -----
From: "Mattijs Kneppers" 
To: 
Sent: Friday, September 15, 2006 7:44 AM
Subject: [maxmsp] Re: CNMAT new download page

>
> This is very nice. Now there is no excuse to implement all those
interesting resynthesis and morphing applications I've been wanting to make
:)
>
> Funny that I find SPEAR (http://www.klingbeil.com/spear/) to look like the
most promising analysis tool but there are not much references to it in the
CNMAT circumference.. any idea why that is?
>
> Anyone heard of an analyser external for max by any chance? ;)
>
> Best,
> Mattijs


Quote: Anthony Palomba wrote on Fri, 15 September 2006 15:03

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

> You should be able to save SPDIF data with SPEAR

> and then load it in Max using the CNMAT externals.

I assumed so, that's probably what I'll do first. Just figured there should be references to spear all over the website of cnmat but there aren't.

And wouldn't it be ultimate luxury to be able to record and automatically analyze a sound all within max? :)

Quote: Anthony Palomba wrote on Fri, 15 September 2006 15:03
----------------------------------------------------
> You should be able to save SPDIF data with SPEAR
> and then load it in Max using the CNMAT externals.
>

And wouldn't it be ultimate luxury to be able to record and automatically analyze a sound all within max? :)


That's probably a better approach, but if you feel like experimenting we 

made a few SPEAR-resynthesis externals (definitely not ready for 

prime-time!) in class last year. Probably going to work on a few more 

http://music.columbia.edu/cmc/courses/g6610/fall2005/week13/index.html

PS: Michael K. has joined the Yale faculty this year -- go Michael go!

On Fri, 15 Sep 2006, Anthony Palomba wrote:

> Sent: Friday, September 15, 2006 7:44 AM

> Subject: [maxmsp] Re: CNMAT new download page

>> This is very nice. Now there is no excuse to implement all those

> interesting resynthesis and morphing applications I've been wanting to make

> most promising analysis tool but there are not much references to it in the

> CNMAT circumference.. any idea why that is?

>> Anyone heard of an analyser external for max by any chance? ;)

That's probably a better approach, but if you feel like experimenting we 
made a few SPEAR-resynthesis externals (definitely not ready for 
prime-time!) in class last year.  Probably going to work on a few more 
this year:

    http://music.columbia.edu/cmc/courses/g6610/fall2005/week13/index.html

PS:  Michael K. has joined the Yale faculty this year -- go Michael go!

> You should be able to save SPDIF data with SPEAR
> and then load it in Max using the CNMAT externals.
>
>
>
> Anthony
>
>
>
> ----- Original Message -----
> From: "Mattijs Kneppers" 
> To: 
> Sent: Friday, September 15, 2006 7:44 AM
> Subject: [maxmsp] Re: CNMAT new download page
>
>
>>
>> This is very nice. Now there is no excuse to implement all those
> interesting resynthesis and morphing applications I've been wanting to make
> :)
>>
>> Funny that I find SPEAR (http://www.klingbeil.com/spear/) to look like the
> most promising analysis tool but there are not much references to it in the
> CNMAT circumference.. any idea why that is?
>>
>> Anyone heard of an analyser external for max by any chance? ;)
>>
>> Best,
>> Mattijs
>
>


Quote: Bradford Garton wrote on Fri, 15 September 2006 15:56

> That's probably a better approach, but if you feel like experimenting we 

> made a few SPEAR-resynthesis externals (definitely not ready for 

Surely interesting.. Resynthesizing is one option, but has any of you heard of (or participated in) a project where this data was used to do some intelligent feature-recognition for (for example) a feature-based morph between sounds?

Quote: Bradford Garton wrote on Fri, 15 September 2006 15:56
----------------------------------------------------
> That's probably a better approach, but if you feel like experimenting we 
> made a few SPEAR-resynthesis externals (definitely not ready for 
> prime-time!) in class last year. 

On Fri, 15 Sep 2006, Mattijs Kneppers wrote:

> Surely interesting.. Resynthesizing is one option, but has any of you 

> heard of (or participated in) a project where this data was used to do 

> some intelligent feature-recognition for (for example) a feature-based 

You might want to look at some software we did in a joint 

music/engineering grad seminar here last year:

It's not exactly what you describe, but the feature-extraction techniques 

are pretty snazzy. All in java, so maybe not too terribly difficult to 

> Surely interesting.. Resynthesizing is one option, but has any of you 
> heard of (or participated in) a project where this data was used to do 
> some intelligent feature-recognition for (for example) a feature-based 
> morph between sounds?

You might want to look at some software we did in a joint 
music/engineering grad seminar here last year:

 	http://labrosa.ee.columbia.edu/meapsoft/

It's not exactly what you describe, but the feature-extraction techniques 
are pretty snazzy.  All in java, so maybe not too terribly difficult to 
integrate into mxj.

I downloaded the OSX version of the objects and Max/MSP crashed many times while doing the Spectral Synthesis Tutorials. I'm using a white Macbook with its native sound card.

I downloaded the OSX version of the objects and Max/MSP crashed many times while doing the Spectral Synthesis Tutorials. I'm using a white Macbook with its native sound card.
Awesome objects by the way!
Best,

It is the resonators~ object that causes Max to crash.

We tend to use the IRCAM analysers at CNMAT, for historical reasons. However, I've used SPEAR a fair bit and am very happy with it. SDIF files open fine with SDIF-buffer. Find it here:

I plan to expand the Tutorials with comments on analysis in the near future. Realtime analysis is much trickier than using SPEAR or AddAn or Loris -- if you have access to the iana~ object, of IRCAM, that is promising.

----------------------------------------------------
> Funny that I find SPEAR (http://www.klingbeil.com/spear/) to look like the most promising analysis tool but there are not much references to it in the CNMAT circumference.. any idea why that is?
----------------------------------------------------

We tend to use the IRCAM analysers at CNMAT, for historical reasons.  However, I've used SPEAR a fair bit and am very happy with it.  SDIF files open fine with SDIF-buffer. Find it here:

I plan to expand the Tutorials with comments on analysis in the near future.  Realtime analysis is much trickier than using SPEAR or AddAn or Loris -- if you have access to the iana~ object, of IRCAM, that is promising.

Quote: Martin wrote on Sat, 16 September 2006 12:42

> It is the resonators~ object that causes Max to crash.

Could you give me any more specifics? I'm running a Macbook Pro and not able to reproduce your problem. Is it just, 1) make resonators~, 2) enjoy crash?

Quote: Martin wrote on Sat, 16 September 2006 12:42
----------------------------------------------------
> It is the resonators~ object that causes Max to crash.
----------------------------------------------------

Could you give me any more specifics?  I'm running a Macbook Pro and not able to reproduce your problem.  Is it just, 1) make resonators~, 2) enjoy crash?

> ----------------------------------------------------

> > It is the resonators~ object that causes Max to crash.

OK, I've got it. resonators~ crashes when closing the patch with audio on.

> ----------------------------------------------------
> > It is the resonators~ object that causes Max to crash.
> ----------------------------------------------------

OK, I've got it.  resonators~ crashes when closing the patch with audio on.

> OK, I've got it. resonators~ crashes when closing the patch with 

Are you calling dsp_free() at the beginning, middle, or end of your 

msp/Mar05/23158.html>. I would have preferred to cite David's 

original message explaining correct deallocation strategy, but I'm 

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

> OK, I've got it.  resonators~ crashes when closing the patch with  
> audio on.

Are you calling dsp_free() at the beginning, middle, or end of your  
deallocation method? Cf.
msp/Mar05/23158.html>. I would have preferred to cite David's  
original message explaining correct deallocation strategy, but I'm  
not finding it quickly.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

Quote: mzed wrote on Sun, 17 September 2006 18:09

> We tend to use the IRCAM analysers at CNMAT, for historical reasons. However, I've used SPEAR a fair bit and am very happy with it. SDIF files open fine with SDIF-buffer.

Great, that means it was not a bad idea to put some time in SPEAR :)

> I plan to expand the Tutorials with comments on analysis in the near future. Realtime analysis is much trickier than using SPEAR or AddAn or Loris

I bet. But only doing offline analysis in an external, have it fire a bang and load SDIF data in SDIF-buffer when done would be crazy too :)

-- if you have access to the iana~ object, of IRCAM, that is promising.

I am afraid I don't have very much contact with IRCAM. Met a few ppl during 2 meetings of NAG (Nederlands Akoestisch Gezelschap) I attended but that's about it.

Quote: mzed wrote on Sun, 17 September 2006 18:09
----------------------------------------------------
> We tend to use the IRCAM analysers at CNMAT, for historical reasons.  However, I've used SPEAR a fair bit and am very happy with it.  SDIF files open fine with SDIF-buffer. 

>
> I plan to expand the Tutorials with comments on analysis in the near future.  Realtime analysis is much trickier than using SPEAR or AddAn or Loris 

I am afraid I don't have very much contact with IRCAM. Met a few ppl during 2 meetings of NAG (Nederlands Akoestisch Gezelschap) I attended but that's about it. 

>
> mz
----------------------------------------------------


> > ----------------------------------------------------

> > > It is the resonators~ object that causes Max to crash.

> OK, I've got it. resonators~ crashes when closing the patch with audio on.

I've posted an updated version of my tutorials that turns off DSP before automagically disposing of patches. This is a workaround for the resonators~ crashes.

Unfortunately the resonators~ bug is a little more involved than the dsp_free() problem that several have been kind to point out.

I've just verified that AudioSculpt 2.6.1 is writing SDIFs in a way that the CNMAT externals are unable to read.

While on the subject of anaylsis, the idea of an external that does a non-realtime analysis in Max, and then spits it out when finished, is pretty interesting. That really isn't Max's Modus Operandi, though. A clever person could record incoming audio to a soundfile, use shell or applescript to open and analyse that in another application, save that data to an SDIF, and open it in Max. Knowing when the other app is done could be tricky.

Also, one should know that the analyses I provided in the tutorials took a fair amount of hand tweaking to get to the point they are at.

> > ----------------------------------------------------
> > > It is the resonators~ object that causes Max to crash.
> > ----------------------------------------------------
>
> OK, I've got it.  resonators~ crashes when closing the patch with audio on.
>
> More soon...
>

I've posted an updated version of my tutorials that turns off DSP before automagically disposing of patches.  This is a workaround for the resonators~ crashes.

Unfortunately the resonators~ bug is a little more involved than the dsp_free() problem that several have been kind to point out.  

I've just verified that AudioSculpt 2.6.1 is writing SDIFs in a way that the CNMAT externals are unable to read.  

While on the subject of anaylsis, the idea of an external that does a non-realtime analysis in Max, and then spits it out when finished, is pretty interesting.  That really isn't Max's Modus Operandi, though.  A clever person could record incoming audio to a soundfile, use shell or applescript to open and analyse that in another application, save that data to an SDIF, and open it in Max.  Knowing when the other app is done could be tricky.

> While on the subject of anaylsis, the idea of an external that does a

> non-realtime analysis in Max, and then spits it out when finished, is

> pretty interesting. That really isn't Max's Modus Operandi, though.

But its exactly what would be needed to close the gap between the power 

of nonrealtime processing with Max. One approach could be to use mxj. It 

should be easy for an external to just write the calculation into a 

buffer~ and bang when ready, or even spit out a "position" value how far 

it got so far. You can play parts of a buffer before its finished 

writing the result into it. All this can be done in a low priority 

mzed wrote:
> While on the subject of anaylsis, the idea of an external that does a
> non-realtime analysis in Max, and then spits it out when finished, is
> pretty interesting.  That really isn't Max's Modus Operandi, though.

But its exactly what would be needed to close the gap between the power 
of nonrealtime processing with Max. One approach could be to use mxj. It 
should be easy for an external to just write the calculation into a 
buffer~ and bang when ready, or even spit out a "position" value how far 
it got so far. You can play parts of a buffer before its finished 
writing the result into it. All this can be done in a low priority 
thread... (or on a second processor)

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


On Tue, 19 Sep 2006, Stefan Tiedje wrote:

> But its exactly what would be needed to close the gap between the power of 

> nonrealtime processing with Max. One approach could be to use mxj. It should 

> be easy for an external to just write the calculation into a buffer~ and bang 

> when ready, or even spit out a "position" value how far it got so far. You 

> can play parts of a buffer before its finished writing the result into it. 

> All this can be done in a low priority thread... (or on a second processor)

Has anyone managed to do this, not just in mxj necessarily but in a 

generic external? I tried fooling with some threads and semaphores to get 

[maxlisp] a little less brittle (tail recursion does really bad things to 

any semblance of real-time), but I continued to get what appeared to be 

timer crashes. But I also don't fully understand how the various max 

> But its exactly what would be needed to close the gap between the power of 
> nonrealtime processing with Max. One approach could be to use mxj. It should 
> be easy for an external to just write the calculation into a buffer~ and bang 
> when ready, or even spit out a "position" value how far it got so far. You 
> can play parts of a buffer before its finished writing the result into it. 
> All this can be done in a low priority thread... (or on a second processor)

Has anyone managed to do this, not just in mxj necessarily but in a 
generic external?  I tried fooling with some threads and semaphores to get 
[maxlisp] a little less brittle (tail recursion does really bad things to 
any semblance of real-time), but I continued to get what appeared to be 
timer crashes.  But I also don't fully understand how the various max 
thread priorities work.

Yes, we did an external that analyses an audio buffer in non-realtime. It has to be done in the dsp thread because you need to guarantee access to the buffer~ you work on, so the trick is to pick an arbitrary amount of samples to process every dsp call.

Up till now we didn't find a way to automatically increase this chunk size to utilize the processor maximally without causing clicks, but since we don't need the results in a fixed amount of time that doesn't form a real problem.

Yes, we did an external that analyses an audio buffer in non-realtime. It has to be done in the dsp thread because you need to guarantee access to the buffer~ you work on, so the trick is to pick an arbitrary amount of samples to process every dsp call. 

On Wed, 20 Sep 2006, Mattijs Kneppers wrote:

> so the trick is to pick an arbitrary amount 

I wish there were a way to fork and slice a low priority (i.e. 

interruptible by Max/MSP if necessary) thread so that all you would need 

to do is let it run and set a semaphore for when it finished. For 

example, suppose I have recursive function "doitall()" to calculate some 

arbitrary fractal gunk, and I don't know exactly how long it will take to 

finish the calculation (or if it ever will, thanks Alan Turing). I would 

like to simply kick it off and not worry about it until I see a 

"calc_finished" flag set, and the CPU will work on it whenever it can grab 

Is this possible? I tried a few initial experiments awhile ago, but I did 

get crashes that suggested that my lower-priority thread wasn't 

relinquishing resources like I had hoped it would.

> so the trick is to pick an arbitrary amount 
> of samples to process every dsp call.

I wish there were a way to fork and slice a low priority (i.e. 
interruptible by Max/MSP if necessary) thread so that all you would need 
to do is let it run and set a semaphore for when it finished.  For 
example, suppose I have recursive function "doitall()"  to calculate some 
arbitrary fractal gunk, and I don't know exactly how long it will take to 
finish the calculation (or if it ever will, thanks Alan Turing).  I would 
like to simply kick it off and not worry about it until I see a 
"calc_finished" flag set, and the CPU will work on it whenever it can grab 
free cycles.

Is this possible?  I tried a few initial experiments awhile ago, but I did 
get crashes that suggested that my lower-priority thread wasn't 
relinquishing resources like I had hoped it would.

> Yes, we did an external that analyses an audio buffer in non-realtime. It has to be done in the dsp thread because you need to guarantee access to the buffer~ you work on, so the trick is to pick an arbitrary amount of samples to process every dsp call.

> Up till now we didn't find a way to automatically increase this chunk size to utilize the processor maximally without causing clicks, but since we don't need the results in a fixed amount of time that doesn't form a real problem.

>
> Yes, we did an external that analyses an audio buffer in non-realtime. It has to be done in the dsp thread because you need to guarantee access to the buffer~ you work on, so the trick is to pick an arbitrary amount of samples to process every dsp call.
>
> Up till now we didn't find a way to automatically increase this chunk size to utilize the processor maximally without causing clicks, but since we don't need the results in a fixed amount of time that doesn't form a real problem.
>
> Mattijs
>


On Sep 20, 2006, at 1:28 PM, Bradford Garton wrote:

> I wish there were a way to fork and slice a low priority (i.e. 

> interruptible by Max/MSP if necessary) thread so that all you would 

> need to do is let it run and set a semaphore for when it finished. 

> For example, suppose I have recursive function "doitall()" to 

> calculate some arbitrary fractal gunk, and I don't know exactly how 

> long it will take to finish the calculation (or if it ever will, 

> thanks Alan Turing). I would like to simply kick it off and not 