Subject: MAX Digest - 4 May 1999 to 5 May 1999 - Special issue (#1999-136)
Date: Wed, 5 May 1999 19:47:10 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 19 messages totalling 725 lines in this issue.

Topics in this special issue:

  1. Floats and "=="!? (6)
  2. PC-AudioCards - new light on the horizon?
  3. Subject: Floats and "=="!?
  4. bleues usb interfaces ?? (2)
  5. multiple Korg 1212's
  6. scoping s/r's
  7. ! NEW authorization bad bugs !
  8. $C263.1P-2.2R1.7X-0.88Y23.51Z46.91T15.0*6B
  9. Local, ultrasonics, Float== (2)
 10. local name scope
 11. - RAID level 4
 12. groove~ with crossfade supplement

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

Date:    Tue, 4 May 1999 22:53:35 -0600
From:    Kevin Walker 
Subject: Re: Floats and "=="!?

>This is weird, and extremely annoying, but something must be wrong with
>the "==" (and maybe the other comparison objects, too?).

Because of round-off errors, it's not usually a good idea to test for two
floats being _exactly_ equal.  Even if the number boxes display them the
same, they might not be precisely equal.  Better to test for the absolute
value of the difference being less that some small number (0.000001, say).
Another option is to generate and compare integers, and then use the
integer divided by 100 (or 1000 or 10000) elsewhere in the patch.

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

Date:    Wed, 5 May 1999 01:46:53 -0400
From:    Johnny DeKam 
Subject: PC-AudioCards - new light on the horizon?

> PC-AudioCards - new light on the horizon?

perhaps even better... Apple released a TIL article on a USB PC-Card adapter
by Macally for only $99...

Combine this with the new Opcode or SonicPort, and you have stereo 20 bit
I/O (analog and digital) for only $350 US...

Story will follow soon on UnMAX ( http://node.net/MAX/ )

-- johnny deKam

PS - not to mention that the new line of powerbooks will have USB and
Firewire builtin, making it even cheaper for high quality audio on a laptop.

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

Date:    Tue, 4 May 1999 23:51:41 -0700
From:    Garry Kling 
Subject: Re: Subject: Floats and "=="!?

>From: Oeivind Idsoe 
>Subject: Floats and "=="!?

>This is weird, and extremely annoying, but >something must be wrong
with
>the "==" (and maybe the other comparison objects, >too?).

>I have a very simple setup with one float going >in the left inlet of
>"==" and one float going in the right inlet of >"==". ...

The problem is comparing floats: the way I understand it,
computers/binary code have a limited accuracy for representing floats
internally, so that your 0.85 may be stored as 0.8499992 or something
like that, and it is rounded for display. It gives a misleading result,
and often a float 0.85 in another context may be represented as
0.8499997, etc in an unpredictable way. Thus, any two floats are rarely
exact in a computer's view. It is strange that it ever works at all.

You should try using ints, if it works in your program, or rescaling
your significant float places into the int range and casting them into
ints. I remember pulling my hair out for hours over the same problem in
C++.

A very good question that keeps many people awake at night...

BTW I am new to the MAX list, and I really enjoy the thoughtful
questions and comments. Glad to be with you!

Best,
Garry Kling
CEMS
Central Washington University

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

Date:    Wed, 5 May 1999 10:55:28 +0100
From:    Hans Tutschku 
Subject: bleues usb interfaces ??

>Except that most USB-to-serial converters won't support an externaly
>clocked serial port, which means they won't do any of the
>widely-available MIDI interfaces.
>
>Leastaways, that's what I read in the newspapers.
>

after tests: USB-to-serial converter is not working with standard
MIDI-interfaces
(Studio 4, Studio 5 etc)

Hans

---------------------------
Hans Tutschku
http://www.multimania.com/hanstutschku

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

Date:    Wed, 5 May 1999 10:56:23 +0100
From:    Hans Tutschku 
Subject: multiple Korg 1212's

>I am not familiar with all the technical issues, but, for what it is worth,
>the person at Korg who did all the initial development for the 1212 card
told
>me when I got mine it would never be possible to run more than one...
>
>x
>Bob Ostertag

Cubase 4.0 can address multiple Korg cards.

Hans

---------------------------
Hans Tutschku
http://www.multimania.com/hanstutschku

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

Date:    Wed, 5 May 1999 03:09:30 -0700
From:    "|K<" 
Subject: scoping s/r's

>I seem to recall from several months back a request for send and receive
>objects whose names had local (as opposed to global) scope.  Do such

when I do such a project which needs strict local scoping on s/r's (quite
often) I simply save my subpatchers as a .pat file which require a single
argument.  then I name all s/r's with starting with #1_
z.b.    #1_aroundtheoaktree
so when the subpatch is instanteated with an argument like
'tieayellowribbon' then my s/r's look something like
r tieayellowribbon_aroundtheoaktree

ok, it's still global in scope, but if the only time you use these s/r's
is within the subpatch, then it's quite handy, and you can have multiple
instanteations of the same subpatch each with a uniqe argument and not
worry about them conflicting with each other.

the only time that this doesn't work out so well is when I need to use
objects that need to get a 'save' message from max (since saved
sub-patchers aren't allowed to change themselves.)

I think this is alot easier than writing a variation on the s/r modules,
but if you prefer to spend your time debugging, then go for it--and let me
know how it turns out!

|K<
kent@music.calarts.edu

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

Date:    Wed, 5 May 1999 11:20:40 +0100
From:    Trond Lossius 
Subject: Re: ! NEW authorization bad bugs !

My advice is that you start whining/ranting at the Opcode list too. Dan
Timis
and Doug Wyatt of Opcode participates voluntarely on that list, and I have
the
impression that the easiest way to get some responce from Opcode is to get
one
of them to forward the message.

http://www.opcode.com/support/mailing-lists.html

Trond

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

Date:    Wed, 5 May 1999 11:21:05 +0100
From:    Trond Lossius 
Subject: Re: Floats and "=="!?

I reproduced the behaviour observed, but it is not a bug.

Connect a button to ==, and you will se that == ain't sleeping. The two
numbers
are different, but the difference is to small for Max to display.

I used an object of mine (not yet public) to display the floats as
scientific
notation, and it turned out that though both number boxes displayed 0.85,
the
real values were:

0.849999552 and 0.850000000.

Check out the UnMax FAQ for further info on floats.

If you know that only two decimal digits precision is required in the patch,
you
could try to use Peter Elseas Lround object.

Trond

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

Date:    Wed, 5 May 1999 11:21:21 +0100
From:    Trond Lossius 
Subject: Re: $C263.1P-2.2R1.7X-0.88Y23.51Z46.91T15.0*6B

Your problem is caused by itoa returning _symbols_ , not floats (even if it
looks like floats). You can verify this by sending the output from itoa to
Dudas' tipe object or the MegaMax object type.

You somehow has to change the type from symbol to float, but I don't know
how to
do so. I tried a few solutions (coll, trigger f, float), but none of them
worked.

The reason why everything seems to work o.k. after moving the message box is
that the whole object is reevaluated by Max, and Max then figures out that
what
is inside looks like a float.

Sorry I can't be of more help.

Trond

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

Date:    Wed, 5 May 1999 13:32:23 +0100
From:    Benjamin Thigpen 
Subject: Floats and "=="!?

Hi,

I have been meaning for months to post a similar question to the list.  I
am frequently interested in using any value generated _except_ 0.0.  I have
found it impossible to test for this number (or 1.0, etc.).  All the
comparison objects will report that 0.0 !=3D 0.0.  The patch below shows
thi=
s.

I presume this has to do with the way floats are represented and stored in
the binary world (no Peter Castine, I did not study this in 5th grade=8A).
But I would like to understand this in order to develop an intelligent
workaround.

Thanks for any explanations/help.

Ben

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

Date:    Wed, 5 May 1999 13:36:37 +0100
From:    Benjamin Thigpen 
Subject: Floats and "=="!?

Oops I forgot the patch.  And the original posting.

max v2;
#N vpatcher 40 56 412 235;
#P message 3 32 17 196617 0.;
#P flonum 187 136 35 9 0 0 0 3;
#P newex 187 104 99 196617 if $f1 != 0. then $f1;
#P newex 96 104 27 196617 < 0.;
#P newex 133 104 27 196617 > 0.;
#P newex 3 104 32 196617 == 0.;
#P newex 46 104 29 196617 != 0.;
#P flonum 3 52 89 14 0 0 0 3;
#P number 96 136 35 9 0 0 0 3;
#P number 133 136 35 9 0 0 0 3;
#P number 46 136 35 9 0 0 0 3;
#P number 3 136 35 9 0 0 0 3;
#P comment 134 21 194 196617 If you roll to the left of the decimal \, or
click on the message obx 0. \, all these objects function as expected.;
#P comment 134 69 195 196617 But if you roll to the right of the decimal \,
they all tell you that 0. != 0.;
#P connect 13 0 6 0;
#P connect 10 0 5 0;
#P connect 11 0 12 0;
#P connect 9 0 4 0;
#P connect 7 0 3 0;
#P connect 8 0 2 0;
#P connect 6 0 8 0;
#P connect 6 0 10 0;
#P connect 6 0 7 0;
#P connect 6 0 9 0;
#P connect 6 0 11 0;
#P pop;

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

Oeivind Idsoe  wrote:

>This is weird, and extremely annoying, but something must be wrong with
>the "==" (and maybe the other comparison objects, too?).
>
>I have a very simple setup with one float going in the left inlet of
>"==" and one float going in the right inlet of "==". The "==" is set to
>"== 0." to allow for comparison between floats. I connect a number box
>from the only outlet of "==" to check the status of the comparison. I
>then set the right float to a fx. 0.85, and then, using the mouse, drag
>the left float box to the same number. The "status" box tells me "1"
>when the numbers are equal, and "0" if not. So far so good, but when I
>use this setup for a few seconds, suddenly nothing happens anymore. The
>status is *always* "0" even if the two floats are equal, and then,
>suddenly, the "==" object works again and gives me the right status. But
>it works a lot less than it should.

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

Date:    Wed, 5 May 1999 15:08:14 +0200
From:    Peter Castine 
Subject: Re: bleues usb interfaces ??

On around 5-5-99 11:55, Hans Tutschku said something like:

>after tests: USB-to-serial converter is not working with standard
>MIDI-interfaces
>(Studio 4, Studio 5 etc)

_Which_ USB-to-serial converter? There are, AFAIK, more than one on the
market. Rumor has it that one _will_ support MIDI. Which one? I don't
know. And that's about all I know (which is what I get for believing what
I read on WWW Sites).

Cheers,

P.

----------------- http://www.prz.tu-berlin.de/~pcastine/ -----------------
Dr. Peter Castine          | I am very pleased to announce that the
4-15 Music & Technology    | 26th International Computer Music Conference
                           | will take place in Berlin in the year 2000.
                           | We look forward to seeing you here!

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

Date:    Wed, 5 May 1999 15:08:03 +0200
From:    Peter Castine 
Subject: Re: Floats and "=="!?

On around 5-5-99 14:32, Benjamin Thigpen said something like:

>I have been meaning for months to post a similar question to the list.  I
>am frequently interested in using any value generated _except_ 0.0.  I hav=
e
>found it impossible to test for this number (or 1.0, etc.).  All the
>comparison objects will report that 0.0 !=3D 0.0.  The patch below shows t=
his.
>
>I presume this has to do with the way floats are represented and stored in
>the binary world (no Peter Castine, I did not study this in 5th grade=8A).
>But I would like to understand this in order to develop an intelligent
>workaround.

No, this generally gets covered in CS 101, which not everyone here has
taken, with some additional details whenever the C printf() statement is
covered.

In brief: in Max, any number in the range from -0.0000005 (or
thereabouts) to 0.000000499999 (or thereabouts) will be represented as
0.0.

As round-off errors go, that ain't too bad (it's more accurate than the
official exchange rates for the euro), but the range *does* cover a lot
of numbers. An infinite number, in fact. (For that matter, an uncountably
infinite number, which is _very_ big). Your computer can only represent a
finite subset of the range, but there are still a *whole bunch* of
different numbers that "look" like 0.0, but internally Max is being much
more careful and will tell the difference between -0.0000000000001 and
0.000000732384985980. For instance.

