From:
                                                            6/27/97 11:37 AM
Subject: MAX Digest - 26 Jun 1997 to 27 Jun 1997 - Special
issueTo: Recipients of MAX digests 

There are 12 messages totalling 523 lines in this issue.

Topics in this special issue:

  1. Displaying PICTs
  2. multi-segment (Was: A Rant) (3)
  3. A Rant (was: New vs. Old)
  4. Galaxy
  5. Hiccups (2)
  6. MAX Digest - 25 Jun 1997 to 26 Jun 1997 - Special issue
  7. int MyList[100] array in C.
  8. rant vs. new vs. old vs. mothra
  9. PowerBooks (was A Rant)

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

Date:    Fri, 27 Jun 1997 06:24:17 +0200
From:    Guenther Albrecht 
Subject: Re: Displaying PICTs

Gregg Wagstaff  wrote about his need to change picts. I had the same
need some weeks ago & ended with a menu object that sent a name to the
pict object when triggered (i used that for cues). you edit the menu
object & write the names into it, what makes changes simple. also you
could easily trigger more menues & picts at the same time. one hint: set
the offset manually (it will work long before...).

hope this helps!

.g.a.

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

Date:    Thu, 26 Jun 1997 21:29:56 -0700
From:    David Zicarelli 
Subject: Re: multi-segment (Was: A Rant)

>Nick Rothwell:
>>I keep saying it because David Z. said it; something about a problem wit=
>h
>>code resource id's in multi-segment projects, which arises under rare
>>circumstances. I can't remember the details now; is there a mailing list=
>
>>archive?
>
>Well, I think you are worrying needlessly (please chime in David, if you
>wish). As I mentioned, multi-segment externals have been safe and
>operational for me for years, under both THINK C and CodeWarrior.

Nick,

Stephen is right. The issue was dealt with in Think C 6. Before that,
the extra segs always had the same numbers. In Think C 6, they're the
negation of your mAxL resource number. In Code Warrior, you can
specify exactly what they are, as well as the resource type (as long
as Code Warrior likes your resource type; it rejects a lot of things
without telling you why.)

Also, I'm not sure why an object-oriented project would require extra
segments. It's the size, not the technique. And yes, you can do C++
externals. The only issue is translating the C++ object to Max
if it contains virtual methods by adding to or subtracting from the
object pointer to skip over the vtable. Also, you can't use new
and delete, you have to let Max allocate and free the memory for you.
If you are going to use vtables you have to new the object with the
flavor of the new operator that does nothing (other than fill in the
vtable). In CodeWarrior you have include  to use it.

OK, there's my scary jargon post for the week.

David Z.

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

Date:    Thu, 26 Jun 1997 23:07:45 -0800
From:    Richard Zvonar 
Subject: Re: A Rant (was: New vs. Old)

On  Thu, 26 Jun 1997 10:18:26 +0100  Nick Rothwell  wrote:

>... For a while, I've been
>thinking that what I need to do is implement my own editor/librarian shell
>for MAX in C, providing stuff like patch randomisation, parent/child
>linkage, parent/child cut and paste, variable-length data objects (like
>wave sequences, or R-8 patterns), and so on.

Please do.

______________________________________________________________________________
Richard Zvonar, PhD                              zvonar@LCSaudio.com
(818) 760-8055 voice/fax                         71501.3342@compuserve.com

                          http://www.well.com/~zvonar

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

Date:    Fri, 27 Jun 1997 02:21:22 EDT
From:    Roland Hemming <100414.2220@COMPUSERVE.COM>
Subject: Galaxy

Further to all this librarian chat.

When MAX 3.0 was being developed there was discussion of making it possible
for
a MAX patcher to become a Galaxy editor.

Presumeably Galaxy would include a sort of MAXplay inside it.

David, could you tell us more about this, and how it might work and why it
didn't or can't happen?

Roland

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

Date:    Fri, 27 Jun 1997 13:05:25 +0300
From:    Gil Wasserman 
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 it
seems that Max hiccups every once in a while, like it garbage-collects or
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 with
Max, OMS, or whatever?

Thanks,
Gil

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

Date:    Fri, 27 Jun 1997 11:28:58 +0100
From:    Nick Rothwell 
Subject: Re: multi-segment (Was: A Rant)

>Stephen is right. The issue was dealt with in Think C 6. Before that,
>the extra segs always had the same numbers. In Think C 6, they're the
>negation of your mAxL resource number.

I had a trawl back through my mail archives, and found a message where you
were talking about some problem with THINK C's numbering of code resources
in a multi-segment project, and how this could potentially clash with the
resource renumbering in Collectives. Is this still a problem? (I should
create a test multi-segment project, where multi=three or more, and see
what it does.)

