Subject: MAX Digest - 3 Dec 1999 to 4 Dec 1999 (#1999-346)
Date: Sun, 5 Dec 1999 00:00:16 -0500
From:
Automatic digest processor <LISTSERV@LISTS.MCGILL.CA>
Reply-To: MAX - Interactive Music/Multimedia Standard Environments <MAX@LISTS.MCGILL.CA>
To: Recipients of MAX digests <MAX@LISTS.MCGILL.CA>


There are 2 messages totalling 66 lines in this issue.

Topics of the day:

  1. no sliders
  2. complexity

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

Date:Fri, 3 Dec 1999 23:07:45 -0800
From:Peter Nyboer <pnyboer@SLAMBASSADOR.COM>
Subject: no sliders

>But no sliders?

As an information consumer, you must feel in your heart that software
sliders are a trendy concept, really, and only for primitives :)Pd has to
be cool, like max, because Miller Puckette has weird hair.

Clearly, I've had a few in me,

Peter.


Peter Nyboer
pnyboer@slambassador.com
No Stores. Only One Product. All in one place.

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

Date:Thu, 2 Dec 1999 21:40:38 -0000
From:Nick Rothwell <nick@CASSIEL.COM>
Subject: Re: complexity

> Don't count on right to left, use trigger.

That's a good one. Actually, I *always* use trigger, just because it
seems more explicit and clearer. What's interesting is that it doesn't
actually add much clutter - my patches have far fewer such points than
one might expect.

> Send note offs before note ons, not at the same time. (Metro 300 feeding
> makenote 90 300 is a prime example of this no-no.)

I don't see why this would cause reliability problems, although it
could cause problems depending on the device being driven. My usual
trick is to put out velocity values using something like "0, 64" in a
message box to keep the ordering explicit.

> Think *between* the beats.

This is a good one. The trick (as you intimate) is to work out the
things that you *know* are going to happen at the next tick, and
separate those from things which are dependent on input which arrives
at the tick itself. At the moment, my pulse sequencing system does
everything on the beat, and even though it's native-coded it can
generate some t_pointer problems under heavy use.


Bizarre as it may seem, these days I'm so familiar with the MAX object
API that I'll often lift out a MAX object and native-code the entire
thing in C to improve modularity and performance, and so far it's
never impacted on reliability or robustness.

--

Nick RothwellCassiel.com Limited
nick@cassiel.comwww.cassiel.com
systems - composition - installation - performance

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

End of MAX Digest - 3 Dec 1999 to 4 Dec 1999 (#1999-346)
********************************************************