Subject: MAX Digest - 20 Jan 1999 to 21 Jan 1999 (#1999-23)
Date: Fri, 22 Jan 1999 00:00:19 -0500
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 12 messages totalling 404 lines in this issue.

Topics of the day:

  1. Max on PC ?
  2. audio lockup??
  3. audio lockup (bit more..)
  4. audio lockup(miraculous cure) + another question
  5. checksum, midi transmission errors, running status
  6. Winter Camping
  7. MAX Digest - 20 Jan 1999 (#1999-22)
  8. SPBRecord error
  9. msp delay~ limited
 10. Max Object List
 11. bundle available
 12. MIDI transmission problem

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

Date:    Thu, 21 Jan 1999 10:48:29 +0100
From:    Peter Castine 
Subject: Re: Max on PC ?

On around 20-1-99 13:28, Mag. Andreas Weixler said something like:

>Sometime ago a Max-Version for PC had been announced.
>Did it become true yet ?

TTBOMK, no.

NB: "PC" covers a multitude of sins. The OS for which future support was
announced is NT, not plain-vanilla Windos.

Hope this helps,

Peter

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

Date:    Thu, 21 Jan 1999 10:33:26 +0000
From:    david stevens 
Subject: audio lockup??

hi all,

thanks for the responses to my compressor request - that problem is now
solved
(and working very nicely).

i've been making some modifications to the overall patch, and something odd
has
occurred which i have so far been unable to figure out. (sorry for the long
message, i've tried to make the problem as clear as possible).

the symptom is that audio output seems to stop, the meters on the final o/p
stage bpatcher freeze. But internal audio is still running - the input
meters on
the output stage are still showing audio playing, as does another meter on a
seperate part of the patcher.

the modification was as follows: i'd added a subpatch which contained a
compressor and a looping delay line. This was fed both to the output patcher
and
the filters patcher, and worked fine. then i added a record~/buffer~
combination, so that i could store any particular sounds that i liked from
the
looping delay line and then read them using an existing bpatcher containing
a
groove~ object.

the change i made to the groove~ bpatcher (which previously only read a
single
(loaded from disc) buffer), was to add a "menu/set $1" combination so that i
could have that groove~ read any of the buffers (new and old) in the whole
patch. the output of the bpatcher goes via a gain~ fader to a send~
object.(and
then into the filterbank subpatcher)

as long as i have the groove~ bpatcher set to read the load-from-disc
buffers,
everything works ok. If i then start with the gain~ fader at 0, and switch
the
bpatcher to read the new delay o/p buffer, everything still works. But as
soon
as i fade up the bpatcher, the main output goes dead - sometimes there's
some
_loud_ distortion before everything goes quiet, which leads me to suspect
that
there's some kind of howlround going on, and the output is muting.

i'm using quite a few send~/receive~ combinations, but i've made sure that
there's no duplication of names.
the signal from the groove~ bpatcher goes through a filter bank subpatcher
before being sent to the output stage bpatcher.
audio is still being received by the output bpatcher (the meters are still
flickering), but the final meters (after the final *~ gain controls) are
frozen,
and there's no output.
i have to turn the whole patch off and on again to get output back.

does anyone have _any_ idea as to what i might be doing wrong? I've tried
using
direct connections instead of send~, and moving the buffer~s over to the
right
of the bpatcher (in case it was some kind of right-to-left problem), but the
problem still occurs.

thanks in advance!

david

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

Date:    Thu, 21 Jan 1999 11:48:53 +0000
From:    david stevens 
Subject: audio lockup (bit more..)

following on from my last missive - i've just discovered that if i use
"read" to
fill my new buffer, rather than recording into it with the record~ object,
the
(presumed) howlround/audio lock up problem doesn't occur.

so i suspect that this points to where the problem is occuring - something
to do
with a record~/buffer~/groove~ loop ??? is this kind of thing possible? or
am i
barking up the wrong tree here?

david

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

Date:    Thu, 21 Jan 1999 16:14:23 +0000
From:    david stevens 
Subject: audio lockup(miraculous cure) + another question

hi Maxers,

well - thanks in advance to anyone who tried to figure out my audio lockup
problem.I found that there seemed to be a problem with the part of the patch
that was resizing the buffer~ according to the delay line length. When i
disconnected that bit, it all worked. Strange thing is - when i reconnected
it,
after running a few tests to see if i could isolate what was going wrong
(and
finding nothing), it continued to work! (touch wood, so far so good, and so
forth). ho hum.

another question...

i'm trying out a cut down version of nobuyasu sakodnas's wonderful
granulation
patch. instead of loading from disc into the granulator's buffer, i'm again
using a record~ object to fill the buffer. This is all working fine, except
that
there's a slight repetitive glitch (especially noticeable on continuous
sounds),
which i suspect happens when the playback of the buffer loops (or perhaps
it's
caused when the record~ object is triggered). can anyone suggest how i could
smooth this out?

thanks

david

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

Date:    Thu, 21 Jan 1999 08:20:12 -0800
From:    Peter Elsea 
Subject: checksum, midi transmission errors, running status

checksum-
In my comment of yesterday, I left out the punchline, which is
[ expr ~(($i1+$i2+$i3+$i4) & 0x7f)]
Told you I was rushed.

Midi transmission errors-
No, don't turn off the warning, you need to know this.
We are now (many of us anyway, I'll bet even Nick will love the iMac) the
proud owners of machines that can leave MIDI sobbing quietly in the dust.
OMS knows this, and tries to compensate by buffering up what we send and
retransmitting it at a rational speed. When the buffer fills, that message
appears. This gives us patches that work on old Macs but not new ones. It's
time to rethink your patch, perhaps just shortening notes so that note offs
don't happen on the same tick as the next note on. Speedlim your controller
data, and try out Lqueue (found at
ftp://arts.ucsc.edu/pub/ems/Lobjects/beta_98/ ) Still beta, but seems
robust.

Running status-
I've noticed that my Studio 64xtc uses running status in a really rigorous
way, giving the effect that after a patch is running, an instrument that is
just turned on will not play any notes because it is not getting that
ctritical 0x80. The clue that this is happening is that sending a control
message or to another channel will make it work. Has anyone experienced
this with other interfaces?

Peter Elsea
Electronic Music Studios
University of California, Santa Cruz
http://arts.ucsc.edu/EMS/Music/index.html
 elsea@cats.ucsc.edu

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

Date:    Thu, 21 Jan 1999 13:58:50 EST
From:    JohnBrit@AOL.COM
Subject: Re: Winter Camping

In a message dated 1/20/99 21:00:50, you wrote:

<<
Date:    Wed, 20 Jan 1999 15:30:16 -0500
From:    Chris Murtagh 
Subject: Gone camping... (yep, in the snow).

Greetings Maxers,

 Just to let you know, I will be gone to Winnipeg for the next couple days
(doing some winter camping), so I will be unable to help with any list
problems etc.. If you have any problems it will have to wait until Tuesday.

Cheers & Happy Maxing.

Chris
>>

Aha!
Now we understand. Chris is a masochist.
JW.

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

Date:    Fri, 21 Jan 2000 11:54:10 -0700
From:    Steve Anderson 
Subject: Re: MAX Digest - 20 Jan 1999 (#1999-22)

         Reply to:   RE: MAX Digest - 20 Jan 1999 (#1999-22)
>On another note, the local supplier with whom I usually try to do
business
>in the name of local support seems to have no idea when MOTU will start
>delivering 2408s. Is this a general problem for the rest of you (i.e.
>one where a company is unable to meet product demand)? If not, who
actually
>has the things?
>shake and bake,
>Gregory

Gregory,

We have been using the 2408 with a G3 tower for a few weeks now. Supply
is limited everywhere and the MOTU elves are working overtime. We got ours
from Banana's Music in Marin, CA. Being there when the truck comes in,
with cash, and elbowing out the other customers helped. It was worth it. We
love it, it works. 24 simultaneous tracks in & out (16 real & 8 virtual
with 2 adats on fiber + more possible in the computer). We record X, Y, RGB,
SMPTE & 2 stereo audio tracks onto 1 adat.
David said the 2408 had a lower latency than the 1212. They are hard to
get because they are the latest, greatest,...it rocks!

Steve Anderson
Laser Dreams

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

Date:    Thu, 21 Jan 1999 22:27:06 +0100
From:    Thierry Fournier 
Subject: SPBRecord error

Dear Maxers,

I don't know if this question has just been asked...
I recently installed MacOs 8.5 and the adc~ doesn't work anymore,
the "SPBRecord err -200" being displayed by the Max Window each time I
turn it on.

I work with an Audiomedia III card, and the version of the Digisystem
Init is 3.4.

Thank you in advance for your ideas about that...

Thierry Fournier
Paris

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

Date:    Thu, 21 Jan 1999 17:53:42 -0500
From:    Ken Mistove 
Subject: Re: msp delay~ limited

>A question: we could not reach more delay time than 3000 ms with the
>delay~, why ?
>Which object can do up to 50 secs ore more audio-delay ?

The delay~ object uses number of samples rather than milliseconds. It's not
the first choice for long delay times. It's best used for very short delays
(with no feedback) and in filter construction.

For long delay lines use the tapin~ & tapout~ objects. You can take a look
at my patcher "Procrastination" available from my website for an example.
Also, the MSP tutorials #25 & 26 show you how to set up these types of
delay lines.

Don't forget that any objects that buffer audio are affected by the amount
of memory you allocate to Max. Feed Max lots of RAM for those long delays.

Ken

For "Procrastination" and my Listening Room:
http://www.eclipse.net/~kmistove/

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

Date:    Fri, 22 Jan 1999 00:53:14 +0100
From:    =?iso-8859-1?Q?Fr=E9d=E9ric?= Dufourd 
Subject: Max Object List

Is someone know how to update my Max Object List ? I see in my reference
manual that it is possible to add some object names to a text file named
"Max Object List". I'm working with max 3.5.9 and I don't find this file in
my max application folder... So I decided to take the "Max Object List"
text file of an older version but Max seems to do not care about it. Is
there a new way to update the very usefull New Object List Menu ? And if
so, is it possible now to create easily new category name and perhaps new
arborescence ?
Thanx...

Frederic Dufourd
CICV Pierre Schaeffer
email: fred@cicv.fr
http://www.cicv.fr

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

Date:    Thu, 21 Jan 1999 16:43:34 -0800
From:    David Zicarelli 
Subject: bundle available

This probably won't mean much to any of you, but I thought I'd
mention that the Max/MSP bundle CD-ROM is now available through
the Cycling '74 web site. Information is available at
http://www.cycling74.com/products/bundle.html

Buying the two programs together will probably represent a significant
savings over buying them separately. The bundle does not come with
paper Max manuals; instead, the manual is on the CD-ROM in Adobe
Acrobat format.

Another aspect of purchasing the bundle is that we will do
"challenge/response" authorization for purchasers, so this makes
it possible to run the software on computers without floppy disks.
Opcode has not announced it will do this yet, so it's
futile to contact them about it. However, I do know that Opcode,
like everyone else, is trying to decide what to do about the wonderful
new world of Apple hardware.

In conjunction with the bundle release, new versions of Max and
MSP will be available soon. Max version 3.5.9-8 (sorry about the
name) and MSP 1.0 release 6 will be making their appearance on the
Opcode and Cycling '74 web sites respectively. 3.5.9-8 will most
likely be the last release of Max before version 4.0 is released
this spring.

By the way, since someone asked, the Windows version of Max, to
be published by Opcode, is still scheduled for relase sometime this
summer. The current thinking on compatibility is that Max will run on
all flavors of Windows (except for CE!), but we can't really say
what's going to happen yet with the audio stuff. In any case, MSP
for Windows will not be released until well after Max is available.

David Z.

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

Date:    Fri, 22 Jan 1999 01:38:53 +0200
From:    Eirik Lie 
Subject: Re: MIDI transmission problem

>Date:    Tue, 19 Jan 1999 22:22:10 -0700
>From:    baxtrr 
>Subject: Re: MIDI transmission problem
>
>>Date:    Mon, 18 Jan 1999 22:18:41 +0200
>>From:    Eirik Lie 
>>Subject: MIDI transmission problem
>>
>>"There is a MIDI transmission problem on the Modem port. Either the
>>interface is missing, or too much data is being sent.
>>
>>The strange thing is, this only happen on
>>my PowerMac 7600 with a Studio4 interface. The same patch running on an
old
>>LC475 with a MIDI Translator II interface works just fine. The patch in
>>question are not particularly MIDI-busy, either.
>
>it could be that the interface itself is getting confused. my first
>suspicion whenever i am told that any midi activity that works with a midi
>translator ii does not work with a studio 4 is to suspect the studio 4.

You're right! I tried the Studio4 on the LC475 and the MIDI TranslatorII on
the PowerMac, and the Studio4 went down after a couple of hours while the
MIDI Translator kept going all day. Before I made this switch, I tried
unchecking the "Report serial overrun..." in the setup for the Studio4, but
this didn't help.

>ps. eirik, _12 bilder_ refuses to leave the cd changer at the cdmuse
offices.
>it is my sad duty to inform you that both you and your music completely
>rule. :)

Thanks!

Eirik Lie, Bjornerabben 9, N-0383 Oslo, Norway
Email: eirikli@notam.uio.no   -   Tel +47 22 50 23 14
Check out my CD "12 Bilder": http://home.sol.no/home/eiriklie/Visual.html

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

End of MAX Digest - 20 Jan 1999 to 21 Jan 1999 (#1999-23)
*********************************************************