Subject: MAX Digest - 28 May 1999 to 29 May 1999 (#1999-161)
Date: Sun, 30 May 1999 00:00:00 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
To: Recipients of MAX digests 

There are 2 messages totalling 81 lines in this issue.

Topics of the day:

  1. overdriving miss daisy
  2. pt~


Date:    Fri, 28 May 1999 22:02:25 -0700
From:    David Zicarelli 
Subject: overdriving miss daisy

Carl Faia  writes:

>I've never really understood exactly how Overdrive is supposed to work.
>That is, if you put audio in scheduler interrupt, my impression is that the
>audio takes priority. That said, there are a lot of factors that affect the
>timing in Max. What are you using as I/O vector size? Do you have a lot of
>stuff displayed in real-time in the patch?

Actually, you put the scheduler in the audio interrupt, and that
means that the scheduler takes priority. And that's why, if it's
stuck processing some MIDI when it normally would just be
computing samples, the audio can be late and you'd get some clicks.
One thing that might help is adjusting the I/O vector size....either
up or down, I don't know...gotta experiment. Another thing is
thinning the MIDI data with speedlim, etc. Those MIDI calculations
are infrequent and expensive, audio tends to be a more consistent
type of calculation from one moment to the next.

When the scheduler is not run in the audio interrupt, the audio
interrupt appears to be able to lock out the timer interrupt
for extended periods (they may be the same kind of interrupt, I'm not
sure, but this problem has actually gotten worse in system 8.1
to the benefit of more audio processing in the CPU and less MIDI).
That means that MIDI processing won't stomp on the audio, but on the
other hand, the audio is stomping all over the MIDI processing.

>You can change the timing in the configuration preference. And maybe try to
>put a defer object in a couple of mysterious places (take a look at the
>help patch).

Note that when using scheduler in audio interrupt mode, the configuration
timing preference is ignored, because it's I/O vector size that
determines the granularity of the scheduler. At 64 samples and 44.1 kHz,
the scheduler runs every 1.45 ms.

David Z.


Date:    Fri, 28 May 1999 22:26:55 -0700
From:    dudas 
Subject: Re: pt~

Robin Davies writes:

>I'm having a hard time getting Max to include pt~ in a compiled app.
>Anyone know a secret I don't?

Oh, that's a bug.  Thanks for finding it.  It seems that the pt~ object was
compiled without a 'mAxL' resource.  Normally the 'mAxL' resource contains
the code for the 68k part of a FAT (68k+PPC) object.  Objects which are
PPC-only therefore seemingly do not need this resource.  However, the
'mAxL' resource has another useful function... it allows a PowerPC object
to be found inside a collective or a standalone application!! So PPC-only
objects (such as MSP objects) need to have a "dummy" (fr: "bidon") 'mAxL'

You can bug-fix your copy of pt~ yourself, by opening it and another MSP
object (such as cycle~ or +~ or whatever) in ResEdit, and copying the
'mAxL' resource from the cycle~ (or whatever) object into pt~.  You then
need to double-click on the mAxL resource icon, get info on the 'mAxL'
resource (cmd-I) that's there, and change the resource's name from cycle~
(or whatever it is) to pt~.  Save the changes you made to pt~ and quit

Your copy of pt~ can now be included in a collective or a standalone.
(Fortunately, this is the only object in Ircam's ISPW compatibility Lib
which has that problem.)



End of MAX Digest - 28 May 1999 to 29 May 1999 (#1999-161)