Subject: MAX Digest - 16 May 1999 to 17 May 1999 (#1999-149)
Date: Tue, 18 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 17 messages totalling 623 lines in this issue.

Topics of the day:

  1. buffer~ and filelengths (2)
  2. position sensors
  3. tapout rant
  4. tapin~ tapout~ problems
  5. tapin/out
  6. Sensors (3)
  7. sensors (3)
  8. MAX Digest - 14 May 1999 to 15 May 1999 (#1999-147)
  9. V1
 10. Any experience with G3 accelerator cards?
 11. sentimental mood
 12. AW: MAX Digest - 15 May 1999 to 16 May 1999 (#1999-148)

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

Date:    Mon, 17 May 1999 00:28:07 -0700
From:    Arne Eigenfeldt 
Subject: buffer~ and filelengths

Is there any way to message buffer~ to find out the length of a file loaded
into it (other than double clicking on buffer~ itself and reading the
numbers on top)?

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

Date:    Mon, 17 May 1999 09:39:18 +0100
From:    Roland Cahen & Ruth Sefton-Green 
Subject: position sensors

>From:    Rob Godman 
>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.

Why don't you try Eric Singer's videoin for a start
http://www.ercisinger.com

the only problem
(a P.I.T.A., is that it only works on 10% of the actual machines)

>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.

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.

Yours sincerly
Roland Cahen

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

Date:    Mon, 17 May 1999 10:42:15 +0200
From:    jvkr 
Subject: Re: tapout rant

>Let's all be like futurists and
>do away with sentiment for the ispw as far as max objects are concerned,
>okay?

No problem.
There was only one occasion where the delwrite~/read~ was really usefull
and that was that they gave the possibility to be called with the #1
variable. Thus the abillity, after defining a global buffer, of having
various references to that buffer in several subpatches (without having
to think about where they were).
(...which was usefull with granular, and maybe that is a sentiment we
have to do away with too?..)

jvkr

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

Date:    Mon, 17 May 1999 11:44:45 +0100
From:    Lawrence Casserley 
Subject: Re: tapin~ tapout~ problems

>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.

No -absolutely nothing changed. I had a working patch one day. When I
loaded it the next it failed.
i get this consistently - edit something and it's OK again - save the
working patch. Restart it again and it fails - I reckon the only solution
is to start again from scratch and see if it goes wrong again!

Incidentally - I tried replacing tapin~/tapout~  with delwrite~/delread~
and I still get the same behaviour - so it must be some wierdo in the
patch. Yesterday for the gig I used an earlier version that worked fine.

Also:

The problem, when it happens, stops _all_ output, even from another part
of the patch that links to the dacs later on.

Thanks for your input - we'll solve it!

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:    Mon, 17 May 1999 11:44:49 +0100
From:    Lawrence Casserley 
Subject: Re: tapin/out

DZ wrote:

>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.

The problem for me comes in certain applications where I am using a lot
of delay taps (sometimes more than 20) with similar control structures to
alter the tap time. It makes sense to put these in subpatchers or
abstractions. It saves a lot of patchcords not having to make that
tapconnect! I really like putting all my functional units in subpatchers,
and I really like getting rid of patchcords where I can. It seems that
there is no possibility of doing this with the tapconnect, or have I
missed something? I tend to use pretty complex patches with multiple
feedback paths, etc, so a way of getting that to a remote location
without an explicit patchcord would be really helpful. It's not a big
issue, but it would be nice :-)> With named delays in abstractions, I
always found that using #1, etc. as the delay name and making it a
parameter of the abstraction worked very well.

Yes, please, David, the flexible approach you suggested would be very
welcome. Either that, or a version of send/receive that would work with
tapconnects. I think there may well be times when the explicit link is
best; I just tend to do a lot of things where it is makes problems.

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:    Mon, 17 May 1999 12:17:01 +0100
From:    Rob Godman 
Subject: Re: Sensors

Hi Chris,
Of course, it doesn't sound like a broken record to me.  Many thanks for
your help.  I have downloaded the iCube software to have a look at.  I
understand from Infusion Systems that it is only available direct from
the States.  Does anyone know of a distributor in the UK or simply a
system I could have a look at?
Don't know anything about AtoMIC or the kit from PaIA but will look into
it.  I certainly would be very interested in the latter as the procedure
that I want the sensors for is a very simple one I suspect  - and $85 is
a little more appealing.  A review would be very useful.
Best wishes,
Rob

>  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

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

Date:    Mon, 17 May 1999 13:27:13 +0200
From:    Robert Henke 
Subject: Re: buffer~ and filelengths

Arne Eigenfeldt said in buffer~ and filelengths at 17/May/1999, Mon
09:28:07.

> Is there any way to message buffer~ to find out the length of a file =
loaded
> into it (other than double clicking on buffer~ itself and reading the
> numbers on top)?

 info~ (name of buffer)

first load soundfile than bang info...

cheers,
rob.

>
>

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

Date:    Mon, 17 May 1999 11:28:45 -0400
From:    Christopher Murtagh 
Subject: Re: Sensors

On Mon, 17 May 1999, Rob Godman wrote:
> I  understand from Infusion Systems that it is only
> available direct from the States.

 Actually Infusion Systems is a small company in Vancouver, Canada. I
think they are too small to have a distribution deal with anyone, so it
looks like you will have to deal with them directly. I have had success
emailing the people there, maybe you can arrange some sort of trial with
them or at least some contact info of their UK clients?

> Don't know anything about AtoMIC or the kit from PaIA but will look into
> it.  I certainly would be very interested in the latter as the procedure
> that I want the sensors for is a very simple one I suspect  - and $85 is
> a little more appealing.  A review would be very useful.

 As soon as I get it built I'll fill you in.

Cheers,

Chris

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

Date:    Mon, 17 May 1999 12:06:10 -0400
From:    Neal Farwell 
Subject: Re: sensors

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);
-       a sensors-to-USB unit, to avoid the MIDI bandwidth issue in
multi-sensor systems, and run tidily on new G3s... ?

Thanks,
Neal

Chris - I'd be very interested to hear how you get on with the PAiA board:

> 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.

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

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
*

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

Date:    Mon, 17 May 1999 09:40:43 -0700
From:    Matt Biederman 
Subject: Re: MAX Digest - 14 May 1999 to 15 May 1999 (#1999-147)

Jose-

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
_______________________

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

Date:    Sun, 16 May 1999 05:54:07 +0200
From:    jose manuel berenguer 
Subject: wht about dvd control? is ther any max object to do it?

hello

perhaps this question has been already asked and answered. if this is the
case, i apologize for it.

is there any object to control dvd devices from a max programm? can be
controled more than one of them?

if it exists, someone could tell me where could i get it?

many thanks

jos=E9 manuel

___________________________________________________________________________
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:    Mon, 17 May 1999 15:29:54 -0400
From:    Christopher Murtagh 
Subject: Re: sensors

On Mon, 17 May 1999, Neal Farwell wrote:
> 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);

 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).

