Subject: MAX Digest - 10 Dec 1998 to 11 Dec 1998 (#1998-96)
Date: Sat, 12 Dec 1998 00:00:02 -0500
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 8 messages totalling 361 lines in this issue.

Topics of the day:

  1. Midi Clock (2)
  2. BPM conversion - please help
  3. movie
  4. MAX Digest - 9 Dec 1998 to 10 Dec 1998 (#1998-95)
  5. First public beta-release of jMax
  6. midi interface
  7. flamewire

McGill is running a new version of LISTSERV (1.8d on Windows NT).
Information is available on the WEB at http://www.mcgill.ca/cc/listserv

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

Date:    Fri, 11 Dec 1998 00:40:34 -0500
From:    Kate 
Subject: Midi Clock

I'm having a problem getting a reliable midi clock sync. Using the Rtin and
Counter objects, the clicks have to cycle once to engage the counter leaving
the sync an 1/8th note off. Suggestions ?

M

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

Date:    Fri, 11 Dec 1998 03:19:20 -0500
From:    Stephen Kay 
Subject: Midi Clock

>I'm having a problem getting a reliable midi clock sync. Using the Rtin
and
>Counter objects, the clicks have to cycle once to engage the counter
leaving
>the sync an 1/8th note off. Suggestions ?

Can you be more specific?  If you're an eighth note off, that's 12 MIDI
clock
ticks.  The fact that this is happening seems to indicate a (your)
programming
error, but if you can't explain in more detail what you are trying to do,=

how can anyone guess?  In any event, I've used MIDI clock arriving from
rtin without any problems for years.  So please expound...

Stephen Kay

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

Date:    Fri, 11 Dec 1998 08:44:02 +0100
From:    "Dr. Karlheinz Essl" 
Subject: Re: BPM conversion - please help

Dear MAXers!

Thank you all for your immediate advices and help! I obviously missed the
basic truth that a  rhythmical pulsation is also a frequency (in another
time scale, though, according to Stockhausens "...wie die Zeit vergeht...").

If one wants to *transpose* a sound, Peter's and Bill's formulas
(twelth-root of 2 per semitone) is correct. However, to change the *tempo*
of a given sound, a linear equation is appropriate:

                transp.factor = required.BPM/given.BPM

Cheers, and thanks again!
   --- Karlheinz

   Dr. Karlheinz Essl - Composer
   Vienna / Austria
   Studio for Advanced Music & Media Technology
   http://www.essl.at/

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

Date:    Fri, 11 Dec 1998 09:56:29 +0100
From:    Jeffrey Burns 
Subject: movie

>>I'd love to see the capability of continuous QT audio playback when
>>scrubbing or skipping around in a movie (i.e, how it sounds when the
>>picture is scrubbed in Premiere); how hard is that to do? Is anyone else
>>(ie a programmer) interested in that?
>
>Implementing this with QT is, I think, not particularly hard. But you
>also have to handle the user interface (track mouse movements, how fast
>are they, is it moving left or right, is the magic key combination--i.e.
>mode--for scrubbing on or off, etc.) All emminently doable by a competent
>programmer, but you'll need a helluva lot more time than a coffee break.

Scrubbing on the movie object can be achieved by attaching a number box to
it (with message sent on mouse up) for position and a message box to it
containing _rate $1 25_  for speed, preceeded by a 0-127 slider and a minus
64 object. This will play the movie from 2 1/2 times normal speed forwards
to 2 1/2 times normal speed backwards.

Even more efficient scratching can be done by attaching a number box (with
continuous message send) via speedlim to the movie object, for position,
and letting metro take care of the subsequent forwards and backwards motion
at any desired speed. However, that won't give you the same audio effect.

Jeff Burns

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

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

Date:    Fri, 11 Dec 1998 07:11:06 -0800
From:    Bill Felton 
Subject: Re: MAX Digest - 9 Dec 1998 to 10 Dec 1998 (#1998-95)

At 12:00 AM 12/11/98 -0500, you wrote:
>Stephen, Antiorp et. all,
>
> I know you are frustrated, and believe me, most of us understand. Please
>understand though that this does not help anything in any way. Please, no
>more of these messages from anyone.
>
>Thank you.

Does that include antiorp?
Will it be enforced equally against antiorp?

If not, why not?
If so, why has it taken so long?

Bill

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

Date:    Fri, 11 Dec 1998 19:23:02 +0100
From:    enzo maggi 
Subject: First public beta-release of jMax

Hello,

The first public beta-release of jMax for Silicon Graphics
platforms is ready for download.

The beta testing is open, but we would like to know who you are and
what do you plan to do with jMax; in order to receive download
information, send a mail with this information to jmaxinfo@ircam.fr,
and we will answer you ASAP.

We are working on the Linux version and it will be out soon.

Contact

jMax home page: http://www.ircam.fr/jmax
Ircam Forum:
http://www.ircam.fr/departements/valorisation/forum/index-e.html

Mailing list

If you are interested in jMax, you can subscribe to the jMax mailing
list which has just opened.

Its adress is: jmax@ircam.fr

To subscribe, send a mail to : listserv@ircam.fr
with body:
        SUBSCRIBE jmax 

or visit Web page:
        http://www.ircam.fr/listes/

Thanks ! A bientot.

The jMax team.
François Déchelle
Maurizio De Cecco
Enzo Maggi
Norbert Schnell

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

Date:    Fri, 11 Dec 1998 10:32:05 -0800
From:    Peter Elsea 
Subject: midi interface

>is there any midi interface out there that won't send midi overun errors
>all the time
>(fast enoff for snaps) and that can work with two computers without bugs?

Nope, and there isn't going to be one. The computers are getting faster and
faster, while MIDI remains the same speed. When we get to sending elaborate
stuff with G3s and such, it's easy to fill the buffers of even the latest
and fastest interfaces- we need to consider output rates in our more
complex patches. To this end, there's a new Lobject, Lqueue in
ftp://arts.ucsc.edu/pub/ems/Lobjects/beta_98/ which will collect up to a
thousand values and output them at a steady rate.

The trick is to not use it just berfore midiout (the interfaces have their
own queues, which fill and generate the error messages) but a little
earlier in the patch. If you were, for instance, generating huge chords
with makenote, you'd put it before makenote and slow the stream of ints to
1 per millisecond. That way the interface wouldn't be hit with all of the
note ons at once, but spread out at more or less the MIDI data rate. (Don't
forget to set Max granularity)

It's a beta object, meaning unfinished. If you try it, please send me your
comments and suggestions for improvement.

As for two computers using the same interface, what I've read on the list
leaves me with the impression that it's much less hassle to use two
interfaces and a merger.
Peter Elsea
Electronic Music Studios
University of California, Santa Cruz
http://arts.ucsc.edu/EMS/Music/index.html
 elsea@cats.ucsc.edu

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

Date:    Fri, 11 Dec 1998 16:20:37 -0000
From:    David Bianciardi 
Subject: Re: flamewire

On 12/11/98 4:59 AM, Automatic digest processor wrote:

>Date:    Thu, 10 Dec 1998 10:41:44 -0700
>From:    baxtrr 
>Subject: Re: MAX Digest - 8 Dec 1998 to 9 Dec 1998 (#1998-94)
>

what delightful prose!  It almost makes having someone jump down your
throat pleasant...

>but if anyone is actually using this stuff
>for any real world digital audio
>i would like to hear about it

well, as both of us point out, the current dirth of available gear means
that not a whole lot of consumers are getting their feet wet, but in the
developer community things are definitely afoot... in any case I've seen
(yes, working) Yamaha promix consoles with an m-lan port, as will other
gear, at a couple conferences.  I've seen and worked with the standalone
1394-audio/MIDI interface box that they were using as their testbed (not
sure if they'll go into production or not) and it's quite elegant.  The
system becomes analogous to a big distributed Audio and MIDI patchbay,
and you can specify routings between machines on a network controller (PC
based as I recall).

A year ago were talking with Jun-Ichi Fujimori
(fujimori-j@emi.yamaha.co.jp), Yamaha's 1394 Project Leader on using
m-Lan in the Interactive Dance club we showed at this year's Siggraph
conference in Orlando, but a last minute bug and a heavy demo schedule
precluded them from participating...  It would have been perfect however,
and the closest thing to a hybrid content/control network since Lone Wolf
was peddling their vaporware a few years back...

>
>without a killer app
>firewire for audio is just another card
>to cause conflicts in your system

so far, the videots seems to have gotten on the bandwagon quicker than
others, but there's a much bigger consumer/pro-sumer market for desktop
video, so it's understandable.

as far as 1394's killer app in the audio market, we may find that it has
nothing to do with desktop computers (and their whining users) at all.
Embedded devices enabling addressable MIDI or digital audio "taps" for
I/O at any point in a high bandwith isochronous pipe might be the best
thing since patchbays that large multi room studios have ever seen.

>>USB is putting up a good fight in terms of actually coming to market,
>>however...
>
>if you consider
>the current market position of usb
>vs. firewire
>to be 'putting up a good fight'
>then i would hate to see
>a one-sided massacre
>
>usb audio peripherals exist
>they are shipping
>they are widely available
>and according to at least one user
>whose bench tests i trust
>they work very nicely indeed
>
>i would definitely call that
>'putting up a good fight'

I'm sorry my intent was not clear to you.  You quoted me, but apparently
failed to read what you quoted.  I consider the "in terms of actually
coming to market" portion of the sentence above to be 100% in agreement
with your next 3 paragraphs of spew...which begs the question...was it
just a bad batch of speed, are you trying to prove something, or are you
customarily abusive of people you've never interacted with before?

>however
>this ignores the fact
>that the specs are not in competition

true, the specs are largely apples vs oranges, but in the consumer's mind
there is some overlap...  one of the reasons for my comparison stems from
the fact that folks in the Max community are probably hearing alot about
both systems now...speaking of specs, MIDI over USB is still, to my
knowledge, not part of the MIDI spec yet, so I guess it's possible that
all the boxen you refer to may "break" in the near future as soon as the
MMA comes around to it ;)

>firewire for pro audio is not a certainty
>the groundwork is being done
>and yamaha is a powerful force in the industry
>but no one will buy into a spec
>that is technically wondrous

we agree again!  as with MIDI, yamaha is working to drive the spec on
MIDI/audio over 1394...we'll see what happens.  the MMA seems hungry for
at least one new transport layer for MIDI, as is the AES SC10, so
hopefully something interesting will happen soon

>but doesn't actually
>do
>anything

here, I'm afraid we disagree.  Not only is the spec nice on paper, but
m-lan works, and has a number of uses that would be very helpful in a
number of applications (at least for my business).

Anyhow, I like it, and am considering putting an order in for Pavo's
Papaya development rig, which might be alot of fun.  Hopefully soon my
company will be offering 1 hour round trip tickets
(Orlando-Beijing)...payment by e-cash only...I'll make sure you're the
1st to know ;)

David Bianciardi
tech@idrc.com

212.353.9087
212.353.3947 fax
______________________________________________
IDRC || 415 Lafayette St || NYC, NY 10003-7000

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

End of MAX Digest - 10 Dec 1998 to 11 Dec 1998 (#1998-96)
*********************************************************