Subject: MAX Digest - 21 Feb 1999 to 22 Feb 1999 (#1999-62)
Date: Tue, 23 Feb 1999 00:00:08 -0500
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 12 messages totalling 508 lines in this issue.

Topics of the day:

  1. Patch Cord Solutions (2)
  2. message variables with comma???? (5)
  3. Patchcords
  4. cost the same on PPC?
  5. Patchcord condiuts
  6. Routing
  7. patch cord crazy,...audio anyone

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

Date:    Mon, 22 Feb 1999 10:51:46 +0200
From:    Tom Mays 
Subject: Re: Patch Cord Solutions

>Stephen Kay 
>I've never had a problem selecting objects OR (||) patchcords.
>If your object has so many patchcords running across it that it's
>impossible to select, then that is a problem of your patch layout.

>I thought the idea was to select an object, and have any patchcords
>connected to it then hilited in some fashion that makes them easier
>to see, and to select.  THAT would be handy.

Max individuality strikes again. For *me* if you can't see where your
patchcords are going (or coming from) by looking and or clicking
in one of them to highlight it,
"then that is a problem of your patch layout."

However, with the current size of the "cord selection zone"  (that
seems to me to have gotten bigger sometime in the last few years)
it doesn't take much of a patch before you start getting frustrated
trying to select an object and getting the patchcord instead.

but, Alas, as I'm writing this I'm starting to beleive I understand
the problem. Those of us who like to use diagonal patchcords
because it's easier to see where they are going end up with
the problem of cords obscuring objects. While those who use
segmented patch cords "a lot" or exclusively don't obscure their
objects, but they can't see where they're connected. Hense, this
polarization of priorities.

So, now "cher" David Z. has to decide to either address one of the
two philosophies, both, or neither - as this could once again be
living proof that Max *is already* the best compromise solution.

Don't know.

I agree with Stephen, though, that lot's of silly layers making things
complicated (and sloppier) is not a solution. A patch cord layer and
and objects layer, however, to me seems justifiable (aka. three edit
modes, as I described in the last digest.).

z mays

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

Date:    Mon, 22 Feb 1999 13:22:17 +0000
From:    david stevens 
Subject: message variables with comma????

hi all,

here's something that i've wanted to do several times, but which i've been
unable to figure out how to do.....

i want to be able to trigger play~ by sending it a list in the usual form of
[0,500 1000], but i also want to be able to change all of the arguments - ie
i
want the message to be [$1, $2 $3].  the sticking point is that comma after
the
first number. i've tried with pack, append, and also with coll, but i
haven't
been able to get the message to play~ in a form that it understands.

there must be a really simple way of doing this! wnat is it!

thanks

david

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

Date:    Mon, 22 Feb 1999 14:59:20 +0000
From:    Lawrence Casserley 
Subject: Patchcords

Hi

Further to the various discussions on saving patchcords, may I add some
comments.

1) IMHO it is frequently possible to make patches more readable by
reducing the number of patchcords in and out of patchers, as they can
sometimes become unreasonably numerous (and splitting the patcher into
smaller units can often make it even worse!). I find there are a number
of useful approaches to this.

2) Liberal use of send and receive can be helpful if care is taken to
make it clear where they are going. I sometimes use names which include
the name of the patcher (I _always_ name patchers!), eg if the patcher
is named 'functionX' then receives within it are called 'functionX-freq'
or whatever. Of course, if a send goes to several patchers some other
device is called for. If you want to make this clear they can be called
'global-section-number' or something. (I am gradually learning that the
extra few characters needed to make easily understandable names saves a
lot of time later - though I still get tempted to abbreviate when in a
hurry! [which is most of the time!!].

3) The advantage of using pack and unpack is that the messages are
synchronised. Whether this is desirable will depend upon the
circumstances. What this does do is group several signals together
making it clear that they all go to the same place. If they go via a
well named send and receive it is even clearer.