The old programmer's trick:

     Never test for x =3D=3D 0.0
     Test for abs(x) < epsilon,
     with epsilon set to something like 0.0000005
     or smaller

Since the IEEE standards for computer numerics (around 1984 or so), a lot
of the problems with floating point calculation on computer have become
more manageable and predictable, but the basic fact that digital
"floating point" representations are only a subset of the real numbers
remains. Ignore the difference at your peril!

Cheers,

Peter

----------------- http://www.prz.tu-berlin.de/~pcastine/ -----------------
Dr. Peter Castine          | I am very pleased to announce that the
4-15 Music & Technology    | 26th International Computer Music Conference
                           | will take place in Berlin in the year 2000.
                           | We look forward to seeing you here!

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

Date:    Wed, 5 May 1999 18:57:46 -0000
From:    Nick Rothwell 
Subject: Re: Floats and "=="!?

> What«s going on? I am trying to make something very simple work: a float
> box is counting down from 1.0 to 0.0 (using line and metro and stuff),
> and when it reaches "0.0" I simply want fx.

I don't that it's "simple" to do this kind of manipulation on floats
and expect accurate tests for equality: it sounds like a classic
rounding error to me. Can't you do the arithmetic in integers and
divide down?

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

--

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

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

Date:    Wed, 5 May 1999 12:18:20 -0700
From:    Peter Elsea 
Subject: Local, ultrasonics, Float==

