Subject: MAX Digest - 17 Feb 1999 to 18 Feb 1999 - Special issue (#1999-57)
Date: Thu, 18 Feb 1999 13:06:14 -0500
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 21 messages totalling 787 lines in this issue.

Topics in this special issue:

  1. dimming/hiliting patch cords (6)
  2. interfaces (6)
  3. interface
  4. 
  5. cmc
  6. layers/dimming/hiliting patch cords -> query select?
  7. Louis and Ella together again
  8. snd problem
  9. Varying text size in LCD object using write object (2)
 10. patch cords

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

Date:    Thu, 18 Feb 1999 00:53:06 -0500
From:    Nicholas Longo <71477.2332@COMPUSERVE.COM>
Subject: Re: dimming/hiliting patch cords

<What
<<>would be nice would be to "dim" all cords except the ones connected to
<<>selected objects.

Stephen Kay: =

<
Subject: interfaces

Patch cords and interfaces...yet another comment:

When creating interfaces, I have (d)evolved into the habit of a liberal use
of recieve and send objects.  I'll often attach a send object to a
lever/knob/button, and take care of the logic elsewhere.  This tends to
make things neater, as well as easily make available the
lever/knob/button/etc. elsewhere in the patch.  However, if I am creating a
module of some sort that I wish to duplicate, then this method is
impractical.  If I open the patch twice, then the modules are interlinked.
Which leads me to the suggestion of a "local" send and recieve that would
only send and recieve within a given patcher window.

Peter.

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

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

Date:    Thu, 18 Feb 1999 01:28:22 -0500
From:    Johnny DeKam 
Subject: interface

Interface enhancements for the sake of productivity enhancement and
organization is imperitive.  There many parts of the max interface that
impair the ease of use.  Here are a couple of suggestions that to me, seem
to be a logical evolution, things that I've come to expect from the tools I
use everyday.

1) Max Patches are big, complex, and require a tremendous amount of screen
real-estate.  (and if not screen real-estate, a lot of nesting)
Enhancement: A hand tool.  Like photoshop, spacebar triggers a hand that
allows the user to interactively PAN a patcher.  Especially usefull on small
laptops, like my trusty MAX workhorse: PB170

2) patch cords and objects can become dense bundles and clusters that become
hard to edit in complex patches.  (especially in interfaces for performance)
Evolution: Magnifier tool - add Zoom in and Zoom out -- instantly Zoom in to
on densely packed patches to expand the space between patch cords and
objects.  (how many times have you struggled to select the proper object,
because several are stacked up on one another?)

3) color code patch cords - patch cords have the same color as their source
object, making it much easier and intuitive to follow the connections.  Hide
all patch cords would be a nice feature to.

5) Contextual Menus!  they are built into the OS now, why not be able to
access functions like 'get info' , 'help' , 'color' , 'edit/lock patch' ,
'new objects' etc.

