Subject: MAX Digest - 6 May 1999 to 7 May 1999 (#1999-139)
Date: Sat, 8 May 1999 00:00:03 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
To: Recipients of MAX digests 

There are 5 messages totalling 326 lines in this issue.

Topics of the day:

  1. looking for a reeeeeally fast metro
  2. Oops: Re: USB serial interface that claims to work with MIDI
  3. Call for works
  4. (LONG) floats vs ints
  5. off topic.. pb2400


Date:    Fri, 7 May 1999 01:02:58 -0400
From:    Alex Burton 
Subject: Re: looking for a reeeeeally fast metro

>Date:    Thu, 6 May 1999 01:55:47 -0400
>From:    Marcel Wierckx 
>Subject: looking for a reeeeeally fast metro
>Hi people,
>Anyone know where I could find a metro object that goes down to 1 or 2 ms.
>intervals? Or if I could even get that kind of resolution in Max?

 Hello Marcel,

 I sort of recall a metro1 object, but could no find it. A feedback delay 1
will work. Alternatively you could drive a line with 1ms grain (you can
vary the grain size during a segment) to get a sort of "superclocker."

 (i can't say how precise these methods are; they do generate 1000 pulses
in 1000 milliseconds (whatever the scheduler setting) but i don't know if
these are real, smooth milliseconds...)

 Out of curiosity, what's your application for that pulse?



Date:    Fri, 7 May 1999 01:25:53 -0400
From:    Eloy Anzola 
Subject: Re: Oops: Re: USB serial interface that claims to work with MIDI

Mr. Stahl said:

> My previous message regarding the Stealth Serial Port was ripe with
> misinformation. I sincerely apologize.  Seems that it is in fact shipping
> to US locations, and does require a special extension. I'll be trying one
> with Max and a Studio 4 Real Soon.
> -Alex Stahl

please let us know the results.

Waiting with anticipation...




Date:    Fri, 7 May 1999 14:33:41 +0200
From:    Gary Berger 
Subject: Call for works

Call for works for the concert season of 1999/2000

The Swiss Center for Computer Music (SCCM) requests submission of musical
for tape, solo instrument and tape and solo instrument combined with live

Please send DATs or CDs of your electroacoustic music
together with some biographical informations and a programe note to the
address below. Pieces with a maximum duration of 10 minutes are prefered.
If you would like to send a selection of your work, please feel free to do
Works for video may also be considered.

All works not selected for the concerts will be saved in the SCCM-archive
and possibly considered for future events.

Deadline: Please submit your compositions until July 1st, 1999.

Thank you for your participation. With kind regards

The Swiss Center for Computer Music

Send your compositions and requests for additional information to:

Gary Berger
Swiss Center for Computer Music
Elisabethenstrasse 3
8004 Zurich


Date:    Fri, 7 May 1999 16:32:14 -0400
From:    Tom Ritchford 
Subject: (LONG) floats vs ints

Trond Lossius  wrote:
>Subject: Re: Getting rid of floats?
>Quoting Tom Ritchford:
>> The best solution is to get rid of floats from your program.
>I tend to use math functions as compositional material. For this kind of
>material there is little or no use in converting to ints as many of ther
>functions can only be calculated as floats in the first place.

right, this is quite true... if you take an exponential or a log
or a trig function then you are in the realm of floating point.

>The field of Fuzzy Logics is another example.

Now, here's where I'd disagree... basically, fuzzy logic is just
a form of statistics, a mechanism for combining probabilities to
get other probabilities.  Since the vast majority of the operations
are simple arithmetic like multiplication and addition, it makes
sense to use scaled integers (see later) rather than

>> Knuth (Art of Computer Programming, vol I) speaks very movingly
>> of this, pointing out that almost no property that you'd expect
>> is valid of floats in the general case (associativity, distributivity,
>> etc.)

And I'm going to shamelessly crib from him in the next sections.
>It is true that ints are evenly distributed, something floats are not.

not only that... you aren't guaranteed eg that (a+b)+c =3D a+(b+c)

>the pass object from Karheinz Essls
>RTC-lib passes a certain percentage of bangs received, using random 100
>and a < (int) object.

>If you start of
>letting through 50% of the bangs, the least change you can make is 49 or
>51, a change of =B12 % relative to 50. If you start off letting through
>only 10%, the least change you can get is =B110%.  \If pass is used to
>contol some kind of density this means that it is more difficult to do
>subtle changes of density (relatively speaking) for low values then
>higher ones.

I quoted all of this because it's a REALLY important point and one
that constantly bites me when using MIDI.  I play a MIDI wind controller,
one which reports the breath pressure using a CC from 0 to 127.   (In fact,
it doesn't even report the full 7 bits of pressure but that's for another
day and thread).  And I experience exactly the same phenomenon... I have
more dynamic control at the top of my dynamic range.

I'm coining a phrase right now and calling it the log-lin problem --
not enough digits for the low numbers, too many for the high ones.

This is a hobby horse of mine so I'll be brief and merely note that
the problem is that of linearity vs logarithmic control.  You hear
and see things logarithmically, you experience ratios rather than
absolute jumps.  So, your controllers should look more like the
scale on a slide rule (remember those, somewhat after the abacus?)
where there is a lot of space given to the numbers between 1 and
2 and very little space given to the numbers between 9 and 10.)