>I seem to recall from several months back a request for send and receive
>objects whose names had local (as opposed to global) scope.  Do such
>objects exist?
Well, not yet. I started to, I even got advice from David Z, but the real
world took over my life. The approach is simple in concept but strenuous in
execution- you have to create a behind the scenes set of linked structures,
each ls and lr linking itself in at creation and giving a pointer to the
name of its owning patcher and some data space. When the ls wants to change
data, it traverses the link, changing the data in structures with a
matching patcher name. It then sends a "look" message to all lrs, which
then output something if their data has changed. I expect to get back to
writing code in a couple of weeks, so these may materialize in a month or
so.

>Anyone have a suggestion for a speaker/amp setup that could be placed
>directly on the body and would accurately represent subsonic and ultrasonic
>sound?
Ultrasonic oscillators are no problem- many of the current analog
oscillators (Serge, Doepfer, PAIA) should go ultrasonic with only minor
modifications to the circuitry (find the timing capacitor and replace it
with something smaller). For transducers, use piezo elements. You may have
to sort through a number of amps to find one that really goes above 100
khz. Be careful, you might burn your skin.
The same amp would probably go subsonic too, and an ordinary speaker will
work.

> The status is *always* "0" even if the two floats are equal
Expand the float box to show all the digits- it's probably comparing
0.000001 with 0.000002, which will both show as 0.00 in a normal size
number box. If you want to do comparisons on floats, I suggest you
investigate Lround, one of the Lobjects available at
ftp:arts.ucsc.edu/pub/ems/lobjects among other places.
Peter Elsea
Electronic Music Studios
University of California, Santa Cruz
http://arts.ucsc.edu/EMS/Music/index.html
 elsea@cats.ucsc.edu

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