6) A grid, and snap to grid feature.  A user definable grid would perhaps
aid in preventing, dense patches.  How much time do you spend "aligning"
your objects so that the pathways are clear?  I know I do... (unless you a
so-called "rat-nest' style maxer)

I could go on for awhile - but these are the most basic features that I take
for granted in EVERY program that deals with a graphical layout environment.

While Max might not be a "graphics App" it certainly is based on a graphical
layout paradigm - there is no denying it

--Johnny DeKam

UnMax - News FAQs Downloads Links Articles - http://node.net/MAX/

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

Date:    Thu, 18 Feb 1999 02:06:52 -0500
From:    Alex Burton 
Subject: 

 hello all...

 MSP's signal routing is done through floats
(32 bits), which is nice. However, how are these
32 bits converted to 16, 20 or 24 for outputting?
(this is assuming/hoping that the dac~ adapts to
the resolution of the driver/interface). Are the
signals dithered or simply truncated?

 thanks,

 Alex.

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

Date:    Wed, 17 Feb 1999 23:16:40 -0800
From:    David Zicarelli 
Subject: Re: dimming/hiliting patch cords

I like the dimming of patch cords idea. I might want to implement
it where if you move the mouse over an object, its connections
are highlighted in some way, or even if you move over a patch
cord, it might show you the objects to which the cord is
connected. Requiring that you select the object might cause
you to move it inadvertantly.

However, I also think some simple layer feature is a necessity.

David Z.

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

Date:    Thu, 18 Feb 1999 03:04:56 +0000
From:    Mathius Shadow Sky 
Subject: cmc

Subject:
         cmc
   Date:
         Wed, 17 Feb 1999 23:51:40 PST
  From:
         "mathius shadow-sky" 
     To:
         mathius@usit.net

Date:    Wed, 17 Feb 1999 00:42:39 EST
From:    RBMengMail@AOL.COM
Subject: computer music controversy, request #1

In a message dated 2/17/99 5:01:30 AM, LISTSERV@LISTS.MCGILL.CA writes:

<< Keep in your mind when you answer to the controversy you talk to
everybody.
 >>

>Also keep in mind, when we choose not to answer, it is because we are
>disinterested and would prefer not to be the target of personal,
professional,
>or political attacks and lengthy diatribes on non-MAX matters.  There
are
>other forums for these topics.

>Many people here will bend over backwards to offer opinions and
assistance on
>MAX related matters at great expense of their time and energy.  Do not
be
>offended by the lack of response -- people value their time -- you
should too.

I am sorry RBMengMail@AOL.COM but everybody should be concern about how
they create music, in which context and for what, if not which kind of
"artists" they are ?

Do not worry about my time to create music, I am kind of busy !

Mathius Shadow-Sky

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

Date:    Thu, 18 Feb 1999 00:54:00 -0800
From:    Simon Gatrall 
Subject: Re: layers/dimming/hiliting patch cords -> query select?

While some of the ideas that people have been suggesting are interesting,
no one has suggested another possible choice: "query select."  This is a
method that I have seen in some CAD programs where you click somewhere and
then you either a) get to step through all the possible choices until you
get to the one you want, or b) a menu pops up with all of the choices and
you pick from them.  Method a) is used in Pro/Engineer, a 3D mechanical CAD
program and b) is in a circuit board layout package that I have used.  An
inportant part of the feedback in either method is that the item in
question is highlighted on screen and the name of the object is displayed
in a message window.

I would ultimately like to have layers in Max, but I think that it would
probably be easier to hack "query select" into the existing structure.  I
see three possible ways of invoking this feature as a pop-up menu:
  1. If you click in a location where there are objects on top of one
another the query select menu pops up automatically.
  2. You have to control-click to get the query select pop-up menu.
  3. You hold the mouse button down for a couple seconds and then the query
select menu pops up if applicable.  (Like the pop-up menus in Nescape
Navigator)

Exactly what this pop-up menu looks like, I'm not sure.  I also don't know
how you would keep the menu from obscuring the objects that you are trying
to select.

Another way would be a slight modification of method 3 above.  Instead of a
pop-up menu, you could use the arrow keys to cycle through the possible
selections.  When you get to the right one, you let up the mouse and the
object would be selected.

-s!mon

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

Date:    Thu, 18 Feb 1999 02:00:25 -0800
From:    dudas 
Subject: Louis and Ella together again

Peter Castine writes:
>Still, I try to match the vowel in coll to the beginning of collection.

That's exactly why I say "call", and Zoron says "cole", and presumably why
one could also say "cull". Sadly, the anglo- languages/dialects/accents do
not optimally offer consistant pronunciation from region to region, or
country to country. For instance, you might get into some trouble when
referring to multiple instances of the rudimentary midi sequence object...
is it seek or seck?

-R

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

Date:    Thu, 18 Feb 1999 09:59:54 +0000
From:    david stevens 
Subject: Re: dimming/hiliting patch cords

Nick wrote:

>  What
> would be nice would be to "dim" all cords except the ones connected to
> selected objects.

