5/11/97 11:01 PM
Subject: MAX Digest - 10 May 1997 to 11 May
1997To: Recipients of MAX digests 

There are 9 messages totalling 328 lines in this issue.

Topics of the day:

  1. AOL mail
  2. menus, efficiency etc
  3. Display list of objects used in a patch ? (2)
  4. rounding squares
  5. Photocells
  6. light sensors
  7. preset problems
  8. OMS programming question


Date:    Sun, 11 May 1997 00:51:37 -0300
From:    Alex Noyes 
Subject: AOL mail

Christopher Murtagh wrote:

> A strange thing has been happening. It seems that all of the subscribers
> with AOL accounts aren't getting their digest. I have been getting 20 or
> so bouncing back each day. If there are any AOL users who are getting this
> message through their AOL account please send me mail.

Although I'm not an AOLer, I've heard through other lists that they have
had some serious mail related problems over the last few days.


Date:    Sun, 11 May 1997 03:22:27 EDT
From:    Roland Hemming <100414.2220@COMPUSERVE.COM>
Subject: menus, efficiency etc

Peter wrote:

>I want to layer a round picture on top of another but I stll get
>the white square background corners of my circle showing.

You could try using Stephen Kays excellent collection of UI objects. Some of
these allow you to create custom buttons with your own pictures. A demo of
collection comes with MAX 3.5. This might help you solve your problem.

Stephen do you have them available for download for non 3.5 users?

>Can I assume that the less objects the better even if they are more
>complex ? Where is this list of object efficiency glossed over in the
>two pages ?

The trouble with a manual for a programming language is that efficancy is
largely on your programming style. I guess this is why efficency is glazed
I used to do exercises like writing a patcher to do something with 25
objects in
it and then try to make the patcher do the same thing using only 15 objects.

It seems to me though that the speed of the Mac can massively affect the
operation of your program. This may seem obvious but there is more to it.
say you are using a 40MHz Mac and Max uses 80% of the CPU just to run
You have 20% of the CPU left for your patcher to run. However if you use an
80MHz Mac, MAX uses 40% of the CPU leaving you with 60% left. This is a 6
speed improvement for your patcher just by doubling the speed of your Mac. I
know this is a simplistic view but it is far more important than minor
tweaks to

A MAX application of mine takes over 5 minutes to launch and load a file on
Powerbook 165, on my PPC 7500 it takes less than 30 seconds.

>So how do I get a file dialog to give the path to a Folder object ?

You can't. This is an ommision in my opinion but there are some issues here
do with how MAX's file search path works. Sometimes you can't get it to find
files outside the MAX folder. We tried to do this with our 'omenu' object
MAX won't let us. Maybe we should have another go...

David Z wrote:

>You might try using the Omenu object instead (to display 300 menu items)

Yes but there is one problem. If you have hundreds of items in an omenu, it
opens exponentially slower when you click on it.



Date:    Sun, 11 May 1997 01:15:43 -0700
From:    Le Quan Ninh 
Subject: Display list of objects used in a patch ?


Is there any way to display the list of all the objects used in a patch ?
That could be very useful when you copy a patch in an another machine.

l                                    l
l  l


Date:    Sun, 11 May 1997 12:37:01 +0200
From:    Jeffrey Burns 
Subject: rounding squares

Peter wrote:

>        I want to layer a round picture on top of another but I stll get
>the white square background corners of my circle showing.
>        I can do a transparent cornered gif, or in photoshop a
>transparent background, but what can I do in Max to get a transparent
>background colour so my corners dissapear ?
>        I don't want to use the internal max oval as I can't shade it or
>impose a picture on it. I also can't find a correct drawing mode as both
>the circle and the background are gradient shades and not solid colours.

As far as I know, you can only import a PICT from Photoshop into a Max
graphic window, and PICT's don't come in diffrent shapes or with holes in
them. Maybe you should try using a QT movie, if you need more than 8-bit



Date:    Sun, 11 May 1997 09:23:15 -0400
From:    Ken Mistove 
Subject: Re: Photocells

>I'm thinking about playing around with using photocells as additional
>triggers for my DrumKat. I have THE BEAM but I want more. Could someone
>send me a basic how to on creating a light sensitive trigger?
>Please keep in mind,
>1) I'm not an electronics technician of this nature (in other words I'm
>a dummy in this area) and
>2) I'm only willing to go as far as the local Le Shack (Radio Shack).

I'm using the I-Cube (not available from "Le Shack") and haven't located an
appropriate light trigger yet. To be honest I haven't spent much time. What
I'm looking for would be appropiate for the DrumKat as well as an Alesis D4
which I use. A photocell to the best of my knowledge will not do the trick.

The output you get from photocells will constantly be changing. In other
words it's always measuring the light level and sending out a coresponding
analog signal. While this might be good for sensing velocity it is not good
for generating triggers.

I see that Radio Shack sells alarm equipment. Among the components they
sell is an infrared light beam switch. When the beam is broken a switch is
thrown. I don't know details such as cost, power requirements and output
signal. It may do what you need.