>Also, I'm not sure why an object-oriented project would require extra
>segments. It's the size, not the technique.

I've never understood it either, but the system does enforce this. A shame,
since I suspect that many of my objects would just about fit into a single
segment, even with the OOP stuff included. Another thing I will try is
creating such a multi-segment project, but with only one actual segment.

>And yes, you can do C++ externals.

I'm not sure I trust Symantec's C++ (aka Zortech) in 6.0 or 7.0 to be as
reliable as Kahl's THINK C.

>The only issue is translating the C++ object to Max
>if it contains virtual methods by adding to or subtracting from the
>object pointer to skip over the vtable.

THINK C has virtuals, but not pure virtuals. Is there still a problem? (I'm
not sufficiently up on OOP implementation to understand all the mechanics.)

>Also, you can't use new
>and delete, you have to let Max allocate and free the memory for you.

Is this other than the usual no-alloc-at-interrupt restriction? (i.e. would
new and delete be fine in main(), and in the object's creation and deletion
methods, and in qelem callbacks?) Or is there something else going on here?

>If you are going to use vtables you have to new the object with the
>flavor of the new operator that does nothing (other than fill in the
>vtable). In CodeWarrior you have include  to use it.

OK, now I'm completely lost...

         Nick Rothwell, CASSIEL        contemporary dance projects
         http://www.cassiel.com        music synthesis and control

             years, passing by, VCO, VCF, and again, and again

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

Date:    Fri, 27 Jun 1997 11:33:53 +0100
From:    Nick Rothwell 
Subject: Re: Hiccups

>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 it
>seems that Max hiccups every once in a while, like it garbage-collects or
>gulps for air.

Completely wild guess: has Overdrive somehow been turned off?

         Nick Rothwell, CASSIEL        contemporary dance projects
         http://www.cassiel.com        music synthesis and control

             years, passing by, VCO, VCF, and again, and again

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

Date:    Fri, 27 Jun 1997 14:57:39 +0300
From:    Jukka Ylitalo 
Subject: Re: MAX Digest - 25 Jun 1997 to 26 Jun 1997 - Special issue

Hi maxers,

two questions:

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.
Has anyone done anything like this? or do i need to dive into AppleScript
world or do it all in C++?

2) Is the wc-object working? I tried to login eith the help patch, it gave
this notice in max
window:

wc:looking for www.opcode.com...
wc: trying to open IP 204.247.95.3...
* error:wc:TCPActiveOpen err -23012 ()

should i have a particular Username or
is the server software for wc available?

__*__*__*______J-u-k-k-a______Y-l-i-t-a-l-o______*__*__*__

-------------------Meet the Meat and sensorsounds-----------------

>>>>>>>>>>>>>>>>>>>>>>juylital@cc.helsinki.fi<<<<<<<<<<<<<<<<<<<

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

Date:    Fri, 27 Jun 1997 14:00:36 +0100
From:    Nick Rothwell 
Subject: Re: multi-segment (Was: A Rant)

oh, yes, the other thing, I guess, is that root classes in THINK C should
be declared as ": direct" rather than ": indirect", otherwise method calls
will be going via handles which are potentially moveable and unsafe at
interrupt...

(All the multi-segment project documentation in the WritingExternals
document seems to make sense btw.)

         Nick Rothwell, CASSIEL        contemporary dance projects
         http://www.cassiel.com        music synthesis and control

             years, passing by, VCO, VCF, and again, and again

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

Date:    Fri, 27 Jun 1997 14:42:59 +0100
From:    "|K<" 
Subject: int MyList[100] array in C.

   > Again, I don't want to have to draw up too 100 patch cords
   > connecting the output of each number box back to the object
   > storing the global MyList list.

>Welcome to MAX!  What you have described as _not wanting to do_ is
>precisely the way you have to do it.  One thing that can make it a
bit
>easier is to use "funnel" to store values into a coll.

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.

when you need to dump it into your number boxes, uzi-counter through
the table into a qlist that sends your messages out to their
respective recieves (number boxes in remote subpatches).  [if you
don't use qlist you can use the message-box method of sending to
remote recieve by starting with a semicolon]

the biggest shame is that send/recieves don't accespt #1 style
argument substitution and neither do tables, so you'll have to use
your uzi-counter scheme to generate the s/r names with sprintf, but
that's easy.

here's an example with a global array of 10 elements, it's easily
modifiable for your situation.

|K<

