Subject: MAX Digest - 9 Aug 1998
Date: Mon, 10 Aug 1998 00:00:00 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 5 messages totalling 197 lines in this issue.

Topics of the day:

  1. Public sound dispersion space.
  2. All Todor Todoroff's Questions Answered Here
  3. binary babbling
  4. Sorry for my message "some additional info for programming MSP external
     objects"
  5. ASCII art

McGill is running a new version of LISTSERV (1.8c on Windows NT).
Information is available on the WEB at http://www.mcgill.ca/cc/listserv

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

Date:    Mon, 10 Aug 1998 08:46:44 +1000
From:    Garth Paine 
Subject: Public sound dispersion space.

Hi all,

I think I remember a call for works being  posting to this list last year
for a multi-speaker dispersion sound space in a public square in Europe.  I
sounded like a fantastic project which I would like to learn something from
to establish a similar space here in Melbourne, Australia in a major public
space - this project, should it be successful would also be based around an
international composition competition.

Any information will be greatfully recieved to my private email.

Thanks all.

Cheers,

Garth

See information about my new immersive interactive sound installation at
http://creativeaccess.com.au/~garth/Map1/MaP1_Sound_Installation.html

<<  ><  >>
. Composer, Sound Designer
.. Interactives Designer
... Interactive Installation Artist
.... Exhibition Consultant
http://www.creativeaccess.com.au/~garth
<<  ><  >>

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

Date:    Sun, 9 Aug 1998 16:54:07 -0700
From:    David Zicarelli 
Subject: All Todor Todoroff's Questions Answered Here

>I'm porting several external objects I wrote for the ISPW.
>There used to be a method to put the object in the dsp chain, called every
>time the dsp state was changed, where I performed some calculation
>depending on the sampling rate.
>As such a method doesn't exist in MSP and, as written on page 18 of "How to
>write MSP Externals": sampling rate and vector size may change since the
>last new instance routine, it seems that I have to check those values
>before computing each vector in the object_dsp method.
>I was wondering whether there was a way to be notified when vector size or
>sample rate where changed by the user without having to check it
>continuously.

You don't compute vectors in the "dsp" method--you do the setup.
That's the only time the sampling rate or vector size changes. Just look
in the signal structure, all the information you need is there,
sampling rate, vector size, etc.

The "perform" method does the signal processing. Until your
"dsp" method is called again, the sampling rate and vector
size remain fixed.

>Another question is how to solve a problem that may occur when sampling
>rate and/or vector size change while running a module that needs to do
>computation on a fixed amount of samples (typicaly fft and ifft)?
>I would like to adopt a standard solution.
>In the fft~ and ifft~, do you drop the past samples and start again when a
>vector size change creates a problem?

It's never a problem--see above. When processing is restarted
I just start over at the beginning of a fresh new vector.

>If I understand right, the best card regarding to latency is still the KORG
>1212I/O (Eric Daubresse from IRCAM told me that the latency was 23 ms).
>But the latency would rise with the number of buffers used.
>Does that mean that with 4 or 8 I/O channels latency would be as high as
>the Sonorus (+/- 47ms)?
>I ask this because I definately plan to use multichannel sounds a lot.

But we never have to use any more than two buffers. It works fine
at 23ms and two buffers. "Buffers" are not the same thing as "channels."
Any number of channels, two buffers per channel, 23 ms. Understand
now? I'm trying to imagine the implementation of an audio card
that would increase latency as you used more of its channels.

>>In addition, the new driver they have made available now (DigiSystemInit
>>3.3), when used in conjunction with the new MSP version, supports
>>ProTools III and ProTools Project cards.
>When you say support, does it mean simultaneous input and output?

Yes.

>If it does, I've got ProTools III and I'm curious about the latency.

That's nice, but make sure it's not a Nubus card. I should have said
Protools III PCI cards. Digi now "supports" all their Nubus hardware
with their lame-ass sound manager driver.

>Is there an optimized fft function availiable when writing external objects
>for MSP?

No. I thought about doing that, but I'm still futzing with "my"
algorithm and its interface. Maybe a 2.0 feature. And no, you
can't have my FFT source code.

>Also, when needing large object structures, is there some useful
>information availiable in order to optimise the cache use? Is the
>structure (or part of it) loaded in the cache? I ask that as I
>understood this used to be true for ISPW.

PowerPC architecture == no control over the cache. Want to know
about how to trick the PowerPC cache into behaving a bit better?
Download the Steinberg VST plug-ins developer kit, and then
after you read some of their hints, follow their advice and
start searching around on the web. And no, I don't remember the
URL for the VST plug-in kit. Look on their web site, it's there.

David Z.

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

Date:    Sun, 9 Aug 1998 22:25:22 -0400
From:    Christopher Murtagh 
Subject: binary babbling

>> There is a slight problem with the logic here. How is your algorithm
>> supposed to know what the 'True' number you wanted? Since it has no way
>> encode the number 11.8, it can't tell if that was the number you really
>> wanted and not 11.7999989989 (these are very different numbers).
>
>Well, no, they are not "very different numbers". How does the computer
>represent 18.8?  18.799998. How does the computer represent
>18.7999989989? 18.799998. They're all the same.  The machine does not
>make any difference. Now, which number is more representative, effective
>and ergonomic to the human's decimal system?

I don't think you understood my point, nor do I see why you are taking
it as a personal attack. My point was that 18.8 and 18.79998 are different
numbers, and that I would not want your (and I don't imply ownership using
the word 'your' I'm simply referring to the algorithm YOU had mentioned)
algorithm to give me 18.8 when I was expecting 18.799998. Yes, to the
computer (after truncation error) they are the same, but to me they are
different. If the computer is going to approximate something, I want to
see it within the BEST of its abilities.  (The number 18.799998413 is a
better example than the 18.799998999 I had given earlier as 18.8 would be
a better approximation).

Divide 188 by 10.000121. Please tell me you would rather see 18.7998
rather than 18.8? Also, maybe you didn't read all of my posting,
especially the part that said that I would rather see what the computer
'thinks' my number is, even if I inputed 18.8. This is especially true if
I'm doing precise calculations with that number later on. This way I can
at least have a chance to track down possibly unexpected errors due to
truncation/IEEE limitations.

Chris

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

Date:    Mon, 10 Aug 1998 04:45:47 +0100
From:    Todor Todoroff 
Subject: Sorry for my message "some additional info for programming MSP
         external objects"

Sorry for that message: I tried it out and the  "object_dsp" is called
whenever the vector size or the sampling rate is modified. I had understood
the contrary from the manual.

Todor

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

Date:    Sun, 9 Aug 1998 22:33:39 -0400
From:    Christopher Murtagh 
Subject: ASCII art

Dear Antiorp,

 Please make your contributions to this listserv positive and useful and
spare us the ASCII art. I do believe there are other public channels where
you can display them if you really feel the urge to do so. Thank you.

Sincerely,

Christopher Murtagh
MAX listserv owner

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

End of MAX Digest - 9 Aug 1998
******************************