From:
                                                            9/14/97 11:00 PM
Subject: MAX Digest - 13 Sep 1997 to 14 Sep
1997To: Recipients of MAX digests 

There are 7 messages totalling 283 lines in this issue.

Topics of the day:

  1. ___HELP: How to 'multiplex' variable length sysexin msgs??___ (2)
  2. I-cube noteoff
  3. ispeak (panning troubles)
  4. iCube questions
  5. MAX Digest - 11 Sep 1997 to 12 Sep 1997 (2)

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

Date:    Sat, 13 Sep 1997 21:07:25 -0700
From:    ai 
Subject: ___HELP: How to 'multiplex' variable length sysexin msgs??___

Hello,

I am writing a patch that needs to respond to and
process incoming variable length sysexin messages.

1. incoming sysexin msgs can be 20 bytes long,
   100 bytes long or 10,000 bytes long

2. depending on certain byte values within
   the 1st 10 bytes of the incoming sysexin msg,
   I need to send:

   20     byte msgs to A
   100    byte msgs to A
   10,000 byte msgs to C

   where A, B and C represent separate post-processing blocks
   that process the 20, 100, 10,000 byte msgs respectively

3. currently I am able to "multiplex" the 20 and 100 byte
   msgs OK as follows:

   sysexin -> thresh  (which combines the incoming sysex bytes)
   thresh  -> if statement #1 (outputs 1 if msg is of type 20 bytes)
   thresh  -> if statement #2 (outputs 2 if msg is of type 100 bytes)
   thresh  -> gate[2]   (complete  msg sent to gate for multiplexing)
   if stmt#1 -> gate[2] (used to choose whether msg is passed through
                         gate output #1)
   if stmt#2 -> gate[2] (used to choose whether msg is passed through
                         gate output #2)

   gate[2] out#1 -> send A (send msg to block A)
   gate[2] out#2 -> send B (send msg to block B)