This is a universal law in some ways which Mandelbrot amongst others
has written about, and it's related to the reason that the first
digits of "random" numbers from the real world are NOT uniformly
distributed... if you look at eg lengths of rivers in an almanac
then some 20% of these lengths will start with the number 1 and
only about 5% with the number 9.

>One more illustration. Some weeks ago there was a request at the max-l
>for a line object for floats. One reply suggested to multiply by 10,
>using line, and then divide by 10 again.

using "scaled integers" (see below).

>I posted a more complex solution ensuring equal step size.
and using floats, which is a much better solution, since you
are STARTING with floats.  The *10/10 solution is just saying,
in essence, let's use floats with one decimal of precision only.

>In general I believe that the addition of MSP will enforce floats to be
>used more than at present.

Agreed.  A shame really... even if your DACs are exponential which
I still in heart believe gives a better response, it's much better
to translate your incoming samples (which are in log form) to a
linearized value (with possible some extra, spurious precision) and
then to do all your calculations with that integer value.

So, Knuth describes for our purposes two methods that are of use,
"scaled integer" and "fractions".

The scaled integer is the simplest and often the best.  Basically,
you have a convention that all the integers "of a certain type"
are scaled by some factor, often a power of 2 or of 10.

Here's an example -- an old style desk calculator that displays
two digits after the decimal point, always.  Really, you are just
doing integer calculations and there's a decimal point painted two
digits to the left of the right side.  Here the scale factor is

In the Essl "pass" object, you are passing probabilities to filter:
these are in principle real numbers from 0.0 to 1.0.  Essl is using
the same representation, with a scale of 0.01.

This brings us to a simpler way to solve the log-lin problem... you
can just make the scale larger until it serves properly even at
the "lowest" levels.  For example, if Dr. Essl used a scale of
0.0001 or 1/10000 then we'd be able to get a variation of 0.1%
of the value even at filter=3D10%.  Of course, no matter what sort
of scale you use you're still going to have problems around 0,
something which a floating point system won't have.

=46or almost all my projects I've used some variation on scaled integers.
There are several things to be careful of.  The first is mixing scaled
and unscaled integers.  You need to be aware of which variable contain
integers that, in your mind, you have decided are scaled and which ones
contain "just integers".

With that in mind, you need to be careful when performing arithmetic.
It's OK to add or subtract two scaled integers but not to add a scaled
to an unscaled integer ("of course").  Multiplication and division are
more tricky.  It's often not well defined to multiply two scaled integers
(ie, what's $3.50*$1.25?) but multiplying or dividing a scaled integer by
an unscaled integer is usually fine (5*$1.25).

In some cases, you can divide and multiply -- filter probabilities are a
good example here.  In these cases you get, respectively, one too few
and one too many factors of the divisor.  Here's the probability examples:

30% * 20% =3D> (30 * 20) / 100 =3D> 6%
30% / 20% =3D> (30 * 100) / 20 =3D> 150% (OK, this makes no sense for
                                      probabilities but does in other

Note that you rescale AFTER the multiplication but BEFORE the division
(to preserve the maximum precision).

=46ractions are much cooler but less useful.  You just keep every number
as two integers, a numerator and a denominator, and then multiply, add,
subtract and divide, just like in grade school.

This is nice because you have EXACT precision.  And IF you can represent
arbitrarily long integers, you can represent any rational number!

The trouble is that if you add a bunch of fractions together randomly,
the numerators and denominators tend to grow pretty fast, even if you
go to the extra effort of reducing the fractions after every operation.
So you run out of integers very fast and then have to do some sort of
fandangle rounding operation.  Not pretty.

Still, this can be really useful in some restricted problem domains where
you can prove that the numerators and denominators won't get too large
(which is often easier than it sounds).

And fractions automatically solve the log-lin problem "because" they have a
few numbers that go waaaay up and then a lot of very little numbers.

When I have used this method, I've usually (always?) just assigned the input
values to be a fraction a/b and then worked out the result algebraically.
So you can get a closed form for the numerator and denominator of the
result in terms of the input.  You can then often show that the calculations
will be bounded and proceed from the beginning to the end in one step.

No doubt Knuth has plenty of subtle examples that I've missed here.

Don't get hung up -- if floats will let you do what you need to do
in the most effective way for your problem then you should use them!



Date:    Sat, 8 May 1999 11:06:47 +1000
From:    Jeremy Yuille 
Subject: off topic.. pb2400

apologies for this off topic q, but is anyone on this list using a
pb2400/180? I'm having some dificulties with mine and would like to talk
with other 2400 owners about it off list if possible..

maybe slightly more on topic..
has nayone fitted a vimage 320MHz/1Mb G3 daughterboard to their 2400?


Jeremy Yuille

           / \



End of MAX Digest - 6 May 1999 to 7 May 1999 (#1999-139)