Subject: MAX Digest - 23 Jul 1998 to 24 Jul 1998 - Special issue
Date: Fri, 24 Jul 1998 15:46:28 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 17 messages totalling 734 lines in this issue.

Topics in this special issue:

  1. Nick Longo was re-posted (3)
  2. MDP driver for Digidesign 888/24 interface?
  3. It don't mean a thang if it ain't got Bang. (2)
  4. k nzume>p rkk nzume>p rk
  5. another lfo (2)
  6. The buck stops here.
  7. FAT Rand
  8. Message order (2)
  9. Part 2 of - The EXACT Timing/Order in which
 10. Cream Ware Pulsar & SCOPE SHARC based ASIO-driven DSP cards
 11. MAX and  Nightingale notation software
 12. sorry for the repost of "Part 2 of The EXACT..."

Email to MAX should now be sent to MAX@lists.mcgill.ca
LISTSERV commands should be sent to listserv@lists.mcgill.ca
Information is available on the WEB at http://www.mcgill.ca/cc/listserv

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

Date:    Thu, 23 Jul 1998 21:37:09 -0800
From:    Gene Schwartz 
Subject: Re: Nick Longo was re-posted

>Date:    Thu, 23 Jul 1998 03:32:19 -0400
>From:    Stephen Kay 
>Subject: Re: Nick Longo was re-posted
>
>>Gene Schwartz:
>>Well, I read it again. It seems to me that complaining about antiorp's
>>'trick' of reposting private email carries very little weight if the
>>so-called private post is far more outrageous than the act of re-posting=
>
>>it. Why is it somehow unethical to re-post an explicit threat? Or what a=
>re
>>you saying the problem is anyway?
>
>Sorry, it's one of the basic "unwritten rules" of internet etiquette
>that you don't make private communications public.
>

So it is your opinion that it is more unethical to disobey an unwritten
rule, which was not 'constructed' to include behavoir like we are
discussing, than it is to explicitly threaten someone?

>I guess what you are saying is that it's OK for someone to make
>that decision based on their own interpretation of what is a threat
>and what isn't.  =
>
>

Sure sounded like an explicit threat to me. Again, you seem to be saying
that the 'interpretation' of an explicit threat and the posting of it is
more unethical than the threat itself. Can you really be so asinine?

>Similar to the kind of thinking that nazis or gestapo or KGB or
>CIA or FBI or etc. employ: the individual has no rights if we
>deem it so:
>

Oh yeah, I forgot. I'm a nazi sympathizer who has disgusted the majority of
the world's population.

>_Ve vill make publik all privat komunikashunz if ve so dezire._
>
>I have in my posession several private communiques from antiorp
>which I do not feel paints him/her/it in the light that s/he/it
>might desire - but they were *private*, so therefore I will not
>quote them or make fun of them as part of my public arguments.
>

Why does Joe McCarthy come to mind here?

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

Date:    Fri, 24 Jul 1998 00:47:57 -0400
From:    Stephen Kay 
Subject: Re: Nick Longo was re-posted

Gene Schwartz:
>Can you really be so asinine?
>I'm a nazi sympathizer

>Why does Joe McCarthy come to mind here?

Because you're an idiot that misses the point.

Go back to thinking about Max. I have. I wish everyone would.

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

Date:    Fri, 24 Jul 1998 16:32:43 +1000
From:    Jim Franklin 
Subject: MDP driver for Digidesign 888/24 interface?

Hi People,

Has anyone (apart from me) tried to run MSP with a Digidesign 888/24
interface box? If so, which driver are you using? Trying the Direct I/O MSP
driver gives a message of "no slots", and this would seem to have been the
only likely candidate.

At present I don't particularly care about using the box in 24-bit mode,
but I would like to use it for i/o (and more than 2-channel digital i/o
would be great) - anything to get away from Mac internal hardware i/o...

Any advice appreciated.

Cheers,

JimF

*****************************************

Dr Jim Franklin
Shakuhachi Master (shihan) and Composer
Course Coordinator, Music
Lecturer in Music Technology
University of Western Sydney, Nepean
Australia
Tel. --61 - 2 47 360 161
Fax. --61 - 2 47 360 166

