Subject: MAX Digest - 26 May 1999 to 27 May 1999 (#1999-159)
Date: Fri, 28 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 15 messages totalling 552 lines in this issue.

Topics of the day:

  1. Mac/PC
  2. hardware merging
  3. wireless headphone mix
  4. Build app that doesn't initialize MIDI?
  5. Measuring system performance?
  6. incompatibility with netscape ?
  7. time in movie object
  8. re : Mac/Windows
  9. Bad Object (2)
 10. Mac OS8
 11. MIDI vs Audio
 12. fft~ and transposing..second try
 13. delay line features
 14. MSP performance Sunday 5/30, Berkeley CA


Date:    Wed, 26 May 1999 23:25:55 +0000
From:    Pablo Silva 
Subject: Re: Mac/PC

Hi Andreas:

The incompatibility I talk about is that if you run Max 3.5.(8-9) and
then run Netscape, or viceversa, the computer freezes. I avoid this by
restarting the machine if I'm switching programs.

Hope this helps, though I see your problem has been more about

Pablo Silva


Date:    Thu, 27 May 1999 15:02:02 +1000
From:    "Sensor.E Overlobe" 
Subject: hardware merging

Hi all,
apologies if this is too off topic.
i'm looking for a (cheap) hardware solution to merging two seperate midi
kits would be great, but..
so far i have seen the midiman 2x2 box,
and an akai me30p, anyone had any experience with either of these products?
or anything else?




Date:    Thu, 27 May 1999 15:31:38 +1000
From:    nomad 
Subject: Re: wireless headphone mix

I'm building an installation with two separate sound sources, one off CD
and the other off the internal mac hard drive. Does anyone know if it's
possible to use a set of wireless headphones and some sort of proximity
sensor, so the closer a person gets to a sound source the more they hear
of it in a headphone mix (only). The further away they get the more of a
mix they get between the two, etc . . . . .

Any technical info would be greatly appreciated.
Damian Castaldi


Date:    Wed, 26 May 1999 23:41:45 -0700
From:    Edward Spiegel 
Subject: Build app that doesn't initialize MIDI?


I was wondering if it is possible to use the applicationInstaller to
build and app that DOESN'T initialize midi/oms. The reason is that I have
a couple of small patches that I built that don't do any midi, and I
don't want the app to do any midi/oms initializing for a variety of
reasons (the main one being that I hate to wait for the extra 20-30
seconds that the Unity DS-1 driver takes to initialize.

I didn't see any obvious way of telling MAX/ApplicationInstaller to not
initialize MIDI.

I hope this made sense.



Date:    Wed, 26 May 1999 23:04:26 -0700
From:    David Zicarelli 
Subject: Re: Measuring system performance?

Edward Spiegel  writes:

>I just dropped by the Cycling74 web site and saw the MSP system
>performance table and I was wondering if anyone has a nice little test
>program they would share for coming up with such stats.

Well, this is what is done to come up with the "statistics"
such as they are:

For in->out latency time, we use the latency tester patch included
with MSP.

The oscillator test is simply a huge number of cycle~ objects.
I usually have a row of 10 that I duplicate, then connect to the
output and repeat. After I hear clicks or can't turn the audio off
because the computer is doing too much processing, I subtract
cycle~ objects until it seems stable.

The efficiency factor is just my guesstimate of the average
CPU utilization reading in the DSP status window when
a single cycle~ object is used. This measures how much
overhead is involved in doing the simplest thing. This
typically varies with I/O vector size, which isn't shown
in the chart. It also varies with processor, although in
my experience it's pretty much like (apologies to non-US
residents here) the EPA mileage estimates for cars. You
won't get exactly the mileage they claim, but it's useful
for comparison purposes.

David Z.


Date:    Wed, 26 May 1999 23:21:20 -0700
From:    David Zicarelli 
Subject: Re: incompatibility with netscape ?

Pablo Silva  writes:

>all kinds of starting-from-zero procedures. And then we have to deal
>with Netscape... which is totally incompatible with MAX and OMS in my

Early last year I did some consulting work for AT&T (if you
download the "A2B Music Player" from, that's my
port of the Windows version, although it was sort of messed up
after I stopped working on it, in my opinion). Anyway, we ran into
this problem where the music player--which does audio processing
and playback at interrupt level, not unlike the sort of thing
Max/MSP does--would randomly cause Netscape, and only Netscape,
to crash.

The bug turned out to be sort of obscure and I actually had
to hire someone to find it for me. Netscape has a bad habit
of using up all the available stack in the computer. So
if a process running at a higher priority interrupts Netscape and
needs a fair amount of stack, it could be out of luck. The
audio decompression library used by AT&T was just such a
process. The solution was to hack some PowerPC assembly
code to run a function with its own stack. This code was
eventually "repurposed" in version 3.5.9 of Max, which
is potentially more stable when running with Netscape than 3.5.8
is, although 3.5.8 had a different strategy for dealing
with the same problem.

Naturally, Opcode never told me anyone was complaining
about incompatibilities with Netscape.

Now I realize that a lot more people use Netscape than Max
or OMS, but in my view, Netscape is a completely evil
piece of software if you are trying to do anything music-
related, and you should be very careful using it at the same
time as anything having to do with music. And you people want
me to finish the Max plug-in for Netscape...

By the way, File Sharing, at least before System 8.1,
has a similar problem. These are the only two known
offenders to the stack consumption problem. I'd bet you that
most of your professional grade Mac sequencers use a private
stack for MIDI and audio playback.

David Z.


Date:    Thu, 27 May 1999 00:33:01 -0800
From:    Peter Nyboer 
Subject: time in movie object

When you send a "length" message to the movie object, what are the units of
the output?  I have been getting different resuts on different types of

with a:
short 15fps cinepack 320x240 movie
I get:
length units=secs*30

the same movie recompressed as Radius SoftDV at 30fps
I get:

with numerous:
Radius Soft DV 30fps 720x480
I get:

with a:
QT movie "with dependencies" Radius Soft DV 30fps 720x480
I get

What is the story behind this?  I really need to know the length of movie
in my patch.  How can I get consistent units from the movie object?  The
manual does mention the time inconsistencies between movies, but doesn't go
farther than that.



Peter Nyboer
"Where the brand meets the hand"


Date:    Thu, 27 May 1999 14:11:08 +0200
From:    "jacques.hoepffner" 
Subject: re : Mac/Windows

I can only share my experience. I work in my proper studio with two Mac
running macos 8.1 and 8.5. I also teach in an artschool where we have old
macs (non powerPC) and brand new windows machines.
With one year of experience, we will buy macs for the next budget.
1 crashs : For the same app, the macs crash a little bit more but you have
a maximum of one hour to repair (outside hardware problems), all is visible
and I have an assistant who take one month to be able to repair it, with
windows it can take one day to find where is the problem (Bios, PCI
numbers, disks etc=8A). With mac you can boot very easely on another disc,
repair the problem very quickly. I think that the numerous layers of
programing in window make impossible to know exactly how each machine work,
and beside two month, the two machine you have buyed are really not the
same (cards, sound etc=8A). If you want th change something in the scsi
chain, change a video card driver, it could be a very strange experience.
I work also on the two systems for multiplatform CDrom with director and
the only reason why I could use windows is that the conduct of the
multimedia is so bad that it is preferable to experiment firstly the worst
problems (lack of real video layer in AVI, quicktime not really
implemented, no cue in sounds, sound latency if you have more than one
sound playing simultaneously).
I experiment very equilibrious thinks on my machine (joining Director and
max via TCP, interactive video=8A) and I experiment many crashs but 5
later all is ready to work.
Hope that help.

Jacques Hoepffner, photographe
31, rue de la R=E9union 75020 Paris France
t=E9l 33 (0)1 44 93 39 27 fax 33 (0)1 44 93 39 70


Date:    Thu, 27 May 1999 13:03:55 EDT
From:    JohnBrit@AOL.COM
Subject: Re: Bad Object

I recently decided to update a Max application that I wrote a few years ago.
Although the original worked OK, when I looked at some the patchers, I got
that "what the hell was I thinking when I wrote this" feeling. (I'm sure
we've all felt this when reviewing stuff we wrote with only a few months of
Max under our belts). The new version is slicker, faster, looks nicer etc.
However, whenever I close the parent patcher I get the following error in
Max window -
Free Object:<7 digit hex number>:Bad Object. Sometimes this prints out
repeatedly until I force quit Max, other times it prints out once and Max
quits with a type 2 error. The hex number is never the same twice. I have
tried through process of elimination for many hours off and on to try to
isolate the offending article but with no success. Anyone got an idea as to
what is happening and how to remedy it ?


Date:    Thu, 27 May 1999 13:21:55 -0400
From:    Stephen Kay 
Subject: Re: Bad Object

>Free Object:<7 digit hex number>:Bad Object. Sometimes this prints out
>repeatedly until I force quit Max, other times it prints out once and Ma=
>quits with a type 2 error. The hex number is never the same twice. I hav=
>tried through process of elimination for many hours off and on to try to=

>isolate the offending article but with no success. Anyone got an idea as=

>what is happening and how to remedy it ?

Did you try the old:
- Save a backup copy of the patcher somewhere safe
- Start deleting objects and saving/closing the parent patcher until
  the problem goes away?

Used to work for me.  As to what causes this error, I could never be
sure.  You just have to futz around until it goes away.  Sometimes
just the very act of moving objects around and resaving can fix the

Stephen Kay

The MegaMAX Collection of professional development oriented objects:


Date:    Thu, 27 May 1999 12:07:34 -0700
From:    Jeff Rona 
Subject: Mac OS8

I upgraded my G3 PowerBook to 8.6 not too long ago. I thought someone had
said that the system took more of the overall CPU bandwidth with the new OS.
However, the CPU use in the dac~ Window was the same as before with 8.5x. I
hope that this shows no loss in overall system efficiency for OS8.6.

  Be, Hear, Now


Date:    Thu, 27 May 1999 12:14:45 -0700
From:    Jeff Rona 
Subject: MIDI vs Audio

 I've done a somewhat complex patch using a fair amount of audio processing.
The dac~ window shows I'm at about 70% of CPU Usage. Everything sounds great
and feels very in time (I'm triggering many audio events with a 'tempo'

 I added some simple MIDI functions. Mainly just some MIDI throughput on a
single channel. This has thrown things for a bit of a loop (no pun). Moving
one slider on a MIDI fader box (not a lot of data) causes the audio to
totally stop while the data is passing through. This unexpected problem only
occurs if I have Audio In Scheduler Interrupt checked. So I uncheck it and
the problem goes away.
 But I do find that the audio itself, when no MIDI is present, seems to be
more rhythmically accurate with AISI checked.
  Has anyone found a similar situation?

  Be, Hear, Now


Date:    Thu, 27 May 1999 12:59:07 -0700
From:    Xavier Chabot 
Subject: Re: fft~ and transposing..second try

- I assume you want to transpose in real time , right?
- yes it is possible, but you would have to do it in C.  MSP programming
would be quite a challenge. Note that using only fft/ifft would give you
only a limited number of possible transposition ratios
- you are better off using an harmonizer or a frequency shifter, but of
course both have a very recognizable timbral signature


David Beaudry wrote:
> Posted this a last week but haven't received any response yet.  Is this
> something that is at least possible, and if so, where should I look for
> help.  Thanks.
> > Hello all:
> > I was reading/searching thru the max digest archive and came across a
> > similar question that I have, however the archive wasn't recent enough
> > me to get the answer (if there was one).  The question was: is there a
> > to transpose a note using fft~/ifft~?  For example, I have my clarinet
> > analyzed by fft~ (by way of adc~)...before sending it out to ifft~, I
> > to tranpose it up a 3rd, for example, then send the new note out thru
> > I there a way to do this?
> >
> > Thanks in advance for any help.
> >
> > David Beaudry
> > UCLA Dept. of Music
> > UCLA Center for the Digital Arts


Date:    Thu, 27 May 1999 15:10:13 -0700
From:    Alex Stahl 
Subject: Re: delay line features

At 10:32 PM -0700 5/17/99, David Zicarelli wrote:
>You can do anything you can do with tapin~ and tapout~ using buffer~,
>record~ and play~--the only problem is that you will get clicks
>if you read over the seam between the old and new material,
>which is simply impossible with a delay line. record~ (or some
>other object) needs to be able to crossfade betwen the new and
>old material so this seam isn't apparent. This too is computationally
>very expensive, but it will make a fair number of people happy
>so I am planning on doing it.

I agree that buffers~ are the way to go for flexible long delays and live
sampling, and I'm thrilled that David is planning ahead for our widespread
happiness. I built a prototype (using existing msp objects) of a
crossfading-record algorithm last year and sent it to David, so it seems
reasonable to assume I am one of the people who would be made happy by an
efficient version.

Unfortunately, I think I have found a major flaw with the idea. At least I
no longer think it is the panacea for glitchy loops which I once thought it
to be.

With hopes of someone pointing out the major flaw in my experiments, or in
the interest of helping others avoid wasting time, I'll try and explain the
issue. I apologize if this gets a little convoluted, but the whole subject
reminds me of watching one of those annoying time-travel TV episodes where
you get to the end of the story only to find out it never actually happens.
And then you realize it's a rerun, too.

The proposal is that a record~-like object writes a short crossfade between
incoming and existing material in the buffer as it records. This guarantees
a continuous waveform throughout the buffer, which seemingly makes it
possible to play any part of the buffer back at any speed, without
encountering a discontinuity (click) at the record location. So, for
example, you could set up a long recirculating delay line and play it back
arbitrarily, sampler-style, while continuously recording. Or you could have
a "tape loop" that plays back at a different speed and pitch (even
backwards). If the delay was short, it would even work as a pitch-shifter.
Or you might set up a long delay playing at 17/16ths normal speed and play
Fripp meets Reich with one finger, uh, if you wanted to. Anyway, it could
be a lot of fun.

The crossfade location has to move, of course, as new material comes in,
that is as the record pointer moves. Like everything else in MSP, this
probably happens in vector increments. Say at one "instant" the crossfade
appears at buffer location "t", then by the next instant the crossfade is
at location t+vectorsize.  (Replacing the old crossfade with a stored copy
of the pristine incoming signal is a necessary step, and that's one reason
this approach is computationally expensive). But since everything else
happens in vector increments too, including any buffer playback operations,
then this might not seem like a problem. As long as the objects which write
the crossfade at its new location and clean up the old location execute in
order, the playback objects should never encounter a glitch in the buffer.
I "proved" this with a patch that allows you to inspect the crossfade at
any point-- it always looks seamless.

Here's the catch.  Playing the buffer at a rate slower than 1 may require
reading portions of the crossfade location over several successive MSP
processing loops. At -1 speed (reverse), a player might encounter the
trailing half of the crossfade in one vector, then the leading half in the
next. But since the crossfade moves in between, there will be a glitch in
the player's output-- even though there doesn't appear to be one in the
buffer when you stop to examine it. The worst case happens when a normal
speed play pointer lags the record pointer by about one crossfade time-- it
then plays a noisy stream of discontinuous crossfades!

The overall result is occasionally better but often worse than just living
with a single loud click. As far as I can tell, there is no way to embed a
delgitching crossfade in the record operation while allowing arbitrary
playback rates. Although my prototype used vector-length crossfades, I
think the problem would remain with arbitrary-length crossfades. The glitch
might be practically imperceptible with a 1-sample vector length, but
that's not a practical option today.

Recently, I have had much better luck with a crossfading player, reading
from two buffers with offset record pointers, although it is even less
efficient, and even harder to describe. The big drawback is that patches
often use more players (delay taps) than recorders (delay lines), so the
inefficiency tends to multiply. Still, it sounds good so far, and if I can
find the time to clean it up I will bring it to MSP Night School or

In the meantime, if you've bothered reading this far, and see an
alternative, please reply. It seems like there are quite a few people
interested in the thread...

-Alex Stahl


Date:    Thu, 27 May 1999 20:15:56 -0700
From:    William Tsun-Yuk Hsu 
Subject: MSP performance Sunday 5/30, Berkeley CA


Yasuhiro Otani, expert MSP manipulator, will be performing
in Berkeley, California this Sunday, May 30. Hope this is of
interest to some of you...

Bill Hsu

Sunday May 30
Beanbender's at the Fine Arts Cinema
2451 Shattuck Ave, Berkeley CA
(at Haste, 4 blocks from Downtown Berkeley BART)

6:00pm  rare film footage featuring Cream (yes, Eric Clapton etc)
7:30pm  from Japan, Shoko Hikage, solo koto
8:30pm  Bob Boster, solo electronics
9:30pm  from Tokyo, Yasuhiro Otani, solo electronics

Hikage, a recent arrival in the Bay area, is a koto virtuoso with
impressive technique and much experience in both traditional and
new music. She studied with Tadao Sawai, prominent Japanese new
music composer and kotoist. Hikage appears on a recent Leo Lab
CD with local shakuhachi player Phil Gelb.

Boster notes: "My live performances as Mr. Meridies (the
electronic music persona of composer and performance artist Bob
Boster) focus on real-time collaging of music and other sound sources,
dynamically drawing material from regular consumer CDs and building
completely new, distinct sonic worlds out of these fragments."
Expect expert CD manipulations, textural disturbances, and the unexpected.

Otani is part of the Experimental Tokyo collective of Japanese
electronic musicians. His adept manipulations of the MSP interactive
audio software result in astoundingly tactile sound sculpting;
sounds and timbres are played as instruments. Otani appears on
solo recordings and CDs with Experimental Tokyo.


End of MAX Digest - 26 May 1999 to 27 May 1999 (#1999-159)