Subject: MAX Digest - 14 Dec 1999 to 15 Dec 1999 - Special issue (#1999-358)
Date: Wed, 15 Dec 1999 20:57:41 -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 8 messages totalling 716 lines in this issue.

Topics in this special issue:

  1. xlisp object?
  2. MAX Digest - 13 Dec 1999 to 14 Dec 1999 (#1999-357)
  3. Your coolest MSP patch. Be a superstar.
  4. Max in pop culture (2)
  5. positional message to subpatch
  6. tracking vocoder
  7. Kyma ?

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

Date:Tue, 14 Dec 1999 20:21:14 -0800
From:Matt Wright <matt@CNMAT.CNMAT.BERKELEY.EDU>
Subject: Re: xlisp object?

Michael Kerenaka Theodore <michael.theodore@COLORADO.EDU> writes:

> I noticed mention of an "xlisp" object
> while perusing http://cnmat.CNMAT.Berkeley.EDU/Max/.
> The "Available" field is empty - does this (FAT?) object live
> on somewhere?

I've never seen this object, and I'm currently maintaining all
of CNMAT's Max stuff, so that's probably a bad sign. Let me
know if you find it!

-Matt

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

Date:Tue, 14 Dec 1999 21:42:34 -0800
From:Jeffrey Stolet <stolet@OREGON.UOREGON.EDU>
Subject: Re: MAX Digest - 13 Dec 1999 to 14 Dec 1999 (#1999-357)

Robert Henke wrote:

...is the kyma. If anyonehere on the list has used / is using it and is
willing to share his/her pro / cons...

I have been using the Kyma system for a number of years now and teach Kyma
in my courses at the University of Oregon. I like Kyma enough to be
planning the purchase of three more systems for the School of Music. The
Kyma system is quite an amazing sound design environment and it has a
pretty straight-forward user interface. So far, Kyma has been able to do
everything that I have asked it to do including the usual suspects like
sampling, AM, FM, additive, subtractive, wavetable, and granular synthesis
as well as analysis and resynthesis in real-time. The new system (320)
also does some neat stuff with surround. For most of my work I drive my
Kyma with Max. I could hardly be more satisfied.

If you have any more questions please do not hesitate to contact me
directly.

Most Cordially,

Jeff


***********************************************
Jeffrey Stolet
Director of Music Technology and Computer Music
University of Oregon
School of Music
Email:stolet@oregon.uoregon.edu
Voice:541-346-4094
http://darkwing.uoregon.edu/~fmo/
***********************************************

On Wed, 15 Dec 1999, Automatic digest processor wrote:

> There are 12 messages totalling 446 lines in this issue.
>
> Topics of the day:
>
>
1. tracking vocoder
>
2. Kyma ?
>
3. Your coolest MSP patch. Be a superstar.
>
4. er: echo machine
>
5. ICMC Submission Deadlines
>
6. "Talking Stick"
>
7. MAX Digest - 12 Dec 1999 to 13 Dec 1999 (#1999-356)
>
8. crash
>
9. Kyma
>
10. Weird Groove Sync problem
>
11. record~ sync out & pop culture
>
12. mute~/pass~ enable/pcontrol MSP etc.
>
> ----------------------------------------------------------------------
>
> Date:
Tue, 14 Dec 1999 02:24:08 -0500
> From:
luke <luke@WOOF.MUSIC.COLUMBIA.EDU>
> Subject: Re: tracking vocoder
>
> scott --
>
> this is just my gut reaction to your problem, but i'm guessing that a
> true-to-form f.r. moore style phase vocoder would be kind of tricky to
> implement given msp's real-time design. at least as a patch (you might be
> able to code up an external to do this -- that certainly _would_ be a
> question for the formidable professor lyon, though).
>
> the concept of 'real-time' and 'time compression/expansion' don't co-exist
> that comfortably in the sense that we (as max users) would use those
> terms. when you say 'real-time phase vocoder' what that usually means is
> that if you have a one-minute soundfile on your hard disk then your
> computer takes one-minute to do whatever time manipulation algorithm it
> uses and then spits out a new soundfile. while this is fine as a
> definition for some software, anything you develop in msp has to be able
> to 'stream' properly or else you'll get gaps in your output. for example:
>
> if you plug a sample stream into an fft~ object to prepare for an
> oscilator bank resynthesis that uses time-stretching you have to deal with
> the fact that the fft~ object is going to keep outputting new windows of
> data every 1024 (or 2048, or whatever) samples. you'd have to buffer the
> samples coming out with some sort of fairly convoluted tapin~/tapout~
> scheme and eventually you'd probably run out of memory. you could
> probably implement a time-stretching algorithm in max provided you set a
> finite input duration into the vocoder patch and then forced msp to just
> flush everything and start over again. time-compression would be even
> more difficult (you'd have to buffer in the other direction -- take
> multiple windows output from fft~ and then spit them out of some sort of
> signal delay system faster than they originally came out -- since msp
> doesn't support multiple sampling rates or up/downsampling this might be
> pretty hard).


>
> you could probably fake it another way by having msp do an entire analysis
> of a soundfile, dump that fft~ output into a couple of syncronized record~
> objects to hold everything in buffers, then play~ back the buffers into a
> resynthesis engine at the wrong playback speed, transposing the bins up or
> down as you go. there are some logistical problems with this idea, i'm
> sure, as i've never tried it but it's my best guess.
>
> the good news is there are lots of pretty good phase vocoders out there in
> macintosh land -- i've had loads of success with the pvoc algorithms in
> soundhack, metasynth, and audiosculpt, just to name the ones closest to
> mind.
>
> all the best.
>
> /luke
>
> --------------------------
> R. Luke DuBois
>
Graduate Teaching / Research Assistant,
>
Computer Music Center, Columbia University
>
e-mail: luke@music.columbia.edu
>
world-wide-waste: http://www.music.columbia.edu/~luke
>
phone:(212)-854-9266 (cmc - prentis)
>
(212)-854-7181 (cmc - dodge)
> --------------------------
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 09:18:57 +0200
> From:
Reinhold Braig <reinhold.braig@SWR-ONLINE.DE>
> Subject: Re: Kyma ?
>
> Robert Henke wrote:
> >...is the kyma. If anyone
here on the list has used / is using it and is
> >willing
> >to share his/her pro / cons please send me an e-mail.
>
> By thew way, has anybody worked with the Creamware Scope platform and the
> SDK kit and will share infos?
>
> reinHOLD
>
> ...Experimentalstudio der...................................
> ...Heinrich-Strobel-Stiftung des SWR e.V, Freiburg, Germany.
> ...><bald auch><....www.experimentalstudio.de....><soon><.
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 01:37:22 -0800
> From:
Les Stuck <les@CYCLING74.COM>
> Subject: Your coolest MSP patch. Be a superstar.
>
>
~~~~~~~~ Send us your clever patch ~~~~~~~~~~~~~~~~
>
> We're talking about a patch that:
>
>
uses an MSP aspect/technique in a creative way
>
>
is clearly laid-out and documented
>
>
shows good programming style
>
>
is made to be recycled by others
>
>
includes only stock max/msp objects
>


>is neither a tutorial nor a help patch
>
>
~~~~~~~~~~~~~~~~~~~~~~~~ Change the world ~~~~~~~~~
>
> We are looking for exemplary patches to be a part of MSP Examples
> for a future release of MSP. If you would like to make a submission,
> kindly email it to me. No patch will be included without your permission.
> We reserve the right to tweak, but only in the interest of making you
> famous. Thank you in advance.
>
>
~~~ <les@cycling74.com> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 03:58:30 -0800
> From:
"|K<" <kent@SHOKO.CALARTS.EDU>
> Subject: er: echo machine
>
> >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<
> kent@music.calarts.edu
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 15:35:33 +0100
> From:
Peter Castine <pcastine@PRZ.TU-BERLIN.DE>
> Subject: ICMC Submission Deadlines
>
> Dear Friends and Colleagues,
>
> This is just a brief note to remind you that the submission deadlines for
> the ICMC 2000 Call for Papers and Call for Works are fast approaching.
> Submission forms and instructions are available on-line at
>
>
<http://www.icmc2000.org/participation/>
>
> We look forward to your submissions and to seeing you in Berlin next year!
>
>
> Best regards,
>
> Peter Castine
> ICMC 2000 Conference Chair
>
>
>
> PS: Your address was included in the distribution list for this message
> in good faith that it will be of interest to you. If this is not the
> case, please accept my personal apologies and disregard this mail. I also
> apologize if you receive multiple copies: invariably some people will
> read this twice, and some never at all...
>
> PPS: Dear List Moderator... if this message is not posted to your list
> because I am not a subscriber, would you please consider forwarding it
> anyway? Perhaps this is the only ICMC 2000 announcement your list has
> seen?
>


> ----------------- http://www.prz.tu-berlin.de/~pcastine/-----------------
> Dr. Peter Castine
| The World-Wide Web Site of the 26th
> 4-15 Music & Technology
| International Computer Music Conference is
>
| now on-line! <http://www.icmc2000.org/>
>
| Enjoy!
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 18:31:55 +0100
> From:
wolf <W.Heiniger@UNIBAS.CH>
> Subject: "Talking Stick"
>
> > The stick is freestanding and controls the
> > max patch via wireless midi.
>
> wireless midi ?
> tell us more, please !
>
> wolf
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 13:51:56 -0800
> From:
Benjamin Nevile/Towers Perrin <nevileb@TOWERS.COM>
> Subject: Re: MAX Digest - 12 Dec 1999 to 13 Dec 1999 (#1999-356)
>
> > Using a delay effect isn't real
> > pratical due to variations in tempo.
>
> Why not use Max to control the tempo of the delay
> via midi?
>
> bbn
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 18:13:00 -0500
> From:
Eric <er@INTERPORT.NET>
> Subject: crash
>
> I'm getting an inordinate number of crashes lately upon closing patcher
> windows - type 2 errors. Running system 8.6 on an original beige G3 233
> w/latest version of Max and lots of RAM. Any suggestions, explanations?
>
> Thanks all,
>
> Eric Rosenzveig
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 17:32:10 -0600
> From:
Bill Meadows <mrbill@FANTASIA.SPS.MOT.COM>
> Subject: Re: Kyma
>
> I have been a MAX user for years, and I have experimented a bit with MSP.
>
> I bought a Kyma system a few months ago, so I am no expert, but my first
> impression is pretty good. The tech support is similar to MAX - my email
> is answered by one of two people who actually write the software.
>
> The learning curve is fairly steep. Although the graphical interface
> LOOKS alot like MAX, it certainly behaves differently. It takes a while
> to un-learn the MAX-way and learn the Kyma-way. Actually there is a lot
> about the Kyma that is very cryptic and hidden.
>
> There is a major software revision due "any day now" that may solve some
> of the user interface and presets problems I've had.


>
> As with anything, Kyma does some things better than others. For example,
> Kyma is very good at vocoding, but not very good at polyphonic pitch-shifting.
>
> Unlike MAX/MSP, most "objects" are very complicated functions like spectral
> analysers and granulators, so it is easier to get complicated results, but
> it is ultimately less flexible.
>
> The software is written in SmallTalk, and I find the syntax to be pretty
> weird (I like C better!)
>
> One nice aspect is that I can run the Kyma software on the Mac, edit, compile
> and upload my program into the hardware box, then switch the Mac over to
> Digital Performer and the Kyma hardware runs just like a stand-alone processor.
> I've used the hardware ("Capybara") in an all-digtal effects loop from
> Digital Performer and it works great. The Capybara gets MIDI directly, not
> via the Mac, so I can control it with my PC1600 fader box.
>
> It's not a silver bullet, but it is a big hammer!
>
> Bill Meadows
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 20:18:23 -0500
> From:
Nick Lloyd <nxlloyd@IX.NETCOM.COM>
> Subject: Weird Groove Sync problem
>
> I'm having a strange problem with the sync output of the groove object. When
> I send groove a stop message, it's sync signal begins to jump around between
> floats (I've watched it hop around, jumping as high as 85!!). When it's
> playing back, it behaves normally, as far as I can tell. Any idea what might
> be causing this?
>
> I also noticed something about loading a buffer with a large amount of audio
> data. When I load files between 60 seconds and 120 seconds, the buffer only
> loads up to roughly 100ms *less* than the amount I stipulate in a 'replace'
> message. For example, if I load a file which should be 120000 ms long, only
> 119917 or something gets loaded. I had initially created a patch which
> automatically sets the loop points to the outer edges of the buffer, using
> the amount of audio specified in the replace command. This wasn't working
> with looping because the groove object doesn't play through the empty end of
> the buffer. Should I not be using replace with large audio files?
>
> Thanks in advance for any tips,
>
>
Nick
> --
>
Gretchen's Kitchen
> A Multi-Purpose Recording Facility
>
ph# - 718/623-1660
>
10 Sterling Place, Brooklyn, NY
>
> ------------------------------
>
> Date:
Wed, 15 Dec 1999 02:55:11 +0000
> From:
filip <filip@RHIZ.ORG>
> Subject: record~ sync out & pop culture
>
> tim wrote:
>
>
I've encountered what seems odd behavior to me in the
> record~ object. The
>
patch I've appended below demonstrates my problem: the
> Sync output doesn't
>
always output. If I've missed something obvious, perhaps
> someone could


>enlighten me. The patch below is supposed to apply a
> window to the input
>
coming into the record~ object...
>
>
Thanks in advance!
>
-Tim
>
> all signal-processing units will stop calculating when
> signal at its "output" is connected via patchcord to some
> input of the same
> unit.
> the workaround is send~ and receive~, see patch below.
> i can only tell, that it always works, but i don't know why
> it does not with patchcords....
>
> btw:
> jim o wrote:
> ..., and the mego label groups (pita, fennesz, etc.) are
> using max and...
>
> using max is true, but in this case it also means using
> lloopp:http://loopool.live.fm
>
> cheers klaus
>
> max v2;
> #N vpatcher 51 113 452 492;
> #P newex 275 67 71 196617 receive~ back;
> #P newex 188 193 55 196617 send~ back;
> #P comment 241 217 136 196622 This side does not;
> #P user number~ 288 129 345 144 9 3 2 2 0. 0. 0 0. 50 0.;
> #P user number~ 65 129 122 144 9 3 2 2 0. 0. 0 0. 50 0.;
> #P message 161 27 44 196617 open;
> #P user ezadc~ 161 41 205 74 0;
> #P user number~ 252 192 309 207 9 3 2 2 0. 0. 0 0. 50 0.;
> #P newex 275 107 75 196617 wave~ Window;
> #P newex 252 128 33 196617 *~ 0.;
> #P newex 252 163 72 196617 record~ Audio;
> #P toggle 166 94 29 0;
> #P user number~ 29 192 86 207 9 3 2 2 0. 0. 0 0. 50 0.;
> #P newex 52 107 75 196617 wave~ Window;
> #P newex 29 128 33 196617 *~ 0.;
> #P newex 29 163 72 196617 record~ Audio;
> #P newex 176 289 105 196617 buffer~ Window 1000;
> #P newex 80 289 95 196617 buffer~ Audio 1000;
> #P comment 194 94 48 196617 toggle me;
> #P comment 14 211 116 196622 This side provides sync;
> #P fasten 13 0 5 0 166 79 34 79;
> #P connect 8 0 4 0;
> #P connect 5 0 4 0;
> #P connect 4 0 7 0;
> #P connect 6 0 5 1;
> #P connect 6 0 15 0;
> #P hidden connect 14 0 13 0;
> #P connect 9 0 18 0;
> #P fasten 13 0 10 0 166 79 257 79;
> #P connect 8 0 9 0;
> #P connect 10 0 9 0;
> #P connect 9 0 12 0;
> #P connect 19 0 11 0;
> #P connect 11 0 10 1;
> #P connect 11 0 16 0;
> #P pop;
>
> ------------------------------
>
> Date:
Tue, 14 Dec 1999 17:51:29 -0800


> From:Timothy Place <tim_place@YAHOO.COM>
> Subject: mute~/pass~ enable/pcontrol MSP etc.
>
> Hi again...
>
> I wanted to ask if there was a way to truly turn off a
> portion (patcher) of an MSP audio-signal network. The
> Mute~/Pass~ combo, or the enable/pcontrol combo seem
> to turn off the mathematical processing inside of
> objects, however the Signal-Patch-Cords are all still
> active and seem to be called by MSP at 44.1KHz (the
> unchangable sampling rate of a B/W G3).
>
> Of the methods I used to confirm that this happens is
> using Trace. Trace steps through every single patch
> cord in every single "disabled" patcher or sub-patch.
>
>
> I'm working on a very large piece for MSP & Alto Sax,
> for which I want to totally shut down non-current
> sections of the piece. On a G3/450MHz 50% of the CPU
> is being burned when *All Sections Are Disabled
> (enable 0 1)*. This means that there are no (zero)
> active objects. It is difficult to do much when an
> inactive patch is burning so hot with no way to shut
> down patch cables etc.
>
> My probable solution will be to use pcontrol/load and
> thispatcher/dispose throughout the piece - however all
> of the opening and closing Max patches from disk
> during
a live performance is a little scary.
>
> Any confirmations/other solutions/etc.
>
> Thanks,
>
-Tim
>
>
> =====
> ~ Timothy A. Place
> ~ someplaces@yahoo.com
> ~ http://kromo-zone.tripod.com/tap/
> __________________________________________________
> Do You Yahoo!?
> Thousands of Stores. Millions of Products. All in one place.
> Yahoo! Shopping: http://shopping.yahoo.com
>
> ------------------------------
>
> End of MAX Digest - 13 Dec 1999 to 14 Dec 1999 (#1999-357)
> **********************************************************
>

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

Date:Wed, 15 Dec 1999 15:56:18 +0900
From:christophe charles <charles@TKD.ATT.NE.JP>
Subject: Re: Your coolest MSP patch. Be a superstar.

>includes only stock max/msp objects

Hello,
maybe it's also time to expand the notion of "stock objects" ?

-
christophe charles
110-0001 tokyo taitoku yanaka 3-21-5-303


t/f 813.5685.6566 mobile 81908.5965264

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

Date:Wed, 15 Dec 1999 17:56:12 -0500
From:Jeff Mann <jefman@UTCC.UTORONTO.CA>
Subject: Re: Max in pop culture

Dominic Robson <dominic_robson@BIGFOOT.COM> wrote:

> The instrument takes the form of a long 5 ft metal tube
> incorporating a 2.5 ft slider. A digital audio sample is mapped along the
> length of this slider and allows the performers to access/play the
> granulated sample.

Curious to know how the long slider sensor was constructed.

I helped to develop a similar instrument which was used by Monty Cantsin
at a recent performance at USINE-C in Montreal. It uses the drawers of a
filing cabinet to granulate QuickTime video. We used bright LEDs on the
backs of the drawers, and CDS photocells on the back wall of the
cabinet. This gave a (suprisingly linear) change in resistance, which is
read by a Basic Stamp II, and sent out as a MIDI controller value. The
QuickTime movies play in short loops or grains, with one drawer
controlling the loop size, and the rest mapping the loop start point
along the length of the drawer.

The sensors are sometimes a bit unpredictable, given changing ambient
light levels etc., so we're looking for something to replace them...
--
Jeff Mann - Information Consumer ___O___O__= -- >
"Tapping one's toe in time with a piece of music while sitting on
a modern carpet can induce +/-10 volt potential change on a can of
Spam five feet away."- The Amateur Scientists' Bulletin

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

Date:Wed, 15 Dec 1999 23:05:34 +0000
From:david stevens <david@RESONANT.DEMON.CO.UK>
Subject: positional message to subpatch

hi all,

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?

thanks

david

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

Date:Wed, 15 Dec 1999 18:12:55 EST
From:Eric Lyon <Eric.Lyon@DARTMOUTH.EDU>
Subject: tracking vocoder

I missed the post this is in response to, but several f.r. moore =
style processors have been implemented by me and Chris Penrose. =
(see http://arcana.dartmouth.edu/~eric/MAX/FFTease/) It was =


surprisingly simple to implement once we adopted a design =
limitation to automatically set the FFT size to MSP I/O vector size =
x4 in our externals. One nice aspect of the Moore model is to =
provide a choice between oscillator bank or IFFT resynthesis. Both =
methods are used in the various externals of FFTease.=20

Regarding live time-stretching, I did design an external, =
residency~ (not in the current release) which captures a series of =
FFT frames into an internal buffer, which can then be resynthesized =
in any order or speed. I was hoping that I could sample and play =
at the same time with this external, but kept on crashing my =
computer. So for now residency~ has to sample first, then play back =
at will. Theoretically it is indeed possible to time stretch in =
"realtime" as Luke described. Perhaps this can even be implemented =
directly in MSP using non FFT granulation.

Eric Lyon

>>
this is just my gut reaction to your problem, but i'm guessing that =
a
true-to-form f.r. moore style phase vocoder would be kind of tricky =
to
implement given msp's real-time design. at least as a patch (you =
might be
able to code up an external to do this -- that certainly _would_ be =
a
question for the formidable professor lyon, though).

...

if you plug a sample stream into an fft~ object to prepare for an
oscilator bank resynthesis that uses time-stretching you have to =
deal with
the fact that the fft~ object is going to keep outputting new =
windows of
data every 1024 (or 2048, or whatever) samples. you'd have to =
buffer the
samples coming out with some sort of fairly convoluted =
tapin~/tapout~
scheme and eventually you'd probably run out of memory. you could
probably implement a time-stretching algorithm in max provided you =
set a
finite input duration into the vocoder patch and then forced msp to =
just
flush everything and start over again.=20
>>

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

Date:Thu, 16 Dec 1999 02:45:47 +0100
From:Sukandar Kartadinata <sk@ZKM.DE>
Subject: Re: Kyma ?

>By thew way, has anybody worked with the Creamware Scope platform and the
>SDK kit and will share infos?

hi reinHOLD,
I worked with Creamware's Pulsars and their then available "low-level SDK"
which allowed me to code a DSP spatialisation module but w/o any GUI
(btw, it was used at this year's Donaueschinger Musiktage, so maybe you
even heard it in operation)

that SDK was a real p.i.t.a. with lots of version mismatch problems, but
with some help from CW support I eventually got things working

the "real SDK" is a big, big beast that lets you do a million things, but


when it comes to ease of use it's a far cry from MAX/msp. My feeling was
that the guys are a little obsessed with the GUI part of their software. I
could only have a glimpse at all the features though as I had to
concentrate on the actual DSP coding. And I have heard different stories
about the overall reliability and "smoothness" of the system....

the whole thing is way too expensive of course


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sukandar Kartadinata
Custom Technology for the Arts
Hagenauerstr. 6, 10435 Berlin, +49-30-44051219
http://members.xoom.com/Sukandar/
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

Date:Thu, 16 Dec 1999 02:45:49 +0100
From:Sukandar Kartadinata <sk@ZKM.DE>
Subject: Re: Max in pop culture

>The sensors are sometimes a bit unpredictable, given changing ambient
>light levels etc., so we're looking for something to replace them...

I've often used ultrasound to measure distance, although there's a lower
limit with that approach
I also had good results with a "Dimension Beam"-like infrared sensor which
worked great at small distances (specified at 10-80cm). Not too expensive
(DM 37), and with an integrated microcontroller that spits out 8-bit serial
data (not really MIDI-compatible though :).
The catalog doesn't tell me who makes it, but it's got 'GP2D02' written on
it, so that might help tracking it down in Canada.

and then there's faders


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sukandar Kartadinata
Custom Technology for the Arts
Hagenauerstr. 6, 10435 Berlin, +49-30-44051219
http://members.xoom.com/Sukandar/
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

End of MAX Digest - 14 Dec 1999 to 15 Dec 1999 - Special issue (#1999-358)
**************************************************************************