Subject: MAX Digest - 28 Oct 1999 to 29 Oct 1999 (#1999-312)
Date: Sat, 30 Oct 1999 00:00:23 -0400
Automatic digest processor <LISTSERV@LISTS.MCGILL.CA>
Reply-To: MAX - Interactive Music/Multimedia Standard Environments <MAX@LISTS.MCGILL.CA>
To: Recipients of MAX digests <MAX@LISTS.MCGILL.CA>

There are 5 messages totalling 173 lines in this issue.

Topics of the day:

  1. X Fade
  2. The real (?) story about Opcode
  3. sampler
  4. dithering
  5. MAX Digest - 27 Oct 1999 to 28 Oct 1999 (#1999-311)


Date:Thu, 28 Oct 1999 16:54:26 -0700
From:Jeff Rona <jrona@EARTHLINK.NET>
Subject: X Fade


did someone a while back post a way to loop a soundfile with some amount of
crossfade (via a groove~ or other opbject)???

Is it in the archive?


Be, Hear, Now


Date:Thu, 28 Oct 1999 21:03:44 -0700
From:Simon Gatrall <gatrall@SLIP.NET>
Subject: The real (?) story about Opcode

This message was posted to the Opcode list:

>I received the following link from an anonymous source:

This is the most coherent, believable explanation yet, but doesn't
bode well for the future of Opcode.



Date:Thu, 28 Oct 1999 22:12:32 -0700
From:jhno <ear@SIRIUS.COM>
Subject: Re: sampler

>I've used Max a fair bit, but not MSP. Can MSP do a good job as a sampler? I
>guess the three primary difficulties would be response time, polyphony and

i think this is a very astute summary of the main problems. since msp has

supplanted my sampler, especially for live work, i'll lend you my
perspective on these issues. bear in mind that i use samplers for loops and
textures, not multi-sampled instrumental sounds...

response time: latency and timing inaccuracy are unfortunate byproducts of
the fact that we are using machines that were designed to do spreadsheets
and desktop publishing. hopefully real-time response will improve at a
hardware and operating system level, but for the time being there is a
certain amount of "sponge factor" that you have to assume is present when
using real-time software sound generation. whether this is relevant depends
on the situation. presently, in msp you can maximize timing accuracy by
doing control processing at audio rate whenever possible, keeping the i/o
vector size low, and enabling the scheduler at audio interrupt.

accurate scheduling and increased precision would be a real boon to the max
community - for example it would be great if you could have a sampling drum
machine patcher that would sync to external midi beat clock. right now the
timing isn't good enough for this to sound tight.

(i have actually worked around this issue for my own live tools, but the
solution is an inelegant hack and i don't really want to go into it right
now... :)

as far as reliability goes, i have had my share of computer problems at
gigs. this is just the nature of the beast - personal computers are complex
and fragile systems. again the problem is that we are using machines whose
primary design motivations were not realtime response and reliability. the
operating system running on your sampler's computer is a lot simpler than
mac os 8.6.

a friend of mine's powerbook just died because someone spilled beer on it
at a party. notebook audio connectors are fragile 1/8" sockets. affordable
and ergonomic multichannel audio i/o for powerbooks has not happened yet.
you have to treat a computer differently than a rugged piece of racked

on the bright side, my powerbook is still way smaller and lighter than my

most of these issues are improving. i have seen more and more musicians
incorporating computers into their live rigs - or just using a computer and
nothing else. as msp has matured, i have seem more musicians using max
successfully in a live context. i am playing a gig tomorrow night with a
jazz/groove crossover project, where i am using custom max/msp software to
play loops and textures in realtime along with live drums, bass, keys. it
works. it took a lot of work to get things to operate in a musical fashion,
but it has been worth it.

so there is my two cents from the field.

best of luck, just dig in and let the music guide you...



Date:Fri, 29 Oct 1999 09:04:35 -0400
From:Neal Farwell <nfarwell@FAS.HARVARD.EDU>
Subject: Re: dithering

David Z. -

Thanks for your reply...

>I'm not sure [a dithering patcher] can work since any MSP algorithm would
>>remain in 32-bit floating-point and then get converted to 16-bit integer.

I don't know what's inside the dac~ objects, but I guess that for each of
the 65536 possible 16 bit codes, there is a well defined range of values in
MSP's +-1.0 range. So an object could still output in MSP floats "knowing"
which integer code would result for each sample? Perhaps internally it
would limit, convert to 24 bit integer, shape to 16 bit, convert back to
floats. Then it could be used before any object that immediately goes back
to 16 bit ints (dacs, soundfile recording etc).

>There was also some debate on the list the last time this was
>brought up as to whether you can even hear the difference
>when 16-bit outputs are dithered.

The application I'm making takes a set of input samples (16 bit) and
amplitude-scales them in performance time. The required dynamic range is
large - so, if the loud sounds are loud (ie the playback speakers are set
loud for 16 bit full-scale), the soft sounds may only be occupying 8-10
bits, when quantization artifacts become audible, especially with "smooth"
sounds - but there's still 16 bit's worth of information in the
pre-conversion floating representation.

So I "feel" that some kind of dithering/noise shaping is both useful and

Best wishes,


Date:Fri, 29 Oct 1999 01:46:14 -0400
From:"||<--Daniel Arce-->||" <d_arce@ALCOR.CONCORDIA.CA>
Subject: Re: MAX Digest - 27 Oct 1999 to 28 Oct 1999 (#1999-311)

I am looking for a patch to treat IP signals and use them with MAX.
I am not yet too informed about the topic, so I can't ask for anything
more specific at the moment.


End of MAX Digest - 28 Oct 1999 to 29 Oct 1999 (#1999-312)