*****************************************

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

Date:    Fri, 24 Jul 1998 02:58:14 -0400
From:    Les Stuck 
Subject: It don't mean a thang if it ain't got Bang.

Dear Maxsters (& Rt!sts),

If I wanted rambling Internet discussions sparked by eloquent
bursts of flaming, I guess I would go to some chatroom and hang
out. However, on the Max list, aside from occassional witticisms
and pithy social comments (no more than one line of text), there
should really be only stuff about Max and what we do with it. Right?
We've gone to all this trouble to make the list Spam-proof; now
let's cut the chatter!

Now I know how much fun it is to get in the last word, but I
would humbly suggest an immediate moratorium on this personal drivel.
Basta.

Tired of scrolling,

Les

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

Date:    Fri, 24 Jul 1998 03:25:15 -0400
From:    Stephen Kay 
Subject: It don't mean a thang if it ain't got Bang.

Les Stuck:
>Now I know how much fun it is to get in the last word, but I
>would humbly suggest an immediate moratorium on this personal drivel.

I totally agree.  I have suggested dropping this thread repeatedly.
I will suggest it again. I will once again stop now, all further
arguments withheld.  But why do I think others will continue?

Please, I hope the list will note that during this time of
argument, I have posted at least three helpful answers to
*real* max questions.  Please check your digests to determine
that this is so.  antiorp =3D none.  Gene Schwartz =3D none.
Some of you others who have ranted and joined in =3D none.
In fact, I don't ever recall Gene Schwartz posting a single
helpful thing whatever to this list.  But I should think
that with some of you at least, my record stands.

Stephen Kay

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

Date:    Fri, 24 Jul 1998 05:24:00 -0600
From:    =cw4t7abs 
Subject: k nzume>p rkk nzume>p rk

>From:    Stephen Kay 
>I have in my posession several private communiques

frrr

>from antiorp
>which I do not feel paints him/her/it in the light that s/he/it
>might desire - but they were *private*,

_______
From: Stephen Kay 
Subject: -098097
Sender: Stephen Kay 
To: =cw4t7abs 

>u ma! make dem publ!k !f u l!ke.

It's really not important to me.
_______

frrr

>This is really sad.  Here I was, just about to think that
>antiorp was a [more professional looking] GOD,

bzum .. bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.bz.

bzum
....p.
anti.boom. \\ http://man104nfs.ucsd.edu/~mpuckett

>Folks,

dr!nk !n dze name ov dze _people- + dze mult!tude shall kroun u.

antiorp bel!evz !n dze ecz!stensz ov dze pe pl az
antiorp bel!evz !n dze ecz!stensz ov g d.

> and s/he/it (pronounce that quickly) had
>to dump this pile of excreta on us.

k nzume>p rkk nzume>p rk
eczkrete>publ!k mmun!.que -z

\\ Charles Baker 

http://developer.apple.com/dev/cftype/register.html

  SpeechChannel           theWriterSpeechChan = nil;

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

Date:    Fri, 24 Jul 1998 12:34:50 +0200
From:    dudas 
Subject: Re: another lfo

Here's another lfo patch that might be useful.
It also shows an example of reading and writing into tables using the expr
object.

