Subject: MAX Digest - 29 May 1999 to 30 May 1999 (#1999-162)
Date: Mon, 31 May 1999 00:00:06 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 5 messages totalling 243 lines in this issue.

Topics of the day:

  1. overdriving miss daisy (starring Defer) (2)
  2. IBVA (fwd)
  3. views on PB 5300?
  4. atombuf_free question

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

Date:    Sun, 30 May 1999 15:49:07 +0100
From:    Carl Faia 
Subject: Re: overdriving miss daisy (starring Defer)

David Z. wrote:

>Actually, you put the scheduler in the audio interrupt, and that
>means that the scheduler takes priority.

Thanks for cleaning up my confusion...

>Note that when using scheduler in audio interrupt mode, the configuration
>timing preference is ignored, because it's I/O vector size that
>determines the granularity of the scheduler. At 64 samples and 44.1 kHz,
>the scheduler runs every 1.45 ms.

What will happen to the MIDI by changing the configuration setting in this
case, and will this affect the balance of the MIDI to Audio processing on
the CPU??

>Another thing is thinning the MIDI data with speedlim, etc.

How can the defer object be used to give or take priority from certain
processes?? The help patch is not terribly helpful and when trying it on
the G3, I no longer see a difference in the responsiveness of the
computer...

Carl

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

Date:    Sun, 30 May 1999 12:39:00 -0400
From:    Stephen Kay 
Subject: Re: overdriving miss daisy (starring Defer)

>How can the defer object be used to give or take priority from certain
>processes?? The help patch is not terribly helpful and when trying it on=

>the G3, I no longer see a difference in the responsiveness of the
>computer...

>Carl

The defer object causes processes which would normally happen at
interrupt level to not happen at interrupt level, but rather to
happen "when the computer has time to get around to it."

It works kind of like this:  picture 2 lists of things to do
being managed by the computer.  One list is the "scheduler" list,
and one list is the "deferred" list.  These lists are maintained
in an order of soonest to farthest away in time.

When you "schedule" anything to happen in max (i.e. by using
code calls like clock_delay, or objects like delay, pipe, metro),
the scheduled event goes into the scheduler list, inserted at
a location related to when it is to be performed.

When you "defer" anything (i.e. by using code calls like qelem_set,
or putting up a screen dialog, or causing something to redraw),
the deferred event goes into the deferred list, likewise.

Every 1 ms (or whatever interval you have chosen for the scheduler),
*no matter what*, all processing currently going on is paused
(interrupted), and a loop is entered where a certain portion (or all)
of the events waiting at the head of the scheduler list are
performed, such as issuing audio, midi, etc. This loop executes =

its required portion of events and cannot itself be interrupted.

In between those interrupts, once the loop has returned control
to the CPU, a similar loop is entered for the deferred list,
with the difference that this loop can be interrupted at any time
by the previously described 1 ms interrupts.  So the deferred loop
operates in whatever time is left over, and has no real priority.

As you can see, if the scheduler list is extremely full (because
the CPU cannot keep up with the amount of "priority" instructions to be
performed), the deferred list will end up getting longer and
longer as less of it is executed in the time remaining, resulting
in things like slow redraws, slow mouse response, etc.  However,
this allows things like music/audio to be executed with timing =

accuracy no matter what else is waiting to be done.

Actions you perform in Max that don't result in an immediate
action, but cause something to happen "in the future" (i.e.
even 1 ms from now) go into the scheduler list, and happen at
interrupt level. For example, say you were using a metro to produce
a bang every 50 ms.  The bang, when it issues, is happening at
interrupt level, and will cause anything else attached to it to
likewise continue to process at interrupt level (until the end
of that particular processing chain).  Inserting a defer object
will "remove" the interrupt priority and cause the rest of that
chain to execute "when the CPU has time".

This may be overly simplified, but that's the basic idea.

Stephen Kay

The MegaMAX Collection of professional development-oriented Max objects:
http://www.musikinetix.com

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

Date:    Sun, 30 May 1999 20:44:46 -0400
From:    Jesse Gilbert 
Subject: IBVA (fwd)

I remember someone asking last week about the IBVA interactive
brainwave analyzer system, originally designed by Masahiro Kahata.  I
regret I don't have the original quesiton handy, but I have used this
system a bit, and can make a few general comments:

-- the IBVA application itself is quite powerful and flexible, allowing
for multiple filters, numerous visualization algorithms, and MIDI output
via Midi Manager.  At this time I don't think OMS is supported, but that
may be coming in future releases.

-- IBVA hardware is (in my experience) a bit fragile to work with, and
requires that those using it take extra care.  You should always have
extra electrodes on hand if you are doing any live performance using IBVA
and Max.  Once you get it working, however, it is very solid.  Dual
channel models are quite nice because they enable two people to input EEG
data simultaneously.

-- IBVA documentation is often difficult to read (at least the web version
that Masahiro maintains at his web site).  I had trouble deciphering the
MIDI translation window, but did eventually get things working.

If people are interested you can take a look at a web archive of a
performance I did with Emily Hartzell, Nina Sobell and Scott Wilson last
winter using IBVA and Max to control two audio and video channels:

http://www.cat.nyu.edu/parkbench/dots/

There is another, newer system called Brainmaster that is currently
available.  I believe it is much more reasonably priced, and has an Open
Source DLL that is available for extensions.  Right now it is
windows-only, but I think there are some projects trying to bring it over
to the Mac.  Tom Collura, the creator of brainmaster, is a very nice guy,
and open to ideas around extending the system in new directions.  I
haven't worked directly with it, though:

http://www.brainmaster.com/

Talking with a programmer the impression I got was that the DLL is very
well organized and well commented.  Those with C++ chops may want to take
a look at this.

hope this helps,
Jesse

(not affiliated with any company)

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

Date:    Sun, 30 May 1999 21:10:37 -0400
From:    Neal Farwell 
Subject: views on PB 5300?

Dear All -

A friend has offered what seems a good price on a PowerBook 5300 (100MHz,
b/w, post-fireworks model). What are your experiences with this machine for
Max/MSP?
MIDI only? Some MSP too? Can it do direct-to-disk record/play? Sound
quality?

Comments gratefully received.

Neal

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

Date:    Sun, 30 May 1999 20:30:05 -0600
From:    Kevin Walker 
Subject: atombuf_free question

Which memory does atombuf_free free?  The entire structure or just
ab->a_argv?

  typedef struct atombuf {
      long a_argc;
      Atom a_argv[1];
  } t_atombuf, Atombuf;

Also, does atombuf_text free the memory of the old atombuf before replacing
it?  In other words, which of the following is correct?

  Atombuf* ab;
  ab = atombuf_new(0L, 0L);
  atombuf_text(&ab, &buf1, size1);
  // use ab
  atombuf_free(ab);
  atombuf_text(&ab, &buf2, size2);
  // use ab
  atombuf_free(ab);
  atombuf_text(&ab, &buf3, size3);
  // use ab
  atombuf_free(ab);

or

  Atombuf* ab;
  ab = atombuf_new(0L, 0L);
  atombuf_text(&ab, &buf1, size1);
  // use ab
  atombuf_text(&ab, &buf2, size2);
  // use ab
  atombuf_text(&ab, &buf3, size3);
  // use ab
  atombuf_free(ab);

or

  Atombuf* ab;
  ab = atombuf_new(0L, 0L);
  atombuf_text(&ab, &buf1, size1);
  // use ab
  atombuf_free(ab);
  ab = atombuf_new(0L, 0L);
  atombuf_text(&ab, &buf2, size2);
  // use ab
  atombuf_free(ab);
  ab = atombuf_new(0L, 0L);
  atombuf_text(&ab, &buf3, size3);
  // use ab
  atombuf_free(ab);

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

End of MAX Digest - 29 May 1999 to 30 May 1999 (#1999-162)
**********************************************************