Subject: MAX Digest - 14 Aug 1998 to 15 Aug 1998
Date: Sun, 16 Aug 1998 00:00:01 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
To: Recipients of MAX digests 

There are 15 messages totalling 656 lines in this issue.

Topics of the day:

  1. What's the deal? (2)
  2. Calling a preset in a encapsulated object (4)
  3. Calling a preset in a encapsulated object/alternative
  4. Double-clicking on a create object = nothing
  5. MAX reference
  6. Issues with the MSP 5 updater
  7. CodeWarrior 3
  8. Multiple Module Coll Memory System
  9. collX update - v1.3
 10. Question about MSP
 11. URL correction

McGill is running a new version of LISTSERV (1.8c on Windows NT).
Information is available on the WEB at


Date:    Sat, 15 Aug 1998 02:20:19 -0400
From:    Nicholas Longo <71477.2332@COMPUSERVE.COM>
Subject: Re: What's the deal?

Thanks for the answers about MPW.  I did downloaded CodeWarrior Lite,
which doesn't let me create new projects, so I figured it was useless.
Besides, I'm definitely  creating commercial applications, so what
appears to be a yearly licensing deal for CodeWarrior looks expensive
in the long term.

Apple supplies MPW free as an alternative to CodeWarrior.  This might
be a new policy, but it looks like they're supporting it, and also
providing a lot of documentation including tutorials and the full
text of Inside Macintosh in PDF format.  For anyone who's interested,
here is some information Peter Castine sent me.  I trust he doesn't
mind me reposting it.


Sure. If someone really wanted to, she could develop Max externals with
Pascal, FORTRAN, (compiled) LISP, Assembler, you name it. As long as you
can produce compiled code (and as long as the implementation of the
language lets you talk to the Mac Toolbox), you could go for it.

The problem with any non-C approach (and I'm coming back to MPW, Nick,
rest assured), is that you would have to re-write the glue to the API. In
other words, you'd need new versions of the .h files included with the
Max Externals developer kit, appropriate to your language and compiler,
that let your code access the function table Max hands as a pointer to
your entrance point (in C-speak, your main()).

Now, for all MPW C and CodeWarrior C (and don't forget THINK C; there's
also Gnu C for Mac, but last time I looked it fell down on the "talk to
Mac Toolbox" condition I mentioned earlier) ...for all these are the
"same" language, there are subtle differences in the implementation. Now,
I don't think these differences would actually have an impact on the .h
files used for the API, but you might have an unpleasant surprise.

There are at least two other areas where you need to roll with a few

1) Talking to the A4 world. For a while the current externals docs
included sections on how to do this with THINK C and with Code Warrior;
I'm not sure if the THINK-related examples are still with us. But this
will be different again with MPW, and you'd have to work out those
differences for yourself. Certainly doable with a good knowledge of the
Toolbox, reading the MPW docs, and a willingness to keep on re-booting
until you get it to work.

2) MPW is a development environment a Unix geek could (almost) love. If
you like makefiles and piping through grep, you'll _love_ MPW. MPW is not
an Integrated Develper Environment in the THINK tradition.

I'm not sure if talking to UPPs is a third issue. I think not, because
the Universal Headers with all the UPP stuff should be identical for MPW
and CW. But programming is full of surprises :-}

In short: Yes, but you'll have a chunk of extra work cut out for you.

