Subject: MAX Digest - 7 Aug 1998 to 8 Aug 1998
Date: Sun, 9 Aug 1998 00:00:00 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
To: Recipients of MAX digests 

There are 10 messages totalling 502 lines in this issue.

Topics of the day:

  1. c97097
  2. x;0709
  3. menubar chapt. 2
  4. number boxes (2)
  5. Floor sensors
  6. floats' displayed precision?
  7. float display, umenu, floor sensors
  8. floor sensors
  9. Digi card

Email to MAX should now be sent to
LISTSERV commands should be sent to
Information is available on the WEB at


Date:    Sat, 8 Aug 1998 00:02:08 -0600
From:    =cw4t7abs 
Subject: c97097

>>combination of these) is being held when an action is initiated.
>It exists: are you aware of the modifiers object by Steve Ellison?
>It will output the current state of the modifier keys when banged.
>Available at the usual places, I'm sure.

!ava!lbl 4 powrpz - !z dze sorsz ava!bl

>Date:    Fri, 7 Aug 1998 11:33:41 +0100
>From:    Trond & Laila Linde Lossius 

>Before we dive into another flam session I'd like to quote a danish
>What did you learn at school today, dear little friend of mine (...)
>I learned that if you're a virgin you get to heaven,
>but in Sweden it's hard to find one passed eleven.
>;-) Trond L

assum!ng v!rg!nz = prefrd : standup-comedian = zmak() swedez > 11.

\+\ denmark zuger

   )      R

>Date:    Fri, 7 Aug 1998 15:27:47 EDT
>From:    JohnBrit@AOL.COM
>Subject: Re: Can I have these please ?

>Can *I* have these please ?

>Having just spent a few months on another maxap, I have a few requests fo=
>r=0Afuture consideration.
>1. Preset object to output a bang or a number (0 ?) from the middle outle=
>t=0Awhen a preset file is read in from disc (like col).

= poszbl nou

>2. Col to output a bang from right outlet when a write dialog box is clos=
>ed so=0Athat an action can be taken after the write operation is complete=

= poszbl nou

>6. to Stephen Kay. How about being able to specify a number which the int=
>=0Aoutlet on a 3D button would output when clicked ON (default 1 ?). This=
> would=0Asave oodles of other objects.

= poszbl nou

>Let me know your thoughts.

= poszbl nou

\+\ aoLzucz   [oodles]


Date:    Sat, 8 Aug 1998 00:04:46 -0600
From:    =cw4t7abs 
Subject: x;0709

>Date:    Fri, 7 Aug 1998 13:25:26 -0000
>From:    David Bianciardi 
>Subject: Re: umenu weirdness

>>Yes, I've also had problems.  But make sure that the "number of items"
>>field is set correctly.  If you have it set to 64 and enter more items,
>>weird behaviour is sure to result.
>>Stephen Kay
>I think stephen has the "disappearing items" issue pretty much

!temz w!ll d!sz appear regardlesz ov sett!ng.

>we also dealt with this by editing the contents manually.

w ? [ opposzd 2 ]


Date:    Sat, 8 Aug 1998 08:12:33 +0100
From:    Trond & Laila Linde Lossius 
Subject: menubar chapt. 2

I'm still working on the menubar, and have observed an odd behaviour.
When defining the menubar, I started of the 5th menu like this:

#X menutitle 5 Detune;
#X item 5 0 Unison;
#X item 5 20 -;

As you can see I've deviated from the recommendation "It's a good idea
to start your item numbers at 1 and list the items in the order you want
them to appear", but the "item number argument only specifies the number
which is sent out the menubar's outlet when the user chooses this
item.". I hoped to avoid using an extra coll or funbuff object.

However menubar did not behaved as I expected:

1) When items were selected in the Detune menu, menubar output 1 for the
first item, 3 for the 3rd item (2nd is just a dividing line), 4 for the
4rth etc. as if I'd been following the recommendations quoted above.
2) When I looked at the menubar script again,