4) Thank you for introducing me to funnel and spray. I seem to have
missed those two. I upgraded from 2.5.2 to 3.5.8 in order to run msp as
part of my migration from ispw. I have a funny collection of old and
upgrade manuals with quite a few holes in the documentation - although I
notice these ones lay overlooked in the original manual! (Any chance of
getting hold of that complete acrobat manual without buying another copy
of MAX/msp?).

funnel and spray would seem to offer the advantage of pack unpack I
suggested above, while allowing the messages to remain independent when
that is desirable. I think I'll be using them. Although a version
handling any message type would make them even more useful. And it just
goes to show that even after many years of working with MAX there are
still things to learn. Let that be a lesson to all of us!!!

Best

Lawrence

--
Lawrence Electronic Operations -Tel +44 1494 481381 -FAX +44 1494 481454
Signal Processing for Contemporary Music -email leo@chiltern.demon.co.uk
http://www.chiltern.demon.co.uk

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

Date:    Mon, 22 Feb 1999 07:46:37 -0800
From:    Philip Aker 
Subject: cost the same on PPC?

(From: Re: dithering (was re: MSP resolution))

Peter Castine <
} In choosing between truncating and rounding, they're both in
} the same computational cost ballpark, with rounding being a
} little more expensive (unless Philip is correct in his
} analysis/guess that both can cost the same on PPC). But the
} difference in audio quality is also not real big.

For multiplying (-1.0 <-> 1.0) by 32767.0 and adding 0.5 the
main instructions I had in mind would be:

fmadd
fmadd.
fmsub
fmsub.

which would probably be used in conjunction with others
for an optimized situation.

In the FPSCR the bits of interest (besides several exception
flags) seem to be:

FR   The floating point fraction has been rounded :1
FI   The floating point fraction is inexact       :1
FPRF Floating point result flags                  :5
RN   Floating point rounding control              :3

FPRF
10001 Quiet NaN
01001 -infinity
01000 -normalized number
11000 -denormalized number
10010 -zero
00010 +zero
10100 +denormalized number
00100 +normalized number
00101 +infinity

RN
00 round to nearest
01 round towards zero
10 round towards +infinity
11 round towards -infinity

Looking at fmadd (the '.' variant updates the condition
register) and quoting from "Power PC:A Practical Companion"[*]:

fmadd frD,frA,frC,frB

The floating point operand in register frA is multiplied by
the floating-point operand in register frC. The floating point
operand in register frB is added to this intermediate result.
If the most significant bit of the resultant significand is
not a one the result is normalized. The result is rounded to
the target precision under control of the floating-point
rounding control field RN of the FPSCR and placed into register
frD. FPSCR[FPRF] is set to the class and sign of the result,
except for invalid operation exceptions whin FPSCR[VE]=1.

And the reason why I'm lead to believe that this takes no more
time than a simple multiply (no add 0.5) is due to the
superscalar nature of these Motorola chips. At the very least
it's much faster than a separate add. Plus the fact that the
rounding factor is a well known problem - hence the specialized
instructions.

Thanks,

Philip
philip@vcn.bc.ca

[*] by Steve Heath, 1994.

Note: This was the only book available at the time. I wouldn't
be surprised if there was a more comprehensive, accurate, and
up-to-date volume published by now.

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

Date:    Mon, 22 Feb 1999 09:28:17 -0800
From:    Alex Stahl 
Subject: Re: message variables with comma????

At 5:22 AM -0800 2/22/99, david stevens wrote:
>i want to be able to trigger play~ by sending it a list in the usual form
of
>[0,500 1000], but i also want to be able to change all of the arguments -
ie i
>want the message to be [$1, $2 $3].  the sticking point is that comma
>after the
>first number. i've tried with pack, append, and also with coll, but i
haven't
>been able to get the message to play~ in a form that it understands.

Put a backslash \ before the comma. For example, to make a message output

