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

There are 8 messages totalling 278 lines in this issue.

Topics of the day:

  1. max and oms timing
  2. crashes with thispatcher
  3. PB5300 interupt rate for midi is 1khz
  4. Learning C++
  5. presets and nesting
  6. MAX Digest - 4 May 1997 to 5 May 1997
  7. preset problems
  8. Poly object bug


Date:    Tue, 6 May 1997 21:50:01 -0700
From:    David Zicarelli 
Subject: Re: max and oms timing

Tom Mays  writes:

>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.

You're not mistaken. It's a good addition, but I think since
I am reluctant to touch the kernel right now there should be a new
sort of delay object as an external. I want to give it another

When a number is received in delay's right inlet, it doesn't
modify the time of the delayed bang if the new delay time is
different than that when the last bang was received in delay's
left inlet. As an example, suppose I send 20 to delay then
a bang, then 5 milliseconds later I send a 40. The object
could act so that it output a bang 35 milliseconds later
rather than 15 milliseconds later.

Does this seem useful to anyone, and if so, has someone already
written an object to do this sort of thing?

As for OMS Timing's inefficiency on slow Power Macs, it's the
same old problem with interrupts and mode switches; you have
even more interrupts and mode switches since there are now
two timers running. I wouldn't be surprised if the 68K version
ran faster on a 7100/66 than the PowerPC native version. (OMS
Timing is wisely written as a 68K library, until Apple gives us
native interrupts.)