There are a good set of links at the I-Cube site as far as sensor
technology goes. is
the address (it's actually the link page of the founder of the I-Cube

Good luck, I'll keep looking.


Ken Mistove


Date:    Sun, 11 May 1997 10:11:58 +0100
From:    Terry Nigrelli 
Subject: light sensors

> From:    Tommy DOG 
> Subject: Photocells?
> I'm thinking about playing around with using photocells as additional
> triggers for my DrumKat. I have THE BEAM but I want more. Could someone
> send me a basic how to on creating a light sensitive trigger?

Check out the I-cube. It has light sensors.


I believe it has light sensors as well.

Terry Nigrelli


Date:    Sun, 11 May 1997 12:55:54 -0400
From:    Steve Smith 
Subject: preset problems

ON Date:    Sat, 10 May 1997 00:30:34 +0100
From:    Terry Nigrelli 
Subject: preset problems

Terry... the following was submitted some time ago by Stephen Kay as a
means of using coll as a data storage to disk method.  A seperate grab is
not necessary (as you mentioned)  Good luck with it, it work's great for

Here are the writings of Stephen Kay.
I used to try to use the preset object in my applications and bpatchers and
up.  IMO, it is fine for quick, down and dirty savings of settings in very
simple, single-patcher patchers.  When you start getting into bpatchers,
multiple-patchers, and situations in which you want to keep modifying things
your application grows, it simply will not suffice.  When you modify a
say by adding another parameter, previous presets will not load, and your
is out the window.  You simply CANNOT modify a patcher and expect previous
preset files to work. Not to mention you've got multiple preset files for
different bpatchers.

One of the ways around this is to use a coll object to store your presets.

Let's say you have 20 parameters in a bpatcher.  Let's say you have 4
In each bpatcher you have a coll, where you _must_ previously store one line
20 parameters, and mark the coll for saving with patcher. However, if there
20 parameters, I usually store 21 parameters, where the address is "1" and
the first parm is a number corresponding to a number argument for the
For example, create this line in the coll:

1, 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20;

There will be a "funnel 21 1" connected to the coll, which is going through
"prepend sub 1" into a grab, then the grab is connected to the coll. (The
causes the sub command to work, but to not cause any output from the coll.)

The first inlet of the funnel is connected to an "int #1" and a loadbang.
causes the bpatcher's argument to get stored as the first number in the
Then the other 20 parms (usually UI objects) are connected to the next 20
of the funnel, either via patchcords or send/receives.  Therefore, each
parameter as it is changed is substituted into it's proper place in the one
of the coll. (The parameters are also connected to/sent to the parts of the
patcher where they actually do things, of course).

In the main patcher there is a "Memory" patcher which consists of a master
file.  Again, in this example there are 4 bpatchers, so 4 lines would
consist of
one "program".  A bank of 48 programs would consistitute 4x48 lines, or 192
lines.  I won't go through a lengthy explanation of what is needed to get
all of
this to work, but the concept is:

To save a "program", send a "1" to all the bpatcher's colls.  This will
the single line out of each of the colls.  Use the first arg of the line (in
this case, 1, 2, 3, or 4) + (program number * 4) as the address at which to
store the lines in your master coll. For example, program # 20 stores the 4
lines at 81, 82, 83 and 84. When storing the lines, keep the bpatcher's
as the first parm i.e.:
81, 1 n n n n ...n;
82, 2 n n n n ...n;
83, 3 n n n n ...n;
84, 4 n n n n ...n;

Sending a program uses the reverse scenario. Send out from the master coll
the 4
lines corresponding to your program. Use a route with the args 1 2 3 4 to
the 4 lines to the proper bpatchers.

Inside each bpatcher is an "unpack" with 20 arguments, corresponding to the
types of your parms; i.e. if all integers, "unpack 1 1 1 1 1 ...etc."  The
bpatcher receives its list from the master coll, and then the unpack
each parm to the proper receiver (generally the UI object that sets that
This also prevents loops, since the receiver then resubstitutes the number
the coll, which has no output because of the grab.

Then you can add parms, remove parms at any time, simply by modifying the
and unpack (remembering to add extra parms in the bpatcher's colls, since
can't substitute a number into a parm that doesn't exist).  Old presets will
still work, although you need to load and resave them with the new added
Even changing the order of parms can be done, because you can open the
coll file and edit the presets by hand if you must, since it's a text file.
user can then save the one master coll file to disk as a set of "presets".

It's a lot of work to get this system working smoothily, but once done, it's
only way to go.

Stephen Kay


Steve Smith


Date:    Sun, 11 May 1997 22:55:51 +0200
From:    Roby Steinmetzer 
Subject: Re: Display list of objects used in a patch ?

>Is there any way to display the list of all the objects used in a patch ?
>That could be very useful when you copy a patch in an another machine.
You have a list of all the objects displayed in the Max window while being
in edit mode and selecting "Get info..."
Of cause no object has to be selected.

Roby Steinmetzer
Luxembourg, Europe


Date:    Sun, 11 May 1997 16:02:31 +0000
From:    Tod Fiste 
Subject: OMS programming question


This isn't exactly a Max question, but I figure there are probably
people on this list who know the answer.

I've been learning C and I've been playing with OMS.  The manual says
that there are 3 structures for receiving MIDI data: OMSPacket,
OMSMIDIPacket, and OMSMIDIPacket255.  I'm trying to use OMSMIDIPacket255
to receive some sysex messages, but try as I might I can't figure out
how to get it to send me more than 3 bytes of data at a time.  In other
words, it's acting the same as the other two structures.  I've gone
through the OMS spec document with no enlightenment.

Does anyone have any code that uses OMSMIDIPacket255 that I could look
at to help me figure out what I'm doing wrong?  For that matter, does
anyone know if it even works?  Barring that, does anyone know of any
lists similar to the Max list for MIDI programmers?

Thanks in advance,



End of MAX Digest - 10 May 1997 to 11 May 1997