Date:    Wed, 5 May 1999 12:55:57 -0700
From:    Matt Wright 
Subject: Re: local name scope

The "classic" solution to this is to use #0.  Remember that #1 through
#9 stand for the arguments to your patch.  Well, #0 is a sort of implicit
argument whose value is (sort of) guaranteed to be unique.  You could make
10
instances of a patch that uses #0, and inside each one, #0 will have a
different value.

So you can say things like "send #0-foo" and "receive #0-foo" to get the
equivalent of locally scoped sends.

Some gotchas to watch out for:

- Max's "argument" substitution (including #0, which isn't really an
argument"
happens only at the beginning of a symbol, so although #0-foo will expand
into
a usable send/receive name, foo-#0 will not.

- Patchers (e.g., "p foo") share the same #0 as the parent patch
in which they are enclosed.  This might bum you out, but it's actually the
only workaround for the next issue:

- Wouldn't it be great for a patch to share its value of #0 with a subpatch
by
passing it as an argument?  Then inside patch A, all full of send and
receive
names based on #0, it could have a patch B, and the argument to patch B
could
be A's #0, and then B could be all full of send and receive names based on
#1.
Well, forget it.  This may work in some future version of Max.

Good luck.

-Matt

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

Date:    Wed, 5 May 1999 15:19:29 -0600
From:    Kevin Walker 
Subject: Re: Local, ultrasonics, Float==