If MPW is really a free compiler now (and this would be news to me...)
then presumably only because Apple is no longer supporting it. Which
means that someday the compiler won't help you when new machines come out
(I went throught this when I picked up a Logo many years ago, and the
Manx C disks I've got sitting around are of no practical value any more).
Which means that all that extra work you'll put into getting external
development running on MPW will be for naught some time down the road.

If you go for it, good luck. But maybe consider one of the books on
programming bundled with a Code Worrior disk.

Hope this helps,


Date:    Sat, 15 Aug 1998 12:04:49 +0200
From:    Jeffrey Burns 
Subject: Calling a preset in a encapsulated object

>I have create a patcher x with a preset object inside. If I open directly
>the patcher x I can change preset settings, etc. After, if I reopen this
>patcher x, the preset settings are here (you know because Save Presets
>with Patcher is check). But, if I want to use this patcher x within a
>patcher y (as a object) I can not retreive my new settings (if I have
>change it) when I
>reopen the patcher y (I hope this is clear). Every new settings disappear
>and the
>original settings of patcher x is here. Do I miss something? Anybody have
>ideas for
>this problem? I want to save the new settings in my top patcher.

Stephen Kay gave a good answer to this question. However, I have one more
idea about how to solve the problem. I use the patcher object. It creates a
subpatch which is saved within the main file, and - even if there a lot of
patcher objects - each subpatch may contain its own preset object which
saves presets specific to that particular subpatch.

Jeff Burns


Date:    Sat, 15 Aug 1998 12:12:04 -0000
From:    Nick Rothwell 
Subject: Re: Calling a preset in a encapsulated object

> If you're starting to
> develop a complex application, you should stop using the preset
> as quickly as possible and move to storing data in a coll object.

...or using my specially-designed registry object, at

I mean, hell, it would be nice to have someone else using it. I make
use of a lot of nested patchers and bpatchers, and objects with
complex state (bits of editor/librarians, arpeggiators and so on), all
of which store their state into parts of the registry directory

Perhaps the problem is that it's 680x0 only? I wonder if the
CodeWarrior Lite that Adam mentions will cross-compile from 680x0 to

        Nick Rothwell, CASSIEL            contemporary dance projects            music synthesis and control

  "Welcome to Moscow, Mrs. Gandhi."  -- Leonid Brezhnev to Margaret Thatcher


Date:    Sat, 15 Aug 1998 10:33:16 -0000
From:    Frederic Murray 
Subject: Calling a preset in a encapsulated object/alternative

>When you save your top patcher, you are *not* resaving the patcher y; =
>therefore you cannot save the presets.  This will never work.

>You must either: =

>- save the preset file to disk manually, then load it manually when
>opening the application/patcher;
>- use a coll file in your top level patcher to store your data, not =
>the preset.

>Presets are really only good for use in very simple, one level patchers.
>They become completely unworkable in situations such as yours, or
>(if you haven't tried it yet) bpatchers.  If you're starting to
>develop a complex application, you should stop using the preset
>as quickly as possible and move to storing data in a coll object.

>Stephen Kay

Thank you Stephen. I have find another alternative. I can make a B
patcher who
call my C preset patcher using load message to pcontrol (using loadbang).
when B patcher is open, C patcher is open immediately (as a real patcher
not a
object). So now, if I make a A patcher a create a B object, the C patcher
is open.
For closing C patcher automatically with my top patcher I use the same
process that
David Zicarelli answer me about shroud message:

>>Dear Maxers specialists, I can send a shroud message to pcontrol to
>>open a invisible patcher but NOW I want to CLOSE this invisible patcher.
>>Is it possible or I have to quit max for that?

>"closing" of patchers is done with the "dispose" message to thispatcher.
>You'll need to find a way to trigger this message in the desired
>patcher. With an invisible one, the best way is using send and

>David Z.

People refer to dispose message in Max Reference p.370 if it's not clear
(or send
me a English course with normal mail)

Also, what is the exactly difference between wclose message and dispose
message to

Frederic Murray


Date:    Sat, 15 Aug 1998 10:33:20 -0000
From:    Frederic Murray 
Subject: Double-clicking on a create object = nothing


I work with children and I want to hide some complicate tasks to them.
So, I create new objects for children. But, if the they double-clicking
in new objects the corresponding patcher window appear (hoooo what's
I know that if I put a ubouton on the object the patcher won't open in
lock mode. But the children have to work on unlocked and lock mode.
They create new patchers with this new objects. I also try to close
the window with a active object (with wclose to thispatcher) but it's

Can I use ResEdit or another trick for permanently HIDE THE CONTENT of new
objects? I remember someone talk about hide some windows but I not find

Thank for help

Frederic Murray
Etudiant en musique
Universite Laval, Quebec


Date:    Sat, 15 Aug 1998 07:32:32 -0700
From:    Jim Wood 
Subject: MAX reference

I wondered if MAX documentaion / Reference was
available as PDF document, save having to carry all
these books around everywhere??

Get your free address at


Date:    Sat, 15 Aug 1998 10:07:28 +0000
From:    David Zicarelli 
Subject: Issues with the MSP 5 updater

Trying to write an updater than can deal with everyone's
Max install is an interesting challenge. Here are some
"challenges" that haven't been addressed perfectly in the
latest MSP updater.

1. An early version of the MSP 5 updater may not have worked
properly on certain existing MSP installs, giving an error,
"Invalid file selected for updating." This has been fixed,
and the revised file is now on all the FTP sites. The file
name was changed to mspup5a.sit.bin from mspup5.sit.bin.

2. If you only have one copy of Max/MSP on the disks connected
to your system, you won't see a Select Folder button, since
there is nothing from which to choose. The updater has
found your copy of MSP, just go for it and install the

3. If you move your copy of Max Audio Library to the extensions
folder, the updater will show the extensions folder as the
place it plans to update your copy of MSP. This will
probably produce bogus results. (Yes, you *can* move your
Max Audio Library to the Extensions folder, and MSP will
still work, except that it might not load any audiodrivers.)

4. If you rename one or more of your MSP folders (audio, msp help,
etc.), the updater will not install the files destined for
those folders, and may not show an error.

David Z.


Date:    Sat, 15 Aug 1998 11:24:52 -0700
From:    Les Stuck 
Subject: Calling a preset in a encapsulated object

>I have [to] create a patcher x with a preset object inside.
        -Frederic Murray

>Presets are really only good for use in very simple, one level patchers.
>They become completely unworkable in situations such as yours, or
>(if you haven't tried it yet) bpatchers.
        -Stephen Kay


I agree with Stephan that "coll" is, in general, a much better solution.
However, Frederic's question is not entirely unreasonable and deserves
a somewhat more precise answer. But first of all, (sorry) a few definitions:

 Patcher: a Max document (containing objects and patch cords) that can be
 opened from within Finder.

 Sub-Patcher: a window which resembles a Patcher, but which is contained
 in and saved as part of the parent Patcher. It is created by typing the
 letter "p" in an object box.

 Abstraction: a Patcher whose name has been typed in an object box within
 a parent Patcher. It is not saved with the parent patcher, but it functions
 within the parent Patcher somewhat like a Sub-Patcher. Every time the
 Patcher is loaded, the Abstraction is loaded anew from its current version
 on disk.

 Bpatcher: an Abstraction, but in this case, when created in the parent
 the bpatcher object asks for the Abstraction file, and one can see the
insides of
 the Abstraction from within the parent Patcher. There are two types:

  Not Embedded: Functions like an Abstraction in that it is loaded
  anew every time the parent Patcher is loaded.

  Embedded: Functions like a Sub-Patcher, once it has been created
  in the parent Patcher. That is, changes made in a Bpatcher (you can't
  edit it, but you can store values in a "preset", for example) are
  saved with the parent Patcher.

An example of using presets effectively in bpatchers can be found in the
folder "MSP Examples : synth~ do it yourself" in the release of MSP.
"my synth~ module" contains a "preset"; "mySynth~ builder" contains
"my synth~ module" as an Embedded Bpatcher. In order to experiment,
you might want to add a number box in "my synth~ module", just below
the "open" and "save" buttons. The save "my synth~ module".

There are three ways to store presets:

 If you simply open "my synth~ module" and store values in the preset,
 they will be saved when you save "my synth~ module" and will be recalled
 when "my synth~ module" is used as a bpatcher in "mySynth~ builder".
 (Use the "Recall Preset" number box in "mySynth~ builder".) This will work
 even if you don't embed "my synth~ module".

 If you open "mySynth~ builder", and then open the Subpatcher "synthShell",
 you will see that you can specify a preset number and store it. You can
 enter new numbers in the number box (which you added to "my synth~
 store them as presets (from within "synthShell"), save "mySynth~ builder",
 close it and reopen it, and voila! the presets are still stored.

 Finally, to add security and flexibility to the system, you can use the
 "open" and "save" buttons in "my synth~ module". (Note that this works
 whether you open "my synth~ module" only, or as a bpatcher in "mySynth~
 builder".) The contents of the preset are stored as a disk file which can
 then be reloaded into any instance of "my synth~ module". Thus you have a
 backup of your preset data in case you make a mistake. Furthermore, if you
 store presets in "mySynth~ builder", but now you want to edit an embedded
 "my synth~ module" (oops!), just save the "my synth~ module" presets to
 make your changes to "my synth~ module", load the presets from disk, save
 "my synth~ module", and reembed it in "mySynth~ builder".

Whew! Now I'm very tired.



Date:    Sat, 15 Aug 1998 18:59:14 -0400
From:    Stephen Kay 
Subject: Re: What's the deal?

>Thanks for the answers about MPW.  I did downloaded CodeWarrior Lite,
>which doesn't let me create new projects, so I figured it was useless.
>Besides, I'm definitely  creating commercial applications, so what
>appears to be a yearly licensing deal for CodeWarrior looks expensive
>in the long term.
>Nick Longo

It's not a yearly licensing deal.  When you buy CodeWarrior Pro, you
get the current version and the next 2 upgrades.  There is nothing to =

stop you from halting your development at CodeWarrior "n" level and
just continuing to use that package for the rest of your life.

Now Nick, don't take this the wrong way, but let me get this straight:

- you're going to jump in and write "commercial" applications in C =

(for which you will probably want to charge people money)

- at least initially, this will be used to write max externals, which
I gather you have not done before.

- all of the written documentation and available example code for =

writing max externals are done with Metrowerks CodeWarrior, the =

world-wide standard Mac C/C++ Compiler (although "commercial").

- rather than buy this world-wide standard, which is a =

completely integrated development environment, with excellent tech =

support, documentation, and news group lists, with tens of thousands =

of people using it (including nearly everyone on this list who =

currently writes max externals)

you are going to go with a (probably eventually no longer supported)
[free, because no one will buy it anymore] Unix-like compiler/program =

which no one has ever used to write a max external.

I applaud your bravery - you've probably just extended the learning
curve by a factor of 5 - 10.  But isn't time worth money? =

(BTW - I don't work for Metrowerks, nor do I have any stock or interest
in the company :-)

Stephen Kay


Date:    Sat, 15 Aug 1998 18:59:05 -0400
From:    Stephen Kay 
Subject: Calling a preset in a encapsulated object

>I agree with Stephan that "coll" is, in general, a much better solution.=

>However, Frederic's question is not entirely unreasonable and deserves
>a somewhat more precise answer.
>Les Stuck

True, and thanks Les for the explanation.  I long ago got completely
frustrated with preset, and rarely even think about it anymore, other
than to plop one down in a patcher in progress to save the current
state of things before I go to bed.

However, I will say this to anyone who is interested:  it may be =

possible to make a preset work for awhile in your application, but
as it grows, and you add objects, remove objects, change the position
of things (oh, this will really screw it up!) the preset will stop
working and you will eventually lose your data.  =

A coll object easily handles any changes you may wish to make because
*you* are in control of where the data goes, and how it is stored.

I invite you to check out a completely programmed example of the
coll being used with multiple bpatchers on my web site, to be announced
in a subsequent (or preceding, depending on how it arrives)

Stephen Kay


Date:    Sat, 15 Aug 1998 18:59:15 -0400
From:    Stephen Kay 
Subject: CodeWarrior 3

BTW, while I'm on the CodeWarrior topic, has anyone made the
fairly recent move from IDE 2.0 to IDE 3.0?  Any problems?

Thanks, Stephen Kay


Date:    Sat, 15 Aug 1998 18:59:08 -0400
From:    Stephen Kay 
Subject: Multiple Module Coll Memory System

A picture may be worth a thousand words, but a patcher is
probably worth a few dozen pictures, so...

In response to those who have asked for my tutorial, I created
a rather complex working example and posted it to my web site.

Here is a release blurb:
Multiple Module Coll Memory System
An example patcher (tutorial) showing a system for collecting =

the data from many UI objects in different patchers or bpatchers =

("Multiple Modules") into a single coll file as a program of =

several lines. Each program can have a name, which appears in =

a popup menu of all the names for various programs. Programs =

may be saved, cleared, or entered, sending the various stored =

values for display in the correct UI objects in the various =

modules. The entire master coll file can be written to or read =

from disk, thereby allowing the user to save a complete "bank" =

of programs. Unlike use of the preset object, your data file =

can be edited as text, and adding/removing UI objects from the =

modules as your application grows is far easier than trying to =

do that with a preset object (which usually stops working =

after awhile).

This is not just a simple patcher, but a complex system that
I have developed and refined over the last 5 years, and used
extensively.  It can be easily modified to support multiple =

banks of presets, more/less modules, etc.

The example shows 4 different bpatchers, each with 8 UI objects
inside, sending and receiving data to a coll.  Each "program" is
4 lines of the coll file, with a 5th line containing the name
of the program, and some global parameters.

The URL is:

Enjoy, and I welcome any comments!

Stephen Kay


Date:    Sat, 15 Aug 1998 18:59:03 -0400
From:    Stephen Kay 
Subject: collX update - v1.3

Hello Maxers,

I have fixed a bad bug with binary file saves, and added the =

following messages (to collX, enhanced coll object):

- open: allows you to open the coll for editing with a message, =

same as double-clicking the object.

- autodump: after editing the text, if the user clicks "Save" in
the resulting dialog when the coll is closed, the contents will
be automatically sent out, as if a "dump" message had been issued. =

collX (v1.3) can be downloaded at:

Stephen Kay
---------------------- The MegaMAX Collection ----------------------
 Over 30 Max objects for the creation of more professional looking, =

         feeling, and functioning patchers and applications.


Date:    Sat, 15 Aug 1998 16:39:34 -0700
From:    Keay 
Subject: Question about MSP

  I have a question about something I saw at CNMAT back in March in
demonstrating some of MSP's capabilities. There was a young woman with
purple hair who had constructed a sound generating system using RC
servos and a cymbal.  Contact mic's attached to the cymbal picked up
the sounds made by the servos scratching and impacting the cymbal.
Then the sounds were somehow processed via MSP to make wholely
different kinds of sounds.
  What is happening here?  The sound are taken in through somekind
input object and the are they used to trigger Software oscillators or
are the sounds processed through somekind software DSP effects?
  I'm just looking for a basic outline for an answer.

SJSU School of Art & design


Date:    Sat, 15 Aug 1998 22:36:41 -0400
From:    Stephen Kay 
Subject: URL correction

Sorry, I may have given wrong addresses.

Multiple Module Coll Memory System:

collX v1.3 update

I always forget that the page on which you download them is
actually different from the directory in which the files
are located.

Anyway, they are pretty easy to find as you wander around
my site, I think.


Stephen Kay


End of MAX Digest - 14 Aug 1998 to 15 Aug 1998