Subject: MAX Digest - 24 Jul 1998
Date: Sat, 25 Jul 1998 00:00:00 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
To: Recipients of MAX digests 

There are 6 messages totalling 220 lines in this issue.

Topics of the day:

  1. MAX Digest - 23 Jul 1998 to 24 Jul 1998 - Special issue
  2. table LFO errors
  3. MAX interface term in french/lcd for? (2)
  4. Order of Execution (me first?)
  5. Message order

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


Date:    Fri, 24 Jul 1998 22:27:38 +0200
From:    dudas 
Subject: Re: MAX Digest - 23 Jul 1998 to 24 Jul 1998 - Special issue

Stephen Kay writes:

>Thanks, Richard, but the 2 "tricky" examples of storing directly to
>a table (right side of patch) do not work, giving error messages like:
>expr: store: need a table name
>* error: expr_bang: unrecognized result 1543634178

strange. are you giving it negative numbers????

I will check this one out.



Date:    Fri, 24 Jul 1998 17:28:05 -0400
From:    Stephen Kay 
Subject: Re: table LFO errors

>>Thanks, Richard, but the 2 "tricky" examples of storing directly to
>>a table (right side of patch) do not work, giving error messages like:
>>expr: store: need a table name
>>* error: expr_bang: unrecognized result 1543634178

>strange. are you giving it negative numbers????

No, I'm just clicking on the enticingly placed bangs connected to the
Uzis.  Is it possible that some intricacy of the expr formula was lost
by being pasted into an e-mail?

Also, opening the patch produces the following message (although this =

is probably not an error):
warning: cosine: can't open

Stephen Kay


Date:    Fri, 24 Jul 1998 20:59:48 -0000
From:    Frederic Murray 
Subject: MAX interface term in french/lcd for?


I want to make a french WEB sit dedicated to MAX. I try to traduct
some interface terms in french, but it is not easy.
Here is the terms:

patcher =
toggle =
inlet =
outlet =
preset =
patcher-in-box (bpatcher) = ouf!
script-driven Envelope =
graphic switch =
graphic gate =
increment/decrement =
Keyboard slider
Range bar =

Finally a question, the letter lcd is for ?

Any help is welcome, please email-me personally if you want.

Thank you

Frederic Murray
Etudiant en musique
Universite Laval, Quebec


Date:    Fri, 24 Jul 1998 23:09:03 -0400
From:    Stephen Kay 
Subject: MAX interface term in french/lcd for?

>Finally a question, the letter lcd is for ?

Liquid Crystal Display. =

Stephen Kay


Date:    Fri, 24 Jul 1998 20:32:39 -0700
From:    David Zicarelli 
Subject: Order of Execution (me first?)

So here's a little story.

I recently did an interview with Carl Stone for a Japanese magazine
called Sound & Recording, in which he asked me questions related to
the whole right-to-left order of execution thing in Max,
and I said something like, "This has been fixed, there are no more
bugs, use it with confidence."

A couple of days before I receive a copy of the magazine with the
interview in the mail, Richard Dudas and some other people ask me at
the Max/MSP Night School about whether I would use a trigger
object or depend on the sorting of fanned patch cords from
a single outlet. I make the claim that all of the problems
have been fixed with patch cord sorting, or at least, no one
has showed me an example where it hasn't worked correctly
in several years.

A couple of days later, we're showing an example of right-to-left
sorting using three print objects connected to the outlet of a
bang button. A number box is added to the patch and suddenly
the execution of the three print objects is completely wrong.
This is, needless to say, one of the most embarrassing moments
of my life, coming after I had made these declarations of confidence
in the patch cord sorting algorithm that bordered on arrogance.

I have done a little bit of research on the problem and found
that you can get into trouble with patch cord sorting in two
situations in the case of a single outlet fanned to three

1) adding a new object to a patch
2) moving all three of the objects together to the left or

I could not create a mis-sort by moving only one or two
of the objects.

With either of these examples, if you save the patch and
reload it, the sorting is correct. Indeed, with #2, it was
only possible to get it to mess up shortly after loading
the patch. Once it messes up and you do something to correct
it, the program seems immune from further mis-sorting.

This means that if you open any particular Max patch with
a fan of patch cords from an outlet, I have not seen a
situation in which it will not work correctly. Max does a
sort of these patch cords each time a patch is loaded.

If you care about execution order, you will want to use the
trigger object. There are other advantages to using trigger,
such as making explicit the order in which you want something
to occur.

I currently have no idea how to fix either of these problems,
but I will let everyone know as soon I as I have done so.
Now that I have so much invested in eliminating patch cord
sorting problems...

David Z.


Date:    Fri, 24 Jul 1998 20:39:05 -0700
From:    David Zicarelli 
Subject: Re: Message order

Christopher Dobrian  writes:

>I remember the article in question (various people's thoughts on the pros
>and cons of Max), and I suspect that Miller was referring to non-Opcode Max
>(i.e., Max as he wrote it originally and as it was further developed at
>IRCAM independently of David Zicarelli's work on Opcode Max). The reliable
>right-to-left/bottom-to-top message ordering was implemented by David for
>the first Opcode release, version 2.0.

There are two slight corrections I would make to this paragraph.
First, Miller actually implemented the ordering in Opcode Max,
and second, based on the long history of its unreliability and
other message I have posted to the list today, I wouldn't
refer to it as "reliable."

My sincere apologies to my esteemed collegue and friend Mr.
Dobrian for having him go out on a limb for me vis a vis
patch cord sorting, only for me to have to pull the rug out
from under him. In theory, the order should be reliable, and if
it's the last thing I do before I die, I will squash every
last case of mis-sorting.

>It's true that the calculations still ultimately need to be made in a
>certain order, and this example is reading and writing the same sample in
>the buffer~, so order is relevant. But in my mind, this begs the question
>of why the buffer~ is being used at all. Why is the signal being poked into
>the buffer~, being stored for "zero" time, and looked up with index~? Why
>not just use the original poked signal (instead of the output of index~)?

You can blame me for this technique. Basically, we want to use
a buffer~ so we can vary the way we play the loop back. Examples
will be provided once we (I?) finish the example patches shown
at the Max/MSP Night School.

David Z.


End of MAX Digest - 24 Jul 1998