>>I seem to recall from several months back a request for send and receive
>>objects whose names had local (as opposed to global) scope.  Do such
>>objects exist?
>Well, not yet. I started to, I even got advice from David Z, but the real
>world took over my life. The approach is simple in concept but strenuous in
>execution- you have to create a behind the scenes set of linked structures,
>each ls and lr linking itself in at creation and giving a pointer to the
>name of its owning patcher and some data space. When the ls wants to change
>data, it traverses the link, changing the data in structures with a
>matching patcher name. It then sends a "look" message to all lrs, which
>then output something if their data has changed. I expect to get back to
>writing code in a couple of weeks, so these may materialize in a month or
>so.

I was planning a different approach, closer to the way scoping works in C,
Perl, etc.  In particular, subpatchers inherit the namepsace of their
superpatchers, unless they carve out their own by declaring themselve
local.  (Actually, the objects declare localality, not the patcher.)

At creation time:

[lsend some_name] -- look in the containing patcher, and then all
superpatchers, for a [lsend local some_name] (or [lreceive local
some_name]) object.  If one is found, point to the associated data
stucture.  If none is found, point to (and create if necessary) the global
some_name data structure.

[lsend local some_name] -- look in containing patcher for another [lsend
local some_name] or [lreceive local some_name].  If found, point to
associated data structure.  If not found, create and point to new data
structure, then relink all [lsend some_name] and [lreceive some_name]
objects contained in subpatchers, unless they are hidden by intervening
[ls/lr local some_name] objects.

[lsend global somename] -- point to (create if necessary) ) the global
some_name data structure.

For [lrecieve ...], same as above except that in addition to pointing to
the appropriate datastructure, install self in the list of lreceive objects
each datastructure maintains.

When objects are deleted, there's more work to do.

The above complexity doesn't affect performance, since when an lsend object
gets a message it simply goes to the datastructure to which it point and
forwards the message to each lreceive object in the data structure's list.

The code traversing the patcher hierarchy is already written and tested, so
I expect that sometime soon I'll find time to finish the job.

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

Date:    Tue, 4 May 1999 23:59:24 +0200
From:    Hucky Bruegger 
Subject: Re: - RAID level 4

>
here's the senario:  i'm trying to set up a raid for an instillation
that
will run for 2 months, hopefully w/out human intervention.  i have a
400mhz
G3 with 2 10000rpm ultrawide2 scsi drives and am possibly going to
purchase
a third ultra ata drive.  evidently, the word from tech for remus and
hard
disk tool kit is that one needs a non-raid configured drive to run the
system folder on a G3.  i am assuming that i could use a cheap ultra ata
drive to house the system folder, and max and all the files that i need
in
max's file path on the 2 drives that are configured for raid level 4.
(the
parity info will be on the third ata drive).  does anyone who has worked
with raids have anything other ideas?  or does that make sense?
>

