Subject: MAX Digest - 12 Feb 1999 to 13 Feb 1999 (#1999-52)
Date: Sun, 14 Feb 1999 00:00:05 -0500
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 12 messages totalling 400 lines in this issue.

Topics of the day:

  1. gates and ints and bangs (oh my) (2)
  2. network communication
  3. YES
  4. Optimized Gates w/2nd arg available!
  5. Things that would be nice
  6. Master Preset Object (2)
  7. the missing dac~ that's right there
  8. help! major collective problem
  9. collective problem additional....
 10. max/msp objects on Ircam ftp

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

Date:    Sat, 13 Feb 1999 01:27:15 -0800
From:    jhno 
Subject: gates and ints and bangs (oh my)

>The only drag would be having to type an extra '1' for the standard gate to
>make it open by default: 'gate 1 1'. But that's the price you pay for
>compatibility.

what if this was a checkbox in the dialog box you get with a command-i (get
info) on gate? this would create no backward-compatability problems - gate
would look exactly the same.

you could also just make an encapsulation, gateo, that has the loadbang in
it. i wonder if this would affect efficiency. with the source, you could
modify the gate object and recompile it as gateo.

even more than gate loadbangs, i am plagued with operand bangs. seems like
half the "+" objects i use have little bangs right to their left, with an
extra patch cord from the right inlet's source, so that both inlets cause
output. maybe i should just build "+2", "*2", etc. abstractions. anybody
got better ideas?

ah, minutia.
jhno

ps - how about a right inlet for sliders and other interface objects, that
sets their value without outputting it? consistent with max standards, and
clears out a whole swath of "prepend set" objects...

() ))  (  ((( ))   ) ))))) ( )((()) (  ( ))   (  )    ) (   ((( )  (()( (()
delicate ear                                                 ear@sirius.com
san francisco, ca                                http://www.sirius.com/~ear

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

Date:    Sat, 13 Feb 1999 08:39:48 -0500
From:    Curtis Bahn 
Subject: network communication

besides the work being done at CNMAT with open sound control,
(http://cnmat.CNMAT.Berkeley.EDU/OpenSoundControl/)
what other network communication objects are available for max?

thanks,
Curtis Bahn

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

Date:    Sat, 13 Feb 1999 10:11:44 -0800
From:    Peter Nyboer 
Subject: YES

>but what
>about a system similar to graphics programs where the parts of the display
>could be in a specific layer.  That way one might be able to easily isolate
>and modify a particular function.

YES!  YES!  YES!  YES!
Also, YES!

Peter.

Peter Nyboer
pnyboer@sirius.com
http://www.sirius.com/~pnyboer
"Now, I not some guru or Dog or anything"

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

Date:    Sat, 13 Feb 1999 13:29:38 -0500
From:    Stephen Kay 
Subject: gates and ints and bangs (oh my)

>>The only drag would be having to type an extra '1' for the standard gat=
e
to
>>make it open by default: 'gate 1 1'. But that's the price you pay for
>>compatibility.

>what if this was a checkbox in the dialog box you get with a command-i
(get
>info) on gate? this would create no backward-compatability problems - ga=
te
>would look exactly the same.

A whole dialog box to set one piece of information that can easily be
handled =

by an argument is not very good interface design :-) (witness coll, for
example.  How many people have had work trashed by forgetting to turn tha=
t
little checkbox on at the beginning of patch construction?)

>ps - how about a right inlet for sliders and other interface objects, th=
at
>sets their value without outputting it? consistent with max standards, a=
nd
>clears out a whole swath of "prepend set" objects...

Things like this become a trade-off.  You talk about adding complexity
and code to every single UI object because it so happens that you have
a need to set their values with a "prepend set", while others may use
these same objects and never have a need to do this type of thing, in
which case their patchers become larger than necessary.

In my experience, it seems the philosophy behind a lot of Max objects
is that many Max objects have been created to work for the lowest
common denominator; the user adds more objects around it to make them
do more specialized tasks.

That is not to say that custom objects that do all sorts of complicated
things at the same time do not have a place - I've written many of these
and will do so again, undoubtedly.  But adding to and overly complicating=

basic Max building blocks is not necessarily the right thing to do.

In fact, it's usually by being forced to solve your own Max programming
problems that these "desired modifications" come to light, which are
often different for each user.  Having these modifications hard-wired
in from the start tends to push one in a certain direction of problem
solving which may not be the best one.

However, I'm certainly not opposed to changes which *do* seem to make
sense and seem to be for the "greater good" and general use of all maxers=
.
I like the idea of an argument to gate to choose the default open
outlet.  Therefore, please see my next message/announcement...

Stephen Kay

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

Date:    Sat, 13 Feb 1999 13:29:47 -0500
From:    Stephen Kay 
Subject: Optimized Gates w/2nd arg available!

Hello Maxers,

Due to popular public demand, the "optimized gates" collection
has been updated to support an optional 2nd argument to specify
the default open outlet.  Now available at:

http://www.musikinetix.com/Download/Download.html

Yes, 'bgate', 'igate', 'fgate', 'lgate' and 'sgate' now allow
you to specify an optional 2nd arg which determines the default =

open outlet.  Fully backwards compatible, too.

Also: .help files now included! (I don't know why, but the
.help files were never put in with the objects before - this
may help some of you with additional features you never knew
existed, or with the use of andGate and orGate, which are
two of my favorite objects, but which may be incomprehensible
without the help files).

For those of you who haven't heard of these objects before,
they allow you to use specifically optimized gates for each
message type - i.e. 'igate' for ints, 'fgate' for floats, etc.
Speeds up operation when using a lot of gates, since regular
gates must do a message lookup to determine what message is
being passed.  Also includes andGate and orGate by David
Roach, two highly useful if more specialized objects.

Happy Maxing,
Stephen Kay

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

Date:    Sat, 13 Feb 1999 13:32:24 -0500
From:    Stephen Kay 
Subject: Re: Things that would be nice

>>As Max 4 is now cooking, would it be possible to add an argument to
>>'gate' (and i/f/l/sgate two...) indicating its loading output?

>John Brit:
>I made this exact point (along with several others) headed "things that
annoy"
>about three months ago. Nobody even acknowledged my input so I hope
someone
>takes more notice of your request.

Maybe it was the negativity of 'things that annoy' rather than
the new-age goodness of 'things that would be nice' ;-)

In any event, I've added the second argument to the optimized gates
collection at: http://www.musikinetix.com/Download/Download/html

Stephen Kay

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

Date:    Sat, 13 Feb 1999 19:38:29 +0000
From:    david stevens 
Subject: Re: Master Preset Object

Todd Wrote:

> You can find this example in my book, "Composing Interactive Music,"  on
> page 275 - 276, in chapter 9, "Score Objects."

thanks - i hadn't read that far yet, but i've skipped ahead now!

david

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

Date:    Sat, 13 Feb 1999 12:05:24 -0800
From:    David Zicarelli 
Subject: the missing dac~ that's right there

If you downloaded the MSP 6 updater and ran the installer very
shortly after I announced it, you may have ended up with a
dac~ object in your Max folder. Due to a bug in Max 3.5,
putting an object in the Max folder may cause it to report
an error "fragment file not found"

The solution is to move the dac~ object out of the Max folder
and into your audio folder in your externals folder. I
quickly fixed the updater to put the dac~ object in the
right folder.

The bug will be fixed in the forthcoming version of Max.
On Friday, the guy at Opcode who can put new stuff on the
web site responded to my e-mail I sent him on January
27 containing the new version, so any week now the update
may actually appear. It is true that a few bugs have been
found since then.

David Z.

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

Date:    Sat, 13 Feb 1999 20:57:38 +0000
From:    david stevens 
Subject: help! major collective problem

hi all,

i'm attempting to turn my max/msp patch into a collective. Of the several
attempts i've made, only one has been successful (tho' i then discovered a
missing table, so i need to redo it).

all the other times (and again now) waht happens is this:

the dialogue box opens. it has a title bar, but no scroll bars or close box
etc.
there is no text in the actual box, which is blank except for a flashing
cursor
to the left of centre 2 lines down, and a "text" box to the right of that,
which
extends to the right of the dialogue box and which also contains a flashing
cursor.

the only way out of this is to do a forced restart.

what on earth does this mean?

thanks

david

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

Date:    Sat, 13 Feb 1999 21:07:41 +0000
From:    david stevens 
Subject: collective problem additional....

further to my last message about problems with the make collective dialogue
box..

as an alternative, i just tried opening a tiny patcher, and then adding my
main
patch as a second toplevel patcher.

half way though i got this message:

check failed:typedmess:window:corrupt object

i understand the last bit! but can anyone tell me what the rest means, and
if it
points me towards exactly where the corrupt object is (and what it is!)?

note that i have managed to make a collective _once_ out of this patcher,
despite the alleged corrput object!

david

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

Date:    Sat, 13 Feb 1999 17:48:43 -0500
From:    Stephen Kay 
Subject: Master Preset Object

Todd Winkler said:
>It's true, what Stephen Kay says, that all of this could be handled more=

>efficiently using a coll object, and his MultiModColl on his web page is=

>well worth studying. However, there often isn't a "correct" way of doing=

>things in Max, just different styles. The style I describe above is quic=
k
>and easy.

The danger of using the preset object is precisely that - it's
"quick and easy".  It tempts one to become attached to it, and to
devise ways that a complex and growing patcher can use it, and
the more you grow and the more complex you get, it will eventually
turn around and bite you viciously.

Everything I say about the preset object is based on years of
experience, and mainly on the experience of trying to use the
preset initially as the main means of storing settings for an
application that was under development for several years.  I have
gone through every scenario that it is probably possible to attempt-
from having all the UI objects in a single patcher, to attempting to
make presets store UI settings in multiple bpatchers, to systems
like what Todd Winkler describes.  The end result of all of these
is failure of the preset object(s) as you change/modify the patchers,
and loss of all presets that you may have developed over a period
of time.  This forced me to move to storing data in coll objects,
which works much more reliably, and which you can even edit as
text should you decide to make major revisions to your patcher.

Also, let's examine the scenario Todd suggests - multiple presets
inside multiple patchers, all being controlled by a main preset.
What happens if you want to make an installed application from
such a system?  Once you've done that, you can no longer save
presets within patchers and subpatchers.  You have to provide
a way for the user to save and load the data from disk.  This becomes
impossible with a preset object - even though it can save to disk,
do you really want to save an individual preset file for every
preset in the application?  Let's say you've got a total of 10
preset objects controlled by 1 master preset object - that's 11
files needing to be written to disk, not to mention the problems
associated with making sure the correct preset file gets loaded
into the correct preset.  This is where a single coll file works
wonderfully.

"Quick and easy" is good - that's why I use the preset object often
during construction of a patch or experiment.  Let's say I want to
go to bed, but I've got something functioning that's kind of cool and
I'd like to pick it up the next day.  Plop down a preset or two,
store the settings, and there you have it.  But if you attempt to
build a bulletproof patcher around it, you'll eventually regret it.

Storing data in a coll file requires a bit of work and a learning
curve; hence, people gravitate towards the preset object, and then
rip their hair out later on as they expand beyond its usefulness. I
haven't written a book about Max (yet), but if I did, I'd write a
whole chapter on why not to use a preset object...:-)

Stephen Kay

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

Date:    Sun, 14 Feb 1999 04:44:38 +0100
From:    Manuel Poletti 
Subject: max/msp objects on Ircam ftp

The following Max/MSP objects have been added to the Ircam Max public ftp:







_M

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

End of MAX Digest - 12 Feb 1999 to 13 Feb 1999 (#1999-52)
*********************************************************