This would be great. As my patcher has gotten  more complex, i'm finding
that
trying to select any object (for editing or moving) becomes very hit or
miss.
Often as not, i end up selecting and moving one of my carefully and neatly
laid
connections instead, and pretty soon i have thick black "trunk lines"
everywhere. (I'm still in Stephen Kay's "briefly segmenting every single
patch
cord" phase :-)   ).

I'd like to be able to "lock" all patch cords, which would then dim, as Nick
suggests. Selecting an object(s) would unlock and darken the patch cords
connected to it (them).
Coloured cords might look nice, but i suspect that in a very busy patch they
would actually confuse things. Perhaps once the cords are locked, any that
are
unlocked by selecting an object could turn red (or any other colour) which
would
make tracing them even easier.

david

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

Date:    Thu, 18 Feb 1999 11:14:07 +0100
From:    Matthew Ostrowski 
Subject: Re: interfaces

>Patch cords and interfaces...yet another comment:
>
>When creating interfaces, I have (d)evolved into the habit of a liberal use
>of recieve and send objects.  I'll often attach a send object to a
>lever/knob/button, and take care of the logic elsewhere.  This tends to
>make things neater, as well as easily make available the
>lever/knob/button/etc. elsewhere in the patch.  However, if I am creating a
>module of some sort that I wish to duplicate, then this method is
>impractical.  If I open the patch twice, then the modules are interlinked.
>Which leads me to the suggestion of a "local" send and recieve that would
>only send and recieve within a given patcher window.
>

I have this situation a lot as well -- what you can do is add an argument
to the name of the send & receive messages (thus you have something like
'send foo_#1' as yr object name), and then type different arguments in when
using multiple copies of the same abstraction.  It also allows you to send
messages from outside to a specific instance of an abstraction.

Of course, then, the bloatware crowd will want a feature that highlights
the like-named 'send' and 'receive' objects...  Having just been required
by a work situation to install MS Word, I'm very down on all 'features'
these days, though.  If anyone cares I think Nick Longo's solution is the
most simple & elegant -- using CAD programs from time to time, I hate
switching layers all the time.   But while this kind of stuff is on the
table, what about a Find command that will look into subpatchers?

\M

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

Date:    Thu, 18 Feb 1999 13:37:01 +0100
From:    Peter Castine 
Subject: Re: interfaces

On around 18-2-99 7:21, Peter Nyboer said something like:

>If I open the patch twice, then the modules are interlinked.
>Which leads me to the suggestion of a "local" send and recieve that would
>only send and recieve within a given patcher window.

Sorry for a "me too!" message.

My #1 wish for Max is local send/receive, local colls, local vars, local
named anything.

I know this sounds like harking back the Desain/Honing critique, but the
fact that _everything_ in Max is global prevents really clean
encapsulation. Yes, I know that you can sort-of localize named objects in
sub-patchers with the #1-string trick, but this is a pretty grotty hack.

I dunno... would this be doable with custom externals (say,
lSend/lReceive?) Or would some reworking to the Max core code be
necessary? I'm afraid the latter, but not absolutely sure without combing
through the externals documentation.

Cheers,

Peter

PS: Yes, sometimes the global behavior of send/receive is groovy, too. I
really want to be able to choose between global and local behavior. A
checkbox in a Get Info dialog box would be more than enough UI for the
developer. Or custom messages (set global/set local perhaps).

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

Date:    Thu, 18 Feb 1999 15:24:51 +0200
From:    oron schwartz 
Subject: snd problem

This is a multi-part message in MIME format.
--------------DD2A9B16205E5960F1BAB410
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi.
I prepared  a sound file using sound forge on a p.c. then saved it as an
snd and also as  an aiff  mac. files.
Max failed to read both versions  . does anyone know of a solution?
Oron Schwartz  www.angelfire.com/or/oronsc

--------------DD2A9B16205E5960F1BAB410
Content-Type: text/x-vcard; charset=us-ascii;
 name="s_oron.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for oron schwartz
Content-Disposition: attachment;
 filename="s_oron.vcf"

begin:vcard
n:;oron
x-mozilla-html:FALSE
url:www.angelfire.com/or/oronsc
adr:;;;;;;
version:2.1
email;internet:s_oron@netvision.net.il
x-mozilla-cpt:;-30736
fn:oron
end:vcard

--------------DD2A9B16205E5960F1BAB410--

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

Date:    Thu, 18 Feb 1999 06:33:52 -0800
From:    Philip Aker 
Subject: Re: dimming/hiliting patch cords

DZ:
} I like the dimming of patch cords idea. I might want to
} implement it where if you move the mouse over an object, its
} connections are highlighted in some way, or even if you move
} over a patch cord, it might show you the objects to which the
} cord is connected. Requiring that you select the object might
} cause you to move it inadvertantly.

} However, I also think some simple layer feature is a necessity.

I've always enjoyed layers as implemented in Freehand (as of
version 3.0 and up). This is simple and clear interface design.

A floating palette lists the named layers and a popup off the
top right provides layer options (New, Remove, etc.). Layers
are ordered by dragging the name in the list above or below
others, and there is a Show/Hide slot to the right of the name
which toggles visibility (indicated by a checkmark in the slot
if shown).

Another nice feature is the the ability to
"Click-Through-Select" overlapping objects by the use of a
modifer. Objects in the area are cycled through when
modifier(s)-click is used. I wouldn't mind if Max was limited
to cycling 74 objects.

Philip
philip@vcn.bc.ca

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

Date:    Thu, 18 Feb 1999 10:02:51 +0000
From:    Steve Smith 
Subject: Varying text size in LCD object using write object

I'm using with write message box connected to the LCD object.

