nick rothwell | project cassiel

> in this vein, why are there so many mac-only externals, patches, 

> etc.? why isn't max/msp components compatible across all platforms 

- Max was Mac-only for, what, fifteen years? A lot of externals go 

back a long way, in terms of source code and compiler options, even 

if they have been recompiled for PPC and OS X. (True, for instance, 

of my registry object, which I wrote about ten years ago; that's 

680x0 to PPC, OS 9 to OS X, and THINK C to Symantec C++ to 

- Some of us don't have Windows machines. (I only have one now 

because the gallery for which we're doing a media installation is a 

Windows-only shop.) I have no use for a Windows machine, and I'm 

still waiting for somebody to pay me to buy one and port my externals.

- These days I'm doing all my externals, or "heavy lifting" code for 

Max/MSP, in Java. This is cross-platform by default (assuming an 

absence of careless coding involving filenames) and for non- 

pathological examples has performance close enough to conventional 

compiler output to make "going native" with development pretty much 

So much for externals. What Mac-only patches have you come across?

nick rothwell -- composition, systems, performance -- 

> in this vein, why are there so many mac-only externals, patches,  
> etc.? why isn't max/msp components compatible across all platforms  
> by now?

- Max was Mac-only for, what, fifteen years? A lot of externals go  
back a long way, in terms of source code and compiler options, even  
if they have been recompiled for PPC and OS X. (True, for instance,  
of my registry object, which I wrote about ten years ago; that's  
680x0 to PPC, OS 9 to OS X, and THINK C to Symantec C++ to  
CodeWarrior to XCode (almost).)

- Some of us don't have Windows machines. (I only have one now  
because the gallery for which we're doing a media installation is a  
Windows-only shop.) I have no use for a Windows machine, and I'm  
still waiting for somebody to pay me to buy one and port my externals.

- These days I'm doing all my externals, or "heavy lifting" code for  
Max/MSP, in Java. This is cross-platform by default (assuming an  
absence of careless coding involving filenames) and for non- 
pathological examples has performance close enough to conventional  
compiler output to make "going native" with development pretty much  
obsolete. (IMHO.)

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


mac-vs-pc-coding-re-re-about-granular-synth

This is really intriguing to me, it makes me much more interested in playing around with Java and Max/MSP/Jitter.

You end it by saying "IMHO". Considering you've done both (compiled externals and Java), I trust your feedback. But can someone from Cycling74 comment on this? Is Java a "close-enough" alternative for someone who wants to avoide compiling externals?

Quote: nick rothwell / cassiel wrote on Fri, 03 February 2006 12:55

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

> - These days I'm doing all my externals, or "heavy lifting" code for 

> Max/MSP, in Java. This is cross-platform by default (assuming an 

> absence of careless coding involving filenames) and for non- 

> pathological examples has performance close enough to conventional 

> compiler output to make "going native" with development pretty much 

You end it by saying "IMHO".  Considering you've done both (compiled externals and Java), I trust your feedback.  But can someone from Cycling74 comment on this?  Is Java a "close-enough" alternative for someone who wants to avoide compiling externals?

Quote: nick rothwell / cassiel wrote on Fri, 03 February 2006 12:55
----------------------------------------------------
> - These days I'm doing all my externals, or "heavy lifting" code for  
> Max/MSP, in Java. This is cross-platform by default (assuming an  
> absence of careless coding involving filenames) and for non- 
> pathological examples has performance close enough to conventional  
> compiler output to make "going native" with development pretty much  
> obsolete. (IMHO.)


> can someone from Cycling74 comment on this? Is Java a "close-enough" alternative for

> someone who wants to avoide compiling externals?

Probably. Like Nick, in my personal Max work I pretty much completely

avoid C. Java excecutes zippily and I find I write 1. more code and

2. better code than I do in C. For people looking to make their own

externals, I think learning Java is a great way to get started. If

you do eventually decide that you need to use C, most of what you

learned in Java-space will be applicable.

> can someone from Cycling74 comment on this?  Is Java a "close-enough" alternative for
> someone who wants to avoide compiling externals?

Probably.  Like Nick, in my personal Max work I pretty much completely
avoid C.  Java excecutes zippily and I find I write 1. more code and
2. better code than I do in C.  For people looking to make their own
externals, I think learning Java is a great way to get started.  If
you do eventually decide that you need to use C, most of what you
learned in Java-space will be applicable.

On 4 Feb 2006, at 16:58, Adam Kendall wrote:

> You end it by saying "IMHO". Considering you've done both 

> (compiled externals and Java), I trust your feedback.

I probably didn't mean IMHO - I meant YMMV.

Right now I'm building a lot of applications which are, design-wise, 

dual MaxMSP/Java in construction. (Current project is a surround- 

sound exhibit interfacing to a gallery's media LAN, so it's half- 

MaxMSP for the audio buffering and playback, and Java for the XML 

processing, HTTP transport and OSC control.) I have a healthy respect 

for the performance impact of the JNI bridge between Max and Java, so 

I keep that protocol pretty sparse and simple, and have the Java 

world and MaxMSP world pretty modular and loosely coupled. (All my 

OSC processing happens in the Java world, for example, and the 

surround control is using Java threads and timers rather than the Max 

A while ago I wrote some sample trigger/algorithmic sequencer type 

things which were much more timing-critical, and found performance to 

be a little bit choppy on my 1GHz TiBook, but absolutely fine on a 

3GHz PC, so it also depends how much iron you throw at it.

I've not done a great deal of audio-in-MXJ so can't comment on that, 

other than to say that my TiBook was working hard to keep up. I think 

there's still a strong argument for "real" externals for audio.

> You end it by saying "IMHO".  Considering you've done both  
> (compiled externals and Java), I trust your feedback.

Right now I'm building a lot of applications which are, design-wise,  
dual MaxMSP/Java in construction. (Current project is a surround- 
sound exhibit interfacing to a gallery's media LAN, so it's half- 
MaxMSP for the audio buffering and playback, and Java for the XML  
processing, HTTP transport and OSC control.) I have a healthy respect  
for the performance impact of the JNI bridge between Max and Java, so  
I keep that protocol pretty sparse and simple, and have the Java  
world and MaxMSP world pretty modular and loosely coupled. (All my  
OSC processing happens in the Java world, for example, and the  
surround control is using Java threads and timers rather than the Max  
scheduler.)

A while ago I wrote some sample trigger/algorithmic sequencer type  
things which were much more timing-critical, and found performance to  
be a little bit choppy on my 1GHz TiBook, but absolutely fine on a  
3GHz PC, so it also depends how much iron you throw at it.

I've not done a great deal of audio-in-MXJ so can't comment on that,  
other than to say that my TiBook was working hard to keep up. I think  
there's still a strong argument for "real" externals for audio.

Mac-vs-PC coding [Re: Re: About Granular Synth]