max v2;
#N vpatcher 96 47 594 479;
#P newex 203 226 27 196617 * 2;
#P newex 203 245 83 196617 expr cosine[$i1];
#P number 203 279 35 9 0 0 0 3;
#P newex 203 205 75 196617 counter 2 0 63;
#P newex 203 184 50 196617 metro 20;
#P slider 243 274 15 128 0 1;
#P toggle 203 162 15 0;
#P button 308 176 15 0;
#P button 334 108 15 0;
#P newex 366 161 90 196617 expr store(cosine[-1]\\\,$i1-1\\\,$i1-1);
#P newex 334 131 43 196617 Uzi 128;
#P newex 308 198 43 196617 Uzi 128;
#P newex 340 228 106 196617 expr
store(cosine[-1]\\\,$i1-1\\\,int(cos($i1/127.*3.14159)*63.+ 64));
#P newex 5 13 45 196617 loadbang;
#P toggle 92 181 15 0;
#P slider 132 274 15 128 0 1;
#P newex 92 203 50 196617 metro 20;
#P newex 92 224 81 196617 counter 2 0 127;
#P number 92 279 35 9 0 0 0 3;
#P newex 92 245 83 196617 expr cosine[$i1];
#P newex 37 115 45 196617 pack 0 0;
#P newex 72 91 185 196617 expr cos($f1/127.*3.14159)*63.+ 64;
#P newex 37 59 27 196617 - 1;
#P newex 5 35 43 196617 Uzi 128;
#N vtable 128 9 48 219 215 1 128 cosine;
#P newobj 37 137 61 196617 table cosine;
#P comment 70 59 100 196617 make a cosine wave table for our lfo;
#P comment 101 139 100 196617 <-- dbl-click to see pretty waveform;
#P comment 3 236 84 196617 cool expr table access trick -->;
#P comment 322 43 116 196617 here is an even trickier way to _write_
directly into a table using the expr object:;
#P connect 15 0 5 0;
#P connect 20 0 18 0;
#P connect 21 0 17 0;
#P connect 17 2 16 0;
#P connect 18 2 19 0;
#P connect 27 0 26 0;
#P connect 27 0 23 0;
#P connect 25 0 28 0;
#P connect 24 0 25 0;
#P connect 28 0 27 0;
#P connect 5 2 6 0;
#P connect 6 0 8 0;
#P connect 6 0 7 0;
#P connect 9 0 10 0;
#P connect 9 0 13 0;
#P connect 22 0 24 0;
#P connect 7 0 8 1;
#P connect 8 0 4 0;
#P connect 11 0 9 0;
#P connect 12 0 11 0;
#P connect 14 0 12 0;
#P pop;

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

Date:    Fri, 24 Jul 1998 08:40:03 -0400
From:    Chris Murtagh Hrdc-drhc 
Subject: The buck stops here.

Dear Maxers,

 It is with a sad heart that I write this letter. After numerous complaints
about the useless dribble in the Stephen Kay(and Friends) vs. Antiorp(and
Friends), I think there can be only one solution: The next person who
breaks this listserv's etiquette shall be removed from this list without
warning.

 These are the type on infractions that shall get you removed (I would have
thought most of these would be obvious):

- Personal attacks against ANYONE (on this list or not)
- Useless rambles regarding Nazis, terrorists or any other sickos
- Slandering any member on the list
- Posting commercial material (especially non-related)  i.e. pyramid
schemes etc. (this does NOT include MAX related concert listings,
performances or gear  i.e. iCube info)

 As I am democrat, I believe that everyone here should have input into this
decision (although many have requested this). If you agree/disagree or have
serious problems with this please email me directly  (NOT to the list) at:

 chris@music.mcgill.ca

