From:
                                                            6/27/97 11:00 PM
Subject: MAX Digest - 27 Jun
1997To: Recipients of MAX digests 

There are 5 messages totalling 308 lines in this issue.

Topics of the day:

  1. timeline reverse
  2. reverse to MouseState
  3. multi-segment (Was: A Rant)
  4. int MyList[100] array in C.
  5. Hiccups

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

Date:    Fri, 27 Jun 1997 09:42:07 -0700
From:    Mike Metlay ++ Atomic City 
Subject: Re: timeline reverse

David Z asks--
>
>If someone has a proposal to define how reversing time would work that
>will make everyone happy, I'm all ears.

Oh, that's easy! Redo all of MAX 4.0 in Prolog! :)

Running for cover,
mike

--
"I want that. I want this. I want it NOW! Please."    (julia metlay, age 2)
===========================================================================
Mike Metlay - ATOMIC CITY - P. O. Box 81175, Pittsburgh, PA  15217-0675 USA
 =  atomic@netcom.com  --  http://pd.net/atomic-city   --  800.924.ATOM  =
CD orders via LOFTY PURSUITS: 800.548.6724 & 904.385.6463, FAX 904.668.5825

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

Date:    Fri, 27 Jun 1997 18:57:50 +0200
From:    Roby Steinmetzer 
Subject: Re: reverse to MouseState

>

>1) Is there a "reverse" object to MouseState? That is an object that
is

>beeing fed with x,y positions and then replaces the control over
mouse

>positions and clicks. And if so could this work in the background so
that

>i could use

>max digestable sensor systems to control another application in mac
by

>max piloted mouse.

Try the following patch:

max v2;

#N vpatcher 46 56 446 356;

#P message 29 36 105 196617 \; max pupdate 100 200;

#P message 28 135 113 196617 \; max pupdate 100 100;

#P pop;

Roby Steinmetzer

Luxembourg, Europe

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

Date:    Fri, 27 Jun 1997 10:36:35 -0700
From:    David Zicarelli 
Subject: Re: multi-segment (Was: A Rant)

I didn't make it clear: the problem with multi-segment code
resources resolved in Think C 6 (and Code Warrior) is precisely the
problem with using them in collectives, or when more than one multi-segment
object is being used at the same time. The only possible problem
might occur if two people wrote multi-segment objects and chose the
same resource IDs for their additional segments. Then some of the
segment resouces wouldn't get copied into the temp file or a collective.
But since the exact ID number of the segments is not important, they
can be changed by someone using the object. Max renumbers its
mAxL resources when adding them to collectives to avoid this problem,
but since in Code Warrior you can choose "any" resource type to
use for the additional segments, Max has no idea what constitutes
such a resource and conservatively leaves all other resource IDs
alone when it is making a collective.

As for using "Think C + Objects" to write externals, I am not
going to get into this. Life is too short to pay attention to
psuedo-C++ hacks when $19.95 will get you an actual C++ environment
with a decent compiler. And you'd be surprised who uses it. I saw
a guy leaning against a light pole drinking out of a paper bag on
Market St. in San Francisco wearing a CodeWarrior t-shirt last weekend.

David Z.

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

Date:    Fri, 27 Jun 1997 16:28:28 -0400
From:    Stephen Kay 
Subject: int MyList[100] array in C.

|K<:
>the biggest shame is that send/recieves don't accespt #1 style
>argument substitution and neither do tables, so you'll have to use

Don't know what you mean.  I use sends/receives with #1 style argument
substitution all the time.  Just put the argument first; i.e. =

#1_Controls     //valid
Controls_#1     //invalid
My#1Controls    //invalid

>it seems to me that you can just use a table.  tables with the same
>name access the same data, and are basically-->int MyList[100] array
>in C.

Here's an example of my method, using the coll and the funnel, to store a=
nd
edit individual bytes in an array.  It's a different approach that I've
used succesfully on many projects, and you can edit/display in the same
numboxes. Note: it's possible this patch may generate an error message on=

loading, since (I'm using a modified coll, but it should still work
correctly.)

Note that the unpack and all the sets could be replaced by an "unpackX 10=

set" (unpackX is from the MegaMAX Collection).

Stephen Kay

CollFunnel:

max v2;
#N vpatcher 50 40 603 460;
#P message 114 318 35 196617 set \$1;
#P number 114 340 35 9 0 0 0 3;
#P message 150 318 35 196617 set \$1;
#P number 150 340 35 9 0 0 0 3;
#P number 186 340 35 9 0 0 0 3;
#P message 186 318 35 196617 set \$1;
#P message 222 318 35 196617 set \$1;
#P number 222 340 35 9 0 0 0 3;
#P number 258 340 35 9 0 0 0 3;
#P message 258 318 35 196617 set \$1;
#P message 294 318 35 196617 set \$1;
#P number 294 340 35 9 0 0 0 3;
#P number 330 340 35 9 0 0 0 3;
#P message 330 318 35 196617 set \$1;
#P message 366 318 35 196617 set \$1;
#P number 366 340 35 9 0 0 0 3;
#P number 402 340 35 9 0 0 0 3;
#P message 402 318 35 196617 set \$1;
#P message 438 318 35 196617 set \$1;
#P number 438 340 35 9 0 0 0 3;
#P newex 214 276 131 196617 unpack 1 1 1 1 1 1 1 1 1 1;
#P newex 214 254 53 196617 r DataList;
#P newex 114 375 27 196617 s r1;
#P newex 186 375 27 196617 s r3;
#P newex 150 375 27 196617 s r2;
#P newex 222 375 27 196617 s r4;
#P newex 258 375 27 196617 s r5;
#P newex 294 375 27 196617 s r6;
#P newex 330 375 27 196617 s r7;
#P newex 366 375 27 196617 s r8;
#P newex 402 375 27 196617 s r9;
#P newex 438 375 33 196617 s r10;
#P comment 293 122 118 196617 store 10 numbers in coll;
#P message 260 142 195 196617 store 1 10 20 30 40 50 60 70 80 90 100;
#N coll int[10];
#T flags 1 0;
#T 1 10 20 30 40 50 60 70 80 90 100;
#P newobj 212 166 59 196617 coll int[10];
#P newex 212 196 53 196617 s DataList;
#P newex 412 52 33 196617 r r10;
#P newex 376 52 27 196617 r r9;
#P newex 340 52 27 196617 r r8;
#P newex 304 52 27 196617 r r7;
#P newex 268 52 27 196617 r r6;
#P newex 232 52 27 196617 r r5;
#P newex 196 52 27 196617 r r4;
#P newex 124 52 27 196617 r r2;
#P newex 160 52 27 196617 r r3;
#P newex 88 52 27 196617 r r1;
#P newex 194 83 131 196617 funnel 10 1;
#P newex 194 133 28 196617 grab;
#P newex 194 106 70 196617 prepend sub 1;
#P comment 64 100 100 196617 click to send to display/edit boxes;
#P button 102 132 15 0;
#P comment 27 186 75 196617 by Stephen Kay;
#P comment 26 333 80 196617 Edit values in the coll in place:;
#P connect 18 0 17 0;
#P connect 6 0 4 0;
#P connect 51 0 30 0;
#P connect 31 0 32 0;
#P connect 32 0 52 0;
#P connect 32 1 50 0;
#P connect 32 2 47 0;
#P connect 32 3 46 0;
#P connect 32 4 43 0;
#P connect 32 5 42 0;
#P connect 32 6 39 0;
#P connect 32 7 38 0;
#P connect 32 8 35 0;
#P connect 32 9 34 0;
#P connect 52 0 51 0;
#P connect 49 0 28 0;
#P connect 50 0 49 0;
#P connect 48 0 29 0;
#P connect 47 0 48 0;
#P connect 46 0 45 0;
#P connect 45 0 27 0;
#P connect 44 0 26 0;
#P connect 43 0 44 0;
#P connect 42 0 41 0;
#P connect 41 0 25 0;
#P connect 40 0 24 0;
#P connect 39 0 40 0;
#P connect 38 0 37 0;
#P connect 37 0 23 0;
#P connect 36 0 22 0;
#P connect 35 0 36 0;
#P connect 34 0 33 0;
#P connect 33 0 21 0;
#P connect 4 0 5 0;
#P connect 5 1 18 0;
#P connect 19 0 18 0;
#P connect 16 0 6 9;
#P connect 15 0 6 8;
#P connect 14 0 6 7;
#P connect 13 0 6 6;
#P connect 12 0 6 5;
#P connect 11 0 6 4;
#P connect 10 0 6 3;
#P connect 9 0 6 1;
#P connect 8 0 6 2;
#P connect 7 0 6 0;
#P connect 2 0 18 0;
#P pop;

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

Date:    Fri, 27 Jun 1997 16:28:35 -0400
From:    Stephen Kay 
Subject: Hiccups

>Hello,
>I've recently upgraded from Max 3.0 to 3.5.4PPC. I've transfered a patch=
 I
>was working with to the new version. A problem I now encounter is that i=
t
>seems that Max hiccups every once in a while, like it garbage-collects o=
r
>gulps for air. It happens more frequently when there's a lot of incoming=

>MIDI. As I'm working with steady beat material it is very apparent, it's=

>adrop in the beat. Does anyone know what is the problem, whether it's wi=
th
>Max, OMS, or whatever?

>Thanks,
>Gil

Well, assuming your problem is not that Overdrive is turned off, then you=

may be the first other person to report what I've known about for a long
time: that in certain situations, 3.5's timing is noticeably less stable
than 3.0.  I have a monstrous application that I've been developing in 3.=
0,
and it simply will not work in 3.5.  When I input midi from a keyboard in=
to
it quickly, the notes that it is generating definately 'hiccup' in
precisely the fashion you have described.

I then built a patcher with standard MAX objects to simulate heavy
processing, and recorded the results into Vision.  The difference between=

3.0 and 3.5 was extremely noticeable, and very measureable.  I sent the
results to David Z. who has confirmed that the program is overall slower,=

but cannot offer any explanation, other than it might be that CodeWarrior=

generates slower code than THINK C, which is what compiled 3.0.

I should note that this "slower" behavior was not noticeble on my 225 mHz=

PPC, which is where I was developing the app at the time I switched to 3.=
5.
 So I plowed along using 3.5 for while, thinking everything was fine, unt=
il
I tried to run the app on my PBook 520 or Quadra 840 A/V.  Then the timin=
g
and hicupping was quite noticeable.

One other thing David Z. suggested to me:  68040s won't be around forever=
=2E
Not much help.
I have been forced to stay locked in 3.0 because of this.

Stephen Kay

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

End of MAX Digest - 27 Jun 1997
*******************************

X-Mozilla-Status: 0001
Content-Length: 3947