Subject: MAX Digest - 4 Feb 1998 to 5 Feb 1998
Date: Fri, 6 Feb 1998 00:00:28 -0500
From: Automatic digest processor 
Reply-To: MAX - interactive music/multimedia standard environments
     
To: Recipients of MAX digests 

There are 8 messages totalling 213 lines in this issue.

Topics of the day:

  1. Two things
  2. wind controller and max
  3. audio PC-card for PB3400
  4. Le Mac est mort, vive le Mac
  5. CD-R Info
  6. MSP audio card support
  7. short delay lines in msp? (2)

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

Date:    Thu, 5 Feb 1998 08:26:40 EST
From:    Bob Gluck 
Subject: Two things

Thanks to several of you who responded to my question about EM PhD/MFA
programs, esp. those working with Max. I was a bit surprised not to see
anything mentioned about any programs on the East Coast. Any further
responses?

Second, in the Zip/Jaz discussion, there seemed to be just about no mention
of
SyQuests. I've been working with SyQuest 270s for about three years now.
With
the exception of one drive that arrived damaged and one other drive that
failed and needed to be reinitialized (fortunately, all data was backed up
ad
nauseum), I've had only positive experiences. My SyQuest is less portable
than
any of the media being discussed. Am I alone here (I somehow doubt it)?

Bob Gluck
Sheffield, MA
http://members.aol.com/Rjgluck

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

Date:    Thu, 5 Feb 1998 09:40:29 -0500
From:    Larry Nelson 
Subject: wind controller and max

I have an interactive piece for wind controller and max on a Powerbook
5300cs.  I use explode to follow my score and use qlist triggers to play
specific note/events.  One of the events is the triggering of digital audio
(aiff) files. I am having problems playing the aiff files.  I am using the
ichi object "aiff" but the playback 'chatters'.  I have set the system disk
cache to various settings from 192 to 1024k and changed the Max scheduler
to various settings from 1 to 15 differently but none of these attempts
change the problem.  Are there other obvious settings to change?  Or is the
problem the 5300?  I would appreciate any help.

lnelson1@swarthmore.edu

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

Date:    Thu, 5 Feb 1998 17:19:27 +0100
From:    "Dr. Karlheinz Essl" 
Subject: audio PC-card for PB3400

Dear MAXers!

All of us who own this wonderful PB3400 (or the perhaps more wonderful
G3-PowerBook) suffer from the bad quality of the built in audio I/O.
Currently it seems to be impossible to achieve real studio quality.
Especially with msp, realtime audio processing will not result in an
apropriate audio quality.

I put my hope in E-MU's "EMU8710 Audio PC Card"

        http://www.emu.com/8710.html

which is already available for Wintel boxes, and which is announced to be
ported to the Mac as well. I have been waiting for it since months, and
yesterday I sent an email to E-MU asking about the progress.

The answer was honest, but frustrating: "The cost of developing the
Macintosh drivers is just to high for the amount of Mac cards we believe we
can sell." (This statement triggered a series a deja-vu's in my brain).

Does anyone know about any other audio PC-Cards for the PB3400?

Cheers,

   Dr. Karlheinz Essl - Composer
   Vienna / Austria
   Studio for Advanced Music & Media Technology
   http://www.essl.at/

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

Date:    Thu, 5 Feb 1998 12:37:46 MST
From:    Mike Metlay 
Subject: Le Mac est mort, vive le Mac

Ben Nevile writes--

>Someone who was at NAMM told me that the one thing that was made VERY
>clear by everybody showing products there was that the Macintosh
>computer is no longer going to be supported the way it once was.  It
>seems the PC will soon take over as the leading computer platform for
>music.
>
>*sigh*
>
>bbn

This is utter bilge. I was *at* NAMM for four days, talking to every
software vendor there in my position as a music-technology magazine editor.
I have a readership that needs to know if there's a sea-change in the
industry that affects how they do music on their computers, and I saw no
hard evidence of the Mac being doomed, or even given short shrift, ANYWHERE.