Eventually, using setclock objects shouldn't be necessary just
for accuracy as it is not difficult to make the millisecond timer
run off OMS Timing, in which case it will be quite a bit more accurate.
(Of course, Apple could fix its timer. I was at a meeting at
Apple where this idea received a hearty laugh, so I'm not

But this should be optional since some users may have come to know and
trust the "non-standard" millisecond, or they might be stuck
using a 7100/66 and want to get some actual performance out
of the machine.

>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?

A little bit. The overhead in the scheduler for a setclock sync-ed
clock object is about twice that when it is running in the usual way.
But generally, the overhead of scheduling isn't significant in
comparison to what you're actually doing with the clock ticks.

David Z.


Date:    Wed, 7 May 1997 14:05:47 +0200
From:    Jeffrey Burns 
Subject: crashes with thispatcher

Jeff Krieger wrote:
>I am having trouble with the fullscreen command for thispatcher.  I have
>setup a patcher window to toggle between fullscreen and normal size.  A
>loadbang sets up the patch fullscreen but when I try to change to normal
>MAX 3.5.1 crashes.  Any ideas why?

I too have been having constant crashes in the last few days in a similar
situation, employing thispatcher to specify size, position and
characteristics of a subpatcher. Initially, the whole system worked
beautifully with the patcher object, which automatically opens any
subpatcher which has been left open on save.
But the moment I put an imovie into the subpatcher (which is the reason for
the setup, and which I suspect Jeff Krieger is doing too), the crash
symphony begins. Imovie seems to be very instable, whereas movie works
similar situations without any problem, the only disadvantage being that
movie decides for itself where on the screen it wants to open, which
hinders elegant presentation during programs.



Date:    Wed, 7 May 1997 08:38:12 -0400
From:    Steve Smith 
Subject: PB5300 interupt rate for midi is 1khz

Does anyone recall how the issue was resolved regarding the 1khz interupt
rate for MIDI on the PB5300?

I think that with Max vers 3.5 - you can regulate the Max scheduler to deal
with this issue.

I am considering the new PB1400 which uses the (same, I think as the
PB5300) PPC 603e 117 mhz chip,  AND would like to know if/how performance
will be affected.


Steve Smith


Date:    Wed, 7 May 1997 09:16:38 -0400
From:    Stephen Kay 
Subject: Learning C++

>I have been using MAX for a couple of years now and would like to take it
>further by creating my own objects.  From monitoring this list it seems
>that most people seem to suggest using C++.  Is this the best language to
>use?  If so, is there a particular version or compiler that seems to work
>best?  Learning to do this is one of my summer projects, so any advice

It's C, not C++, and the compiler of choice is CodeWarrior.

Stephen Kay


Date:    Wed, 7 May 1997 09:16:42 -0400
From:    Stephen Kay 
Subject: presets and nesting

>the problem is that when I 'read' a 'written' file into the preset, It
>shows the little black squares to indicate preset entries, but it doesn't
>send any info to the patcher-in-windows.

>Is this because I shouldn't really be using the preset in this way?
>If so, is there any other type of object that can save the settings of
>sliders, ints, and led's that are within a number of sub-patches, into one

Presets and bpatchers (patcher-in-windows) do NOT mix.  Don't waste your
time.  Use a coll to store and retrieve your UI settings.  I once posted a
rather long and involved explanation of how to do this, which I don't have
with me at the moment (I'm on the road), but use a funnel to get values
into a list in the coll, with each line being a "preset", and then use an
unpack on the output of the coll to send the list to various objects when
loading a "preset".

Stephen Kay


Date:    Wed, 7 May 1997 13:46:05 -0500
From:    MALONE Don A 
Subject: Re: MAX Digest - 4 May 1997 to 5 May 1997

> >>>> 4) How would YOU split incoming polyphonic chord information from a
> NoteIn object so that you could treat each say velocity value
> differently ? I'm having a bit of a conceptual problem with combining
> and extracting lists.
i have pretty good luck using the Borax object for this
each parameter could then be a separate array in a coll object

Lone Monad


Date:    Wed, 7 May 1997 15:35:31 +0100
From:    Terry Nigrelli 
Subject: preset problems

Automatic digest processor wrote:
> There are 4 messages totalling 149 lines in this issue.
> Topics of the day:
>   1. presets and nesting
>   2. Poly Object plus (long)
>   3. MAX Digest - 1 May 1997
>   4. copy protection failure / Max 3.5
> ----------------------------------------------------------------------
> Date:    Mon, 5 May 1997 16:59:11 +1000
> From:    Jeremy Yuille 
> Subject: presets and nesting
> Hi,
> I'm wondering if anyone can help me with a (preset) problem?
> 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
> input of the sub patches.
> this is done so that i can save everything in one file with a 'write'
> command to the preset, and load it in with the 'read' command.
> when sending both these commands to the preset I get all the proper
> dialogues etc.
> the problem is that when I 'read' a 'written' file into the preset, It
> shows the little black squares to indicate preset entries, but it doesn't
> send any info to the patcher-in-windows.
> Is this because I shouldn't really be using the preset in this way?
> If so, is there any other type of object that can save the settings of
> sliders, ints, and led's that are within a number of sub-patches, into one
> file?
> thanks in advance
> ps. it's for an 808 emulator

These are among the few limitations of the preset object. As Steven Kay
informed me some time ago, if you use the preset object to save object
values then add objects to your patcher you will lose all your presets.
The coll object is much more flexible and powerful way of storing values
which can be written to and read from a disk.

You can use an object (e.g. number box) connect it's output to a prepend
to add a symbol or a number for the coll line then connect that to a
coll. then connect the output or the coll to the destination object
(e.g. makenote) . You may also want to send the output of the coll to a
grab and then back to the original number box so that the value gets
sent to the number box when you load a file but it doesn't create a
loop. You can use a several coll objects with the same file name in
patchers and sub-patchers so all the values get stored in the same
place. When you add objects you just create a new line in the coll to
store its data. I also use funnels and sprays to connect several objects
to the same coll.
It isn't pretty but it works. At least that's the way I do it. Does
anyone know of another way?

Terry Nigrelli

my home page:

Bay Shore Schools home page:


Date:    Wed, 7 May 1997 23:39:57 +0100
From:    "K-) Peter" 
Subject: Poly object bug

As sugggested by Chris Muir, the Borax object works far more reliably,
although it does need overdive (even on a PPC 601 90) and just
occassionaly also loses count. However then you can bang it.

I've discovered that the Poly object 1 in 6 times or so will treat a
note off velocity as a new note on and go on like that for a while
ignoring or adding note offs until it sorts its life out. This is with
version 3.00.
        So yes my keyboard does send note off velocities. I've tried
using the Xnotein object but can't see anything useful to do with the
on/off status at the moment in this application.
        All I actually want to do is to split a chord (or sequence of
held added notes) into separate outputs so that I can process each note
separately. Surely not too much to ask of Max. My splitting process
needs to reliably know how many notes are currently held so that it can
max count a counter to route the notes out.

        I've tested with just the poly and borax object off the same
NoteIn and the borax works and the poly object loses count quite often.
How sad that this is its only function in life :-(
        I'm probably using it wrongly as I realsie the Poly output is an
assigned polyphony number rather than a current polyphony state and
perhaps (although I'm only playing one note), it's still counting the
others as held (though I'm not retriggering faster than quavers),
however sometimes it works and other times it counts or ignores note
offs. Is it just me or is it a bug and is it fixed in 3.5 ?


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