Please make the subject 'Etiquette', as I expect many emails coming into my
mailbox. Support and criticism for this would be greatly appreciated (well
more the former than the latter, but I shall not ignore anyone's opinions).

 Please, please remember that this is a list that is to HELP people
communicate any ideas or problems that they have with a fantastic piece of
software and not to create enemies because of differences in ideologies.
Lately, it has just been frustrating reading the rubbish that has been
posted along with the complaints (sent directly to me).

 To all others who were not involved in this recent tiresome debate, thank
you for your patience and with a bit of luck this shall be the LAST posting
on the subject (no more "last postings" and "I-told-you-so's" PLEASE).

Sincerely,

Christopher Murtagh
MAX listserv owner
chris@music.mcgill.ca

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

Date:    Fri, 24 Jul 1998 16:06:49 +0200
From:    dudas 
Subject: Re: FAT Rand

>1. Is there a PPC or FAT version of the Rand, RandIJ
>objects available?

there is now. it seems to work correctly

you can find it at:
ftp://ftp.ircam.fr/pub/forumnet/max/FAT/chance/
(otherwise known as the "fat chance" directory)

Remember that to get to the ircam Max object public ftp site you must type
the FULL path for the directory ftp://ftp.ircam.fr/pub/forumnet/max/,
because it is invisible from its parent directory.

By the way, a little-known fact is that the randIJ function already exists
within the expr object - random number between 64 and 128 (not inclusive)
can be made like this:

expr random(64\,128)

check out this teensy-weensy patch:

max v2;
#N vpatcher 337 155 737 455;
#P number 63 119 35 9 0 0 0 3;
#P button 63 57 15 0;
#P newex 63 93 104 196617 expr random(5\\\, 10);
#P number 187 119 35 9 0 0 0 3;
#P button 187 57 15 0;
#P number 239 68 35 9 0 0 0 3;
#P number 291 68 35 9 0 0 0 3;
#P newex 187 93 115 196617 expr random($i2\\\, $i3);
#P connect 1 0 0 2;
#P connect 2 0 0 1;
#P connect 3 0 0 0;
#P connect 5 0 7 0;
#P connect 0 0 4 0;
#P connect 6 0 5 0;
#P pop;

-Richard

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

Date:    Fri, 24 Jul 1998 12:41:30 -0400
From:    Eric Singer 
Subject: Re: Nick Longo was re-posted

CAN WE TAKE THE NAZI THREAD SOMEWHERE ELSE?  THIS IS OFFENSIVE AND ABSURD,
AND I DON'T SEE HOW THIS RELATES TO MAX.  FEEL FREE TO SEND ***PRIVATE***
EMAIL ON THE SUBJECT, BUT PLEASE STOP BOTHERING THE LIST.  ENOUGH ALREADY!

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

Date:    Fri, 24 Jul 1998 09:51:18 -0700
From:    Christopher Dobrian 
Subject: Message order

ddurlach@WORLD.STD.COM quotes a Computer Music Journal article which quotes
(originator of Max) Miller Puckette saying "...sometimes you can predict
the [order in which messages will be sent] by looking at the spatial layout
of the patch, but it should always be regarded as an error unless the order
the messages are received in doesn't matter."

I remember the article in question (various people's thoughts on the pros
and cons of Max), and I suspect that Miller was referring to non-Opcode Max
(i.e., Max as he wrote it originally and as it was further developed at
IRCAM independently of David Zicarelli's work on Opcode Max). The reliable
right-to-left/bottom-to-top message ordering was implemented by David for
the first Opcode release, version 2.0.

When objects are connected by patch cords in Opcode Max, the message order
is completely reliable, and the spatial layout of the patch is a crucial
part of the way it works. Despite this reliability, it's understandable
that some people might be disturbed by the fact that you can totally change
the behavior of your patch by moving an object one pixel onscreen. Some
people choose to "over-use" the trigger object, just to be sure.

However, there certainly are plenty of cases where the message order is
"undefined". This is usually as the result of "remote" messages, without
patch cords. For example, if two or more receive objects share the same
name, the order in which those objects will receive a message from a send
object with that name is unknown to you. Also, you generally can't predict
the order in which a preset object will send values remotely to user
interface objects. (The buddy object was created for the purpose of
synchronizing two int messages coming from just such an unpredictable
source.)

With regard to the preset object, here's an undocumented tidbit for the
(virtual) Max FAQ:

Q:
Is there a way to control the order in which UI objects receive their
values remotely from a preset object? Does the order in which objects
were created, or their placement onscreen, or anything like that,
affect the order in which they receive their values from preset?

A:
Yes. Select the object you would like to have receive the preset restore
first,
then choose Send to Back from the Max menu. Then save the preset again--by
saving the patch (if the preset is being stored in the patch) or by using
the "write" message (to save the preset as a separate file).

ddurlach@WORLD.STD.COM also sent specific examples of his concerns:
Scenario 1:
    __________
   |object A  |
   |__ ____ __|
      |    |
 ____ |    | _______ from any number of other objects
    _\|____|/_
   |object B  |
   |__________|

It seems to me that the success of this scenario depends primarily on
whether the output of the right outlet of object A is also being sent
somewhere else, to the left of the right inlet of object B, which could
eventually trigger an object to send a message into the right inlet of B
(thus erasing the message that came from object A). If that's not the case,
and assuming that objects A and B are written as one would expect (e.g., no
delay inside object A between its right output and its left output, etc.) I
can't think of a reason this wouldn't work. (But I probably just lack
imagination.)

Scenario 2:
  __________
 |object A  |
 |__ ____ __|
    |    |
    |   _|________
    |  | object C |
    |  |_ ________|
    |    |
    |    |
  __|____|__
 |object B  |
 |__________|
...with object C processing for "an undetermined amount of time"

Assuming that that "undetermined amount of time" does not mean scheduling
object C's output for some time in the future, and assuming that the output
from object A and C's outlets is not going elsewhere and triggering other
objects that might interfere, this too is reliable. As sk@COMPUSERVE.COM
noted, if the objects can handle the numbers packed together as a two-item
list, then you can just keep the numbers together as a list if you're
concerned. (And then there's always good ol' empirical testing, or tracing
with the Trace menu commands, to see how things work.)

Within an MSP network, the message order question is kind of (but not
totally) irrelevant. The signal network one makes (i.e., the connections
between MSP objects) is a description from which MSP figures out how to
build a "call chain" of functions in the right order to calculate the
signal.

But alex@PIXAR.COM writes: "I am using a count~ object as a master
synchronization source for a bunch of buffer manipulations. This includes
reading and writing to the same location in a buffer 'at the same time'.
The order in which the various index~ and poke~ objects actually execute,
makes all the difference...".

It's true that the calculations still ultimately need to be made in a
certain order, and this example is reading and writing the same sample in
the buffer~, so order is relevant. But in my mind, this begs the question
of why the buffer~ is being used at all. Why is the signal being poked into
the buffer~, being stored for "zero" time, and looked up with index~? Why
not just use the original poked signal (instead of the output of index~)?

It is possible to make "illegal" signal networks--ones that feed back into
themselves (without being delayed by a tapin~-tapout~ pair)--causing MSP to
refuse to work. The send~ and receive~ objects can permit you to work
around this in some cases.

When objects make a link between Max and MSP (such as line~, etc.) the
message order seems to be equally reliable, but you must take into account
the fact that signal data is calculated a chunk at a time, so Max and MSP
only "talk to each other" once per signal vector.

To summarize, in my experience the message order behaves *very* reliably as
advertised. (That's with supported Max objects; I can't vouch for the
correctness of all objects, obviously.) Whenever the message order appears
to be malfunctioning, it always turns out to be a bug in the Max patch
rather than any fault of Max. Obviously, there are many ways to scr*w
yourself while programming in Max (a few of which I've described above),
but avoiding them is mostly a matter of careful
planning/debugging/testing/tracing. (Of course, the devices you're
controlling with Max all have their own problems and idiosyncrasies,
too...whee!)

--Chris

                              ----------------
             Christopher Dobrian / School of the Arts - Music
             University of California / Irvine, CA 92697-2775
                Phone: (949) 824-7288 / Fax: (949) 824-4914
                      http://www.arts.uci.edu/dobrian/

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

Date:    Fri, 24 Jul 1998 12:59:29 -0400
From:    Stephen Kay 
Subject: Re: Part 2 of - The EXACT Timing/Order in which

>Is it guaranteed that object B will always receive  with its
>associated , when you consider that the inlets of B are
>connected not only to A, but to other objects as well?  In other words,
>is the following *unacceptable* sequence of events possible:

>1. object B receives  from object A
>2. object B receives another timestamp from some other object
>3. object B receives  from object A

I cannot say for sure whether or not this could happen.  It seems to
me in discussions of reentrancy that have taken place on this list
that it might be possible.  I guess David Z. could answer this.

However, several observations:

1) If you want these 2 numbers to always stay together, why not
pack them as a list, then send them to object B? That way nothing
can separate them.  If you are writing objects A & B in C Code,
this would be very easy to accomplish; if using plain vanilla
Max objects, use pack and unpack.

2) In the case of your second example, where you want to do some
processing on the , you would unpack the list at object
C, process the 2nd number, repack the list and send to object B.
Again if writing the object yourself in C, this could easily be
done internally.

Packing and unpacking can add some (slight) processing overhead, =

but it seems like it would be a solution to your problem.

Stephen Kay

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

Date:    Fri, 24 Jul 1998 12:59:33 -0400
From:    Stephen Kay 
Subject: Re: another lfo

>Here's another lfo patch that might be useful.
>It also shows an example of reading and writing into tables using the ex=
pr
>object.

Thanks, Richard, but the 2 "tricky" examples of storing directly to
a table (right side of patch) do not work, giving error messages like:

expr: store: need a table name
* error: expr_bang: unrecognized result 1543634178

Stephen Kay

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

Date:    Fri, 24 Jul 1998 07:02:43 -1000
From:    "Djry J. Pam" 
Subject: Cream Ware Pulsar & SCOPE SHARC based ASIO-driven DSP cards

Once the Mac versions of these come out, it would be very nice if MSP could
use them. I would have to buy MSP at that point. What's the chance D.Z.?

http://www.harmony-central.com/Newp/1998/Pulsar.html

http://www.harmony-central.com/Newp/1998/New-SCOPE-Specs.html

> One of the I/O choices incorporates an additional 4 SHARC DSPs and offers
20 I/O capacity. Each base SCOPE card
> is capable of 64 I/O. A 20 I/O setup provides a peak performance of 3420
MFLOPS and can even be expanded by
> adding more SCOPE boards using the high-speed SCOPE TDM (time division
multiplex) bus. According to
> CreamWare, configurations of over 100 DSPs will be possible. The SHARC DSP
is the fastest floating-point
> processor available today

Cost per Analog Devices ADSP-21065L for 100,000 units is just $10.00 each.
We'll be seeing a lot of it in the future.

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

Date:    Fri, 24 Jul 1998 15:16:48 -0500
From:    "M. Abidh Waugh" 
Subject: MAX and  Nightingale notation software

Some of you may have heard of or may even be using the music notation
program,
Nightingale.  Many composers and instrumentalists find this program not only
very powerful, but also very easy to use.  The program also has a unique
feature that I believe would be of interest to MAX users.  This feature is
called the Notelist, a human- and machine-readable ASCII file format which
simply provides a listing of the essential musical contents of the score's
data-structure.  Notelist can best be described as a "snapshot" of the
structural features of a native Nightingale file. A Notelist is unlike a
MIDI
file, which ignores notational aspects altogether. Notelist incorporates the
data necessary for performance of a score.  A Notelist file is restricted
only to the limits of normal musical notation as represented in the
extensive
capabilities of Nightingale itself.

Notelist format is documented in detail in the book Beyond MIDI: The
Handbook
of Musical Codes, edited by Eleanor Selfridge-Field (MIT Press, 1997).

I am working with the creator of Nightingale, Don Byrd, to determine if
there
is any interest among MAX users in having MAX objects which could handle the
notelist file, and to format MAX messages to notelist format. The possible
uses of this sort of compatibility are, needless to say, only limited by
one's creative purposes.  Please respond to my personal email address or to
the max list so that we can gauge the interest in such objects.

        Thank you.

        M. Abidh Waugh
        abidh3@usa.net

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

Date:    Fri, 24 Jul 1998 15:19:19 -0400
From:    Stephen Kay 
Subject: sorry for the repost of "Part 2 of The EXACT..."

Sorry for the accidental repost - for some reason I thought it
didn't go through.
Stephen Kay

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

Date:    Fri, 24 Jul 1998 15:45:23 -0400
From:    Stephen Kay 
Subject: Message order

>When objects are connected by patch cords in Opcode Max, the message ord=
er
>is completely reliable, and the spatial layout of the patch is a crucial=

>part of the way it works. Despite this reliability, it's understandable
>that some people might be disturbed by the fact that you can totally
change
>the behavior of your patch by moving an object one pixel onscreen. Some
>people choose to "over-use" the trigger object, just to be sure.

I don't mean to question this "reliability", but I have actually seen =

cases where a patch worked correctly after creating it;
then you save it, and next day or a week later upon opening it no longer
works correctly because some object must be moved 1 pixel, after which it=

again works as you intended.  After several such experiences, I now =

liberally use trigger objects in places where I'm concerned about =

order of execution.  I wouldn't characterize it as "over-use"; I'd =

characterize it as "bullet-proofing" your Max code.

Stephen Kay

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

End of MAX Digest - 23 Jul 1998 to 24 Jul 1998 - Special issue
**************************************************************