Subject: MAX Digest - 13 Dec 1999 to 14 Dec 1999 (#1999-357)
Date: Wed, 15 Dec 1999 00:00:01 -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 12 messages totalling 446 lines in this issue.

Topics of the day:

  1. tracking vocoder
  2. Kyma ?
  3. Your coolest MSP patch. Be a superstar.
  4. er: echo machine
  5. ICMC Submission Deadlines
  6. "Talking Stick"
  7. MAX Digest - 12 Dec 1999 to 13 Dec 1999 (#1999-356)
  8. crash
  9. Kyma
  10. Weird Groove Sync problem
  11. record~ sync out & pop culture
  12. mute~/pass~ enable/pcontrol MSP etc.

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

Date:Tue, 14 Dec 1999 02:24:08 -0500
From:luke <luke@WOOF.MUSIC.COLUMBIA.EDU>
Subject: Re: tracking vocoder

scott --

this is just my gut reaction to your problem, but i'm guessing that a
true-to-form f.r. moore style phase vocoder would be kind of tricky to
implement given msp's real-time design. at least as a patch (you might be
able to code up an external to do this -- that certainly _would_ be a
question for the formidable professor lyon, though).

the concept of 'real-time' and 'time compression/expansion' don't co-exist
that comfortably in the sense that we (as max users) would use those
terms. when you say 'real-time phase vocoder' what that usually means is
that if you have a one-minute soundfile on your hard disk then your
computer takes one-minute to do whatever time manipulation algorithm it
uses and then spits out a new soundfile. while this is fine as a
definition for some software, anything you develop in msp has to be able
to 'stream' properly or else you'll get gaps in your output. for example:

if you plug a sample stream into an fft~ object to prepare for an
oscilator bank resynthesis that uses time-stretching you have to deal with
the fact that the fft~ object is going to keep outputting new windows of
data every 1024 (or 2048, or whatever) samples. you'd have to buffer the
samples coming out with some sort of fairly convoluted tapin~/tapout~
scheme and eventually you'd probably run out of memory. you could
probably implement a time-stretching algorithm in max provided you set a
finite input duration into the vocoder patch and then forced msp to just
flush everything and start over again. time-compression would be even
more difficult (you'd have to buffer in the other direction -- take
multiple windows output from fft~ and then spit them out of some sort of
signal delay system faster than they originally came out -- since msp
doesn't support multiple sampling rates or up/downsampling this might be
pretty hard).

you could probably fake it another way by having msp do an entire analysis
of a soundfile, dump that fft~ output into a couple of syncronized record~
objects to hold everything in buffers, then play~ back the buffers into a
resynthesis engine at the wrong playback speed, transposing the bins up or


down as you go. there are some logistical problems with this idea, i'm
sure, as i've never tried it but it's my best guess.

the good news is there are lots of pretty good phase vocoders out there in
macintosh land -- i've had loads of success with the pvoc algorithms in
soundhack, metasynth, and audiosculpt, just to name the ones closest to
mind.

all the best.

/luke

--------------------------
R. Luke DuBois
Graduate Teaching / Research Assistant,
Computer Music Center, Columbia University
e-mail: luke@music.columbia.edu
world-wide-waste: http://www.music.columbia.edu/~luke
phone:(212)-854-9266 (cmc - prentis)
(212)-854-7181 (cmc - dodge)
--------------------------

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

Date:Tue, 14 Dec 1999 09:18:57 +0200
From:Reinhold Braig <reinhold.braig@SWR-ONLINE.DE>
Subject: Re: Kyma ?

Robert Henke wrote:
>...is the kyma. If anyonehere on the list has used / is using it and is
>willing
>to share his/her pro / cons please send me an e-mail.

By thew way, has anybody worked with the Creamware Scope platform and the
SDK kit and will share infos?

reinHOLD

...Experimentalstudio der...................................
...Heinrich-Strobel-Stiftung des SWR e.V, Freiburg, Germany.
...><bald auch><....www.experimentalstudio.de....><soon><.

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

Date:Tue, 14 Dec 1999 01:37:22 -0800
From:Les Stuck <les@CYCLING74.COM>
Subject: Your coolest MSP patch. Be a superstar.

~~~~~~~~ Send us your clever patch ~~~~~~~~~~~~~~~~

We're talking about a patch that:

uses an MSP aspect/technique in a creative way

is clearly laid-out and documented

shows good programming style

is made to be recycled by others

includes only stock max/msp objects

is neither a tutorial nor a help patch

~~~~~~~~~~~~~~~~~~~~~~~~ Change the world ~~~~~~~~~

We are looking for exemplary patches to be a part of MSP Examples


for a future release of MSP. If you would like to make a submission,
kindly email it to me. No patch will be included without your permission.
We reserve the right to tweak, but only in the interest of making you
famous. Thank you in advance.

~~~ <les@cycling74.com> ~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Date:Tue, 14 Dec 1999 03:58:30 -0800
From:"|K<" <kent@SHOKO.CALARTS.EDU>
Subject: er: echo machine

>There are times when I need to begin playback before the capture is
>complete (playback from buffer while recording in progress (or playback
>head chasing record head at normal speed)).

the buffer~ object is cool in that all buffer~ objects which share the
same name are sharing the same data (just like a table). so to answer
your question, just use one buffer to record into, and everytime you need
a new 'tap' make another copy of the buffer~ with the same name. play back
at any speed (or direction) you like. it's up to you to make sure you
don't read past your current write boundary.

|K<
kent@music.calarts.edu

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

Date:Tue, 14 Dec 1999 15:35:33 +0100
From:Peter Castine <pcastine@PRZ.TU-BERLIN.DE>
Subject: ICMC Submission Deadlines

Dear Friends and Colleagues,

This is just a brief note to remind you that the submission deadlines for
the ICMC 2000 Call for Papers and Call for Works are fast approaching.
Submission forms and instructions are available on-line at

<http://www.icmc2000.org/participation/>

We look forward to your submissions and to seeing you in Berlin next year!


Best regards,

Peter Castine
ICMC 2000 Conference Chair


PS: Your address was included in the distribution list for this message
in good faith that it will be of interest to you. If this is not the
case, please accept my personal apologies and disregard this mail. I also
apologize if you receive multiple copies: invariably some people will
read this twice, and some never at all...

PPS: Dear List Moderator... if this message is not posted to your list
because I am not a subscriber, would you please consider forwarding it
anyway? Perhaps this is the only ICMC 2000 announcement your list has
seen?

----------------- http://www.prz.tu-berlin.de/~pcastine/-----------------
Dr. Peter Castine| The World-Wide Web Site of the 26th
4-15 Music & Technology| International Computer Music Conference is
| now on-line! <http://www.icmc2000.org/>
| Enjoy!


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

Date:Tue, 14 Dec 1999 18:31:55 +0100
From:wolf <W.Heiniger@UNIBAS.CH>
Subject: "Talking Stick"

> The stick is freestanding and controls the
> max patch via wireless midi.

wireless midi ?
tell us more, please !

wolf

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

Date:Tue, 14 Dec 1999 13:51:56 -0800
From:Benjamin Nevile/Towers Perrin <nevileb@TOWERS.COM>
Subject: Re: MAX Digest - 12 Dec 1999 to 13 Dec 1999 (#1999-356)

> Using a delay effect isn't real
> pratical due to variations in tempo.

Why not use Max to control the tempo of the delay
via midi?

bbn

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

Date:Tue, 14 Dec 1999 18:13:00 -0500
From:Eric <er@INTERPORT.NET>
Subject: crash

I'm getting an inordinate number of crashes lately upon closing patcher
windows - type 2 errors. Running system 8.6 on an original beige G3 233
w/latest version of Max and lots of RAM. Any suggestions, explanations?

Thanks all,

Eric Rosenzveig

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

Date:Tue, 14 Dec 1999 17:32:10 -0600
From:Bill Meadows <mrbill@FANTASIA.SPS.MOT.COM>
Subject: Re: Kyma

I have been a MAX user for years, and I have experimented a bit with MSP.

I bought a Kyma system a few months ago, so I am no expert, but my first
impression is pretty good. The tech support is similar to MAX - my email
is answered by one of two people who actually write the software.

The learning curve is fairly steep. Although the graphical interface
LOOKS alot like MAX, it certainly behaves differently. It takes a while
to un-learn the MAX-way and learn the Kyma-way. Actually there is a lot
about the Kyma that is very cryptic and hidden.

There is a major software revision due "any day now" that may solve some
of the user interface and presets problems I've had.

As with anything, Kyma does some things better than others. For example,
Kyma is very good at vocoding, but not very good at polyphonic pitch-shifting.

Unlike MAX/MSP, most "objects" are very complicated functions like spectral


analysers and granulators, so it is easier to get complicated results, but
it is ultimately less flexible.

The software is written in SmallTalk, and I find the syntax to be pretty
weird (I like C better!)

One nice aspect is that I can run the Kyma software on the Mac, edit, compile
and upload my program into the hardware box, then switch the Mac over to
Digital Performer and the Kyma hardware runs just like a stand-alone processor.
I've used the hardware ("Capybara") in an all-digtal effects loop from
Digital Performer and it works great. The Capybara gets MIDI directly, not
via the Mac, so I can control it with my PC1600 fader box.

It's not a silver bullet, but it is a big hammer!

Bill Meadows

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

Date:Tue, 14 Dec 1999 20:18:23 -0500
From:Nick Lloyd <nxlloyd@IX.NETCOM.COM>
Subject: Weird Groove Sync problem

I'm having a strange problem with the sync output of the groove object. When
I send groove a stop message, it's sync signal begins to jump around between
floats (I've watched it hop around, jumping as high as 85!!). When it's
playing back, it behaves normally, as far as I can tell. Any idea what might
be causing this?

I also noticed something about loading a buffer with a large amount of audio
data. When I load files between 60 seconds and 120 seconds, the buffer only
loads up to roughly 100ms *less* than the amount I stipulate in a 'replace'
message. For example, if I load a file which should be 120000 ms long, only
119917 or something gets loaded. I had initially created a patch which
automatically sets the loop points to the outer edges of the buffer, using
the amount of audio specified in the replace command. This wasn't working
with looping because the groove object doesn't play through the empty end of
the buffer. Should I not be using replace with large audio files?

Thanks in advance for any tips,

Nick
--
Gretchen's Kitchen
A Multi-Purpose Recording Facility
ph# - 718/623-1660
10 Sterling Place, Brooklyn, NY

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

Date:Wed, 15 Dec 1999 02:55:11 +0000
From:filip <filip@RHIZ.ORG>
Subject: record~ sync out & pop culture

tim wrote:

I've encountered what seems odd behavior to me in the
record~ object. The
patch I've appended below demonstrates my problem: the
Sync output doesn't
always output. If I've missed something obvious, perhaps
someone could
enlighten me. The patch below is supposed to apply a
window to the input
coming into the record~ object...

Thanks in advance!


-Tim

all signal-processing units will stop calculating when
signal at its "output" is connected via patchcord to some
input of the same
unit.
the workaround is send~ and receive~, see patch below.
i can only tell, that it always works, but i don't know why
it does not with patchcords....

btw:
jim o wrote:
..., and the mego label groups (pita, fennesz, etc.) are
using max and...

using max is true, but in this case it also means using
lloopp:http://loopool.live.fm

cheers klaus

max v2;
#N vpatcher 51 113 452 492;
#P newex 275 67 71 196617 receive~ back;
#P newex 188 193 55 196617 send~ back;
#P comment 241 217 136 196622 This side does not;
#P user number~ 288 129 345 144 9 3 2 2 0. 0. 0 0. 50 0.;
#P user number~ 65 129 122 144 9 3 2 2 0. 0. 0 0. 50 0.;
#P message 161 27 44 196617 open;
#P user ezadc~ 161 41 205 74 0;
#P user number~ 252 192 309 207 9 3 2 2 0. 0. 0 0. 50 0.;
#P newex 275 107 75 196617 wave~ Window;
#P newex 252 128 33 196617 *~ 0.;
#P newex 252 163 72 196617 record~ Audio;
#P toggle 166 94 29 0;
#P user number~ 29 192 86 207 9 3 2 2 0. 0. 0 0. 50 0.;
#P newex 52 107 75 196617 wave~ Window;
#P newex 29 128 33 196617 *~ 0.;
#P newex 29 163 72 196617 record~ Audio;
#P newex 176 289 105 196617 buffer~ Window 1000;
#P newex 80 289 95 196617 buffer~ Audio 1000;
#P comment 194 94 48 196617 toggle me;
#P comment 14 211 116 196622 This side provides sync;
#P fasten 13 0 5 0 166 79 34 79;
#P connect 8 0 4 0;
#P connect 5 0 4 0;
#P connect 4 0 7 0;
#P connect 6 0 5 1;
#P connect 6 0 15 0;
#P hidden connect 14 0 13 0;
#P connect 9 0 18 0;
#P fasten 13 0 10 0 166 79 257 79;
#P connect 8 0 9 0;
#P connect 10 0 9 0;
#P connect 9 0 12 0;
#P connect 19 0 11 0;
#P connect 11 0 10 1;
#P connect 11 0 16 0;
#P pop;

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

Date:Tue, 14 Dec 1999 17:51:29 -0800
From:Timothy Place <tim_place@YAHOO.COM>
Subject: mute~/pass~ enable/pcontrol MSP etc.

Hi again...


I wanted to ask if there was a way to truly turn off a
portion (patcher) of an MSP audio-signal network. The
Mute~/Pass~ combo, or the enable/pcontrol combo seem
to turn off the mathematical processing inside of
objects, however the Signal-Patch-Cords are all still
active and seem to be called by MSP at 44.1KHz (the
unchangable sampling rate of a B/W G3).

Of the methods I used to confirm that this happens is
using Trace. Trace steps through every single patch
cord in every single "disabled" patcher or sub-patch.


I'm working on a very large piece for MSP & Alto Sax,
for which I want to totally shut down non-current
sections of the piece. On a G3/450MHz 50% of the CPU
is being burned when *All Sections Are Disabled
(enable 0 1)*. This means that there are no (zero)
active objects. It is difficult to do much when an
inactive patch is burning so hot with no way to shut
down patch cables etc.

My probable solution will be to use pcontrol/load and
thispatcher/dispose throughout the piece - however all
of the opening and closing Max patches from disk
duringa live performance is a little scary.

Any confirmations/other solutions/etc.

Thanks,
-Tim


=====
~ Timothy A. Place
~ someplaces@yahoo.com
~ http://kromo-zone.tripod.com/tap/
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

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

End of MAX Digest - 13 Dec 1999 to 14 Dec 1999 (#1999-357)
**********************************************************