Everyone who was supporting the PC and saying the Mac was doomed before,
was still doing so. Everyone who was supporting the Mac before was still
doing so. Crossplatform developers were still working both platforms. There
were a few places where the balance was tipped one way or the other, but
extrapolating them into an industry-wide trend would be an exercise in
paranoid delusion.

Sorry to come down on you so hard, Ben, but self-fulfilling prophecies of
doom really bug me.

mike

--
J. Ryait: "I am thinking of replacing my SY77 with an AN1x."
P. Nagle: "And I am thinking of replacing my pet armadillo with a kiwi
fruit."
===========================================================================
Mike Metlay - ATOMIC CITY - P. O. Box 81175, Pittsburgh, PA  15217-0675 USA
 =  atomic@tesser.com  --  http://pd.net/atomic-city   --  800.924.ATOM  =
CD orders via LOFTY PURSUITS: 800.548.6724 & 904.385.6463, FAX 904.668.5825

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

Date:    Thu, 5 Feb 1998 17:44:35 -0400
From:    Kenneth N Babb 
Subject: CD-R Info

A useful source of information about CD-Rs is available at:

http://www.cd-info.com/CDIC/Technology/CD-R/FAQ.html

Regards,
Kenneth Babb

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

Date:    Thu, 5 Feb 1998 15:38:29 -0800
From:    David Zicarelli 
Subject: MSP audio card support

Recently, people have inquired about MSP support for the Event and
Yamaha PCI cards as well as the E-Mu PCMCIA card.

While I'm not doing anything right this second to support these
cards, I am willing to support any card that can be supported. As
an American, I believe it is my duty to ensure that the consumer's
paradise of way too many options continues indefinitely.

David Z.

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

Date:    Thu, 5 Feb 1998 15:56:03 -0800
From:    David Zicarelli 
Subject: Re: short delay lines in msp?

Kevin Walker  writes:

>It seems that the minimum delay for the tapin~/tapout~ objects is twice the
>Signal Vector Size.  (Can anyone confirm this?)  What's the best way to get
>a shorter delay?  Do I need to write my own external?  Has anyone already
>written such an external?  Has anyone implemented the Karplus-Strong
>plucked string algorithm in msp?

There was a bug in the tapout~ object that caused it to have
incorrect delay line lengths when in "fixed delay" mode, which will
be fixed in an update I'm now finishing. This will probably give
you shorter delays. I've also chopped the extra vector size off
the minimum delay time, and I'm considering allowing smaller
signal vector sizes (16 and 32 samples). This will let you do
a fairly good range of Karplus-Strong.

You won't be able to do better than a signal vector size for
minimum delay if you want feedback in your delay line, unless the
feedback is internal to the delay line, as in the comb~ object.
I'm unable to provide a clear explanation for this right now, but
I will attempt one when I recover more fully from my recent food
poisoning episode.

David Z.

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

Date:    Thu, 5 Feb 1998 19:32:01 -0700
From:    Kevin Walker 
Subject: Re: short delay lines in msp?

>Kevin Walker  writes:
>
>>It seems that the minimum delay for the tapin~/tapout~ objects is twice
the
>>Signal Vector Size.  (Can anyone confirm this?)  What's the best way to
get
>>a shorter delay?  Do I need to write my own external?  Has anyone already
>>written such an external?  Has anyone implemented the Karplus-Strong
>>plucked string algorithm in msp?
>
>There was a bug in the tapout~ object that caused it to have
>incorrect delay line lengths when in "fixed delay" mode, which will
>be fixed in an update I'm now finishing. This will probably give
>you shorter delays. I've also chopped the extra vector size off
>the minimum delay time, and I'm considering allowing smaller
>signal vector sizes (16 and 32 samples). This will let you do
>a fairly good range of Karplus-Strong.

That sounds great.  Thanks.

>You won't be able to do better than a signal vector size for
>minimum delay if you want feedback in your delay line, unless the
>feedback is internal to the delay line, as in the comb~ object.
>I'm unable to provide a clear explanation for this right now, but

No explanation needed -- it's obvious now that you point it out.

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

End of MAX Digest - 4 Feb 1998 to 5 Feb 1998
********************************************