Subject: MAX Digest - 23 Dec 1997 to 24 Dec 1997
Date: Thu, 25 Dec 1997 00:00:53 -0500
From: Automatic digest processor 
Reply-To: MAX - interactive music/multimedia standard environments
     
To: Recipients of MAX digests 

There are 3 messages totalling 93 lines in this issue.

Topics of the day:

  1. lockout_set and click methods (2)
  2. MAX Digest - 21 Dec 1997 to 22 Dec 1997

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

Date:    Wed, 24 Dec 1997 17:19:30 +0000
From:    Nick Rothwell 
Subject: lockout_set and click methods

I'm probably being dense here, but I want to clarify something...

I'm currently implementing an external which bears striking similarities to
"coll". (It's sort-of based on the best features of the Windows (spit!)
Registry, so it behaves like a heirarchical coll or directory. It's my
particular attempt to get away from the well-known problems of basing large
systems on "preset".)

I don't see anything in the coll source code which prevents a clash between
a destructive coll update (say, "delete") from a click on a message box
versus one from a MIDI or timer event. I was expecting some lockout calls
there.

Perusal of the documentation suggests a different paradigm: objects which
*output* must lockout for non-interrupt output of messages (qelem output,
for example), which presumably means that objects which *input* are
guaranteed proper critical separation for all messages.

Am I correct in this assumption? According to the documentation all UI
objects (message boxes, numericals and so on) should be doing lockouts
whenever they transmit? (And preset too, for that matter, if clicked.) And
presumably a UI object might still need internal interlocks between UI
clicks and interrupt-level messages coming in to it, regardless of whether
it's outputting?

Oh, for what it's worth, my analysis suggests a bug in the coll source
code: it doesn't do a lockout when writing to a file via qelem, so if an
interrupt-level routine manipulates the internal data structures while the
qelem is walking over them and building the binbuf, it could go off its
trolley.

Thanks for any illumination. Oh, and Merry Christmas...

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

             years, passing by, VCO, VCF, and again, and again

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

Date:    Wed, 24 Dec 1997 13:37:18 -0500
From:    Stephen Kay 
Subject: lockout_set and click methods

>Nick Rothwell:
>Am I correct in this assumption? According to the documentation all UI
>objects (message boxes, numericals and so on) should be doing lockouts
>whenever they transmit?

Yes, if they are transmitting as a direct result of being clicked on
or having a message sent in via user action.  Presumably, this means
that if the message to transmit something is sent as a result of clicking=

on a _different_ object, then that object outputs something which causes
the second object to transmit, the lockout is not needed (I think?)

In any event, all the UI objects in the MegaMAX collection use
lockouts for transmission of bangs and other data in response to =

user actions.

>And
>presumably a UI object might still need internal interlocks between UI
>clicks and interrupt-level messages coming in to it, regardless of wheth=
er
>it's outputting?

I don't think this is necessary - if you're putting up a save dialog,
for example, you use defer_low(), but I defer_low() to David Z.

Stephen Kay
----------------------- The MegaMAX Collection -----------------------
  Over 30 Max objects for the creation of more professional looking, =

         feeling, and functioning patchers and applications.
                      http://www.musikinetix.com
                          sk@musikinetix.com
----------------------------------------------------------------------

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

Date:    Wed, 24 Dec 1997 19:44:57 +0100
From:    Ek del Val 
Subject: Re: MAX Digest - 21 Dec 1997 to 22 Dec 1997

unsuscribe

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

End of MAX Digest - 23 Dec 1997 to 24 Dec 1997
**********************************************