++++++++max v2;
#N vpatcher 146 49 766 582;
#P number 488 386 35 9 0 0 0 3;
#P newex 487 367 27 196617 r r3;
#P number 527 385 35 9 0 0 0 3;
#P newex 527 366 27 196617 r r4;
#P number 449 386 35 9 0 0 0 3;
#P newex 449 367 27 196617 r r2;
#P number 411 386 35 9 0 0 0 3;
#P newex 411 367 27 196617 r r1;
#P comment 411 352 100 196617 remote edit boxes;
#P newex 528 407 29 196617 t b i;
#P message 528 427 14 196617 4;
#P newex 488 407 29 196617 t b i;
#P newex 450 408 29 196617 t b i;
#P message 450 428 14 196617 2;
#P message 411 427 13 196617 1;
#P newex 411 407 29 196617 t b i;
#P message 488 427 14 196617 3;
#P newex 410 453 29 196617 pack;
#P newex 454 449 28 196617 pack;
#P newex 490 450 28 196617 pack;
#P newex 527 450 28 196617 pack;
#P newex 417 487 136 196617 s changeGlobalArrayElement;
#N vtable 10 40 55 250 222 2 65566 globalArray;
#P newobj 17 463 87 196617 table globalArray;
#P newex 17 444 136 196617 r changeGlobalArrayElement;
#P number 494 231 35 9 0 0 0 3;
#P newex 493 212 27 196617 r r3;
#P number 533 230 35 9 0 0 0 3;
#P newex 533 211 27 196617 r r4;
#P number 455 231 35 9 0 0 0 3;
#P newex 455 212 27 196617 r r2;
#P number 417 231 35 9 0 0 0 3;
#P newex 417 212 27 196617 r r1;
#P comment 416 187 100 196617 remote view boxes;
#P comment 147 466 237 196622 http://music.calarts.edu/~kent;
#P comment 216 417 100 196644 K·  ;
#P button 329 229 15 0;
#P message 196 251 114 196617 kent@music.calarts.edu;
#P newex 208 61 162 196617 t i b;
#P message 205 43 20 196617 10;
#P newex 202 203 121 196617 sprintf append r%d %d\\\;;
#N vtable 10 40 55 250 222 2 65566 globalArray;
#P newobj 225 167 87 196617 table globalArray;
#P button 346 165 15 0;
#P message 343 203 35 196617 set \\\;;
#P newex 209 107 66 196617 counter 9;
#P newex 208 136 40 196617 t i i b;
#P newex 209 84 126 196617 Uzi;
#P button 206 25 15 0;
#P comment 223 25 254 196620 click to update edit boxes;
#P newex 11 82 147 196617 s jamTenNumbersIntoMyArray;
#P message 11 63 95 196617 9 8 7 6 5 4 3 2 1 0;
#N vtable 10 40 55 250 222 2 65566 globalArray;
#P newobj 17 372 87 196617 table globalArray;
#P newex 17 317 66 196617 counter 9;
#P newex 17 350 28 196617 pack;
#P newex 17 287 27 196617 t b i;
#P newex 18 268 25 196617 iter;
#P newex 18 245 147 196617 r jamTenNumbersIntoMyArray;
#P comment 10 45 127 196618 enter all 10 at onces;
#P connect 7 0 8 0;
#P connect 2 0 3 0;
#P connect 3 0 5 0;
#P connect 3 1 4 1;
#P connect 5 0 4 0;
#P connect 4 0 6 0;
#P connect 1 0 2 0;
#P connect 11 0 13 0;
#P connect 11 1 21 0;
#P connect 18 0 19 0;
#P connect 14 0 20 0;
#P connect 13 0 12 0;
#P connect 49 0 50 0;
#P connect 51 0 52 0;
#P connect 55 0 56 0;
#P connect 53 0 54 0;
#P connect 50 0 41 0;
#P connect 52 0 44 0;
#P connect 16 0 17 1;
#P connect 12 0 17 0;
#P connect 12 1 16 0;
#P connect 56 0 45 0;
#P connect 54 0 47 0;
#P connect 42 0 39 0;
#P connect 43 0 38 0;
#P connect 40 0 37 0;
#P connect 17 0 20 0;
#P connect 15 0 14 0;
#P connect 21 0 20 0;
#P connect 46 0 36 0;
#P connect 19 0 11 0;
#P connect 19 1 15 0;
#P connect 44 0 43 0;
#P connect 44 1 38 1;
#P connect 45 0 40 0;
#P connect 45 1 37 1;
#P connect 47 0 46 0;
#P connect 47 1 36 1;
#P connect 41 0 42 0;
#P connect 41 1 39 1;
#P connect 36 0 35 0;
#P connect 37 0 35 0;
#P connect 38 0 35 0;
#P connect 39 0 35 0;
#P connect 33 0 34 0;
#P connect 25 0 26 0;
#P connect 27 0 28 0;
#P connect 29 0 30 0;
#P connect 31 0 32 0;
#P connect 10 0 18 0;
#P pop;