0,500 1000

type

0\, 500 1000

into the message box. The backslash will not be output, but the comma will.

$1 \, $2 $3 will work also.

The backslash means, do not interpret the following character as anything
special, just send it out.
If you ever want to get a backslash  out of a message box, you can use \\.
I don't know when that might be useful, although DOS uses a lot of
backslashes, and someone might prefer its interface over Max and wish to
emulate it :-)

>there must be a really simple way of doing this! wnat is it!

Simple, yes. Obvious, not necessarily...

-Alex S.

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

Date:    Mon, 22 Feb 1999 11:04:46 -0800
From:    Peter Elsea 
Subject: Patchcord condiuts

>(Other than funnel only works for ints.  But a floating point or
>symbol version would be relatively simple to make.)

Label (one of the Lobjects- ftp://arts.ucsc.edu/pub/ems/) works like
funnel, except you can have arbitrary labels and it will work with floats
and lists. Used in conjunction with route, it will give the behavior you
have been discussing.

There is a new version of Label in the beta_98 section that supports my 00h
hex data format. It works very nicely with lsx (also in beta) to do sysex
with automatic data packing. I've had no complaints about any of the
beta_98 Lobjects, so I suppose that means they are all bulletproof and
terribly useful, right?
Peter Elsea
Electronic Music Studios
University of California, Santa Cruz
http://arts.ucsc.edu/EMS/Music/index.html
 elsea@cats.ucsc.edu

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

Date:    Mon, 22 Feb 1999 14:11:22 EST
From:    JohnBrit@AOL.COM
Subject: Re: Routing

In a message dated 2/21/99 21:00:36, SK wrote:

> it would be simple to write a pack object that
>output its list when receiving input at any inlet, and equally simple
>to write an unpack object that only sent data out of an outlet if it had
>changed from previously sent data.  Therefore, you could move 1 UI object
>connected to the pack, and have 1 data item come out of the appropriate
>outlet of the unpack.  Since unpackX (enhanced unpack object) is already
>part of the MegaMax Collection, this would be relatively simple for me
>to do.  If people think this is useful, let me know.  But I don't think
>it's necessarily any better than below

Stephen,
As you pointed out, using funnel and spray works fine for ints. Route and
Gate
at the decode end work for any type but since they can only have 10 outlets,
it would be necessary to chain a few together. This kind of limit is often a
problem. SelX is a godsend (although I'm not implying that you are a god).
If
you could write the packx and unpackx as described in your posting so that
any
input only caused a corresponding output, I would say gimme gimme gimme. You
might not see this as useful as I do but then that proves the old addage
that
"one man's pizza is anotherman's dogshit".
JW.

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

Date:    Mon, 22 Feb 1999 20:59:29 +0000
From:    david stevens 
Subject: Re: message variables with comma????

ok -

i wrote:

> >i want to be able to trigger play~ by sending it a list in the usual form
of
> >[0,500 1000], but i also want to be able to change all of the arguments -
ie i
> >want the message to be [$1, $2 $3]. 
>
Alex Stahl replied: (thanks Alex)

> Put a backslash \ before the comma. For example, to make a message output
>
> 0,500 1000
>
> type
>
> 0\, 500 1000

ok, i tried that. I have 3 number boxes feeding into a [pack 3]. this goes
into
a message box with the form [$1\, $2 $3].  if i connect [print] to this, i
am
indeed getting a message in the correct form.
if i then connect this message into [line~]  (which feeds into [play~] ), i
keep
getting the message
error: line~ does not understand "1125,"  (where the number obviously varies
as
to the first number in my list).

i also tried using [pack] into [set $1\, $2 $3] into a message box, with a
bang
from pack to send the message to [line~] - but i still get the same error
message. I suspect that the first part of the message has turned into a
symbol,
which is why [line~] doesn't recognise it. yes? no?

so the original query still stands - how can i vary the 3 numbers needed to
control [play~] from 3 number boxes?

thanks

david

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

Date:    Mon, 22 Feb 1999 18:46:07 -0500
From:    Stephen Kay 
Subject: Re: message variables with comma????

>ok, i tried that. I have 3 number boxes feeding into a [pack 3]. this go=
es
into
>a message box with the form [$1\, $2 $3].  if i connect [print] to this,=
 i
am
>indeed getting a message in the correct form.

The "\" reverse backslash is only needed if you want the message box
to put out the comma.  In this case, you don't.  You want to send
2 separate messages, which is what the comma does - it separates
individual messages inside a message box.  So you are not getting the
message in the correct form.  What you should see in the Max window
is something like:

print: 5
print: 10 20

>so the original query still stands - how can i vary the 3 numbers needed=

to
>control [play~] from 3 number boxes?

I can't seem to duplicate your problem.  In other words, if I hook up
a 3 number [pack] to a message box with [$1, $2 $3], and then run
the output to line~, there are no error messages.

Stephen Kay

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

Date:    Mon, 22 Feb 1999 18:46:11 -0500
From:    Stephen Kay 
Subject: Re: Patch Cord Solutions

Tom Mays said:
>However, with the current size of the "cord selection zone"  (that
>seems to me to have gotten bigger sometime in the last few years)
>it doesn't take much of a patch before you start getting frustrated
>trying to select an object and getting the patchcord instead.

>but, Alas, as I'm writing this I'm starting to beleive I understand
>the problem. Those of us who like to use diagonal patchcords
>because it's easier to see where they are going end up with
>the problem of cords obscuring objects. While those who use
>segmented patch cords "a lot" or exclusively don't obscure their
>objects, but they can't see where they're connected. Hense, this
>polarization of priorities.

Actually, another possibility that occurs to me is that one
of the available modifier keys (I think maybe  is the only
one unused at the moment) could be used to "select through"
patchcords.  In other words, if you have an object covered
with patchcords, by using the control key the cursor essentially
ignores the patchcords and selects the object underneath.

Stephen Kay

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

Date:    Mon, 22 Feb 1999 16:08:52 -0800
From:    Alex Stahl 
Subject: Re: message variables with comma????

>The "\" reverse backslash is only needed if you want the message box
>to put out the comma.  In this case, you don't.

Of course. My mistake, I glommed onto "the old comma in a message box
problem" without
reading the specifics carefully enough. Monday morning, teething one-year
old, etc etc.

>>so the original query still stands - how can i vary the 3 numbers needed
>to
>>control [play~] from 3 number boxes?
>
>I can't seem to duplicate your problem.  In other words, if I hook up
>a 3 number [pack] to a message box with [$1, $2 $3], and then run
>the output to line~, there are no error messages.

Yes, that works for me too.

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

Date:    Mon, 22 Feb 1999 16:48:42 -0800
From:    Jim Wood 
Subject: patch cord crazy,...audio anyone

Id like to ask again if theres a chance MPEG format
could be read into MAX Msp in thee near future
Possibly an object like Eric Singers Aiff player or
a converter object for buffer~
Anyone got any ideas about this?

My thinking is a lot of people will use MPEG audio as
time goes on because of good compression.

THere are a number of Mac apps to play encode
MPEGlayer 2&3 too difficult to port to MAX

cheers

Jim Wood

PS Idont think that MAx is supposed to be  agraphics
application as someome sneered.Just a modernisation
of graphics window/quicktime capabilities would bring
it up to date with MacOS 8+ screen and Quicktime3.
Its funny that so much thought goes into what colour
shape size texture etc to make the patch cords.
Anyway I agree that the simplest idea is best-
dimmable
unselected , and colurable as objects from foldercolors
seems like enough.

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

End of MAX Digest - 21 Feb 1999 to 22 Feb 1999 (#1999-62)
*********************************************************