by setup your drives with SoftRAID (AppleRAID) your can build
HFS, HFS+, RAID-0, RAID-1 with multiple Volumes on the same
two drives.
You can boot your MacOS from any Partition (also RAID-0)
You get higher performance compared with Remus-RAID.
to get max. out of your system go like:
build RAID-0 partitons first (first partitions are faster)
then HFS and HFS+
on the end of the drives layout your RAID-1 partitions.
you will get:
RAID-0 partitions:     highest speed -   lowest security
HFS, HFS+ partitions: midrange speed - midrange security
RAID-1 partitions:      lowest speed -  highest security

use the partitions for:
RAID-0:    data-streaming, Audio, Video, Caches....
HFS, HFS+: standard applications
RAID-1:    your personal data, backup

hucky bruegger @ redline musicware

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

Date:    Thu, 6 May 1999 01:48:16 +0200
From:    Manfred Karrer 
Subject: groove~ with crossfade supplement

i have  posted some questions how to do crossfade with the groove object
a few days ago and i have added a patch  which contained 2 abstactions.
here it is again but without these abstractions.

kao-li

max v2;
#N vpatcher 147 55 561 499;
#P button 211 165 15 0;
#P comment 49 373 100 196617 re:signal with fades;
#P message 234 86 20 196617 10;
#P newex 248 152 38 196617 / 100.;
#P comment 250 105 50 196617 fadetime in %;
#P newex 163 150 45 196617 loadbang;
#P comment 186 117 50 196617 endpoint;
#P newex 39 323 27 196617 *~;
#P newex 57 301 27 196617 *~;
#P newex 237 196 27 196617 / 1.;
#P newex 57 253 27 196617 -~;
#P newex 142 252 27 196617 *~;
#P newex 57 277 27 196617 *~;
#P message 173 175 17 196617 1.;
#P newex 173 200 27 196617 - 0.;
#P newex 74 229 62 196617 clip~ 0. 1.;
#P newex 49 37 45 196617 loadbang;
#P user ezdac~ 5 346 49 379 0;
#P flonum 248 129 52 9 0 50 3 3;
#P newex 142 230 62 196617 clip~ 0. 1.;
#P message 49 61 14 196617 1;
#P flonum 187 129 52 9 0 0 0 3;
#P flonum 129 129 49 9 0 0 1 3;
#P message 103 96 41 196617 loop \$1;
#P toggle 103 77 15 0;
#P toggle 49 87 15 0;
#P newex 49 113 27 196617 sig~;
#P newex 49 151 79 196617 groove~ sample;
#P message 154 69 28 196617 read;
#P newex 154 89 75 196617 buffer~ sample;
#P comment 129 117 50 196617 startpoint;
#P comment 49 341 100 196617 li:signal without fades;
#P connect 29 0 13 0;
#P connect 28 0 17 1;
#P connect 28 0 12 2;
#P connect 28 0 31 0;
#P connect 28 0 22 1;
#P connect 26 0 18 0;
#P connect 24 0 14 1;
#P connect 23 0 24 1;
#P fasten 22 0 19 1 242 273 79 273;
#P fasten 22 0 20 1 242 249 164 249;
#P connect 21 0 19 0;
#P connect 20 0 23 1;
#P connect 19 0 23 0;
#P fasten 18 0 21 0 178 195 62 195;
#P connect 18 0 17 0;
#P connect 18 0 22 0;
#P connect 17 0 16 1;
#P connect 31 0 17 0;
#P connect 31 0 22 0;
#P connect 16 0 21 1;
#P connect 15 0 11 0;
#P fasten 15 0 29 0 54 56 239 56;
#P connect 13 0 28 0;
#P connect 12 0 20 0;
#P connect 11 0 6 0;
#P connect 11 0 7 0;
#P connect 10 0 4 2;
#P connect 9 0 4 1;
#P connect 8 0 4 0;
#P connect 7 0 8 0;
#P connect 6 0 5 0;
#P connect 5 0 4 0;
#P fasten 4 0 14 0 54 176 10 176;
#P fasten 4 0 24 0 54 177 44 177;
#P connect 4 1 16 0;
#P connect 4 1 12 0;
#P connect 3 0 2 0;
#P pop;

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

End of MAX Digest - 4 May 1999 to 5 May 1999 - Special issue (#1999-136)
************************************************************************