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

There are 7 messages totalling 339 lines in this issue.

Topics of the day:

  1. off topic.. pb2400
  2. highpass filter
  3. (LONG) floats vs ints.
  4. looking for a rlly fast metro?
  5. MAX Digest - 5 May 1999 to 6 May 1999 (#1999-138)
  6. Pulse Sequencing
  7. SMPTE without hardware

----------------------------------------------------------------------

Date:    Sat, 8 May 1999 10:23:24 +0000
From:    Nick Lowe 
Subject: Re: 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?

The misleadingly-titled DuoList is actually dominated by 2400 users, and
very active and knowledgeable. Details, archive &c. at
http://www.themacintoshguy.com/lists/DuoListFAQ.shtml.

Nick Lowe
n.lowe@rhbnc.ac.uk

------------------------------

Date:    Sat, 8 May 1999 12:24:54 +0200
From:    Robert Henke 
Subject: highpass filter

Dear Masters of Coefficients...
..has anybody calculated coefficients for a 2nd order highpass filter ( f =

~ 35 Hz ) using biquad~ and is willing to share them ?
thanks.
rob.

.........................................................................
                M   O   N   O   L   A   K   E
a collaboration of gerhard behles and robert henke
               http://www.monolake.de
..........................................................................

------------------------------

Date:    Sat, 8 May 1999 11:50:09 +0100
From:    Trond Lossius 
Subject: Re: (LONG) floats vs ints.

Thanks for a very thorough reply, Tom.

When choosing whether to use ints (/scaled ints) or floats, one has to
consider
the properties of both number representations and choose the one that best
fit
the task. I'll try to line out some properties and differences of the two
number sets.

1. If floats and ints both use 32 bits (I think this is the case in Max)
both
number sets are able to represent a limited number of numbers. The bits
available offers 4294967295 different permutations, and this is the upper
limit
of available numbers. Ints use the entire range of possibilities. The range
of
available floats is somewhat less, as several bit representations could
describe the same number (in the same way as 0.01234 * 10^1 and 0.1234 *
10^0
describe the same number in decimal notation).

2. Ints are uniformly distributed, floats are not.

Distance between consecutive ints are uniform, this is not the case for
floats.

If floats are represented using only 6 bits: 1 for sign of mantissa, 3 for
mantissa number, 1 for sign of exponent and 1 for value of exponent, the
following numbers could be represented (please view using Fixed With font):

    1  1   3  1   5  3   7  1  5  3  7     5  3  7
0 -- - -- - -- - -- - - - - 1 - - -
   16  8  16  4  16  8  16  2  8  4  8     4  2  4

The distribution is dense close to zero (numbers 1/16 apart) and wider as
numbers increase (1/4, then 1/2).

If normalized floating points is used the first bit of mantissa _has_ to be
1
except for the number 0 (zero). Some of the above numbers would then be
prohibited, creating what is known as "the hole at zero:

   1   5  3   7  1  5  3  7     5  3  7
0 - -- - -- - - - - 1 - - -
   4  16  8  16  2  8  4  8     4  2  4

There is a relatively wide gap between 0 and the smallest positive number
(1/4)
compared to distance between that number and the next (1/16).

3. Precision can be measured in different ways. The absolute error of BETA
as
an approximation to ALPHA is

abserr = abs(ALPHA-BETA)

The relative error of BETA as an approximation to ALPHA is

relerr = abserr / abs(ALPHA)

If ints are used to approximate real numbers the absolute error will be
about
0.5 as long as real numbers do not exceed the range of ints. The relative
error
might be as high as 1 (100%) for numbers close to zero or as low as 2 *
10^-10
(0.00000002%) for MAXINT.

The behavior of floats is quite the opposite in this respect. The relative
error of floats will be more or less constant while the absolute error might
vary wildly.

4. Due to distribution properties, the range of integers is restricted to

-2147483648 <= int <= 2147483647

The range of floats is a lot wider, but absolute error of floats will
increase
as the numbers increase.

I'll finish of with a brief remark on scaled ints and fractional numbers:

> So, Knuth describes for our purposes two methods that are of use,
> "scaled integer" and "fractions".
>
Both options is based on the assumption that you work on discrete sets of
numbers: int and scaled int assumes a uniformly distributed set, and
fractions
assumes that you are dealing with rational numbers. As soon as you start
working on any real numbers, the problem of representational errors
reappears.
Your choice of representation then will have to take into consideration

-efficiency
-what is more suitable of uniform or logarithmic distribution?
-what is most important to keep consistent: absolute or relative error?
-what range are you working on?

and probably quite a few more points.

ints might seem easier to handle, especially when it comes to comparing as
done
by Max objects ==, route, or sel. If you use floats you have to take into
account the problem of representational errors and also degrading of
relative
precision by math operations.

Have a nice weekend!

Trond L.

------------------------------

Date:    Sat, 8 May 1999 16:29:55 +0200
From:    jvkr 
Subject: Re: looking for a rlly fast metro?

> Hello Marcel,

>...

> (i can't say how precise these methods are; they do generate 1000 pulses
>in 1000 milliseconds
?
I have my doubts.

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

The patch that comes with this message uses something very fast: sound. I
thought, take a 1000 Hz sawtooth and use edge~ that bangs every wrap, and
there you are. The results quite astonished me, but try it yourself.

jvkr

max v2;
#N vpatcher 173 65 552 348;
#P toggle 145 150 15 0;
#P number 153 228 78 9 0 0 0 3;
#P newex 153 201 66 196617 counter;
#P newex 145 107 60 196617 t b b b;
#P button 145 89 15 0;
#P newex 145 127 48 196617 del 1000;
#P flonum 65 71 56 9 1 0 1 3;
#P newex 145 167 29 196617 dac~;
#P flonum 65 34 56 9 1 0 1 3;
#P newex 65 51 81 196617 expr 1000./$f1;
#P newex 65 149 34 196617 edge~;
#P newex 65 127 40 196617 ==~ -1;
#P newex 65 107 44 196617 change~;
#P newex 65 88 44 196617 phasor~;
#P comment 121 35 35 196617 t [ms];
#P comment 121 72 34 196617 f [Hz];
#P comment 160 90 169 196617 count bangs generated in one second;
#P connect 10 0 3 0;
#P connect 8 0 7 0;
#P connect 7 0 10 0;
#P fasten 6 0 14 0 70 189 158 189;
#P connect 5 0 6 0;
#P connect 4 0 5 0;
#P connect 3 0 4 0;
#P connect 11 0 16 0;
#P connect 12 0 13 0;
#P connect 13 0 11 0;
#P fasten 13 1 16 0 175 147 150 147;
#P connect 13 2 14 3;
#P connect 14 0 15 0;
#P connect 16 0 9 0;
#P pop;

------------------------------

Date:    Fri, 7 May 1999 22:53:18 -0000
From:    Nick Rothwell 
Subject: Re: MAX Digest - 5 May 1999 to 6 May 1999 (#1999-138)

> > (In seven or eight years of intense MAX work, including a dozen
> > native-code-based projects, I've *never* used floats...)

> In general I believe that the addition of MSP will enforce floats to be
> used more than at present. In particular when creating ones own
> instruments/sounds in MSP I see little or no point in restriciting
> oneself to the 0-127 range of the MIDI regime.

Sure - agreed - but you were wanting to use floats for algorithmic
control purposes (as a condition for a loop) rather than as passive
data, which I think is dangerous. Manipulating float data is fine, so
long as you're aware of the way real numbers behave.

--

            Nick Rothwell                  Cassiel.com Limited
            nick@cassiel.com                   www.cassiel.com
            systems - composition - installation - performance

------------------------------

Date:    Sat, 8 May 1999 14:49:57 -0000
From:    Nick Rothwell 
Subject: Re: Pulse Sequencing

> I'm curious to know what the advantages are in abstracting to
> such a degree, as opposed to creating more specialized tools for specific
> functions.

I certainly didn't want to have to write a new package for every
different kind of sequencing task I could think of, certainly not
while trying to compose, or while doing workshop residencies and the
like. Flexible, reusable components are just as valuable for musical
applications as for more conventional IT ones.

> If I understand correctly your registry object works by organizing
> the settings of your pulses and sequences in terms of configuration
> as well as data, allowing you to manipulate this algebra in
> different ways.

There's no difference between configuration and data: a data sequence
can be entered manually (just like constant arrays in any programming
language), or can be captured as a binding (essentially, a snapshot
recording process).

The registry is generic, and used for all sorts of library tools; the
tools just need to know the basic registry command set, which the
pulse sequencer does.

> This sentence particularly struck me - an analog step sequencer is very
> easy to program, in part because the results are easy to predict. It
sounds
> like you must be using a very different programming metaphor then. How are
> you breaking this "what you see is what you get" correlation without
> clouding the (more or less linear) relationship between interface and
> result? Or is that relationship even an issue?

It's not really an issue. I'm much more concerned with what structure
can be heard, as opposed to what structure can be seen. Language-based
systems are much more expressive than anything graphical, partly
because they deal with abstraction well. The pulse sequencer is not
graphical at all, although I do have a bpatcher wrapper which provides
dialogues and menus for each instance.

Actually, part of the plan was to allow a library of more
conventional, graphical modules as wrappers at a later stage - step
sequencers, arpeggiators and so on - but use the pulse sequencer as
the computing engine for them. The problem with graphical interfaces
is saving and restoring state, which is why I've been motivated to
think about it very deeply yet.

--

            Nick Rothwell                  Cassiel.com Limited
            nick@cassiel.com                   www.cassiel.com
            systems - composition - installation - performance

------------------------------

Date:    Sat, 8 May 1999 18:54:24 -0400
From:    Neal Farwell 
Subject: SMPTE without hardware

Dear All

My first post to this list!
Please point me to the right archive if the following has come up before:

Is it possible to use the standard sound in/out hardware on a PowerMac to
read (and write) SMPTE?

I'm thinking of an object for MAX, or perhaps an OMS device that derives
MTC from the analog SMPTE... I guess one could program such a thing in MSP
or SuperCollider if the Sound Manager latencies were predictable, but I
don't own MSP or S-C (sigh...).

Thanks.

Neal

=========================================
Neal Farwell

Visiting Fellow in Composition

Music Department
Harvard University
Cambridge MA 02138

(617) 591-9478

nfarwell@fas.harvard.edu

http://www.fas.harvard.edu/~nfarwell
=========================================

------------------------------

End of MAX Digest - 7 May 1999 to 8 May 1999 (#1999-140)
********************************************************