Subject: MAX Digest - 17 May 1999 to 18 May 1999 (#1999-150)
Date: Wed, 19 May 1999 00:00:03 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 18 messages totalling 691 lines in this issue.

Topics of the day:

  1. Any experience with G3 accelerator cards? (4)
  2. delay line features
  3. tapin/out (2)
  4. tapin~/out~
  5. Sensors and thorny interactivity
  6. MAX Digest - 16 May 1999 to 17 May 1999 (#1999-149) tapin~/tapout~
  7. trigger rater
  8. MAX Digest - 16 May 1999 to 17 May 1999 (#1999-149)
  9. dvd control
 10. sensors (3)
 11. IAC
 12. PAiA Midi Brain..

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

Date:    Tue, 18 May 1999 00:00:21 -0500
From:    "Brian K. Shepard" 
Subject: Re: Any experience with G3 accelerator cards?

>Hi,
>I was thinking of converting my old PowerMac 8500/120 MHz to a powerfull
MSP
>workingstation with the help of one of those G3 accelerator cards. The G3
>300MHz with 1Mb cache seemed to me to be good value for money.
>Did any of you try something similar? I'm interested in having your
comments
>as I'm not sure if there is any incompatibility with either MSP or
>Digidesign ProjectII which serves as my interface.
>Thanks for sharing any bad or good experiences,
>
>Todor Todoroff

FWIW:  The much touted Mac OS X will only run on an actual G3, not a
machine with a G3 accelerator card.  You might keep that in mind as the
latest buzz has OS X being released in August.  Of course, thats just buzz!
I'll believe it when I actually see it.

--Brian

Dr. Brian K. Shepard
University of Oklahoma
School of Music
bkshepard@ou.edu
http://music.ou.edu/faculty/shepard/

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

Date:    Mon, 17 May 1999 22:32:44 -0700
From:    David Zicarelli 
Subject: delay line features

Melvyn Poore  writes:

>There is an important point here about performance practice: I would like
to
>be able to say at a certain point, yes, I want to turn that sound - or
>sequence, etc. - into a sample and play it as if I had originally recorded
>it as a sample instead of the short-lived delay buffer that it is.

Well, if you use buffer~ to do your delay lines, then you
would have this option, or just keep recording the stuff going
into a tapin~ into a record~ object. Attempting to do a buffer
freeze with tapin~ gives me a bit of headache just thinking about
it. Adding a set message to tapin~ is equally problematic since
the implementation of these objects is not the same as a pointer
to some data like buffer~--it's a pointer plus a recording
point.

You can do anything you can do with tapin~ and tapout~ using buffer~,
record~ and play~--the only problem is that you will get clicks
if you read over the seam between the old and new material,
which is simply impossible with a delay line. record~ (or some
other object) needs to be able to crossfade betwen the new and
old material so this seam isn't apparent. This too is computationally
very expensive, but it will make a fair number of people happy
so I am planning on doing it.

David Z.

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

Date:    Tue, 18 May 1999 10:25:45 +0200
From:    Carl Faia 
Subject: Re: tapin/out

Lawrence,

I'm not sure what you mean by having a send and receive that works with
tapin/out~ objects. They do work...

____________________

max v2;
#N vpatcher 50 40 462 370;
#P newex 274 96 83 196617 r to_tapout_buff;
#P toggle 215 185 15 0;
#P message 53 24 28 196617 open;
#P toggle 17 31 15 0;
#N sfplay~  1 16384;
#P newobj 53 47 42 196617 sfplay~;
#P newex 239 213 45 196617 dac~ 1 2;
#P newex 239 33 83 196617 r to_tapout_buff;
#P newex 53 108 83 196617 s to_tapout_buff;
#P newex 274 120 69 196617 tapout~ 1750;
#P newex 239 57 63 196617 tapout~ 250;
#P newex 53 83 63 196617 tapin~ 5000;
#P connect 8 0 6 0;
#P connect 7 0 6 0;
#P connect 6 0 0 0;
#P connect 0 0 3 0;
#P connect 4 0 1 0;
#P connect 1 0 5 0;
#P connect 9 0 5 0;
#P connect 10 0 2 0;
#P connect 2 0 5 1;
#P pop;

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

Date:    Tue, 18 May 1999 10:17:30 +0100
From:    Lawrence Casserley 
Subject: tapin~/out~

Melvyn wrote:

>1. First the simple, but practical revision: if the patch cord requirement
>were to disappear, one would not have to worry about  keeping tapin~ and
>tapout~ in the same place.  The advantages of this will become clear below.

This is execatly what causes me grief - it is really impractical to keep
them in the same place.
>
>2. If tapout~ were to take an argument for the buffer name, it would be
>possible to  have a command to change the name - just as already exists in
>play~ and groove~, for example.  Then one could - with less programming
>(less objects (less cycling overhead)) - switch between delay buffers.  The
>buffers might well be in quite different parts of the program - including
>abstractions, of course.

I have one patch where I have four delays and eight voices reading the
delays - selecting which delay to read is a function of the voice. I
tried everything to select the tapconnects, but they only work with
direct connections. The solution? Every 'voice' subpatcher has four
tapout~s connected via inlets to the four tapin~s. It works, but what a
mess!
>
>3. A very useful extension of the tapin~ object would be a kind of freeze
>function where recording would stop but reading continue. (if one turns off
>dsp and then on again - the pointers stop running, then it takes up reading
>where it left off, usually adding a mild click).  I have no idea how
>practical this is in terms of adding the behaviour to tapin~, but maybe it
>could be implemented in the form of dynamically-created buffer~ and play~
>objects (where the name of the buffer is passed as an argument to the
freeze
>command sent to tapin~ or, better still, the name is generated
automatically
>from the original tapin~ parameter).  An option to make the
>delay-converted-to-sample durable or not could be invoked by a parameter.
>Where to create the new objects?  Hmm... I guess next to the original
>tapin~s...

I have done this by having a record~ connected to a tapout~ set to the
maximum delay time. If I fire that it simply empties the current contents
of the delay into a buffer~ and leaves the delay running. But of course
if you are running out of memory........

I too am unsentimental - I am just saying what works best for me!

Best

Lawrence

--
Lawrence Electronic Operations - Tel +44 1494 481381 - FAX +44 1494 481454
Signal Processing for Contemporary Music - email leo@chiltern.demon.co.uk
http://www.chiltern.demon.co.uk

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

Date:    Tue, 18 May 1999 11:11:54 +0100
From:    Lawrence Casserley 
Subject: Re: tapin/out

Carl Faia wrote:

>I'm not sure what you mean by having a send and receive that works with
>tapin/out~ objects. They do work...

By gosh you're right!

All I can say is, when I first tried it, must have been over a year ago,
it definitely _didn't_ work - I just assumed that was a limitation of the
system and got on with life. And since I was very busy at the time I
never got round to enquiring about it. I tried both s/r and
send~/receive~ and neither worked. I just assumed that tapconnect was
neither a signal nor a control, but something special.

Presumably this is something that got fixed in between, and since I
didn't try it again, I didn't know! Thanks for pointing it out. That
certainly will help cut down the patchcord forest in many cases.

Unlike Richard - I much prefer send and receive to patchcord forests. I
use lots of them. In an earlier post I talked about naming conventions -
these make patches much more understandable IMHO.

Best

Lawrence

--
Lawrence Electronic Operations - Tel +44 1494 481381 - FAX +44 1494 481454
Signal Processing for Contemporary Music - email leo@chiltern.demon.co.uk
http://www.chiltern.demon.co.uk

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

Date:    Tue, 18 May 1999 14:54:41 +0100
From:    Rob Godman 
Subject: Sensors and thorny interactivity

cahen.sefton.green@WANADOO.FR>
Subject: position sensors

>Why don't you try Eric Singer's videoin for a start
>http://www.ercisinger.com
Thanks for that, I'll look into it.
>the only problem
>(a P.I.T.A., is that it only works on 10% of the actual machines)
What does this mean?

>So what esle do you think is interactiv music ?
>I suppose your structures are time structures, which I reckon isn't easily
compatible with real time interaction.
Partly, but this has a lot to do with why I'm interested in allowing the
viewer to alter the space they are in, and not the linear structure of
the work that I produce.
I have no idea (or wish) of how to define 'interactive music'.  Many
interactive works that claim to be musical (I have even less wish to
define musical, coward that I am!) replace any musical substance that a
composer may wish to input.  Too many times, I have heard (from rather
experienced practitioners, that again I'm too cowardly to name, although
I haven't spotted them on the Max list!) that it is the issues of
interactivity between machine and user that is important (which is fine)
and not the music that is produced (not fine and a big cop out).
The beauty of Max, as far as I'm concerned, is that it hasn't pushed me
down a particular route, even though I've heard it decribed as an
interactive composition tool.
By the way, I've certainly heard plenty of Max pieces that have musical
substance  - many by people on the Max list  - he creeped (crept
possibly)!
Best wishes,
Rob

From:    Garth Paine 
Subject: Re: sensors

I would like to suggest that you also look at the ADB I/O which is
relatively inexpensive and works well within MAX.  I have used a couple
in
commercial jobs, and they prove very reliable.

http://www.bzzzzzz.com

Cheers,

Garth

Hi Garth
Thanks for this also.  Again, this is something I know nothing about.

Rob

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

Date:    Tue, 18 May 1999 10:27:13 -0400
From:    Christopher Murtagh 
Subject: Re: Any experience with G3 accelerator cards?

On Tue, 18 May 1999, Brian K. Shepard wrote:
> FWIW:  The much touted Mac OS X will only run on an actual G3, not a
> machine with a G3 accelerator card.  You might keep that in mind as the
> latest buzz has OS X being released in August.  Of course, thats just
buzz!
> I'll believe it when I actually see it.

 Thankfully there is one small exception to this rule. The XLR8 G3Z (ZIF)
upgrades are supposedly 100% OS X compatible. So use owners of lowly first
generation G3s can upgrade to 400Mhz 1MB backside cache machines. Still
pretty expensive ($989 US), but cheaper than a new B&W G3 (plus they are
ugly :).

Cheers,

Chris

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

Date:    Tue, 18 May 1999 10:43:55 -0400
From:    Christopher Murtagh 
Subject: Re: Any experience with G3 accelerator cards?

On Tue, 18 May 1999, Christopher Murtagh wrote:
>  Thankfully there is one small exception to this rule. The XLR8 G3Z (ZIF)
> upgrades are supposedly 100% OS X compatible. So use owners of lowly first
> generation G3s can upgrade to 400Mhz 1MB backside cache machines. Still
> pretty expensive ($989 US), but cheaper than a new B&W G3 (plus they are
> ugly :).

 Oops, I quoted the wrong price - this was the price I saw yesterday,
looks like they were updated. A 400Mhz 1M Backside is now only $689 US!

Cheers,

Chris

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

Date:    Wed, 19 May 1999 07:50:59 -0800
From:    anechoic audio engine 
Subject: Re: Any experience with G3 accelerator cards?

Todor
I'm using a Powerlogix G3 400 in a PowerCenter 120 with Max/MSP and a AMIII
card...no problems so far except that SDII 2.8.2 and Sound Edit 16 don't
work (could be that I am using the cards backside cache and removed the L3
cache from the 120's motherboard)...SDII 2.8.3 *does* work (have to buy
this upgrade for $40 from Digidesign) on the G3 card...the price was
recently dropped on the G3 400 card so check out the Powerlogix webpage for
more details 
**btw: their customer service is top notch: the CustService guy spent 20
minutes helping me hotrod my machine by getting it to clock at
442MHz...they also got very high ratings in the Feb 1999 issue of MacWorld
magazine...I recommend this company highly...
good luck!
KIM

__________________________
kim.cascone
sound.designer...composer

kim@anechoicmedia.com
http://www.anechoicmedia.com

Out Now:
                blueCube( ) (Rastermusic)
                nb2e_Vortex.aiff (Mille Plateaux)
                vortexShedding (Caipirinha Music)

"the medium is no longer the message, the tool has become the message"

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

Date:    Tue, 18 May 1999 09:18:58 PDT
From:    Chris Tignor 
Subject: Re: MAX Digest - 16 May 1999 to 17 May 1999 (#1999-149)
tapin~/tapout~

In addition to Melvyn Poore's suggestions for new tapin~ features related to
"instant" composition, including the "stop recording/continue playing"
feature, (switching between two taps achieves this, I believe) I would also
find extremely useful a feature which would allow certain outlets from
tapout~ to be disabled on the fly.  This would allow an easy way for the
interesting rhythyms one can create from a single source to tapin~ to
constantly change, without having to reassign values and get, at best, that
tape flange zip.  If there was even a way to "flush" the buffer completely
and make the entire unit stop outputing completely while new info is still
being fed in perhaps, that would also allow greater flexiblity- no longer
would one have to "wait" for a tapout~ sequence to finish its routine, etc.
etc.

Chris Tignor

_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

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

Date:    Tue, 18 May 1999 09:51:14 -0600
From:    Steve Anderson 
Subject: trigger rater

         Reply to:   trigger rater
>> Does anyone know of:
>> a sensors-to-MIDI unit that gives >8 bit conversion, at a
>> respectable sample rate (perhaps packing all its sensor channels into
a
>> SysEx for efficient MIDI bandwidth);

One easy-to-use alternative to rolling your own;
I do this with an Alesis D4 pad-to-midi unit. The D5 has 16 chnls, more
features & sounds.
The bit depth (16 bit resolution) is one issue, the (fast) conversion
rate is another feature.
I don't think packing into Sysex will help. Simultaneous individual
note-ons work for me & max.
There is very low latency even when all 12 inputs fire at once. The
DrumKats are good, too.
The nice thing about the D4 is the inputs have individual velocity curves
(aka ADSR).
So, for instance, a miked bongo can have a different attack than a stick
hitting a piezo sensor.
These are commonly used to replace drum sounds from a taped signal source
or to "midify"
analog drum tracks. With triggers, you often need to compress or expand
velocity to map
to the desired response. Of course, they work with any voltage and can
trigger any sound.
They cost about half-way ($380) between the Paia kit & the C-cube unit.

steve "happy customer" anderson
laser dreams

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

Date:    Tue, 18 May 1999 17:19:00 +0200
From:    jose manuel berenguer 
Subject: Re: MAX Digest - 16 May 1999 to 17 May 1999 (#1999-149)

hi Doenado

you can send/receive MIDI information from Bstamp to/from your Mac via
serial port, indeed. its highest baud rate is 38400 . this is not very
faster than MIDI rates (33000)

to reach faster baud rates you should use other pic's.

i-cube's microcontrolles is faster and accuracy can be set to 12 bit. 2^12
= 4096 different values.

with serial communication you can eassely perform any accuracies,  but as
you increase the amount of bits coding your information, time to transmite
it becomes greater

cheers

jose manuel

>Date:    Mon, 17 May 1999 18:25:46 +0100
>From:    "=?iso-8859-1?Q?Do=E9nado?=, el Ur" 
>Subject: Re: Sensors
>
>>  I have just ordered a kit from PaIA which looks quite promising
>> (http://www.paia.com/midibrn.htm). This device only has 8 voltage to Midi
>> converters on it, so it is a bit less powerful than both the iCube and
>> AtoMIC, but it also costs way less ($85 US and you have to build it
>> yourself). If you want, I can give it a review once I get it and have it
>> working.
>
>I am working with a PAiA MIDIbrain successfuly with photocells,
>flexsensors, etc.
>The real limitation common to all this devices is the little 128 values
>of MIDI
>A more useful device would connect to Max via the serial object. This
>can be done
>with a BasicStamp, for example. Any suggestions or experiences this way?
>--
>
>
>
>d
>*

___________________________________________________________________________
Jose Manuel Berenguer

Coclea.
tel/fax 34-93-2857150.  tel/fax 34-972-795002
jmcoclea@intercom.es http://usuarios.intercom.es/coclea

Orquestra del Caos. tel 34-93-3064137. fax 34-93-3064113
caos@cccb.org http://www.cccb.es/caos

nosotros tambien 3000ya.com http://www.3000ya.com
___________________________________________________________________________

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

Date:    Tue, 18 May 1999 18:17:10 +0200
From:    jose manuel berenguer 
Subject: dvd control

Matthew,

thank you very much for your information. i think i can contact Pioneer. in
fact this afternoon i'll search this model on the net. but if you believe
you can send me this information by e-mail i guess i'll have it faster.
anyway i'm also very interested on how you manage things in your patch. so
if you want send me it, it should be very usefull for me.

by the way, could i ask you if haven't you had troubles or system crashes
when running max to control environnements or devices such as dvd or cdrom
for a long time?

___________________________________________________________________________

I've had success using the Pioneer DVDv7200.  The machine code is available
from their tech support.  Use those with the serial object and you're set!
The problem (maybe) is that the players are only accurate to 3 frames -
sometimes more, so if you are needing extremely precise control this may or
may not work for you.  Let me know if you are having trouble getting through
to Pioneer, I can send you the pages you need+the patch I used to control 5
of 'em.

____________________
Matthew Biederman
SFMOMA
151 Third Street
San Francisco, CA 94103
v:(415)357-4129
f:(415)357-4158
mbiederman@sfmoma.org
_______________________
___________________________________________________________________________

___________________________________________________________________________
Jose Manuel Berenguer

Coclea.
tel/fax 34-93-2857150.  tel/fax 34-972-795002
jmcoclea@intercom.es http://usuarios.intercom.es/coclea

Orquestra del Caos. tel 34-93-3064137. fax 34-93-3064113
caos@cccb.org http://www.cccb.es/caos

nosotros tambien 3000ya.com http://www.3000ya.com
___________________________________________________________________________

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

Date:    Tue, 18 May 1999 11:39:26 PDT
From:    v a u g h n 
Subject: sensors

>>So, I'm after a sensor that will pick up their movements.
>>The sensor needs to know how far away someone is from it.

the best solution to this that i have found is david rokeby's  Very Nervous
System.  far from an $85 solution, the vns is an amazing device that allows
for one to connect a video camera for use as a sensor.  the hardware version
accepts a bnc signal from any camera, (low light black and white security
camera seems to be the best setup) and outputs via a scsi cable to an object
in max called vns.  the object can be configured to extract many types of
info from the vns.  my favorite being 'headtracking'  where the vns will
track multiple 'heads' in the space and output information on each of them
simultaneously.  a software version is also available that uses a signal
from a video card and uses the cpu to do the processing.

>>which sends MIDI data

max can do that no sweat

for more info:
http://www.interlog.com/~drokeby/home.html

good luck,
vaughn~

_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

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

Date:    Wed, 19 May 1999 07:08:19 +1000
From:    David Rodger 
Subject: Re: sensors

Chris Murtagh wrote:
> I'm not sure what you mean by 'respectable' sample rate, but the iCube
>will do 12 bit conversion.  Everything from the iCube is via SysEx, which
>can get pretty demanding bandwidth wise (with all inputs running). I'm not
>sure why the AtoMIC doesn't go into hi-res control changes at all (max is
>8 bit), especially considering the cost. There should be support for it
>even without SysEx as MIDI does support hi-res control changes (14 bit I
>think).

Indeed it is 14 bit, by combining two controller numbers 32 numbers apart,
e,g, 0 and 32, 1 and 33, etc.  Of course, one has to have gear which
understands this.  The 14-bitness is not built into every device.

If I remember correctly, the MAX objects that'll take 14-bit controllers
have names something like xctlin and xctlout.  (Sorry, I couldn't be
bothered firing up MAX right now.)  They aren;t much discussed here,
because there aren't too many products which support 14-bit controllers.

Regards, David

David Rodger:  Audio Engineer, RLSS Lifeguard Trainer, General Curmudgeon
  mailto:auricle@alphalink.com.au   http://farben.latrobe.edu.au/motion
http://www.alphalink.com.au/~auricle  http://www.alphalink.com.au/~adzohu
=========================================================================
      Stop the bloat: no auto-HTML'd e-mail, no ms-tnef, no .vcf

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

Date:    Tue, 18 May 1999 16:11:55 -0400
From:    Christopher Murtagh 
Subject: Re: sensors

On Wed, 19 May 1999, David Rodger wrote:
> Indeed it is 14 bit, by combining two controller numbers 32 numbers apart,
> e,g, 0 and 32, 1 and 33, etc.  Of course, one has to have gear which
> understands this.  The 14-bitness is not built into every device.

 The idea I was getting at was that because MIDI supports 14 bit
controller changes, a sensor device (ie. any voltage to midi converter)
should be able to use this to transmit hi-rez changes without having to
resort to SysEx. It just makes it a bit easier to parse in MAX. I guess
though if someone was using it without MAX then they would need to buy
specific gear. Then again, an iCube isn't all as fantastic without MAX
either.

Cheers,

Chris

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

Date:    Tue, 18 May 1999 13:43:52 -0700
From:    Peter Elsea 
Subject: IAC

> any on-line tutorials on using Max with other apps
>via the IAC bus out there??

It's pretty easy.
In your OMS studio setup window, double click on IAC driver. (If it's not
showing, you may have to make a new setup that has it.)
Create and name at least 2 busses. Remember that Max shows  OMS ports
alphabetically in the MIDI setup window, so give the busses names that
start late in the alphabet. Otherwise your a b c ports might get screwed up.
The busses will now appear as ports in any OMS savy application. Use one to
send data from Max and the other to bring data to max. Note that if you try
to send and receive on the same buss, feedback will occur.

About timecode to control the V1. It occurs to me that you should be able
to record some TC into a buffer and play that back? Of course it uses up an
audio channel. How about using MMC to control some device that outputs
SMPTE? Emu Darwin and a host of other hard disc audio recorders should do
the job. (Look for one that has video sync in.) As I mentioned the other
day, I'd get a PPS-2 and reverse engineer the setup software to figure out
how to control it.
Peter Elsea
Electronic Music Studios
University of California, Santa Cruz
http://arts.ucsc.edu/EMS/Music/index.html
 elsea@cats.ucsc.edu

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

Date:    Tue, 18 May 1999 20:40:37 -0500
From:    John Phillips 
Subject: PAiA Midi Brain..

I have used a PAiA MIDI brain for quite a while (4 years...) and it works
fine as a something-which makes-voltages to MIDI note device.

John

...............
               ....................................
John Phillips / sound artist: http://terragizmo.net

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

End of MAX Digest - 17 May 1999 to 18 May 1999 (#1999-150)
**********************************************************