Q:  How do I vary the size of the text being printed in the LCD?
Q:  Can I get the Macintosh's special characters to print in the LCD?

With thanks... Steve Smith
_____________________________

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

Date:    Thu, 18 Feb 1999 11:16:45 -0500
From:    Stephen Kay 
Subject: Re: dimming/hiliting patch cords

DZ:
>I like the dimming of patch cords idea. I might want to implement
>it where if you move the mouse over an object, its connections
>are highlighted in some way, or even if you move over a patch
>cord, it might show you the objects to which the cord is
>connected. Requiring that you select the object might cause
>you to move it inadvertantly.

A problem might arise if you have more than one patch cord
layered.  When positioning the mouse over them, which patch
cord and objects would be hilited?

At least if you click on the object, the connected patch
cords would remain hilited in some fashion, so that it would
be easier to select them.  Furthermore, if the patch cords
extend a long distance in a patcher window, you could click
an object, have the connected patch cords hilited, and
then scroll the window to a different section and still have
the patch cords remain hilited.

Stephen Kay

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

Date:    Thu, 18 Feb 1999 11:16:51 -0500
From:    Stephen Kay 
Subject: Re: interfaces

Matthew Ostrowski:
>I have this situation a lot as well -- what you can do is add an argumen=
t
>to the name of the send & receive messages (thus you have something like=

>'send foo_#1' as yr object name), and then type different arguments in
when
>using multiple copies of the same abstraction.  It also allows you to se=
nd
>messages from outside to a specific instance of an abstraction.

You must put the "#1" at the beginning of the send name.

'send foo_#1'  <- does not work
'send #1_foo'  <- correct

Stephen Kay
--------------------------------------------------------------------
The MegaMAX Collection: =

   http://www.musikinetix.com/MegaMax/MegaMax.html
Free Max objects!:
   http://www.musikinetix.com/MaxCorner/PublicDomain.html
--------------------------------------------------------------------

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

Date:    Thu, 18 Feb 1999 11:16:49 -0500
From:    Stephen Kay 
Subject: Re: interfaces

Peter Castine:
>Yes, I know that you can sort-of localize named objects in
>sub-patchers with the #1-string trick, but this is a pretty grotty hack.=

Why is this such a "grotty hack"?  Using an argument, what you end
up with is a completely controllable, local send/receive. It can
be local to one patcher, or you can share it between any number
of patchers by using the same argument.

>I dunno... would this be doable with custom externals (say,
>lSend/lReceive?) Or would some reworking to the Max core code be
>necessary? =

Based on my knowledge, I'd say it would be pretty easy to create
a 'real' local send/receive.  Right now, the object must search =

through all patchers to find objects to send messages to.  It
would be simple to make it only search the patcher that it is
inside.

But I still don't see why it would be much/any better than using an
argument.

Stephen Kay

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

Date:    Thu, 18 Feb 1999 08:48:40 -0800
From:    Alex Stahl 
Subject: Re: dimming/hiliting patch cords

>DZ:
>>I like the dimming of patch cords idea. I might want to implement
>>it where if you move the mouse over an object, its connections
>>are highlighted in some way, or even if you move over a patch
>>cord, it might show you the objects to which the cord is
>>connected. Requiring that you select the object might cause
>>you to move it inadvertantly.

I can usually figure out where patch cords go, it's selecting one of them
out of a jumble that I find challenging.

I suggest the inadvertant moving of objects is a separate problem (although
I often resort to nudging an object to identify its patch cords). It might
be solved by adding a Lock Position function, that locks the selected
objects position. Sort of like Hide on Lock, although it would be different
meaning for Lock, and then there would be the issue of how to pronounce it.

Another random brainstorming idea is that holding some modifier key while
clicking on an object might select one patch cord connected to the object
rather than the object itself. Repeated clicking would cyclically select
all the patch cords, one at a time. Maybe this same modifier could enable
your highlight-on-rollover idea too.

Whatever may come to pass, please make it optional. Slow machines can get
seriously bogged down highlighting patch cords.

-Alex Stahl

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

Date:    Thu, 18 Feb 1999 09:02:12 -0800
From:    Alex Stahl 
Subject: Re: interfaces

Don't forget you can also use #0 and it will become a local four-digit
number in each instance of the encapsulation.

I believe the hackish grottiness is related to the variable width objects
you get.  #1-var can become #1-longVariableName inside your subpatch, and
the object expands to show this-- often overlapping other objects and patch
cords.

-Alex

