Subject: MAX Digest - 15 May 1999 to 16 May 1999 (#1999-148)
Date: Mon, 17 May 1999 00:00:05 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 6 messages totalling 228 lines in this issue.

Topics of the day:

  1. 4-8 channel DSP patches?
  2. tapout rant
  3. tapin~ tapout~ problems (2)
  4. Sensors (2)

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

Date:    Sun, 16 May 1999 14:14:17 +0800
From:    KEYES CHRISTOPHER 
Subject: 4-8 channel DSP patches?

Anybody have/know-the-where-abouts-of any multi-channel (4-8) DSP
patches they'd like to pass along (other than the one in examples)?

Thanks,

Christopher Keyes

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

Date:    Sat, 15 May 1999 23:56:08 -0700
From:    dudas 
Subject: tapout rant

Lawrence Casserley writes:

> While I am on the subject, permit me one small rant! I find the named
> delwrite~ and delread~ used on the ISPW infinitely more intuitive and
> flexible. The tap link seems to be an anomaly in the system - you can't
> use send and receive (or send~ and receive~) to get around the problem.
> It seems to be a bit unreliable through inlets/outlets also. Does anyone
> else have any views on this?  Oh yes, and I don't like the names either!
> :-)>

Melvyn Poore adds:

>Maybe I'm just being sentimental, but I did find delwrite~ and delread~
>conceptually easier to implement and having to have the wired connection
>looks like an unnecessary limitation.  Is it not possible to have the
tapin~
>and tapout~ objects name their memory space, thus avoiding the wired
>connection?  I'm sure there are things involved here which haven't yet
>occurred to me...

well, I'll add my two small monetary unit's worth:

I have to admit always hated the way delread, delwrite and vd worked (sorry
Miller), and avoid send/receive like the bubonic plague.  I remember how
glad I was to see the "symbolic connection" between the MSP tap obejcts.
Also the tap objects have faster names to type (two less letters), with the
exception of the beautifully named "vd~".  Let's all be like futurists and
do away with sentiment for the ispw as far as max objects are concerned,
okay?

-R

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

Date:    Sun, 16 May 1999 11:37:12 +0100
From:    Carl Faia 
Subject: Re: tapin~ tapout~ problems

>1 - A message to change the tap times in a multiple output tapout~ does
>not work. The first tap time is not changed, and the first time in the
>list is applied to the second, the second to the third, etc. Using unpack
>works correctly....

Can you post an example, or send me one??

>2 - I am using a number of individual tapout~s in separate subpatchers
>with the tap link going through inlets. I had some trouble getting this
>to work initially, but have had a patch with four tapin~s linking to four
>voices of tapout~s in a polyphonic system running successfully for about
>a year. Now I am trying to implement a simpler system with one tapin~
>linked to eight voices in subpatchers. It was working fine yesterday, but
>today it refuses to run. If I change the tapin~ to a slightly different
>delay time it usually, but not always, then kicks in, but saving the new
>version and restarting _always_ fails. All the components are tried and
>true patchers which have been running fine for months. I have tried
>eliminating various bits of the system to see if it helps. I just can't
>see that I am doing anything wrong - and the gig is on Sunday - it was
>all going so well!  :-(>

Did you update Max before you had this problem (and after your first
succesful patch)?? Could be that there is a problem with old/new versions
of tapin~ and tapout~, or maybe a problem in the Max search path.

>While I am on the subject, permit me one small rant! I find the named
>delwrite~ and delread~ used on the ISPW infinitely more intuitive and
>flexible. The tap link seems to be an anomaly in the system - you can't
>use send and receive (or send~ and receive~) to get around the problem.
>It seems to be a bit unreliable through inlets/outlets also. Does anyone
>else have any views on this?  Oh yes, and I don't like the names either!

I've used tapin~ and tapout~ with send and receive without any problem in
several patches. The anomaly could be in your Max enviroment.

I prefer the names used in MSP for the various objects that have the same
or similar funtions on the ISPW, if only to differentiate the two programs
(in this case, I think that using 'tapin' and 'tapout' for a tap delay line
is pretty intuitive).

Carl

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

Date:    Sun, 16 May 1999 17:17:48 +0100
From:    Rob Godman 
Subject: Sensors

Dear all,
As a twice-over virgin first-timer to the Max electronic mailing list
(first time to the list  - .......... and @virgin.net!) I hope this gets
a reading!

I'm currently working on an installation in collaboration with an
architect with the aim of creating an 'acoustic space' that is capable
of evolution.  In very simple terms, I'm hoping that it will be possible
for a viewer to control their own acoustic space by their own movements
(they go to the centre of a room and a sound is close to them; to the
edge and it's far away etc.).
So, I'm after a sensor that will pick up their movements (which sends
MIDI data that is transferred via 'Max' into wet/dry, reverb decay, LP &
HP filters of an effects unit).  The sensor needs to know how far away
someone is from it.
Not being the greatest enthusiast of interactive music, the idea is that
I maintain control over all my musical structure/ideas but the viewer is
capable of controlling the space that the music is heard.
The question is........  I don't know a great deal about sensors.  Can
you offer some advice?  What's available?
I'm proposing 5 sensors altogether, one with a range of about 5 metres
and the other four much more local (all detecting distance I think).
At the moment, I'm using Max, 2 effects units (with real-time MIDI
parameter control) and a sampler as the sound source provider.  The
sampler may be replaced with MSP on-site.
--
*******************************************************************
Rob Godman
Composer

