Subject: MAX Digest - 1 Dec 1999 to 2 Dec 1999 (#1999-344)
Date: Fri, 3 Dec 1999 00:00:21 -0500
Automatic digest processor <LISTSERV@LISTS.MCGILL.CA>
Reply-To: MAX - Interactive Music/Multimedia Standard Environments <MAX@LISTS.MCGILL.CA>
To: Recipients of MAX digests <MAX@LISTS.MCGILL.CA>

There are 16 messages totalling 672 lines in this issue.

Topics of the day:

  1. pluggo plug ins & vst obj
  2. more usb audio/noisy pb
  3. getting spaces out of symblos
  4. jMax or Pd?
  5. fiddle~ 1.1 and bonk~ 1.1
  6. max and usb
  7. G4 Installation problems
  8. MAX Digest - 30 Nov 1999 to 1 Dec 1999 (#1999-343)
  9. Audiodesk
  10. subdividing an integer?
  11. MOTU 2408 problems
  12. MAX and USB compatibility
  13. subdividing the integer
  14. pasture time?
  15. Max on an iMac? (2)


Date:Wed, 1 Dec 1999 19:27:38 -0700
From:jhno <ear@SIRIUS.COM>
Subject: Re: pluggo plug ins & vst obj

>i must have miss something but i really don't understand whether and how it
>is possible to use the pluggo plugins within max/msp.

at the moment, it is not possible to use pluggo plug-ins inside of max/msp.
there are some very sticky technical reasons why this is the case.

david z. has indicated that he will address this in a future release. when
pluggo works inside of max, it will have the interesting effect of creating
an alternative encapsulation technique for max/msp programmers. right now,
all hierarchical encapsulation is based on sub-patchers and bpatchers,
which have their own conventions for communication and scope (inlets,
send/receive, etc.). pluggo plug-ins provide an alternative convention for

this will all get more interesting as "synthesizer" vst plug-ins become
available. one could imagine a system created in max that lets you control
multiple synthesis/sampler/generative sound source vst plug-ins and route
their audio through any number of sound processing vst plug-ins.

as i see it, the advantage to the plug-ins approach is that the "objects"
(i.e., plug-ins) are big, easily understandable chunks of synthesis or
processing capabilities... much like hardware devices in a recording
studio. each one has its own character, and a set of functionality that is
stable and well-known. this facilitates our symbolic cognitive assiciation
process and we have an easier time constructing and maintaining a map of
the audio system's architecture in our mind.

to put it a different way, plug-ins are accessible to people because they
seem like one "thing" which has a certain number of capabilities, and
allows a certain degree of control. it has a certain number of inputs and

of course, the subversive-minded among us will always find ways to use them

in an unexpected way - a working ethic to which pluggo itself is a living
testament... :)

i think this idea of "level of encapsulation" reveals an interesting
spectrum... an axis along which audio/musical tools can be placed. as a
musician, i like to work in whatever part of the spectrum is most
appropriate to the music i am making. i think max/msp occupies a
particularly sweet spot that allows extraordinary flexibility while still
providing some existing structure to work with.

here are some sound sources, and the position they occupy in the
encapsulation dimension:

greater encapsulation <----------------------------> less encapsulation


since encapsulation "hides" complexity, this axis is strongly correlated to
that of "accessibility" - or "novice user <--------------> expert user"
above. when designing musical systems and interfaces, you have to decide
what level of encapsulation to expose to the user - even if the user is
yourself. i have certainly been the victim of my own overly-complex,
under-encapsulated interfaces when i get around to using them in live

as an aside: there are interesting parallels to be observed in all forms of
art and expression... i.e., how much of a given piece of work is composed
of elements that were already assembled by someone else? of course, this
type of analysis also applies to software, architecture, biology...

if you open up "someone else" to allow non-human participants, it becomes
yet more interesting...

waxing philosophical,

() ))(((( ))) ))))) ( )((()) (( ))( )) (((( )(()( (()
san francisco, ca


Date:Wed, 1 Dec 1999 00:15:16 -0800
From:Charles Shriner <ccps@IQUEST.NET>
Subject: Re: more usb audio/noisy pb

I tried to order one today. The Mac version will be available
in 8 they say. ASIO driver will be included

> roland ua30 looks like a reasonably inexpensive audio solution for noisy
> powerbooks. is anybody using it yet?

Office 317-926-0773
OMS users: Follow this link & sign the petition
to save OMS

Boycott Gibson products
Follow this link for more info:


Date:Thu, 2 Dec 1999 00:43:08 -0500
From:Stephen Kay <sk@COMPUSERVE.COM>
Subject: getting spaces out of symblos

>Pretty smart. Do you know how to get rid of the space that a message box=

>containing append $1 always adds when tacking on symbols to previous

>Jeff Burns

Actually, yes, come to think of it. But it requires my 'ListToSymbol'
object (freely available at

Here's an example on how to do it (assuming you have the object):
In other words, each time you bang a message box full of things separated=

by spaces, ListToSymbol outputs the same thing with all the spaces =

removed. You can also have ListToSymbol insert dashes, underscores,
or whatever you want between each symbol.

Stephen Kay

max v2;
#N vpatcher 50 40 453 568;
#P message 242 78 53 196617 append \$1;
#P number 242 53 35 9 0 0 0 3;
#P button 215 79 15 0;
#P message 126 64 44 196617 set fred;
#P message 36 205 259 196617;
#P newex 36 179 60 196617 prepend set;
#P button 9 77 15 0;
#P newex 36 153 69 196617 ListToSymbol;
#P message 36 128 257 196617 fred;
#P number 36 51 35 9 0 0 0 3;
#P message 36 76 58 196617 prepend \$1;
#P comment 119 49 100 196617 to start over;
#P connect 2 0 5 0;
#P connect 2 0 1 0;
#P connect 9 0 3 0;
#P connect 11 0 3 0;
#P connect 8 0 3 0;
#P connect 5 0 3 0;
#P connect 1 0 3 0;
#P connect 3 0 4 0;
#P connect 4 0 6 0;
#P connect 6 0 7 0;
#P connect 10 0 9 0;
#P connect 10 0 11 0;
#P pop;


Date:Thu, 2 Dec 1999 00:55:19 -0500
Subject: Re: jMax or Pd?


i've done some puttering around with both on linux-pentium systems, so
here's my two cents, for what they're worth:


jmax is in my experience a bit of a drag to install, though in all
fairness it's probably more the fault of the way in which i installed the
jdk than the way ircam's script works. that said, it took me
about three or four hours of tinkering to get it to run. pd (and mark
danks' really neat opengl extension set, gem) pretty much unpack and
compile. so if you're at all unix-hostile pd might be the path of least
resistance. also pd/gem run on nt with no real problems provided your nt
distribution is moderately stable. mine isn't these days, so i'm sticking
with linux.

if you've got them both running then you're in pretty good shape, and you
can probably take your pick. here are a couple comments, and depending on
what you want / need to do you can then make a slightly more informed
decision, though if anyone on the list has a gripe with what i say then
please feel free to correct me:

jmax vs. pd

jmax has a reasonably slick interface, and if you use max/msp (or ispw
max/fts) you will find maneuvering around to be a reasonably familiar
experience. there is a tool bar with the usual object / inlet / outlet /
checkbox / etc. configuration. the bells and whistles of max a la
zicarelli (re-sizeable re-scaleable sliders, cnmat multisliders, quicktime
movies, pict files, etc.) are missing from the ui experience, though the
api might support them if someone wants to do the coding in the future.

pd, by contrast, is quite spartan. everything is accessed by menus, and
there are no 'user-interface' objects, per se, so if you want the
equivalent of a button object you make a message box and type the word
'bang' into it -- when you click it, the object will send out a bang.

syntactically, jmax uses an expanded language based on max/fts for the
ispw. what this means for the max/msp user is that if you search through
the documentation you'll discover that a lot of the objects have the same
names and functions, but that quite a few (most noteably the signal
objects) either have different names (cycle~ in msp is osc1~ in jmax) or
work in a slightly idiosyncratic manner (fft~ and line~, though they do
ostensibly the same thing in both msp and jmax, have an improved level
of functionality in msp, for example). jmax can read ispw patches (and
thus, in a slightly handicapped way, max/msp patches if you save them as
text), but writes out its own binary file type.

pd is lexically more compatible with max/msp than you might initially
think, and is actually a little improved in that it's less heavily typed
than other versions of max (i.e. pd doesn't really discriminate too
heavily between signal-rate and control data -- which is nice if you want
to make an oscillator or envelope follower control an image rotation in
gem, for example). gem, which lets you do opengl rendering and is _very_
cool, is one big functional bonus for pd that both jmax and max/msp lack
in the standard package. pd reads and writes .pd files, which are text
files using the same #? syntax as max text files but use #X for pretty
much everything and can really screw up if you try to open them in

both distributions have an api of sorts (ircam's is a bit more complete
and well documented, but also looks a lot harder to dive into -- miller's
objects are simple C routines which you can probably whip up and compile
into the package pretty easily, whereas the jmax api looks pretty deep).
the fact that both are open source means you can pretty much steal code
and fiddle around until you get the hang of things -- i haven't tried this
so i could be wrong here.

as for performance, your p166 probably won't cut it for anything really
serious using either pd or jmax, though i'm sure it's plenty fast for
doing simple synthesis / time-domain signal processing / etc. i'd love to
see some benchmarks at some point.

that's about all i have to say on the matter. my only closing opinion is
that until either platform has a large body of user-related documentation
and support groups (i.e. this list), using either platform for a mission
critical project is probably inadvisable if you've got a macintosh and a
max/msp installation to spare. i have a lot of hope for pd especially,
since i think it's a neat paradigm for generic data manipulation, and i'm
sure things can only get better.

speaking of which...

why the hell doesn't the swedish post office ever send _me_ pentiums?



R. Luke DuBois
Graduate Teaching / Research Assistant,
Computer Music Center, Columbia University
phone:(212)-854-9266 (cmc - prentis)
(212)-854-7181 (cmc - dodge)


Date:Wed, 1 Dec 1999 22:39:57 -0800
From:Ted Apel <tapel@UCSD.EDU>
Subject: fiddle~ 1.1 and bonk~ 1.1

Small updates of fiddle~ and bonk~ for MSP are available at

Please send any bug reports to me at


Ted Apel


Date:Wed, 1 Dec 1999 23:46:10 -0800
From:Erick Gallun <erick@EAR.PSYCH.BERKELEY.EDU>
Subject: max and usb

>Will MAX recognize anything (ie. a controller) via a MIDI-USB

yes, my usb midisport2x2 works fine.


Date:Thu, 2 Dec 1999 10:03:45 +0100
From:Trond Lossius <Trond.Lossius@BERGEN.IT-AKADEMIET.NO>
Subject: Re: G4 Installation problems

> I just tried to install Max 3.59 on my G4 450 Mhz machine running OS 8.6.
> I've found that no matter what I do, the application crashes the computer
> upon running it.

> Anyone else experience similar G4 nightmares and come up with a solution?

I had similar problems installing bundled Max/MSP and managed to solve them
using a Yano UFD-03
USB floppy drive:

1) Download and install the latest PACE hack to solve USB compatibility
problems (there's a link at the Cycling'74 homepage).

2) Insert Max/MSP floppy (it is important that the floppy is inserted before
you start Max)

3) Start Max. You will now be able to authorize Max but not MSP.

4) Quit Max, eject the floppy and insert it once more.

5) Start Max once more. This time you will be able to authorize MSP.

Trond L.


Date:Thu, 2 Dec 1999 02:49:48 -0800
From:"|K<" <kent@SHOKO.CALARTS.EDU>
Subject: Re: MAX Digest - 30 Nov 1999 to 1 Dec 1999 (#1999-343)

>The Yamaha DSP-F would be a great MSP interface *IF* it had working ASIO
>drivers + OMS driver for access to all the mixer and fx features. Is
>anybody here using one successfully with other Mac applications?
>(Yamaha's Japanese site seems confident it works on Mac with Cubase,
>Logic, Vision etc.)

I've tested the DSP-F and sent it back immediately. reducing the ASIO
buffers to under 2048 causes severe audio damage, and keeping them at 2048
causes severe latency. you HAVE TO run the 'mixing desk' program
alongside your ASIO host program in order for the ASIO drivers to work at
all [and not freeze your machine]. for my purposes this card was useless.
my colleagues who have also tested this card on windows reported that the
latency was far too high to be usable for realtime music purposes.



Date:Thu, 2 Dec 1999 07:17:45 -0500
From:Bob Gluck <gluckr@RPI.EDU>
Subject: Audiodesk

>On Wed, 1 Dec 1999, Neal Farwell wrote:
>> BTW, off-topic for MSP, apparently the 2408 lets you use it, with the
>> noisy computer turned off, as a format converter, eg analogue to 44.1k
>> SPDIF - good if you've an older 48k-only DAT machine. Does anyone have
>> experience with Motu's AudioDesk program?

I just completed a piece using Audiodesk. It worked fine. Nothing flashy.
Reason I used this App was that the manual stated that one can convert the
files, using a Digidesign utility (OMF Tool), to a format that can be read
by Pro Tools. Unfortunately, it turned out that the latest version of OMF
Tool doesn't support automated fades and volume changes, so I had to bounce
to one stereo track to open it in PT in order not to lose all of this data
(thus, I gave up on this option). It doesn't accept VST plug-ins, leaving
me using my Premiere plugs, which are more limited, but did the trick. But
the end result sounds decent enough to me.

Bob Gluck

"Ancient sky watchers saw the heavens as a kind of cosmic sculpture garden,
eternal and unchanging. But modern astronomers who study huge explosions
called gamma ray bursts are discovering a universe that is more like a
wild, all-night disco party." (J. Glanz, NY Times, 10/26/99)


Date:Thu, 2 Dec 1999 23:01:27 +0900
From:Takahiko Suzuki <takahiko@SHOTGUN.PHYS.CST.NIHON-U.AC.JP>
Subject: Re: subdividing an integer?

Hi Steve,

> </fontfamily>Your patch works fine except I want to be able to specify
> how many sub-divisions there are, so it is not fixed at 3
> sub-divisions. The number of sub-divisions should be a variable.

This algorithm is recursive, so I don't think it is possible to implement
this algorithm in Max as a generic patch in usual manner, because Max does
not CALL functions, Max LOADs functions. If you don't specify two numbers,
i.e. one of the numbers are fixed, it is possible like the one of
Sukandar's. I think there are two possibilities for realize this algorithm,
one is patching dynamically using 'thispatcher' object, but in this way, bit
scarely for use in realtime performance. Another is implement algorithm as
an external.

let' express [p, q] for subdividibg the number p into q divisions.

[p, q]

1:p-q+1 and [q-1, q-1]
2:p-qand [q, q-1]
3:p-q-1 and [q+1, q-1]
4:p-q-2 and [q+2, q-1]
n:p-q+2-nand [q-2+n, q-1]

in generic form, it will be expresssed as

i:p-q+2-iand [q-2+i, q-1]

where i is an index number. and n, last index, must be

(q-1)(p-q+2-n) >= q-2+n

This condition comes from "one number is not 1 and all the rest are 1" and
this condition can be written as

n <= p-q+2-p/q

Hope this helps...


T a k a h i k oS u z u k iGuitarist/Composer

e-mail :

web :


Date:Thu, 2 Dec 1999 10:52:55 -0800
From:Ian Knopke <iknopk@PO-BOX.MCGILL.CA>
Subject: MOTU 2408 problems

>On Wed, 1 Dec 1999, Neal Farwell wrote:
>> BTW, off-topic for MSP, apparently the 2408 lets you use it, with the
>> noisy computer turned off, as a format converter, eg analogue to 44.1k
>> SPDIF - good if you've an older 48k-only DAT machine. Does anyone have
>> experience with Motu's AudioDesk program?
>>I've had a 2408 from since they came out. It is a great unit, probably
>>the best piece of audio hardware I have ever bought for my computer. And
>>the format convert / standalone mode is also great. You can convert TDIF
>>to lightpipe or SPDIF and back again all without turning on your

The only problem that I have noticed with the MOTU 2408 was a tendency for
MAX/MSP to crash or not function on certain patches involving various FFT
oriented objects. Everything worked fine once the sound manager was used instead.
The problem was first noticed by Philippe Depalle, who would bring patches in for
his class which worked on other machines, including his portable G3, but not on
the class machine with the 2408. I posted a message to the list on his behalf
some time ago, but apparently no one else has had similar difficulties. The only
other thing was a tendency for some of the menu options in the included
configuration utility to "dissappear" or become stuck on occaision, which would
go away after rebooting. Other than that it seems like a great unit which does an
amazing amount for the price.

Ian Knopke


Date:Thu, 2 Dec 1999 11:22:49 -0800
From:Bruce Alexander <balexander@INTOUCH.BC.CA>
Subject: Re: MAX and USB compatibility

On Dec 1 James Barry <BarryJC@CARDIFF.AC.UK> asked:

>In brief, can anyone tell me of their experience using Opcode Max
>on an iMac?
>My reason for asking is because I read the MAX "Getting started"
>manual on Opcode's website, and was concerned to see no
>mention of support for USB - only serial and modem ports referred
>Will MAX recognize anything (ie. a controller) via a MIDI-USB

In brief too, yes.

I'm using an opcode MIDIport 32 and have no trouble with my iMac and
Max/MSP. Make sure you have OMS 2.3.7 or higher and it will all work
without tears of frustration.

Bruce Alexander.


Date:Thu, 2 Dec 1999 13:02:12 -0800
From:Peter Elsea <elsea@CATS.UCSC.EDU>
Subject: subdividing the integer

>true enough

>actually if I were to implement what Steve really had in mind I'd go external
>however, I'd be curious to see a Lobject implementation

So would I. I can't think of anything in the Lobjects that addresses this
kind of task directly. Lrun is handy for generating number series, and with
[expr $i2 - $i1] (where Lrun and expr $i2 gets the input N) you can
generate series pairs that always add up to a given N. You can even cascade
these things so that for each pair generated, you substitute a
complementary series pair for the first number, generating a set like this
for two stages with input 5:
[32] 122
I've also found a scheme for eliminating reordered duplicates by filtering
for monotonic sets (allowing only those in which a member is >= the one to
its left), leaving

I don't have the math skills to prove that this technique is correct for
all input- it seems to work for small values.

But the problem is scalability. If you want 4 subdivisions, you need a
three module patcher, for each extra subdivision, an extra module is
needed. I suppose a recirculating scheme is possible (using loop as the
driver) but my first attempts became pretty ugly fast. I have built a
version that has different inputs for different numbers of subdivisions. (
but that's not totally satisfactory either.) This is where procedural
languages like C and Lisp really shine- once you've solved a problem on a
small scale, going to the large scale is usually simple. If I were to
tackle this problem in something like C. I'd try the following algorithm:

to subdivide a number N into Y integers whose sum is N
use an array n[1]...... n[y-1] and an integer X which is always kept at N -
(in other words for a five part division of 10, start with 1 1 1 1 6)
increment n[y-1], calculate X and check for monotonicity. If it's
monotonic, you have another valid set of numbers- output it and increment
n[y-1] again.
If the result is not monotonic, increment n[y-2] and set n[y-1] equal to
it- calculate X and test. Work backwards through the array until you find
yourself trying to increment n[0]- at that point you are done.

7 sub_by 3 calcualtes like this

1 1 5
1 2 4
1 3 3
(1 4 2 fails because it's not monotonic- note that we've already seen this
2 2 3
(232 fails)
(3 3 1 fails and we are finished)

In C this would be done with an array and a few pointers, and the code for
dividing into 18 components looks just like that for 2. It would be very
easy to debug in codewarior, because you can show the variables and watch
them as the programe setps. (displying thig is very quick and easy in Max,
but complicates the window. Also, it's trivial to add input range checking
as was also requested.

Max is wonderful for what it does, but we must recognize its limitations
and be ready to pick up other tools.
Peter Elsea

Director, Electronic Music Studios
University of California, Santa Cruz


Date:Thu, 2 Dec 1999 20:39:46 -0000
From:Nick Rothwell <nick@CASSIEL.COM>
Subject: Re: pasture time?

> I'm thinking it might be time to put the lib object and its
> friends out of their misery.

Fine by me. I never found the file handling quite sophisticated enough
to be totally usable, and the GUI ergonomics of the patch list windows
were always a little odd. Yeah, cut it all free...


Nick Limited
systems - composition - installation - performance


Date:Thu, 2 Dec 1999 20:32:04 +0100
From:Kasper T Toeplitz <kasper@CLUB-INTERNET.FR>
Subject: Re: Max on an iMac?

>In brief, can anyone tell me of their experience using Opcode Max
>on an iMac?
>Will MAX recognize anything (ie. a controller) via a MIDI-USB

It works very well, even with USB. Nothing to complain about here

Kasper T Toeplitz
Compositeur &Bassiste Electrique


Date:Thu, 2 Dec 1999 13:58:50 -0800
From:"Michael P. Whyte" <matrix6k@YAHOO.COM>
Subject: Re: Max on an iMac?

--- Kasper T Toeplitz <kasper@CLUB-INTERNET.FR> wrote:
> >In brief, can anyone tell me of their experience using Opcode Max
> >on an iMac?
> >Will MAX recognize anything (ie. a controller) via a MIDI-USB
> >interface?
> It works very well, even with USB. Nothing to complain about here
no complaints here either. I just wish this silly thing had audio in....
btw: roland super usb 4x4 works fine.

Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping:


End of MAX Digest - 1 Dec 1999 to 2 Dec 1999 (#1999-344)