#X item 5 0 Unison;

was all gone, though "Unison" still showed up in the menu. After closing
and reopening the patch, "Unison" was completely gone, both from script
and menu.

I thought that maybe the zero item number caused the problem, and
replaced for 40. Now the menu item stay in place in the script and when
reopening the patch, but menubar still outputs numbers according to
their position in the menu, not the menu item argument I specified.

I use a 6th menu to, scripted as recommended, and that one works fine.

It's not a big deal, and easy to get around using a funbuff, but I
wanted to mention and know if anyone else has experienced the same.

Possible solutions:

Is there a error of mine that I'm not able to see, or is the menubar
behaviour revised? Or is it the dividing lines that causes this to


Trond L.

BTW: I finally realised that it's a good idea to use an external text
editor and copy and paste when writing the script... :-/


Date:    Sat, 8 Aug 1998 11:29:45 +0200
From:    Robert Henke 
Subject: number boxes

> 3. Yellow triangle not to highlight in number box if the window is =
> ve or=3D0A(even better) up / down arrow keys to work on highlighted =
number =3D
> box even if=3D0Athe window containing it is inactive. (This drives me =
> e !!! Here I am=3D0Atrying to inc / dec a highlighted number box and =
I=3D92m =3D
> changing the value of the=3D0Alast highlighted number box in the active =
> dow. Infuriating.....)
.. i absolutely agree that the possibility to change numbers via arrow
keys / typing in can be very very confusing.
I am using a lot of patchers witch are controled via key strokes for live
performances and this feature gave me serious troubles sometimes...
I would like to have the option to simply turn that feature of  ( no =
to number boxes via the keyboard ) I think this would make sense as a
global option for all ptchers ( like the overdrive mode )
Maybee even more elegant could be a version which allows the access only
for a specified period of time after the last mouse click  on the number

That active / inactive problem also appears with the table window . I =
it would be cool if it is possible to edit a table even if the window is
not in front.


  .  .. .  .. ..  . .  . . . . . . .... .. .. .. .