4 Mill Close Wotton-under-Edge Gloucestershire GL12 7LP United Kingdom
T. (44) 01453 521895
F. (44) 01453 844447

For more information (if slightly out of date......)

http://www.composer.co.uk/musicnow/composers/godman.html
*******************************************************************

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

Date:    Sun, 16 May 1999 14:47:54 -0400
From:    Christopher Murtagh 
Subject: Re: Sensors

At 5:17 PM +0100 5/16/99, Rob Godman wrote:
>The question is........  I don't know a great deal about sensors.  Can
>you offer some advice?  What's available?

 At the risk of sounding like a broken record to others on this list...
Have you looked into the iCube (http://www.infusionsystems.com)? Also,
IRCAM has a competing device called AtoMIC
(http://www.ircam.fr/produits/techno/real/Atomic-e.html).

The up side to both of these devices is that they seem to be pretty good
quality and they are multi featured (I can vouch for the iCube, but I have
never used the AtoMIC). The down side is that they both cost a fortune
(relatively that is - about $600 US for the iCube, and about $800 US for
AtoMIC).

 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.

 Using any of these devices pretty much assumes that you have a basic
understanding of electronics and that you know how to use a soldering iron.
If this doesn't seem comfortable to you, you might want to ask some help
from a fellow Maxer. I would be willing to lend a hand, and there is also a
list of qualified people at Johnny DeKam's excellent Max page
(http://www.node.net/MAX/  - click on the people link).

I hope this is enough to get you started.

Cheers,

Chris

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

Date:    Sun, 16 May 1999 17:26:04 -0700
From:    David Zicarelli 
Subject: Re: tapin~ tapout~ problems

Melvyn Poore  writes:

>Maybe I'm just being sentimental, but I did find delwrite~ and delread~
>conceptually easier to implement and having to have the wired connection
>looks like an unnecessary limitation.  Is it not possible to have the
tapin~
>and tapout~ objects name their memory space, thus avoiding the wired
>connection?  I'm sure there are things involved here which haven't yet
>occurred to me...

I like the patch cord connection because it lets you
use delay lines in abstractions that don't interfere
with each other if you make more than one copy of the
abstraction. For instance if you make some kind of
delay line "effect" as an abstraction and you want to use
two of them, you'd have to use the #0 hack to get a
unique name for each tapin~-tapout~ pair. Having said that,
I'm willing to investigate whether tapin~ and tapout~
couldn't be flexible enough to work in both connection
and named modes depending on the arguments you gave the
objects.

There was a bug in controlling tapout~ objects with multiple
inlets that I have fixed. It will be available in an MSP
update I'm preparing.

David Z.

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

End of MAX Digest - 15 May 1999 to 16 May 1999 (#1999-148)
**********************************************************