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

There are 3 messages totalling 89 lines in this issue.

Topics of the day:

  1. presets and nesting
  2. standalone menus
  3. max and oms timing


Date:    Mon, 5 May 1997 22:34:01 -0700
From:    David Zicarelli 
Subject: Re: presets and nesting

Jeremy Yuille  writes:

>I have a patch (3.0) that uses a preset to remember settings within some
>patcher-in-windows, by connecting the 'included' output of the preset to an
>input of the sub patches.

You can't save presets of stuff in subpatchers of the patcher containing
the preset object. You might be able to do it temporarily, but it won't
get saved across program executions.

This is implied in the 3.0 manual, but perhaps it needs to be stated more
strongly, which is what I hope I'm doing here.

David Z.


Date:    Mon, 5 May 1997 22:48:12 -0700
From:    David Zicarelli 
Subject: standalone menus

"K-) Peter"  writes:

>>>> 3) Still IMPORTANT.  Is there anyway of removing the Maxplay menu
>when you compile the program as standalone or is it always going to look
>like a Max program. Does the pure Ircam one do the same thing ? I'd
>really rather not have the Maxplay shell showing - even if it costs me
>money !

Using the menubar object, you can replace the about item in the
Apple menu (the help file does this). In addition, the second argument
to menubar, which is optional, suppresses other menu items such
as Overdrive and Midi Setup. Additionally, the Single Play Installer
allows you to get rid of the Status window item in the Windows menu.
All of this is documented. At no cost to you.

>        In terms of programming efficiency, are there any major pitfalls
>in Max'ing; i.e. are Patchers more efficient processor wise ? Anything
>to avoid or use in preference ?

Hmmn. Did you read the "Efficiency" section of the manual?

David Z.


Date:    Tue, 6 May 1997 09:25:33 +0200
From:    Tom Mays 
Subject: max and oms timing

This is a bug/ideas report to David Z. disguised as a submission to the
maxlist - just because.

I've been doing some tests with oms timing in max, an it seems to work well,

Unless I'm mistaken, del does not accept the "clock" message to sync it
to a, let's say, setclock fed by timein in milliseconds. However, pipe,
metro, tempo, timer, clocker, and line do.

This would be the last link to finally having precise timing within max - as
it's known by anybody trying to do longterm time measurements that the max
clock is fast. In fact it seems to be about 5% fast when comparing it to oms
timing, or any other non-max timing source for that matter. I've always
assumed that it was a low-level problem and that it obvoiusly would be
better callibrated if it could be, but I'm bringing it up here because
I've "assumed" long enough.

Anyway, oms timing seems to be a solution, but it does seem to slow down
max considerably, such that on a 7100 66 (yes, I know, 1st generation ppc --
ie. Ircam isn't as rich as most people think...) I had to set the max
to 5 ms. Is this normal?

Also, does the "cost" of using oms timing to a setclock increase with
every syncd object used. That is, once the oms timing ext clock is running
within max, does it matter how many metros etc. are syncing to it, other
the normal cost of these objects?

many thanks,



End of MAX Digest - 5 May 1997 to 6 May 1997