> Chris - I'd be very interested to hear how you get on with the PAiA board:

 I think it might have arrived today, which means that I will try to build
it er... soon. When I get it tested and running, I'll give a report to the
MAX list (I have had a couple such requests).

Cheers,

Chris

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

Date:    Mon, 17 May 1999 20:46:44 +0000
From:    andy gracie 
Subject: V1

>From:    Johnny DeKam 
>Subject: Doremi V1
>MIME-Version: 1.0
>Content-Type: text/plain; charset="US-ASCII"
>Content-Transfer-Encoding: 7bit
>
>Can you post the URL for this Doremi Labs V1 device... its new to the list
-
>
>We would like to know more!
>
>Johnny DeKam
>
>Unauthorized Max
>http://node.net/

weeellll.....

i can't tell you a huge amount about it and i don't currently have a URL,
sorry.
the V1 has evolved from the early Dawn system which i also know very little
about! its a hard disk, rack mount, random access video unit, that's
INSTANT random access. according to the UK distributors, the Tyrell
Corporation (yes, honest), we are the first artists to get our grubby hands
on one (though we only have it for ten days).

its used commercially in a lot of live sports situations for those instant
playbacks and slo-mos. the V1 works off timecode - MTC,SMPTE,LTC,VITC,
whatever, and attaches its clips to that, so basically you're just playing
back the timecode with whatever is attached to it. consequently, as i have
found, its not the ideal device to use with Max, i still haven't cracked
the problem of getting i-cube information to translate into MTC cues. the
using Max to control cubase plan seems the most appropriate alternative,
but i haven't been able to get the two to talk and when cubase is running
my Max patch/es won't. very confusing and frustrating. i haven't managed to
'bluff' timecode either. any on-line tutorials on using Max with other apps
via the IAC bus out there??

so...i'm still up for suggestions and i'll post more info and a URL for the
device when i have them.

andy

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

Date:    Mon, 17 May 1999 23:15:01 +0100
From:    Todor Todoroff 
Subject: 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

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

Date:    Tue, 18 May 1999 08:30:14 +1000
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

BTW: note that I have changed email and www addresses to
activatedspace.com.au
creativeaccess.com.au will not work after June 01, 1999

,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.
Activated Space
. Composer, Sound Designer, Installation Artist
.. Interactives Designer, Exhibition Consultant
........ph. 61 3 95720133
garth@activatedspace.com.au
http://www.activatedspace.com.au
.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.

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

Date:    Tue, 18 May 1999 01:32:38 +0200
From:    Melvyn Poore 
Subject: sentimental mood

Richard Dudas wrote:

> 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?

No, its not OK (or even okay)!  I'm very seldom sentimental (if that is any
comfort to you), but I prefer sentimentality to hatred and there's no way I
wanna be like those futurists.  I am happy to read that you too can be glad.

Melvyn

----------------------------------------------------------
Melvyn Poore
Uferstrasse 166
D-53859 Niederkassel
Germany

Tel & Fax: +49-2208-911217
email: mpoore@bigfoot.de
see also:
http://www.chaconne.com/poore/
http://www.shef.ac.uk/misc/rec/ps/efi/mpoore.html

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

Date:    Tue, 18 May 1999 02:12:52 +0200
From:    Melvyn Poore 
Subject: AW: MAX Digest - 15 May 1999 to 16 May 1999 (#1999-148)

David Zicarelli  writes:

> 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.
>

I thought a little more about it and came up with the following pros.  I'll
probably come up with the contras after I've sent this message...

If I make an abstraction which uses tapin~ and tapout~ (to keep it simple
let's put them both within the _same_ patch), I have to give the parameters
as arguments in the calling object and tapin~ and tapout~ are connected by a
patch cord which at the moment is compulsory.

The basic proposal now is that the patch cord disappears by virtue of a
tapout~ object being able to reference a named memory space which is "owned"
by a tapin~ object.

I'd like to expand on this a little.

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.

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.

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...

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.  It is no
problem to implement this mechanism when the compositional decision is made
in advance of playing the sounds: instant composing, however, requires
different techniques and this is one of them that I'd like to see available.

Of the above points, the first two are serious proposals, the third, also a
serious wish, is a little more fantastic, but not at all sentimental (jetzt
ist Schluss damit).

Have a nice day.

Melvyn

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

End of MAX Digest - 16 May 1999 to 17 May 1999 (#1999-149)
**********************************************************