Subject: MAX Digest - 5 Apr 1998 to 6 Apr 1998
Date: Tue, 7 Apr 1998 00:01:26 -0500
From: Automatic digest processor 
Reply-To: MAX - interactive music/multimedia standard environments
     
To: Recipients of MAX digests 

There are 6 messages totalling 243 lines in this issue.

Topics of the day:

  1. MaxPlay Save erases patcher objects? (2)
  2. Digital Soundscapes Workshops
  3. coll save tutorial (was Maxplay erases...)
  4. julia object (2)

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

Date:    Mon, 6 Apr 1998 04:37:01 -0400
From:    Nikki Halpern <101762.3705@COMPUSERVE.COM>
Subject: Re: MaxPlay Save erases patcher objects?

Hi,

Thanks David Zicarelli, Stephen Kay, Nick Rothwell.  =

>You're not missing anything. It's a bug. The solution would be
>to use the menubar object to eliminate the Save item from the
>File menu.

I guess I'll keep using Max for anything I want to be able to save, and
eliminate Save on anything to be used in MaxPlay.  (Another solution woul=
d
be to eliminate all the patcher objects, changing them to separate files;=

in my case, however, the information that I want to save is _in_ these
patcher objects, and so it would not be saved when the main patch is
saved.)

>Why does Save even exist in Maxplay? Because people wanted to
>save presets.

And colls and tables and....  Preset was just the simplest example for my=

question.  Like Stephen, and thanks to his suggestion on this list, I als=
o
use coll instead of preset.  But the problem remains the same.  And if yo=
u
have 6 or 8 different colls in your patch, each with its own pop-up menu,=

which can be used to rename the "presets," then the write-to-file option
becomes rather, well, user-mean.

And of course, there's no reason to presume the user won't save the patch=

anyway, just automatically, for no reason at all.  And then, whoops, no
more subpatchers.

>I'll change this in the future
>so that the test consists of looking for the word "patcher"
>or "p" in the box, rather than testing to see whether it's
>locked. Since, I may also want to make it possible to edit
>abstractions eventually.

Fantastic.  Thanks again,

Ben Thigpen (a.k.a. ...)

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

Date:    Mon, 6 Apr 1998 10:05:13 -0000
From:    Nick Rothwell 
Subject: Re: MaxPlay Save erases patcher objects?

> And if yo= u have 6 or 8 different colls in your patch, each with
> its own pop-up menu,= which can be used to rename the "presets,"
> then the write-to-file option becomes rather, well, user-mean.

My registry object allows you to use a single file for every project,
with different sub-patches and UI objects attached to different
"working directories" within the registry. Hence, any READ or WRITE
operations will read or write the entire registry file; and the file
is saved on QUIT by default.

Alternatively, I'm pretty sure that Stephen's procedure for using
colls was in fact to just use a single coll file, and index the
entries in some way by numbering the sub-patcher occurrences, so the
end result is similar.

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

        NOTICE - this vessel has triple screws - keep clear of blades

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

Date:    Mon, 6 Apr 1998 09:06:58 -0600
From:    Jon Christopher Nelson 
Subject: Digital Soundscapes Workshops

Looking for a chance to spend some time in the Rockies while
learning Csound, MAX, KYMA, or algorithmic composition?  If so, we
still have a few slots available in our Digital Soundscapes Summer
Workshops.  For more information, please check out our web site at
http://www.music.unt.edu/CEMI/cb

with warmest regards,
Jon C. Nelson

Jon Christopher Nelson, Director
CEMI (Center for Experimental Music and Intermedia)
University of North Texas College of Music
P.O. Box 13887
Denton, TX 76203
USA

ph. (940) 369-7531
fax (940) 565-2002
jnelson@sndart.cemi.unt.edu
http://www.music.unt.edu/comp/jnelson.htm

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

Date:    Mon, 6 Apr 1998 13:23:49 -0400
From:    Stephen Kay 
Subject: coll save tutorial (was Maxplay erases...)

Nick Rothwell:
>Alternatively, I'm pretty sure that Stephen's procedure for using
>colls was in fact to just use a single coll file, and index the
>entries in some way by numbering the sub-patcher occurrences, so the
>end result is similar.

Correct.  Here's my old explanation, reprinted for anyone who cares.
(Note: David Cronkite, I modified this slightly to go into more
detail.)
-----------------------------------------------------------------
Put a coll in each bpatcher. Use funnel to "substitute" each =

parameter into it's place in one line of the coll.  For example, =

if you have 10 parameters in your bpatcher, you create the coll =

with one line such as "0, n 1 2 3 4 5 6 7 8 9 10;".  Then each =

parameter is connected to the proper inlet of a 10 inlet =

"funnel 10 2", then connected to the coll running through a =

"prepend sub 0". "n" here would be a special "address" number, =

different for each bpatcher.  For example, if you had 4 bpatchers, =

use 1 through 4 for each of them. Use a grab between the prepend =

and the coll to prevent the coll outputting anything when you sub.  =

Then, to save a complete "program", you send a "0" to all the =

bpatchers, which then send out their values as lists to a main =

coll where they are stored in groups of 4 lines - for example, =

at 4 lines per program, the address of a program is 4 * program_num, =

so program #50 would need to prepend the 4 lines with 'store 200', =

201, 202, and 203 etc.  Using the previous 4 bpatcher example, your
main coll would end up looking like this:

0, 1 n n n n n....;     //1st program
1, 2 n n n n n....; =

2, 3 n n n n n....; =

3, 4 n n n n n....; =

4, 1 n n n n n....;     //2nd program
5, 2 n n n n n....; =

6, 3 n n n n n....; =

7, 4 n n n n n....; =

8, 1 n n n n n....;     //3rd program, etc.

Every four lines is a new program.  This is a bit simplified =

explanation from my actual program, but you get the idea. A =

global line can also be inserted for each program containing a name,
or other global information, in which case the above example would
have 5 lines per program.

To recall a program, you send a number to the main coll, which =

spits out the proper four lines - for example, at 4 lines per =

program, the address of a program is 4 * program_num, so program
#50 would need to send out lines 200, 201, 202, and 203.  These
4 lines then go into a route, which uses the 1st number of the list =

as the return address of the proper bpatcher and routes it to it,
i.e. 'route 1 2 3 4', with the output of each outlet of the route
connected to a send to the proper bpatcher.

Then you use an unpack in each bpatcher to send the parms back =

to the proper UI objects.  Since they then resubstitute themselves =

into their own colls but cause no output, there are no stack =

overflow loops.

Advantages of this approach:
All values are in one main coll, which can be saved and =

loaded as a single file.  If you use my 'collX' object, this
file can have a custome file and creator type. Furthermore, =

if you change your bpatchers, you can edit the text file of =

your programs to refit the new configurations and not loose =

your presets.  bpatchers can grow and add parms as your =

program evolves.

Stephen Kay

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

Date:    Mon, 6 Apr 1998 23:16:30 +0000
From:    Dragan Petrovic 
Subject: julia object

Hi
I just uploaded at ftp.ircam.fr/pub/incoming/max new max external object
"julia".
Dragan Petrovic
petrovic@wanadoo.fr

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

Date:    Mon, 6 Apr 1998 21:11:26 -0400
From:    Stephen Kay 
Subject: julia object

>I just uploaded at ftp.ircam.fr/pub/incoming/max new max external object=

>"julia".
>Dragan Petrovic

What does it do?

Stephen Kay

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

End of MAX Digest - 5 Apr 1998 to 6 Apr 1998
********************************************