Subject: MAX Digest - 23 Nov 1999 to 24 Nov 1999 (#1999-336)
Date: Thu, 25 Nov 1999 00:00:08 -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 20 messages totalling 652 lines in this issue.

Topics of the day:

  1. WaveRider
  2. Koblo synths/Max
  3. groove~ sync output
  4. u/hslider problem
  5. what time is it/ UI + stability (2)
  6. groove~ and clicks
  7. MSP vs mac performa 6400
  8. Caught in an Eternal stack overflow loop
  9. what time is it...
  10. WaveRider BioData Interface (2)
  11. Max/MSP on a G4
  12. G3 PB in concert (2)
  13. Hi
  14. 4 channels out of a PB
  15. CD object/Speechmanager
  16. timing...
  17. Fiddle'n

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

Date:Tue, 23 Nov 1999 22:00:57 -0800
From:David Zicarelli <zicarell@CYCLING74.COM>
Subject: Re: WaveRider

Garth Paine <garth@ACTIVATEDSPACE.COM.AU> writes:

>This is really a question for David Z, but others may also have some
>experience.
>I am looking at buying a secondhand WaveRider Jr interface, but it
>comes with MAX 2.5 objects, and I am wondering if anyone has used it
>with MAX 3.x objects on PPC/G3 machine?

David Z. can't help you. I don't even know what a WaveRider is,
not to mention its son.

David Z.

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

Date:Tue, 23 Nov 1999 22:04:21 -0800
From:David Zicarelli <zicarell@CYCLING74.COM>
Subject: Re: Koblo synths/Max

Roger Carruthers <thelone.roger@VIRGIN.NET> writes:

>Incidentally, does the presence of MSP (albeit only in demo mode), put much
> more load on the host machine's CPU or could it be in conflict with the
> Koblo audio engine ? If so, how does one uninstall MSP?

MSP can be disabled by dragging the Max Audio Library out of
the Max folder. Harmless errors will appear, just ignore them.
The only thing MSP does when it starts up is open the Sound
Input manager. I don't believe it does any audio output
from startup unless you're using one of the audio card drivers.


David Z.

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

Date:Tue, 23 Nov 1999 22:19:43 -0800
From:David Zicarelli <zicarell@CYCLING74.COM>
Subject: Re: groove~ sync output

Johan van Kreij <j.vankreij@TELE2.NL> writes:

>Concerning groove~ and its sync output, some questions have risen. I use the
>sync output to drive an envelope (cycle~), that is multiplied with the
>output of groove~ itself, a quite regular setup. Yet I find the sync output
>to have some jumpy behaviour when making short and varying loops. Does
>groove~ update start and endpoint (int) when it has completed its loop or
>are they updated when they are being received (and thereby rescaling the
>sync)?

The sync output values are based on the position of the
sample pointer within the current loop. That means that
if you are halfway through a loop and you reset the loop
so that you are three quarters through a loop, the
sync output should jump immediately from 0.5 to 0.75.

Note that the loop point cannot change within the processing
of a vector size worth of samples as is true with
any control information.

Some hints:

First of all, you should use the setloop message that updates
both loop points at the same time. Second, you'll want to update
loop points at a higher priority than event (mouse click) level,
otherwise the audio processing interrupt could intervene and
you'll get groove~ output that won't immediately reflect
the change you made.

Finally, note that the use of signals to set the loop points
in groove~ is badly broken. A fix is currently being tested.
If this worked you might be able to interpolate changes in
loop points.

David Z.

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

Date:Tue, 23 Nov 1999 22:27:23 -0800
From:David Zicarelli <zicarell@CYCLING74.COM>
Subject: Re: u/hslider problem

Benjamin Thigpen <Benjamin.Thigpen@IRCAM.FR> writes:

>Yesterday, I discovered (when the patch I was constructing in class didn't
>work...) that the uslider & hslider objects dated 11 Feb 99 do not put out
>their current value when they receive a bang. The older versions (23 Apr
>97), however,
work fine.

This bug was fixed a long time ago but somehow I failed to incorporate
the latest sliders into the 3.5.9-9 update etc.

Download the fixed sliders at ftp://ftp.cycling74.com/sliders.sit

David Z.

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

Date:Wed, 24 Nov 1999 01:41:19 -0500


From:Kurt Ralske <kurtralske@EARTHLINK.NET>
Subject: what time is it/ UI + stability

>yes, software timing is a mess. yes, since the days of ISPW on NeXT MAX
>has been wretched at keeping time. no, because the original architechts
>of MAX did not consider the scheduler as important as most musicians would
>demand doesn't mean that it isn't possible, there are many great pieces of
>software out there which have accurate schedulers. it's just the price
>you pay for having a cool graphic programming language with an open API.
>"just buy a faster Cpu and you won't notice how poor the scheduler is..."

Whew, strong words. But:

This is semi-related to another question: is there a correlation between
degree of user interface interactivity and program stability? That is --
the more responsive the interface, the greater the chance of crashes?

I've written a few patches recently that consistently crash after a few
minutes. This behavior seems unrelated to CPU usage. What is different
about these patches is that they're very interactive; they're listening
for 60 different types of midi controller info and 50 different keypress
combos, etc. Since crashes have been occuring whether data is being
input or not, I'm idly theorizing that the very necessity of listening for
so many types of input is enough to make the thread scheduler throw
up its arms and say, "This is too much! I quit."

Does anyone have any thoughts on this -- would it be correct to say,
as a rule of thumb, that more interactive patches are less stable than
less interactive ones? Would my patches become more stable if I
streamlined the amount of input they accepted?

Kurt Ralske

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

Date:Wed, 24 Nov 1999 01:41:21 -0500
From:Kurt Ralske <kurtralske@EARTHLINK.NET>
Subject: groove~ and clicks

>Concerning groove~ and its sync output, some questions have risen. I use the
>sync output to drive an envelope (cycle~), that is multiplied with the
>output of groove~ itself, a quite regular setup. Yet I find the sync output
>to have some jumpy behaviour when making short and varying loops. Does
>groove~ update start and endpoint (int) when it has completed its loop or
>are they updated when they are being received (and thereby rescaling the
>sync)? I would expect the first to be the case, but when I record the sync
>to a soundfile to examine its behaviour (because I hear clicks), it seems
>more likely that the second is the case. The clicks could then occur because
>the sync (envelope) does not always reach the endpoint in a straight line,
>but jumps back or forth from somewhere in the middle. Could someone shed
>some light on this issue, or give me a hint as how to make silent fades,
>that is, without clicks.

One thing you can try is to "duck" the point of zero-crossing by sending
the message 0, 1 5 (or 0, 1 10) to a line~ controlling gain, every time
you
retrigger.

And even better: if you know the duration of the loop in advance, send
line~
0, 1 10 1 $1 0 10, and give this message the value of (loop duration
minus 20).

Kurt Ralske

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


Date:Wed, 24 Nov 1999 10:46:15 +0100
From:Johan van Kreij <j.vankreij@TELE2.NL>
Subject: Re: MSP vs mac performa 6400

>how much power i would get out of a mac parforma 6400 w/=20
>200 mhz and 90 mb RAM...?

I'm working with the 180 mhz version, an actually on the verge of bying me a
new Mac. Basically you can do everything, but not much of it. You easily
reach the top of the DSP usage (as a rule for me: until 50% is safe). At
that point timing/scheduling accuracy drops, is my experience. But it's
better to
program Max on this machine, then not to do it at all...

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

Date:Wed, 24 Nov 1999 10:46:20 +0100
From:Johan van Kreij <j.vankreij@TELE2.NL>
Subject: Re: Caught in an Eternal stack overflow loop

>I've tried 'open As text' to eek out
>the offending loadbang or receive object but the patch is too big and it
>only opens the first 30k.

Instead of putting everything in one big patch, I choose to work with many
(sub) patches, that I then can call for in the main patch. This makes it
easier to keep an overview, an when something goes wrong, you just drag the
subpatches to another folder.

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

Date:Wed, 24 Nov 1999 02:52:36 -0700
From:jhno <ear@SIRIUS.COM>
Subject: Re: what time is it...

>the max scheduler has always been <IMHO>
>useless for any kind of rhythmic accuracy.

i think we are all hoping that this will be addressed in future revisions
of max... but meanwhile i have gotten more and more into audio-rate
programming in msp. for example, you can make looping and sequencing tools
where everything happens with audio objects. use buffer~'s instead of
colls. use a phasor~ as master sync source. it can be challenging, but the
reward is sample-accurate timing.

the biggest problem is that these sample-accurate tools can not interface
tightly with the rest of the world. in other words, an audio-rate sequencer
can trigger synthesis in MSP with sample-accurate precision, but if you use
it to send MIDI you are subject to the discrepencies of the scheduler.

jhno

() ))(((( ))) ))))) ( )((()) (( ))( )) (((( )(()( (()
delicate earear@sirius.com
san francisco, cahttp://www.sirius.com/~ear

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

Date:Wed, 24 Nov 1999 22:55:32 +1100
From:Garth Paine <garth@ACTIVATEDSPACE.COM.AU>
Subject: WaveRider BioData Interface

I guess because no one has replied that no one has used the WaveRider
interface with MAX, or is not using it at present? The objects I was
sent by the seller are all not PPC compatible, so my purchase of the
interface depends on finding PPC objects, so if anyone has any idea
about this please email me.


Thanks heaps
Cheers,

Garth

Listen to some of the tracks from my latest CD at
http://www.activatedspace.com.au
See my MAP1 installation
http://www.activatedspace.com.au/Map1/map1.html(RealVideo)

,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.
Activated Space
. Composer, Sound Designer, Installation Artist
.. Interactives Designer, Exhibition Consultant
........ph. 61 3 95720133
.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.

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

Date:Wed, 24 Nov 1999 14:50:10 +0100
From:Trond Lossius <Trond.Lossius@BERGEN.IT-AKADEMIET.NO>
Subject: Max/MSP on a G4

I've Max/MSP up and running on a G4 using OS 8.6. At the moment I'm not
using any external sound cards.

Max/MSP was authorized using the bundled version key disc and a Yano UFD-03
USB floppy drive.

At first the G4 crashed when launching Max. This problem was solved after
downloading and installing the latest PACE hack to solve USB compatibility
problems (there's a link at the Cycling'74 homepage).

Max/MSP was not able to see the floppy if it was inserted after the
application was launched, so I had to make sure that the Max/MSP floppy was
inserted before launching Max. On launching I was able to authorize Max but
not MSP. This was due to the floppy being ejected on completion of Max
authorization. After quitting Max, inserting the floppy again and then
starting Max again, MSP was authorized.

Speed is (of course) way up from the 8600/200 I have been using. A patch
demanding 80-90% CPU on 8600/200 only required 20-25% of CPU on the G4. I've
been running several patches, doing major changes to them as well as running
some of them for several hours. I have not experienced any problems so far.
:-)

Trond L.

BTW: Dear Gibson: Could you please consider buying PACE?

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

Date:Wed, 24 Nov 1999 14:03:19 +0000
From:lawrence casserley <leo@CHILTERN.DEMON.CO.UK>
Subject: G3 PB in concert

Hi Everyone

I promised to report on using the G3 PB for my Spanish concerts. First I
will detail the system as it stands at present.

I got a 400MHz G3 PB with 192Mb memory. I am using MOTU Fastlane USB MIDI
plus a Keyspan USB Serial Adaptor for my Wacom tablet. I also have a USB ZIP
drive for transfering files, but I don't need to connect that in
performance, so the two USB ports are enough. At present I am using the
Apple analogue I/O (more on that later).


The MIDI setup:
Two DrumKat 3.5s are daisy-chained into one MIDI input
A Yamaha MFC10 foot controller and Peavey PC1600 are daisy-chained to the
second MIDI input
I don't use any MIDI outputs
My Wacom Intuos "Oversize A4" tablet goes into the serial interface.

Once the Freemidi/OMS problem was solved (thanks again to those who helped!)
MIDI worked fine. The Wacom driver doesn't always find the tablet on boot,
but switching it on in the control panel always works (maybe there is/will
be a driver update?). Otherwise all of that works exactly as on my other G3.
The current version of the Signal Processing Instrument is _very_ tight on
the PB - my other G3 is a 466MHz, so I am running a vector of 128 for both
msp and i/o and that seems reliable, although screen updates were sometimes
a bit slow.

The only real problem I had was with the analogue i/o, which is _very_ noisy
when running off the power supply, but clean when using battery (Anyone else
encounter this problem, or do I have a faulty machine?). Sometimes I could
persade it to go clean, but the only reliable way was to run on battery. I
am getting about two hours plus off the battery, and recharging seems to
take about the same time, which was _just_ OK for these gigs (but the encore
in Valencia was a bit worrying!!). If I was going to use this regularly I
would get another battery.

The other piece of kit I got for my "flying" setup is a Roland VM-1300 Pro
mixer. Apart from the fact that it only has two mic inputs (but I have a
small two channel mic preamp to bump it up to four) and the profusion of
phono plugs (RCA Jacks to some of you), which are most definitely _not_
professional (but marginally better than stereo 3.5mm Jacks, I guess!!),
this is really quite a flexible little desk (and it _is_ small and light!).
You can assign inputs to different channels and busses to different outputs,
but there are some odd lacunae, and the operating system is a masterpiece of
illogicality, only matched by the manual, which is clearly designed to
prevent you doing any of these things!!!!! Still, it has an eight channel
digital interface, which should ultimately be connectible to the PB. I note
some posts while I was away - the Yamaha stuff looks worth watching.

The only other problem is that I _hate_ odd little boxes on strings (power
supplies, interfaces, etc). One of the things about the Roland that _is_
professional is an internal power supply with an IEC mains connector (not
that other bete noir the permanently attached mains lead!!!)

The upshot is, that while not yet perfect I have got a compact system, which
is now down to ca 50Kg - a huge improvement - and it _does_ work OK apart
from the analogue I/O, which I intend to be temporary, anyway. A worthwhile
beginning.

.....and the tapas.....and the tinto!!!!! :-)>


Best

Lawrence


--
Lawrence CasserleyLawrence Electronic Operations
leo@chiltern.demon.co.ukTel: +44 1494 481381FAX: +44 1494 481454

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

Date:Wed, 24 Nov 1999 09:43:59 -0400
From:Dafna Naphtali <dafna.naphtali@NYU.EDU>
Subject: Re: G3 PB in concert


Slightly off subject from Lawrence's post:My G3 PB stopped powering
my serial Fast Lane MIDI interface altogether (!) when I was running
on battery power- therefore NO MIDI. I presume that was because my
Energy Saver control panel settings needed to be tweaked in some way..

Any suggestions?

Dafna

Lawrence Casserley wrote:
>
>
>The only real problem I had was with the analogue i/o, which is _very_ noisy
>when running off the power supply, but clean when using battery (Anyone else
>encounter this problem, or do I have a faulty machine?). Sometimes I could
>persade it to go clean, but the only reliable way was to run on battery. I
>am getting about two hours plus off the battery, and recharging seems to
>take about the same time, which was _just_ OK for these gigs (but the encore
>in Valencia was a bit worrying!!). If I was going to use this regularly I
>would get another battery.

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

Date:Wed, 24 Nov 1999 16:59:19 +0100
From:Alain Pern Hernndez <aph00003@TELELINE.ES>
Subject: Hi

1-If I dont have any card of sound, How I listenMax/msp?
2-How I do for Max utilize Audiomedia III?
Its my first time with that programs.
Thanks
Alain

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

Date:Wed, 24 Nov 1999 11:36:08 -0500
From:Eric Singer <eric@ERICSINGER.COM>
Subject: Re: what time is it/ UI + stability

At 1:41 AM -0500 11/24/99, Kurt Ralske wrote:
>I've written a few patches recently that consistently crash after a few
>minutes. This behavior seems unrelated to CPU usage. What is different
>about these patches is that they're very interactive; they're listening
>for 60 different types of midi controller info and 50 different keypress
>combos, etc. Since crashes have been occuring whether data is being
>input or not, I'm idly theorizing that the very necessity of listening for
>so many types of input is enough to make the thread scheduler throw
>up its arms and say, "This is too much! I quit."
>
>Does anyone have any thoughts on this -- would it be correct to say,
>as a rule of thumb, that more interactive patches are less stable than
>less interactive ones? Would my patches become more stable if I
>streamlined the amount of input they accepted?

One thought...check your methods for deriving this input info and
experiment with other ways. Are you using multiple ctlin objects? Or a
single one, with gate objects to route the output (better, IMO - true,
David Z.?).

I've often heard complaints about problems with Max's efficiency, when the
problem is actually that the programmer has written an inefficient patch
(not an accusation towards Kurt, just making a point). There are usually
ten ways to do anything in Max. It's difficult to come up with
hard-and-fast rules, but going back and rewriting one's patch with a mind
towards efficient data flow will often solve many problems, including
timing, screen redraw slowness, crashing problems, etc.


Some examples: Use gate objects early in the chain of data flow, and turn
them off during times when the data is not used. Turn MIDI input/output
objects (like notein or noteout) off using 'enable $1' messages when not in
use. Choose ints over floats as much possible. Calculate constants in
advance, not each time they are needed (trivial example: 'expr $i1 + 60'
instead of 'expr $i1 + 12 * 5'). Choose multiplication over division (*
0.333333 instead of / 3).

It would be worthwhile for the Max community to come up with a "Max
Programming Tips and Efficiency" FAQ. Anyone want to start one?

Eric

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

Date:Wed, 24 Nov 1999 12:02:21 -0500
From:Stephen Kay <sk@COMPUSERVE.COM>
Subject: WaveRider BioData Interface

>I guess because no one has replied that no one has used the WaveRider
>interface with MAX, or is not using it at present? The objects I was
>sent by the seller are all not PPC compatible, so my purchase of the
>interface depends on finding PPC objects, so if anyone has any idea
>about this please email me.

Hello Garth,

I have a WaveRider - never used it (as of yet). I was discussing
some projects with the creators of this product years ago, but =

nothing ever came of it. At the time, I was given the e-mail
address of the programmer who wrote the Max objects for the
device:

Marco Carra
SlimyFrog@eworld.com

For all I know, this is no longer a valid e-mail address. But
you could try.

Also, the founder of the company was:
Jonathon Purcell
74243.657@compuserve.com

Good luck,
Stephen Kay

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

Date:Thu, 25 Nov 1999 03:14:14 +0900
From:Takahiko Suzuki <takahiko@SHOTGUN.PHYS.CST.NIHON-U.AC.JP>
Subject: Re: 4 channels out of a PB

At 03:00 -0700 11/24/99, jhno wrote:
> this is exactly what i have been waiting for...! but on the mLAN page they
> only mention a 2-in 2-out device.

I think/hope it is an old prototype. There are several planned mLan prducts
and I heard the most recent prototype has 8 channels, but we can't know
until Yamaha releases... According to Yamaha's press release in 1997
mentioned IEEE1394TA aproval on digital audio and music data transfer, one
isochronous channel can transfer 256-340 channels of digital audio, with
sampling rate upto 128kHz and the latency is 302.59-352 usec. and also 256
MIDI lines!! But, I'm not sure about channel num of digital audio, I think
that numbers are "maximum" num at transfer rate 400Mbps, recent news from
Yamaha's page says "64 digital audio and 256 MIDI at 100Mbps transfer rate"
and I heard they are now testing 200Mbps.


> is there some other site where they are
> announcing products or making press releases?

Yes, but in Japanese.

http://www.yamaha.co.jp/product/decbx/event/macworld/index.html

Yamaha is planning to release 3 mLan products in this year.

* mLan-Faucet
converter box for connecting existing interfaces to mLan
* mLan-SY
board for connecting EX5/EX/7/EX5R and A3000 to mLan
* mLan-YGDAI
board for connecting O2R/O3D to mLan

I forgot a few things to writeto MAX-ml,
*Yamaha ran mLan demo with Powerbook G3 at MIDI World
*the driver will be ASIO compatible.
*Apple has anounced supporting mLan at WWDC


some Japanese pages. you can see the pictures...
http://www.miroc.co.jp/Tango/qrys/NEWS/NEWS_mlan.html
http://www.bonito.co.jp/dtm/midiworld99.html

other mLan info
http://www.aes.org/standards/reports/SC-06-02-POSITION-IEC-PAS-61883-6.html
http://www.pavo.com/mlan/index.htm
______________________________________________________________________

T a k a h i k oS u z u k iGuitarist/Composer

e-mail : takahiko@shotgun.phys.cst.nihon-u.ac.jp
web : http://www5.big.or.jp/~trustno1/takahiko
______________________________________________________________________

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

Date:Wed, 24 Nov 1999 20:22:19 +0100
From:Sven Erga <sven.erga@NOTAM.UIO.NO>
Subject: Re: CD object/Speechmanager

You could use the ispeak object in the ichi-objectsFATv3.sea from the ircam
ftp.
-sven
>I've had Max speechsynthesizer objects at some point, but I am
>unable to find them.

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

Date:Wed, 24 Nov 1999 12:36:23 -0800
From:Peter Elsea <elsea@CATS.UCSC.EDU>
Subject: timing...

>connect metro(250)-->midNoteOut, record output and measure in
>your favorite editor. not only are the impulses not 250 ms apart, but
>they are not even consistently fast or slow. they are simply useless.

I did just that, recording not the output of some instrument, but the MIDI
data itself (if you connect a MIDI line to the input of a DAT recorder
through a 0.01 capacator, you will get a nice pop with the message STOP ( a
single byte message 250)). There is a surprising amount of latency and
variation in all MIDI instruments that I am familiar with.

I've only had time for a quick look at the data-- With a nominal period of


250 ms, I found a variance of up to +171 to -165 samples, or about 3.5 ms
worst case. There is a pattern of long and short that seems to even out the
time fairly well. The cumulative error over 90 seconds seems to be about 2
ms slow.

This is on a blue and white 350 with overdrive off, using a MACman
interface connected to a stealth adapter. OMS 2.3.7.

Since most of us are equipped to make this test, perhaps we could get data
from a variety of setups old and new.
Peter Elsea
Director, Electronic Music Studios
University of California, Santa Cruz
http://arts.ucsc.edu/EMS/Music/index.html
elsea@cats.ucsc.edu

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

Date:Wed, 24 Nov 1999 16:12:19 +0000
From:Robb Drinkwater <rdrink@ARTIC.EDU>
Subject: Fiddle'n

Can anyone send me documentation for Millers' fiddle~, bonk~, and rufus~
objects?
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Robb Drinkwater
SAIC Sound Department
312 345 3573
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^

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

End of MAX Digest - 23 Nov 1999 to 24 Nov 1999 (#1999-336)
**********************************************************