Subject: MAX Digest - 15 Dec 1999 to 16 Dec 1999 (#1999-359)
Date: Fri, 17 Dec 1999 00:00:00 -0500
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 5 messages totalling 163 lines in this issue.

Topics of the day:

  1. experimental input devices
  2. positional message to subpatch
  3. Talking Stick
  4. Midi Sync and Lib Scripts
  5. er: echo machine/ copying buffers ?


Date:Thu, 16 Dec 1999 01:09:37 -0500
From:Louis Klepner <lou@EXPRESSIVEIMAGING.COM>
Subject: experimental input devices


I think there are problably a lot of people on this list who would be
interested in hearing about controller solutions people have developed.
Linear motion converters, drawing tablets, wireless midi, ultrasonic
devices, and other experimental approaches.
i am personally interested in ways of converting kinetic motion to midi.
Somehow measuring the speed or tempo of a group of people, and converting it
into usable data. I regret I have no information to share. If people seem to
be interested in this subject, I will certainly post any experiences I have
in the future.

-Louis Klepner


Date:Thu, 16 Dec 1999 08:30:35 +0100
From:Jeffrey Burns <jeff@BERLIN.SNAFU.DE>
Subject: positional message to subpatch

>in the patcher that i'm working on, i have a subpatch that appears quite
>a few times. as i'm still tweaking, i thought that i should make it into
>an external, so that any changes are reflected across all the instances
>of the subpatcher.
>the problem with this is that whenever i call any particular instance of
>the patch it always appears in the same place on the screen, whereas i'd
>like each one to appear next to the patcher from which i called it.
>is there a way of telling each window to open in a different place? i'm
>using [pcontrol] to open the subpatchers, but as far as i can tell from
>the manual, you can't send positional info that way?

On page 113 of Max 3.5 Mannual Addendum the window messages to
thispatcher are described. Just pack the desired window coordinates
into a list, prepend window size and send the whole megillah to a
thispatcher object within the desired window.

Jeff Burns


Date:Thu, 16 Dec 1999 11:27:35 +0000
From:Dominic Robson <dominic_robson@BIGFOOT.COM>
Subject: Re: Talking Stick

>Curious to know how the long slider sensor was constructed.

We managed to find a series of long throw potentiometers, the sort of
things that are usedi think in position feedback for mechanical/hydraulic
systems. They vary up to about 1meter in throw and are usually long and
cylindrical with a central spindle that extends as the slider.

The drawback is that they are quite expensive in the $100's range but they
are100% robust and consistent. Having reliability at the sensor end of
things was pretty crucial for them to be used with confidence for a large
scale performance piece.

>wireless midi ?
tell us more, please !

we looked around at commercial wireless midi systems and i could only find
one that was made by midiman (?) and had been discontinued . This with the
popularity of midi surprised me and i suspect that there probably is other
stuff hiding out there. It seemed on a web surveyto be in the domain of
useres of yamaha style midi wind instrument controllers.

I was not heavily involved in the radio side of things but essentially a
PIC microcontroller converted the sensor information from the stick and
then formatted the information with some encoded error checking. This was
transmitted from the stick using readily commercially available local area
transmitter board modules and received at the Mac end by the matched
receiver. These boards may have been specific to digital use , i dont
recall. This fed to another PIC chip which did the appropriate error
checking and filtered out corrupted data and sent the rest out as midi
information that went straight to the Mac . The communication was only one
way. this system works well up torange of around 30m . In radio noisy
areas like Manhattan this could be less with a big increase in the number
of bad messages. we werent however ever using full midi bandwidth.



Date:Thu, 16 Dec 1999 08:47:23 -0800
From:"Michael P. Whyte" <matrix6k@YAHOO.COM>
Subject: Re: Midi Sync and Lib Scripts

I have gotten this to work:
I have max on the ibook and it starts oms timing, formatted to beat clock.
Oms timing starts Vision, also running on the ibook. (vision is set to internal
clock, and remote start is on so max can start it.)
Vision sends out midi sync to the desktop, running logic. Vision starts logic.

This wasn't easy. Oms timing will start sequencers at the bpm specified,
but I had a hard time locking a tempo object to the setclock object. (setclock
was oms timing in, or setclock "name" ext)
The tempo object was running way too fast. What I did was set the tempo object
to another setclock object, this time the setclock object was in multiplicative
mode. I set this clock to the other oms timing referenced clock, and put the
multiplication factor at .7228. This is accurate to one hundred measures or so,
and then starts to drift.
I'd like to find something better, any ideas are appreciated.
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping:


Date:Thu, 16 Dec 1999 13:37:36 +0000
From:Robert Henke <robert@MONOLAKE.DE>
Subject: Re: er: echo machine/ copying buffers ?

well it does actually not make sense to copy the buffer~ object itself but to use the RAM space
allocated via the name of the buffer by differnt objects simulataniously.
there is no need to have more then one buffer object for one soundfile in RAM. every object
which is meant to use the information writen in the buffer~ GONZO has to have that name : index~
GONZO, play~ GONZO etc. thats all.


|K< said in er: echo machine at 99/12/14Tue 11:58.

> >There are times when I need to begin playback before the capture is
> >complete (playback from buffer while recording in progress (or playback
> >head chasing record head at normal speed)).
> the buffer~ object is cool in that all buffer~ objects which share the
> same name are sharing the same data (just like a table). so to answer
> your question, just use one buffer to record into, and everytime you need
> a new 'tap' make another copy of the buffer~ with the same name. play back
> at any speed (or direction) you like. it's up to you to make sure you
> don't read past your current write boundary.
> |K<

the secret life of digital music


End of MAX Digest - 15 Dec 1999 to 16 Dec 1999 (#1999-359)