Subject: MAX Digest - 24 Nov 1999 to 25 Nov 1999 (#1999-337)
Date: Fri, 26 Nov 1999 00:00:08 -0500
Automatic digest processor <LISTSERV@LISTS.MCGILL.CA>
Reply-To: MAX - Interactive Music/Multimedia Standard Environments <MAX@LISTS.MCGILL.CA>
To: Recipients of MAX digests <MAX@LISTS.MCGILL.CA>

There are 15 messages totalling 475 lines in this issue.

Topics of the day:

  1. timing...
  2. UI + stability
  3. What time is it?
  4. PB batterie_hummin
  5. what time is it/ UI + stability
  6. moRe: groove~ sync output
  7. folder listings
  8. u/hslider problem
  9. analogue i/o (2)
  10. More analog noise i/o on PB
  11. G3 PB in concert
  12. G3 PB - USB MIDI
  13. PB noisy sound out
  14. incmopatibilities: kensington-max/msp??


Date:Wed, 24 Nov 1999 21:32:33 -0800
From:David Zicarelli <zicarell@CYCLING74.COM>
Subject: Re: timing...

Peter Elsea <elsea@CATS.UCSC.EDU> writes:

>I did just that, recording not the output of some instrument, but
>the MIDI data itself

This is a pretty clever idea! I'd be curious to know if there
are appreciable differences between the MIDI output of Max and
other types of software. That would tend to point the finger
at Max wouldn't it?

I believe most of the problems with timing in Max stem from its
use of Apple system software to do the timing. According to
someone who used to work at Apple, this particular facility
is "a joke, even worse than the thing it was supposed to improve."

Funny that there have been many, many revisions of system
software since then and they haven't bothered to make it any
less funny.

Another problem is that when using MSP, the audio is processed
in what is called the primary interrupt. Other interrupts are
locked out during this time (including the USB interrupt
handler, which is why newer machines often spin out of control
with lots of audio processing--another thing I have to try to
fix). By moving to a lower priority interrupt (at least as an option),
the MIDI might get more accurate when using audio.

Remember, however, that there is a scheduler interval setting
you can play with in the Configuration... from the Options
menu. I have no idea whether that will make any difference,
but it's worth a try. It definitely won't affect the long
term inaccuracy that is definitely there but it might affect
the variance one sees.

At some point soon I'll create a test bed that uses a bunch of
different timing systems and we can compare and contrast.
I think the most promising approach may be to continue using
the "joke" system software and attempt to play the straight
man by using another timing reference to correct it now and

David Z.


Date:Thu, 25 Nov 1999 01:03:34 -0500
From:Kurt Ralske <kurtralske@EARTHLINK.NET>
Subject: UI + stability

>>Does anyone have any thoughts on this -- would it be correct to say,
>>as a rule of thumb, that more interactive patches are less stable than
>>less interactive ones? Would my patches become more stable if I
>>streamlined the amount of input they accepted?
Eric Singer wrote:
>One thought...check your methods for deriving this input info and
>experiment with other ways. Are you using multiple ctlin objects? Or a
>single one, with gate objects to route the output (better, IMO - true,
>David Z.?).

Thanks Eric, I think you nailed this one. To interface with my Roland
midi controller, I was using 60 seperate ctlin objects! I've just tried
and routing a single one, and the patch seems much happier.

Kurt Ralske


Date:Thu, 25 Nov 1999 09:13:18 +0100
From:Jeffrey Burns <jeff@BERLIN.SNAFU.DE>
Subject: What time is it?

>use buffer~'s instead of
>colls. use a phasor~ as master sync source. it can be challenging, but the
>reward is sample-accurate timing.

Firstly, I would like to thank all the nice people who have answered my
question on timing. Basically, I have come to agree with Peter Elsea's
conclusion that software timing is a mess, and synchronization to a common
clock is often preferable to the attempt to run at absolute time. (Of
course, the best solution in a particular case depends on the nature of the
piece you are doing.) The one consoling thing I found out, however, is that
QT is a pretty good time keeper and that it will keep its various tracks

BTW, as David Z. told us a long time ago, there is nothing that he can do
to improve Max timing, as long as Apple doesn't decide to build more
musical hardware.

Jhno, have you tried out your suggestion of using phasor~ as a master sync
source? I did, but found that, as soon as the cpu is overloaded, it forgets
where it is. If you have a good patch, please make it available.

Jeff Burns


Date:Thu, 25 Nov 1999 10:06:17 +0100
From:michael <sm@XDV.ORG>
Subject: PB batterie_hummin

i´have managed to reduce the hummin of a PB analouge output when working
without batterie to a less annoying sizzle-sound using an D.I.-Box in
GND-lift mode - for some kinds of electronic music this would work fine
i guess.

i heard of digital_out_USB interface for the mac - that would solve some
problems, wouldn´t it?


Date:Thu, 25 Nov 1999 11:15:46 +0200
From:Tom Mays <tmays@HOL.GR>
Subject: Re: what time is it/ UI + stability

Kurt Ralske wrote:
>they're listening
>for 60 different types of midi controller info and 50 different keypress
>combos, etc. Since crashes have been occuring whether data is being
>input or not, I'm idly theorizing that the very necessity of listening for
>so many types of input is enough to

Eric Singer wrote:
>Are you using multiple ctlin objects? Or a
>single one, with gate objects to route the output (better, IMO

Try also putting a defer object after each ctlin. I've had
problems with overdrive mode and midi input. I almost *always*
have to speedlim the controller data as well. That queue fills up mighty
fast when even 5 or 6 sliders are all going at once.



Date:Thu, 25 Nov 1999 10:58:56 +0100
From:Johan van Kreij <j.vankreij@TELE2.NL>
Subject: moRe: groove~ sync output

>>sync output to drive an envelope (cycle~), that is multiplied with the
>>output of groove~ itself, a quite regular setup. Yet I find the sync output
>The sync output values are based on the position of the
>sample pointer within the current loop. That means that
>if you are halfway through a loop and you reset the loop
>so that you are three quarters through a loop, the
>sync output should jump immediately from 0.5 to 0.75.

I understand that this implies that one should wait untill the loop has
reached the end before providing new start and end points.

>One thing you can try is to "duck" the point of zero-crossing by sending
>the message 0, 1 5 (or 0, 1 10) to a line~ controlling gain, every time
>you retrigger.

The problem with that is that you need to bang all kinds of audio events.

In some occasions I don't want to bang audio events because bangs migth be
too late or arrive too early. What I tried to construct was a continuous
loop (25-100 ms length) that can move through an audiofile. Start/end points
arrive from an independent proces using random/tendency. Once I had the

chance to do something similar using KYMA. From its behaviour I figured that
the loop function evaluates the new start/end on reaching the loop end,
disregarding what arrived in between, in a way securing the loop from being
disturbed. The advantage of this approach is that you don't need to
monitor an audio rate stream, convert that into bang, and have that start an
audio rate stream again (sync~ / >~ / edge~ / bang / i&i / setloop $1 $2,

(Who would like to rescale a loop while it's playing anyway?)

Thanks for your answers.


Date:Thu, 25 Nov 1999 12:22:30 +0100
From:Benjamin Thigpen <Benjamin.Thigpen@IRCAM.FR>
Subject: Re: folder listings

>My question is if anybody ever solved the problem of getting listings of
>files in a folder (any folder). The folder object says to do this but only
>for folders contained in the Max folder. The ^-command to direct to the
>startup volume does not seem to work.

You need to give folder the entire path:volume:subfolder: subsubfolder:
subsubsubfolder. This will not work if there are any spaces in any of
these names. Otherwise it has always worked fine for me.



Date:Thu, 25 Nov 1999 12:27:00 +0100
From:Benjamin Thigpen <Benjamin.Thigpen@IRCAM.FR>
Subject: Re: u/hslider problem

David Z. wrote:

>This bug was fixed a long time ago but somehow I failed to incorporate
>the latest sliders into the 3.5.9-9 update etc.
>Download the fixed sliders at

Thanks! These work great.

BTW, there's a typo in the filename, so the currently functional address is



Date:Thu, 25 Nov 1999 09:01:11 +0100
From:Kasper T Toeplitz <kasper@CLUB-INTERNET.FR>
Subject: Re: analogue i/o


>The only real problem I had was with the analogue i/o, which is _very_ nois=
>when running off the power supply, but clean when using battery (Anyone els=
>encounter this problem, or do I have a faulty machine?). Sometimes I could
>persade it to go clean, but the only reliable way was to run on battery. I
>am getting about two hours plus off the battery,

Withmy new "bronze" 333, I have the same problem - well it's not THAT

noisy (the sound is million times better than on my previous machine, the
PB 3400), but with the power supply there is SOME noise, which completly
disappears when using battery. The only solution I found so far is the
usual one - to keep the audio cables as far away from the power cables, to
plug the PB in another power circuitthan the PA=8A=8A=8A

But some of my friends say their "Bronze" PB are dead silent......

and a little trick - I Plug the power on during the "noise" parts of the
music, and unplug for the pianissimios !!!! (and it works !!! not very
different from avoiding to yell the chord changes on stage during the a
capella part)


and a question

does anyone know about an object I could use to make a bang when I press a
key on the keyboard, and another one when depressing it (could be very
useful to keep a gate, a send, anything like that, open only when the key
is pressed - with two bangs (on and then off) there is always a chance to
forget the second one....
Kasper T Toeplitz
Compositeur &Bassiste Electrique


Date:Thu, 25 Nov 1999 13:06:17 +0100
From:Kasper T Toeplitz <kasper@CLUB-INTERNET.FR>
Subject: More analog noise i/o on PB

and just when I send my message (about the noise coming from the power
supply) I tested the same config at another place - perfectly silent, no
difference between power supply and battery.- (and everything was plugged
into the same power socket)

Comes out it's all depending of you electric insallation - but the Power
Book is OK.
Kasper T Toeplitz
Compositeur &Bassiste Electrique


Date:Thu, 25 Nov 1999 12:25:20 +0000
From:david stevens <david@RESONANT.DEMON.CO.UK>
Subject: Re: G3 PB in concert

hi Lawrence

> The only real problem I had was with the analogue i/o, which is _very_ noisy
> when running off the power supply,

i found this also with my PB G3/400. i normally use a Mackie 1202 to
feed the Powerbook, so i tried swapping over to my Spirit Folio and the
noise went away - so i guess that i'm looking at some kind of
shielding/earthing problem. i don't know if it's because the Spirit has
an external PSU that it doesn't pick up all that processor noise, but i
find it a little odd that the Mackie should be more of a problem than
the Spirit. i'm using balanced leads as far as possible, with an
unbalanced feed from the PB directly to an amp.

i presume that once i manage to get digital I/O then this will no longer
be a problem (correct me if i'm wrong someone), but i suppose in the
meantime i should look at some kind of seperate power supply for the PB
and the Mackie (or keep using the Folio).



Date:Thu, 25 Nov 1999 11:46:23 +0000
From:lawrence casserley <leo@CHILTERN.DEMON.CO.UK>
Subject: G3 PB - USB MIDI

Dafna wrote:

> Slightly off subject from Lawrence's post:My G3 PB stopped powering
> my serial Fast Lane MIDI interface altogether (!) when I was running
> on battery power
- therefore NO MIDI. I presume that was because my
> Energy Saver control panel settings needed to be tweaked in some way..
> Any suggestions?

I haven't had this problem - but I disabled _all_ the power saver options as
I find they are incompatible with real-time processing (maybe some are OK,
but I think it is safer without them!)


Lawrence CasserleyLawrence Electronic Operations +44 1494 481381FAX: +44 1494 481454



Date:Thu, 25 Nov 1999 14:13:23 +0100
From:Hans Tutschku <Hans.Tutschku@IRCAM.FR>
Subject: PB noisy sound out

At 0:00 Uhr -0500 25.11.1999, lawrence casserley wrote:
>The only real problem I had was with the analogue i/o, which is _very_ noisy
>when running off the power supply, but clean when using battery (Anyone else
>encounter this problem, or do I have a faulty machine?).

It's exactly the same for the PB G3 300 MHz.

Hans Tutschku



Date:Thu, 25 Nov 1999 10:09:53 +0100
From:bshauf <bshauf@SIL.AT>
Subject: incmopatibilities: kensington-max/msp??

hi all,

are there any known incompatibilities max/msp has with a kensington
trackball? (apparently peak has problems with the kensington
my setup:
lombard, 333mhz, macos 8.6, 192 ram, max 3.5.9./msp bundle



Date:Thu, 25 Nov 1999 12:00:48 -0500
From:Stephen Kay <sk@COMPUSERVE.COM>
Subject: Re: analogue i/o

> does anyone know about an object I could use to make a bang when I pres=
s a
> key on the keyboard, and another one when depressing it (could be very
> useful to keep a gate, a send, anything like that, open only when the k=
> is pressed - with two bangs (on and then off) there is always a chance =
> forget the second one....
> Kasper T Toeplitz

Unless I'm misunderstanding your question, this seems pretty straightforw=
You can use the velocity of the key(s) to open/close a gate. Here are a
few examples:

Stephen Kay
The MegaMax collection of Max objects:

max v2;
#N vpatcher 50 40 574 384;
#P button 381 135 15 0;
#P toggle 214 217 15 0;
#P toggle 108 124 15 0;
#P newex 381 107 35 196617 sel 60;
#P comment 380 46 105 196617 bang for a specific note press and release;
#P newex 381 79 40 196617 notein;
#P button 275 106 15 0;
#P newex 275 79 40 196617 notein;
#P newex 182 105 31 196617 swap;
#P newex 203 172 27 196617 gate;
#P newex 203 136 35 196617 =3D=3D 60;
#P comment 155 45 100 196617 open and close a gate with a specific key;
#P newex 183 77 40 196617 notein;
#P newex 203 196 27 196617 > 0;
#P newex 203 237 27 196617 gate;
#P newex 94 146 27 196617 gate;
#P newex 94 101 27 196617 > 0;
#P newex 79 77 40 196617 notein;
#P comment 51 45 100 196617 open and close a gate with any key;
#P comment 274 46 100 196617 bang for each note press and release;
#P comment 94 183 100 196617 toggles for illustration only;
#P connect 3 1 4 0;
#P connect 4 0 5 0;
#P connect 4 0 18 0;
#P connect 8 0 12 0;
#P connect 8 1 12 1;
#P connect 12 1 10 0;
#P connect 10 0 11 0;
#P connect 11 0 7 0;
#P connect 7 0 6 0;
#P connect 7 0 19 0;
#P fasten 12 0 11 1 187 163 225 163;
#P connect 13 0 14 0;
#P connect 15 0 17 0;
#P connect 17 0 20 0;
#P pop;


End of MAX Digest - 24 Nov 1999 to 25 Nov 1999 (#1999-337)