Subject: MAX Digest - 19 Nov 1999 to 20 Nov 1999 (#1999-332)
Date: Sun, 21 Nov 1999 00:00:00 -0500
From:
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 4 messages totalling 309 lines in this issue.

Topics of the day:

  1. pasture time: lib
  2. USB-Audio interface
  3. What time is it?
  4. Additive synthesis control

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

Date:Fri, 19 Nov 1999 22:31:17 -0800
From:David Zicarelli <zicarell@CYCLING74.COM>
Subject: Re: pasture time: lib

sean paul zitello <spazello@MINDSPRING.COM> writes:

>But really my main question here regards Mr.
>Zicarelli, Cycling74, and Opcode and the
>relationships therein. I've always been a bit a
>bit confused as the whether or not MAX as a whole
>is still a "live" product, with new versions
>planned, consistency/standards between objects,
>etc. etc.

I think it's important for everyone to understand that there
is essentially no development connection between Max and Opcode
and that this has been true since the release of version
3.5 in late 1996, which coincided with the resignation of the last
actual Max product manager at Opcode, Butch Rovan. This was also
the point at which I resigned as an Opcode employee after they
rejected the Max-based development strategy I proposed to them.
(For those of you reading all the "who killed Opcode" stuff
floating around on the net, I will say that their passing on
my ideas was probably not such a bad thing! But that was the
point when I decided I wasn't going to be working for other
people for a while.)

This coming year Max will celebrate its tenth anniversary
as a commercial product. It will likely have a new publisher,
but the principal developer has never changed: it's still me.
During the past ten years, I have been an employee of Intelligent
Music, Opcode, IRCAM, and now Cycling '74, but I've been doing
basically the same thing all these years: working on Max.
(Let's forget about that brief time with Gibson in which I didn't
work on Max full-time.) Which is why whenever anyone asks me what's
new, I usually say not much. Currently there is more effort being
expended on Max development than at any point in its history. New
versions are being created for Windows and the BeOS; the Windows
version is nearing the alpha stage. It's been a gigantic project.

But you might wonder, why has there not been a new "upgrade" of
Max since late 1996? One reason is that Max 3.5 is perfect.

Seriously, the main reason is that Opcode was never interested
in another version until about a year ago, when they decided
to restructure the financing of the development to pay out royalties.
At that point it became possible to think about a new version,
but as you know most of the Mac platform development in recent


months has gone into broadening the runtime capabilities of Max
in the plug-in environment.

We also decided to delay the release of a new version until
after the Windows version came out in an attempt to avoid going
entirely crazy with version skew. Obviously, with almost three
years since the last upgrade, things are starting to feel a little
out of date. I do apologize for that. But I have been fixing all
the major bugs that have been reported over the past three
years, and it is my intention to continue to do so.

I am opposed to the opening up of all the Max source code because
it would essentially make my job completely miserable, and
if I'm going to do this sort of work I sure as hell am going to
enjoy it. I have the intention of opening up much more of the
source code in the future, but I am going to wait until we have
a cross-platform code base so it has usefulness for both the Mac
and Windows. My approach has been to try to maintain and document
a decent set of support routines to make it possible to extend Max
in as many directions as possible. I think if you look around at all
the wonderful things that have been done on top of the Max kernel,
you could judge this approach to have been pretty successful
at meeting precisely the same goals that are purported to be
those of opening up the source code.

David Z.

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

Date:Sat, 20 Nov 1999 12:27:18 +0000
From:david stevens <david@RESONANT.DEMON.CO.UK>
Subject: Re: USB-Audio interface

this _does_ look interesting, but what would make me very happy is a way
of getting 4 audio channels out of a Powerbook. The only way i know of
to do this is to get a Magma box, but i don't think that they have an
aadptor for the "bronze" powerbooks yet - and the USB boxes are cheaper!

Is there a way to encode 4 channel audio inside a PB and then decode it
in the outside world? or would that use humungous amounts of processing power?
has anyone tried any of the USB audio boxes with a Powerbook yet? know
anything about quality and performance hits?

david

> http://www.swissonic.com/Seiten/USB%20Studio.html
>
> called swissonic usb studio?
> costs are about 600/850 $ +tax.
> featers sounds great, but who knows ...
>

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

Date:Sat, 20 Nov 1999 14:15:43 +0100
From:Jeffrey Burns <jeff@BERLIN.SNAFU.DE>
Subject: What time is it?

After doing a bit of testing, I found that QuickTime is closer to the time
that Max calls up from the CPU than is MTC from Vision or, of course, Max's
own time. The following patch demonstrates that even QT is about 1/4 per
cent off (regardless of whether the movie or nato object is used). Can
anyone explain this discrepancy? (The midi-movie file that is read in has
exactly one note-on oer second, that is to say, when read as a text file,
the note-ons are at 1000, 2000, 3000, 4000, etc. QT plays to the IAC buss
#1 at OMS port b. Using a beige g3/233)


max v2;
#N vpatcher 90 61 375 437;
#P newex 162 250 50 196617 timer;
#P button 162 223 15 0;
#P number 162 277 57 9 0 0 0 3;
#P message 193 223 50 196617 clock;
#P newex 162 196 50 196617 stripnote;
#P newex 162 171 50 196617 notein 17;
#P message 209 115 50 196617 start;
#P message 157 115 46 196617 read;
#N movie100 100 400 400;
#P newobj 157 142 50 196617 movie;
#P message 45 277 37 196617 \$1 17;
#P newex 45 302 83 196617 line;
#P newex 77 115 25 196617 1;
#P newex 21 142 67 196617 line;
#P message 21 115 25 196617 1 5;
#P newex 21 56 50 196617 loadbang;
#P newex 45 250 72 196617 * 16.666662;
#P newex 45 223 50 196617 change;
#P message 140 88 50 196617 clock real;
#P newex 45 330 73 196617 setclock real;
#P newex 21 196 35 196617 date;
#P message 21 171 35 196617 ticks;
#P newex 21 88 41 196617 metro;
#P connect 20 0 21 0;
#P connect 20 0 21 1;
#P connect 2 2 5 0;
#P connect 0 0 8 0;
#P connect 5 0 6 0;
#P connect 1 0 2 0;
#P connect 6 0 12 0;
#P connect 21 0 19 0;
#P fasten 4 0 21 0 145 243 167 243;
#P connect 16 0 17 0;
#P connect 17 0 20 0;
#P connect 16 1 17 1;
#P connect 12 0 11 0;
#P connect 8 0 9 0;
#P connect 11 0 3 0;
#P connect 10 0 9 2;
#P fasten 10 0 11 2 82 136 122 136;
#P connect 7 0 0 0;
#P connect 9 0 1 0;
#P fasten 7 0 4 0 26 80 145 80;
#P connect 18 0 21 0;
#P fasten 7 0 10 0 26 80 82 80;
#P connect 15 0 13 0;
#P connect 14 0 13 0;
#P pop;

This patch demonstrates that MTC from Vision is about 1% off: (Here again,
I would like to know where the discrepancy comes from.)

max v2;
#N vpatcher 90 61 446 769;
#P newex 208 615 50 196617 sel 0;
#P number 208 666 49 9 0 0 0 3;
#P message 282 595 50 196617 clock;
#P number 208 590 35 9 0 0 0 3;
#P number 162 590 35 9 0 0 0 3;
#P number 116 590 35 9 0 0 0 3;
#P number 70 590 35 9 0 0 0 3;
#P newex 70 567 33 196617 & 31;
#P newex 208 544 33 196617 + 0;
#P newex 162 544 33 196617 + 0;
#P newex 116 544 33 196617 + 0;


#P newex 70 544 33 196617 + 0;
#P newex 208 519 33 196617 * 16;
#P newex 162 519 33 196617 * 16;
#P newex 116 519 33 196617 * 16;
#P newex 70 519 33 196617 * 16;
#P newex 70 494 198 196617 route 7 6 5 4 3 2 1 0;
#P newex 70 468 50 196617 pack;
#P newex 110 443 33 196617 & 15;
#P newex 70 443 33 196617 / 16;
#P newex 70 419 50 196617 unpack;
#P newex 70 397 75 196617 match 241 nn;
#P newex 70 370 50 196617 midiin b;
#P message 195 302 30 196617 stop;
#P message 236 302 34 196617 start;
#P newex 236 330 41 196617 timeout;
#P message 45 277 37 196617 \$1 17;
#P newex 45 302 83 196617 line;
#P newex 208 643 50 196617 timer;
#P newex 77 115 25 196617 1;
#P newex 21 142 67 196617 line;
#P message 21 115 25 196617 1 5;
#P newex 21 56 50 196617 loadbang;
#P newex 45 250 72 196617 * 16.666662;
#P newex 45 223 50 196617 change;
#P message 282 561 50 196617 clock real;
#P newex 45 330 73 196617 setclock real;
#P newex 21 196 35 196617 date;
#P message 21 171 35 196617 ticks;
#P newex 21 88 41 196617 metro;
#P connect 39 0 11 0;
#P connect 39 0 11 1;
#P connect 37 0 11 0;
#P connect 36 0 39 0;
#P connect 31 0 36 0;
#P connect 32 0 33 0;
#P connect 30 0 35 0;
#P connect 27 0 31 0;
#P connect 28 0 32 0;
#P connect 26 0 30 0;
#P connect 25 0 29 0;
#P connect 29 0 34 0;
#P connect 24 0 28 0;
#P connect 23 1 28 1;
#P connect 23 0 24 0;
#P connect 23 3 29 1;
#P connect 23 4 26 0;
#P connect 23 2 25 0;
#P connect 23 5 30 1;
#P connect 23 7 31 1;
#P connect 23 6 27 0;
#P connect 22 0 23 0;
#P connect 21 0 22 1;
#P connect 20 0 22 0;
#P connect 19 1 20 0;
#P connect 19 1 21 0;
#P connect 18 0 19 0;
#P connect 17 0 18 0;
#P connect 15 0 14 0;
#P connect 16 0 14 0;
#P connect 13 0 12 0;
#P connect 12 0 3 0;
#P connect 10 0 9 2;
#P connect 11 0 38 0;
#P fasten 10 0 12 2 82 136 122 136;
#P connect 8 0 9 0;
#P connect 9 0 1 0;
#P connect 7 0 0 0;


#P fasten 7 0 10 0 26 80 82 80;
#P fasten 7 0 4 0 26 80 287 80;
#P connect 6 0 13 0;
#P connect 2 2 5 0;
#P connect 5 0 6 0;
#P connect 0 0 8 0;
#P connect 4 0 11 0;
#P connect 1 0 2 0;
#P pop;

Jeff Burns

http://www.snafu.de/~jeff

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

Date:Sat, 20 Nov 1999 23:30:02 +0100
From:Georg Hajdu <hajdu@UNI-MUENSTER.DE>
Subject: Additive synthesis control

Dear MAXers,

I'm currently working on a new version of Macaque, an additive synthesis and
MIDIfication patch that translates Lemur files and does resynthesis with a
large number of oscillators.

Everything seems to be working fine (except for some artifacts which I
attribute to Lemur) when dealing with small amounts of data, e.g. sounds
that are less than, say, 10" in duration.
But with large analysis files the performance degrades quickly, and playback
slows down dramatically. The most likely culprit is the "coll" object which
I use to store the amplitude and frequency data and which doesn't seem to
handle very large files well (even on a G3).

My questions are:
Does it make a difference for "coll" whether to use index numbers or a
goto/next pair in terms of performance?
What are the alternatives to storing large lists and to read them out in
real-time? The only possibility that comes to my mind is to bang out the
data from a"filein" object.
Ideally, a coll-variant with a fixed line/list size should do the work more
efficiently because it doesn't have to keep track of the number of items per
line. Am I right?

Any input on my problem is greatly appreciated!

Georg

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

End of MAX Digest - 19 Nov 1999 to 20 Nov 1999 (#1999-332)
**********************************************************