m  o  n  o  l  a  k  e  .
a collaboration between gerhard behles and robert henke.
fine electronic music since 1795.
...... . . . . . .   ... ... ... . . . .  .  . . .
         LIVE performances :

   14.8.98 PopKomm, Cologne  ( monolake dance department)
   21.8.98 Logos Tetrahedron , Gent ( tape concert: "Silicea" ( G.Behles =
   24.9.98 Parochialkirche, Berlin ( 50 th anniversary of musique concrete =
..... . . . . . .   ... ... ... . . . .  .  . . .
composing new cd. 69 % done. watch out.
...... . . . . . .   ... ... ... . . . .  .  . . .


Date:    Sat, 8 Aug 1998 11:51:48 +0200
From:    Sukandar Kartadinata 
Subject: Re: Floor sensors

I've just bought some of those floor switch sensors you mentioned as I
found myself in a similar situation like you where simple is best. However,
being in Germany I'm not sure if my source can be of much help to you.
Anyway, here it is: Conrad Electronic
order codes are 75 17 66 and 75 17 58 (two different sizes)
I suppose if they don't ship to the US I could send you some....
however, I'm signing off for two weeks, so it'd have to wait
hope this helps,

Sukandar Kartadinata
Custom Music Technology
Hagenauerstr. 6, 10435 Berlin, 030-44051219


Date:    Sat, 8 Aug 1998 03:53:24 -0700
From:    Jim Wood 
Subject: number boxes

Is it  possible  to select a number box from the
keyboard (NOT MOUSE), or possibly another controller.
so its highlighted and can then have number typed
into it? Frees mouse for control of other things.

Jim Y-wood.

Get your free address at


Date:    Sat, 8 Aug 1998 15:30:04 +0200
From:    Peter Castine 
Subject: Re: floats' displayed precision?

Hosken  wrote:
>I appreciate Peter's careful explanation (this wasn't my issue--I'm just
>getting in on the action), but I beg to differ a bit philosophically with
>his commentary.

If I may summarize thus: Computers should adjust to people and not
t'other way around.

The point is well taken, and is one I have been known to propagate
myself, often and vociferously (believe it or not).

My position on the visual representation of that subset of real numbers
representable in Max and referred to as "floats" (in Max) or "floating
point" (in C and many other programming languages) is, however, tempered
by two issues.

1: Max _is_ a programming language; we _are_ programmers. And when
programming (like in any other construction endeavor), I would expect the
constructor to be aware of (or make it her business to learn) the
properties of the materials she uses. Particularly when the property in
question had been discussed in this forum (which is supposed to be a
specialist list, and not a discussion group for basics of digital
computer design), if I recall rightly, twice in very recent times. The
inquiry admitted to having not paid attention to the subject matter when
it was discussed previously, I had hoped that a somewhat emphatic
response might encourage others to pay attention now rather than ignore
the issue only to bring it up yet again next weekend. [Never mind that
Alex fooled more than just me into thinking he was a neophyte when, in
fact, he was well aware of the basic problems involved.]

When programming, sooner or later you are confronted with the fact that
your hammers and nails are all zeros and ones. Might as well get used to
the fact soon and not act surprised by trying to use the hammer as a
screwdriver. (If you follow the metaphor.)

2: Sure, it would be nice for float number boxes to behave a more in the
manner in which "normal" human beings (as opposed to those of us who have
been numbed by decades of contact with stupid computers) expect. It would
be eminently doable. But I would rather David Z. turned his talents to
the discrepancy between Max' milliseconds and real world ms, to name just
one of many more important issues.

Note that the representation issue could be dealt with by a 3rd party
external. I admit that it would be a lot easier for David Z. to tweak the
code for the (built-in) float number box than for someone else to build
an external from scratch. If people can convince D.Z. & Opcode that this
is a high priority, I will go happy enough to see this featurelet in a
future Max. I just think there are more pressing things.



---------------- ----------------
Dr. Peter Castine           | Never hit a man with glasses. Hit him with   | a baseball bat.


Date:    Sat, 8 Aug 1998 10:59:48 +0100
From:    peter elsea 
Subject: float display, umenu, floor sensors

>this appears to be a bug.  Lround 1 does *not* round certain
>floats, including 18.8.  Very bizarre.  Or maybe it *is* actually
>performing the rounding correctly; but once again when it sends out
>18.8, there is no object in Max capable of displaying that particular

Lround is doing its best- the number 18.8 simply does not exist in the IEEE
32 bit floating point numbering scheme. To quote from Inside Macintosh:
PowerPC Numerics
"Although there are infinitely many real numbers, a computer can represent
only a finite number of them.... Binary floating point numbers can
represent real numbers exactly in relatively few cases..."

The closest value to 18.8 is (to 10 digits precision) 18.7999992371. The
float box shows this at 6 digits precison as 18.799999. [ Lround 1] will
produce this number with any input from 18.75 to 18.85. If you multiply
this number by 10.0, you get 188.0, so it all works out in the end.

We can coerce sprintf into displaying numbers at any precison. the trick is
to include a non-breaking space (option space) in the string. Use[ sprintf
%.1f_] (use NBS instead of underline)-> Prepend set and drop it into a
message box. Of course,  if you type 18.8 into a float box to test this,
you are going to see 18.7 in the float box and 18.8 in the message.

I'd enjoy a float box that lets you set display precision, but it's not at
the top of my priority list.

>I'd be delighted to receive an example of some text, which when
>typed into a umenu, causes it to go poof.
I don't think it's sensitive to a particular string, I think it's in the
code that deals with semicolons and other punctuation. If you try to enter
something like .:;"'!@# several times into the same umenu, eventually you
will break it. Sypmtoms may be:
umemu can no longer be edited
strange characters displayed
system crash.
Or it may just be repeated editing that makes it go poof. I don't have time
to systematically test this, perhaps someone could spend a day exercising
the beast, keeping track of exactly what you type?

floor sensors
>Anyone know of a source for this kind of switch-pad (even an ancient
>A & P being torn down in the 'hood), or are they just lost in the mists of
You don't want the sensors from the A&P, they were pnenumatic as I recall.
Home security shops sell switches designed to go under rugs. They are pads
about 2' square.

Peter Elsea
Director of Electronic Music Studios
University of California, Santa Cruz


Date:    Sat, 8 Aug 1998 14:22:44 -0000
From:    David Bianciardi 
Subject: Re: floor sensors

On 8/8/98 3:59 AM,  David Crandall  wrote:

>There are so many issues to resolve with the piece I'm working on that I
>really want just the simplest/cheapest solution for the floor sensors.
>The trouble is that so many of the sources I look at for sensors are
>concentrating on higher-tech stuff that I'm not seeing the older items.

I'm not sure I remember the thread on this one, but here are some

- several home security and industrial machine safety outfits sell
pressure mat switches, these are essentially a "network" version of the
little hose switches that are used to count cars on roadways.  You can
get them normal open and normal closed, for sourcing or sinking inputs,
and use them with most MIDI digitizers (Pavo, Infusion, etc)...
check out for an example.  there
are cheaper ones
out there for home use with different thresholds (ignore cat, don't
ignore burglar).

- Infusion makes something called a "taptile", ostensibly for use w/ the
I-cube, but they'll work w/ any 0-5v ADC.  we used these in our
Interactive Dance Club project for Siggraph '98, and they worked fine.
they may be more elegant than you need, though, as they output a variable
voltage based on the flexion of the MDF square they're affixed to.  We
ended up just using them as simple on/off digital inputs by filtering the
data based on rate of change and thresholds.  they do have a bit height
to them, coming almost an inch from the floor.
we built a platform for them with cutouts so they were flush to the floor.

not sure about your applications requirements, but if you're just trying
to sense WHERE someone is, how about VNS or Pixound.   with an overhead
(or nearly overhead) camera, either will do a good job of giving you x,y
positions of "hot" areas, via MIDI.

feel free to email me directly.

good luck.

David Bianciardi

212.353.3947 fax
IDRC || 415 Lafayette St || NYC, NY 10003-7000


Date:    Sat, 8 Aug 1998 14:20:02 -0700
From:    David Zicarelli 
Subject: Digi card

Here's some more news about audio cards. Digidesign is going
to come out with a new card that I believe they're calling
the Protools Project II. They're going to be showing it at
the AES show in September, and magazines have been sent
press releases now, so I can talk about it. It has 16 ins and
outs, 24.87 ms I/O latency (measured in MSP), 24-bit internal
resolution, and will cost $795.

It's a PCI bus master like the Korg 1212 I/O, which increases its
efficiency (equals more DSP). The only downside may be that
it has a proprietary connector on the back so you have to
get a Digidesign I/O box to work with it. (If they threw
in the box, they could crush the 2408 and you people could

I've recently been working with a prototype, and have been
delaying the MSP update until I had it working properly with
the card. I'm finished now and will be working on getting
the update ready to go before I leave for a vacation on
Tuesday. Perhaps even more exciting is that Digidesign has
given me an alpha version of a new driver that essentially doubles
the amount of DSP you can do with with the new card and the
d24, and provides about 75% more CPU with the Audiomedia III.
This driver update should be available within a few weeks. In
addition, the new driver they have made available now (DigiSystemInit
3.3), when used in conjunction with the new MSP version, supports
ProTools III and ProTools Project cards. (ProTools IV (d24) systems
were already supported, but the MSP driver didn't actually work until
now. Sorry about that.)

They still haven't fixed the "too many interrupts" bug, but
since the Direct I/O driver used by MSP is the only thing that runs
their new card, it is a priority for them. Obviously, the
main target market is Cubase VST users, but MSP users have
a certain coolness factor that helps a bit.

Hope this is "news you can use."

David Z.


End of MAX Digest - 7 Aug 1998 to 8 Aug 1998