4. The above seems to work fine;  however, when I create a
   3rd if stmt for identifying 10,000 byte long sysexin msgs,
   and change gate[2] to a gate[3] (3-output gate), the 3rd
   gate[3] output never seems to contain the 10,000 byte msgs
   correctly

   (I tried using a slice[10] to feed the 3 sep. if stmts,
   but this didn't help).

Q1. Am I handling 20 and 100 byte msgs correctly in #3 above?

Q2. Is there some limit to the length of a msgs/list which
    thresh can handle?  (thus resulting in the bad behavior
    for the 10,000 byte msg I am seeing in #4 above?)

Q3. What would be a 'better' way to process incoming
    variable length sysexin msgs (20, 100, 10,000 bytes
    long) in order to be able to route them to different
    post-processing blocks A, B, C ?
    (where if stmts are doing the "steering").

Thanks in advance for any help on this to:

   ai@wco.com

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

Date:    Sun, 14 Sep 1997 12:26:00 +0200
From:    Oeyvind Brandtsegg 
Subject: I-cube noteoff

Hi

As Stephen Kay wrote, you can use a makenote object to provide note off.
There's also another solution that might work: Icube-input (goes to)
change (to) numberbox (to) flush (to) noteout, you then connect the
rightmost outlet (1 for transition from nonzero to 0) of the change
object to a bang object and then to the left inlet of flush. This way
you would get noteoffs for all notes triggered by that particular sensor
when the sensor input goes to zero.

Hope this helps

Oeyvind Brandtsegg (Composer/Vibraphone)
Nedre Bakklandet 47 A
7014 Trondheim
Norway
mailto:obrandts@online.no

>
> it's basically a note off problem. we are sending values out via the
> i-cube object (from sensors) and then putting them through a change
> object then to a number box then to a note out. I know that there is a
> simple note off thing missing but I just can't figer it out at the
> moment!!!!
>

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

Date:    Sun, 14 Sep 1997 21:29:00 +0900
From:    =?ISO-2022-JP?B?GyRCQGlMbiEhPSgwbBsoQg==?=

Subject: Re: ispeak (panning troubles)

Dr. K@rlheinz Essl wrote,

>>the "pan $1" message does not affect the panning
>>of the voices. Instead, it is speaking the "pan" message, even from
your
>>example patch.

i've been unpligged for 3 weeks. sorry for late res.
sorry and thank you for the indication. that was NOT a real fat (i for
got to include 68k code). since i fixed this already it'll be availabl
e in a few days. at
ftp://ftp.ircam.fr/pub/forumnet/max/FAT/sound/
or
ftp://ftp.ircam.fr/pub/forumnet/max/incoming/

ichi

ps. my e-address is in the object itself. you can see it using ResEdi
t.

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

Date:    Sun, 14 Sep 1997 12:36:44 -0400
From:    Stephen Kay 
Subject: ___HELP: How to 'multiplex' variable length sysexin msgs??___

>Q2. Is there some limit to the length of a msgs/list which
>    thresh can handle?  (thus resulting in the bad behavior
>    for the 10,000 byte msg I am seeing in #4 above?)

Most of the regular MAX objects have a list length limit of 256, which I
believe is your problem with thresh.

Although I (or anyone with a compiler) could easily recompile a version o=
f
thresh that would handle 10,000 byte lists, I don't think that ultimately=

that will help you, because many other objects have that built in
limitation (the problem is that unless you design an object with an
argument that specifies list size, or count the arguments or something so=

that you can dynamically allocate RAM, most (simple) objects create the
arrays with a default maximum size, and reserving space for 10,000 bytes =
in
every single max object would be a horrendous waste of RAM since most
people never need that kind of list length.)

Personally, I think that if you are going to be regularly dealing with
lists of this size in MAX, the only way you're going to succeed is to bre=
ak
them up into smaller pieces.  One solution would be to "chop" the 10,000
byte list into something like 50 lines of 200 bytes and store it in a col=
l.

You could do this easily enough with the "group" object (from James
McCartney's ListOps).  An example patcher which does this is attached,
showing storing 20 item lines in a coll from a 60 byte message, which can=

easily be modified to 200 item lines.

>Q3. What would be a 'better' way to process incoming
>    variable length sysexin msgs (20, 100, 10,000 bytes
>    long) in order to be able to route them to different
>    post-processing blocks A, B, C ?
>    (where if stmts are doing the "steering").

Pursuant to the above, store the 20 byte message in line "0" of the coll;=

store the 100 byte message in line "1" of the coll, and store the 10,000
byte message in lines 2 - 52 of the coll; slice off the first 10 bytes of=

either of the 3, and then based on your analysis, output the line (or
lines) of the coll to the post processing blocks.

It may be possible that Peter Elsea's Lobjects have some way of dealing
with huge lists and this situation - I'm sure he'll jump in if so ;-)

Best regards,
Stephen Kay
------- The MegaMAX Application Developer's Collection --------
Full color 3D UI Objects for creating professional looking apps,
     Macintosh Interface objects, and other Max helpers.
-----------check out the demo on the MAX 3.5 CD----------------

max v2;
#N vpatcher 40 55 447 441;
#P newex 131 290 70 196617 prepend store;
#P newex 195 200 27 196617 0;
#N coll;
#P newobj 131 312 53 196617 coll;
#P newex 131 209 27 196617 t l b;
#P newex 131 189 48 196617 group 20;
#P newex 148 233 66 196617 counter;
#P message 148 257 64 196617 set store \$1;
#P newex 85 152 25 196617 iter;
#P comment 202 49 100 196617 <-click here;
#P newex 177 73 28 196617 t b b;
#P button 177 48 15 0;
#P message 85 108 290 196617 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 =
18
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 4=
3
44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59;
#P connect 7 0 8 0;
#P connect 0 0 4 0;
#P connect 6 0 5 0;
#P connect 8 0 11 0;
#P connect 8 1 6 0;
#P connect 5 0 11 0;
#P connect 11 0 9 0;
#P connect 2 0 0 0;
#P connect 2 1 10 0;
#P connect 10 0 6 2;
#P connect 1 0 2 0;
#P connect 4 0 7 0;
#P pop;

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

Date:    Sun, 14 Sep 1997 18:14:39 -0400
From:    Ken Mistove 
Subject: Re: iCube questions

Mark,

Sampling resolution is easily overlooked. Make sure you have set the
sensors to use 12-bit resolution (4096 steps). If the sensors are set to
8-bit you will only get 128 steps. You might also take a look at your
sampling interval. I've found 50 milliseconds to be adequate, but you can
go down as far as 4. I hope that clears up your problems.

>Any iCube object users out there? I'm helping a music therapist evaluate
>the iCube sensor kit and we are having problems getting good data (i.e.
>a wide range of values) out of some of the sensors.

Ken

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

Date:    Sun, 14 Sep 1997 18:25:30 -0400
From:    Raymond Neeves 
Subject: Re: MAX Digest - 11 Sep 1997 to 12 Sep 1997

max info
end

Um Hi,

Sorry if this gets to the list itself, but if it does would one of you mind
letting me know how I get the "bounced" version of the list instead of the
"Digest".

Thanks
Raymond

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

Date:    Sun, 14 Sep 1997 19:43:34 -0400
From:    Bill Vorn 
Subject: Re: MAX Digest - 11 Sep 1997 to 12 Sep 1997

On Sun, 14 Sep 1997, Raymond Neeves wrote:
> Sorry if this gets to the list itself, but if it does would one of you
mind
> letting me know how I get the "bounced" version of the list instead of the
> "Digest".

Send the "set max index" message to LISTSERV@VM1.MCGILL.CA
It will reply that this mode is not available for max, but it does work.

To verify your request, send the "query max" message to the listserv.

More options are available.  Send the "info refcard" message to have a
complete list.

Bill Vorn
Montreal (Quebec) Canada

Thanks to Jean Favory for the info.

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

End of MAX Digest - 13 Sep 1997 to 14 Sep 1997
**********************************************