>Matthew Ostrowski:
>>I have this situation a lot as well -- what you can do is add an argument
>>to the name of the send & receive messages (thus you have something like
>>'send foo_#1' as yr object name), and then type different arguments in
>when
>>using multiple copies of the same abstraction.  It also allows you to send
>>messages from outside to a specific instance of an abstraction.
>
>You must put the "#1" at the beginning of the send name.
>
>'send foo_#1'  <- does not work
>'send #1_foo'  <- correct
>
>Stephen Kay
>--------------------------------------------------------------------
>The MegaMAX Collection:
>   http://www.musikinetix.com/MegaMax/MegaMax.html
>Free Max objects!:
>   http://www.musikinetix.com/MaxCorner/PublicDomain.html
>--------------------------------------------------------------------

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

Date:    Thu, 18 Feb 1999 12:41:41 -0500
From:    Eric Singer 
Subject: Re: Varying text size in LCD object using write object

LCD accepts 'font x y', where x is a font number and y is the font size.

I recently discovered this new Max feature.  If you option-shift-click on
an object, you get a pop-up box listing all the messages it accepts.  (I'm
sure this was advertised before, though I had forgotten about it).

Eric

At 5:02 AM -0500 2/18/99, Steve Smith wrote:
>I'm using with write message box connected to the LCD object.
>
>Q:  How do I vary the size of the text being printed in the LCD?
>Q:  Can I get the Macintosh's special characters to print in the LCD?
>
>With thanks... Steve Smith
>_____________________________

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

Date:    Thu, 18 Feb 1999 10:10:07 -0800
From:    Peter Elsea 
Subject: patch cords

>Not to start a debate on patch cord style (well, ok, start one),
Not to continue the  debate, but working with what we've got, I've compiled
a set of suggested practices for my class to chew on. (These are available
with illustrations in the word 5.1 document "Max&Problems" found at
ftp://arts.ucsc.edu/pub/ems/maxtutors ) Since I'm due to revise that
document, I would appreciate comments and additions from the list:

Guidelines For Readable Patches
** Keep it all on one screen.
At least if you can without cramming everything together. There's nothing
wrong with a top screen full of subpatchers- that shows off the logical
structure of your program.

** If you can't keep it all on the screen, scroll only one way.
It's just too easy to get lost in huge windows. Patches usually have a
single direction, down for a process with a lot of steps, across for
several parallel activities.

** Flow downward.
It just seems sensible that consequences are below causes. Besides, the
cords get too kinky when you move up.

** Keep related objects together.
Sure, it keeps the cords short, but it also makes it clear how things fit
together. When objects aren't related, leave a bit of extra space.

** Align vertically, misalign horizontally.
Alignment helps the eye make associations. When side by side objects are
related, align them horizontally, but break the line between unrelated
clusters of objects.

** Use segmented cords, most of the time.
A few angles break up the monotony. There's no point in segmenting
temporary connections for diagnostics and tests. In fact, the angled cords
make them easy to find when it's time to take them out. Sometimes a short
angle on a segmented cord can clarify what might be a confusing connection.

** Don't run cords over objects.
It makes the lettering hard to read, and you can't tell what's connected.

** Route cords to minimize intersections.

** Make intersections unambiguous.
A full cross should always mean the cords cross with no connection. A three
way means two cords join going to a common inlet or coming from the same
outlet. Don't stack cords that aren't going to the same place.

** Use trigger objects for fanout at the end of long cords.
If you take an output across a window with two or three cords, use one cord
to a trigger rather than several parallel cords. This is more reliable as
well as neat.

** Use send and pv instead of convoluted cords.
You can only have five corners on a cord. You should never need more than
three.

** Make your names for send and value mean something.
Names like rate and theNote can help you understand what is going on. Names
like Fred and X3 don't.

** Subpatchers should only have one function, but they should have all of
it.
A subpatcher should have a simple purpose. All of the objects needed should
be in there, even if it means duplicating a bit. A subpatcher should be
ready to move out on its own if it gets the opportunity.

** Subpatcher names should mean something too.
If the subpatcher has a single purpose, the name won't be hard to find.

** Never use two objects where one will do.
Don't send a message to two of the same objects.
Don't use messages to set values that can be set with arguments.
Use the comma in message boxes when two messages are always needed.
Don't use a button to make a bang if the message is already a bang. (Unless
you need a visual indicator)
Peter Elsea
Electronic Music Studios
University of California, Santa Cruz
http://arts.ucsc.edu/EMS/Music/index.html
 elsea@cats.ucsc.edu

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

End of MAX Digest - 17 Feb 1999 to 18 Feb 1999 - Special issue (#1999-57)
*************************************************************************