_______________________________

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

Date:    Fri, 27 Jun 1997 09:23:10 -0700
From:    Mike Metlay ++ Atomic City 
Subject: Re: rant vs. new vs. old vs. mothra

From:    Peter Nyboer 
>
>>The truth is that these machines are not designed to work perfectly
>>with a wide suite of applications for music on them, because the
>>people who write said applications do not WANT them to coexist.  MOTU
>>and Opcode are not in this business to make nice-nice with each other;
>>they are in this business to crush, kill, DESTROY each other...
>
>True, but Quicktime has developed as a nice standard for pushing pictures
>on computers.  Not that it's flawless, but it certainly enables a lot of
>hardware and software makers to make things that make everything from
>crappy little desktop videos to high-quality video productions.  Of course,
>Quicktime is more lucrative for Apple since it drives the sales of
>high-profit video capable machines, and people seem to be doing a whole lot
>more looking at things than listening....

QuickTime was handed down from Apple to everyone else and they were
ordered to make it the Next Big Thing; it was in the best interest of
people who wanted to make money with it to do so, since the basic idea
was solid enough to make exploring alternatives less than profitable,
so it became a standard. No touchy-feely involved. Apple said, "Use
this tool to accomplish this task" and the industry said "Okay, since
it works (or will work with some tweaks)."

No different than MIDI, when it was introduced-- most youngsters don't
remember the incompatibility black hole the synth industry was heading
into in 1981-1982, and what a godsend MIDI must have seemed to those
forward-looking enough to get past the initial implementation problems
(and rich enough to force the issue). For that matter, does anyone
remember the ENORMOUS stink the industry raised when Apple invented the
3.5" floppy disk with its hard shell and fiddly little springloaded
door, when 5.25" floppies were a perfectly acceptable standard? Heh.

>>The only motive is profit. The only impetus is success.
>
>Have you been giving corporate motivational semiars??  Ok, so the rest of
>the letter indicates not, but the above does have a certain Anthony
>Robbins-esque ring to it.

Nah, my primary inspiration is Ayn Rand, mixed liberally with a 20-year
history in the music business, with time spent firmly in many different
camps: end user, journalist, manufacturer....

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 09:37:20 -0700
From:    Mike Metlay ++ Atomic City 
Subject: PowerBooks (was A Rant)

Nick Rothwell make scratch on rock with flint:
>
>Mike will testify that, for a lot of the time I was with him on a recent
>recording project, we were making phone calls to all manner of dodgy
>computer resellers in an attempt to find a second PB165 for me.

I will testify to no such thing. In fact, I won't get NEAR a courtroom
with you. Do you know what my life would be worth if I testified?

>I don't have any MIDI problems with any of my PowerBooks, although their
>SCSI implementations are distinctly dodgy, which is why I still have my
>SE/30 sitting in a corner, in case I need to mount something weird in a
>hurry.

Since all I ever do over SCSI is drag'n'drop to a Zip, this isn't an
issue for me. But I'd imagine people using MAX to control SCSI
peripherals might find this aggravating. What sort of problems does
one see?

>>MAX has as
>>part of its fascination the ability to evolve and add new features and
>>abilities...
>
>This is where I think our wavelengths are different. MAX does fascinate me
>because it's open-ended. But I'm looking at open-endedness on a different
>axis: it's a construction set, and I can build things in it; that's nothing
>to do with upgrades.

That's what I was getting at. Like I said, I'm always fascinated by
where David Z and the many contributors to the MAX idea base take this
program; it's a growth process, which I watch with amazement and some
joy. Perhaps not everything new is useful to me, but a solid new set
of tools to automate tasks that might otherwise have to be customized
is a big sweat-saver. I'd rather be building a wall than making bricks
(sorry, Herr Eno, wherever you are).

>Btw, sticking with Galaxy means sticking to instruments which are either
>front-panel editable, or old enough that your version of Galaxy supports
>them, since you can't extend Galaxy with new editors. Yeah yeah, so what's
>my point?

As Peter said: that it'd be nice if MAX had better objects for
building librarians and editors? I'm not sure if I agree. MAX does
such cool stuff that it seems rather pedestrain and wasteful to use it
as an editor/librarian. Rather like using an axe to kill a fly. Or,
perhaps, like designing and building a robot to swat flies for you.

Personally, I'd settle for Galaxy having been designed more sensibly...
oh, never mind. Yeah, maybe MAX *is* the way to go....:-\

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

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

End of MAX Digest - 26 Jun 1997 to 27 Jun 1997 - Special issue
**************************************************************

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