Subject: MAX Digest - 20 Feb 1999 to 21 Feb 1999 (#1999-61)
Date: Mon, 22 Feb 1999 00:00:00 -0500
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 12 messages totalling 524 lines in this issue.

Topics of the day:

  1. MSP resolution
  2. OT: MIDI into Director (MacOS)
  3. dithering (was re: MSP resolution) (2)
  4. Patch Cord Solutions (2)
  5. notation
  6. Ichi's ispeak object
  7. Patchcord conduits (2)
  8. White Queen managment
  9. X platform Soundfiles

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

Date:    Sat, 20 Feb 1999 21:56:45 -0800
From:    David Zicarelli 
Subject: Re: MSP resolution

Alex Burton  writes:

> MSP's signal routing is done through floats
>(32 bits), which is nice. However, how are these
>32 bits converted to 16, 20 or 24 for outputting?

Let's say the resolution of the dac is 16 bits. A float signal
value of 1.0 should have the value of 32767 and a value of
-1.0 should have the value of -32768.

The easiest and fastest thing to do is a floating-point multiply
by 32767.0 followed by a truncation.

Anyone who cares is free to tell me why this is bad and what I should
do instead. Then we can compare techniques and see if anyone can
hear the difference. I went for speed rather than worrying about the
least significant bit.

David Z.

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

Date:    Sun, 21 Feb 1999 17:16:55 +1030
From:    Ross Bencina 
Subject: OT: MIDI into Director (MacOS)

Greetings,

I have a mostly finished Director Xtra that uses OMS on the mac, and also
runs on the PC. If enough people are interested I could be pursuaded to
finish it.

Please email me privately,

Ross.


>Date:    Sat, 20 Feb 1999 22:14:08 +1100
>From:    Garth Paine 
>Subject: MIDI into Director (MacOS)
>
>Hi all,
>
>>>I have just uploaded my little XFCN that allow the MacOS version of
>>>Director to use Midi. It has been tried with Director 6, but I have no
idea
>>>if it will work with the latest version. It requires Apple MidiManger to
>>>work -- sorry, no OMS yet.
>>>
>
>Unfortunately, XCFNS ad XObjects don't work with Director 7, that includes
>the serialPort Xobject,
>so there's an "opportunity" to write a USB communications xtra (and extend
>it to MIDI).

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

Date:    Sun, 21 Feb 1999 03:05:59 -0500
From:    Alex Burton 
Subject: dithering (was re: MSP resolution)

 just read the digest and responses to my enquiry about resolution roamed
around down to assembly code, without really answering my question.  so
permit me a few words on dithering:

 truncating (even rounding) a long word length to a shorter one basically
adds harmonic distortion. Take an extreme example: a sine wave oscillating
in the 9 last bits of a 24 bits signal truncated to 16 bits becomes a 1-bit
pulse wave; rounding it makes it rise and fall more sharply (so more
precisely harmonic).

 dithering is a process that amounts to applying some statistical noise to
the soundstream's unwanted bits (for instance those last 8 bits of a
24-bits signal).

 Some people describe this as "covering the last bit with tape hiss so you
don't hear the sound crack when your signal fades to digital silence", but
what really happens is that the result of the modulation carries over the
16th bit, indeed "covering" the square wave with noise, but noise that is
statistically and (directly) related the the content of those 8 last bits.
It happens that the marvelous human ear/brain can decode that noise to the
original data. (if you want to try an experiment, reduce some 16 bits files
to 8 bits with and without dither; the difference is pretty clear. Dither
is "noisier", but way better, especially in the "ambiance" or "feel" of the
sound. Same applies to 16 bits or more, only the noise floor is lower).

 Which means that while the theoretical signal-to-noise ratio of 16 bits is
near 96db, the dynamic range of the same width (when properly dithered) is
about 115db (because the dither process "encodes" up to approx. 4 bits
worth of data).

 (white noise is "cheap" dither; some more fancy high-end mastering tools
use complex filtering to put the noise energy in less sensible part of the
spectrum (so noise is less present) while preserving even more than 4 bits.
However, this means more DSP crunching that rises somewhat exponentially to
the actual result).

 a parallel: dithering is also used in the graphics world for small color
palette; extra colors (extra bits) can be approximated by using the right
colors so the eye "melts" the pixels into the wanted color. But the best
colors are not the closest matches to the original (truncating) but the
ones that will work best together. "Ultimate" dithering is reducing to 2
bits (duotone), where two contrasting colors are calculated and spread used
so the picture "feels" better to the eye, creating nice patterns of color1
& color2 pixels (that the eye sees as hues of in-between colors) instead of
large clumps of a single color when brightness > 50%.

 while i agree that straight 16 bits is good enough for a final, controlled
signal (such as a mastered CD), a working situation is very different
(especially when recording/processing live, impredictable or interactive
stuff, you want to keep off the clipping point (0 db) by a couple of bits).
Dithering means the extra headroom of the internal processing can be
usefully exploited. It also means MSP can be used in critical and "pro"
situations where every bits count (especially in the specs ; ), even when
the final output is up to 24 bits wide.

 now, i've tried fooling around with saving very small amplitudes (cycle~
-> /~ 20000.) and normalizing then in an audio editor, and indeed,  sines
looks like clean pulse waves (while multiplying the small amplitude in MSP
by 20000. gives back a nice sine wave).  i'll try putting up a dithering
patch together, but not tonight (hey, it's saturday!).

 i guess only David Z. can confirm on what's going on in the dac~... ; )
if the dac~ doesn't cut it, there's need for a dither~ !

 cheers,

                            Alex.

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

Date:    Sun, 21 Feb 1999 10:15:44 +0200
From:    Tom Mays 
Subject: Re: Patch Cord Solutions

(as Nicholas Longo explained)
...
>However
>by automatically placing objects in one layer and patch cords in another
>layer, which is really the underneath of a simulated circuit board, the
>same convention of connecting objects to patch cords remains intact.

I would just like to add my support of this simple and perfectly adequate
idea for making patch cord and object manipulations easier without
turning Max into a sophisticated "graphics" program that it was never meant
to be.

Just TWO layers, cords and objects, and some clever way of dimming the one
that you can't edit. To me, this means that the "edit" mode has three
"positions" :
        normal (as it has always been)
        edit objects (dim patch cords)
        edit patch cords (dim objects)

I would say, when a patcher is in "edit" mode one could command-click
on the "open lock" icon in the title bar to toggle through the three modes.
There could also be a menu selection. In any case, this information
would NOT be saved with the patcher - to avoid changing anything about
the way patchers are saved. These are simply EDIT options.

>And since
>traces on a real circuit board can't cross each other without making
>electrical contact, but patch cords can, I would suggest some kind of
>graphic indicator that automatically appears when two patch cords cross.

A nice idea, but I could easily do without it. I have always been able to
find
some combination of diagonal and segmented patchcords and object
positioning to make it more clear what cords go where.

That's my two cents (roughly 5 drachmas...)

        tmays

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

Date:    Sun, 21 Feb 1999 12:08:48 +0100
From:    Jeffrey Burns 
Subject: notation

>1) Some sort of sequence controller that scrolls a score across the screen
>presenting x number of notes in advance of what is being played.
>(explode or follow in conjunction with a sequencer ?)
>
The prospect of having Max do some kind of real time notation is - just
like graphics - one of those intriguing things that Max wasn't originally
meant to do but would be very exciting for certain users. Stephan Tiedje
got a scrolling notator window (almost) working. But I think scrolling
notes are impossible to read, so I tried saving sequences from detonate to
disc as MIDI files and immediately opening them in Overture by means of a
QuicKeys shortcut. (The shortcut was triggered by Max using Peter Castine's
QuicKeys extension. It took about 1/2 of a second.) That worked perfectly,
as long as I don't put complicated stuff into the MIDI file which would
make Overture scramble up the notation. (It works with Finale too, but
Finale is slower and is more likely to do notation scrambling. StudioVision
Pro will give you a bouncing ball, but I havent tried that out with Max
yet.)

On second thought, the above ideas are intended for a patch that is
composing in real time. If your sequence is prepared in advance, why don't
you just save pict screenshots of it from a notation program and stick them
into a quicktime move which advances frames on command?

Good luck

Jeff Burns

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

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

Date:    Sun, 21 Feb 1999 13:02:13 +0000
From:    sinclair 
Subject: Ichi's ispeak object

I am currently running an installation at the musˇe d'art contemporaine
in Lyon, France, which uses ichi's ispeak and sr objects to allow a
groupe of 4 laptop computers to converse.

I am using the sync symbol function to animate a quicktime movie of
moving mouths (imovie) on screen, a sync symbol infront of each word
selects a frame showing an appropriate mouth shape.

My main problem is overload in Max after running my patch for some time
(as much as several hours) the metro objects stop and I have to hit
resume or max freezes or crashes and I find max temporary items in
trash.

my second problem is that after 64 sync symbols in one text the synccb
ceases to function untill a new text is loaded, I have got round this by
deviding my texts into small pieces, but it would be very helpfull if I
could resolve this.

I am using Ichi objects v3: ispeak created  14 sept 1997
Is there an updated version of ispeak? if so where can I get it? Can
anyone help in anyway?

Peter Sinclair

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

Date:    Sun, 21 Feb 1999 12:14:18 -0500
From:    Stephen Kay 
Subject: Re: Patch Cord Solutions

>tmays:
>Just TWO layers, cords and objects, and some clever way of dimming the o=
ne
>that you can't edit. To me, this means that the "edit" mode has three
>"positions" :
>        normal (as it has always been)
>        edit objects (dim patch cords)
>        edit patch cords (dim objects)

This seems to me to be straying from the original proposal/idea.

I've never had a problem selecting objects OR (||) patchcords.
If your object has so many patchcords running across it that it's
impossible to select, then that is a problem of your patch layout.

I thought the idea was to select an object, and have any patchcords
connected to it then hilited in some fashion that makes them easier
to see, and to select.  THAT would be handy.

I don't know about this "layer" idea.  I use and abuse Photoshop.
I'm well acquainted with layers.  I just don't see this paradigm
translating to Max in any real useable fashion.

What would a layer be?  Uh, all the send/receive objects in a patch.
Uh, all the UI objects.  Uh, this particular arbitrary grouping
of objects that I probably should have just encapsulated.
Patchers can be big - they can also be nested.  You don't
have to put UI objects on top of the rest of your patch. =

You also don't have to segment every single cord, and then lay
them on top of each other.

The idea of selecting an object and seeing where its patchcords
go, and then being able to more easily select one of them is a
good one - and it doesn't require "layers".

Stephen Kay

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

Date:    Sun, 21 Feb 1999 14:05:11 EST
From:    JohnBrit@AOL.COM
Subject: Re: Patchcord conduits

Stephen Kay wrote:

>
>There are 2 ways I can think of offhand of doing this in an external
>object:
>
>1) packing the data into a list, sending it out one outlet, then
>receiving the list, and splitting it up again.  You can easily do this
>simply with a pack and unpack.  Pack all your data from "n" sources
>into a list, send it down one "trunkline", and then unpack it into
>"n" destinations.  Doing this simply to avoid extra patch cords
>seems like a waste to me...
>
>2) Give each data item an identifier, send them all down the "trunkline",=
>
>and then route them accordingly at the destination.  This is also
>possible in max simply by using a funnel/spray combination (although
>funnel currently only works for ints).  Once again, I question the
>extra processing power simply to get rid of patch cords.
>
>Since both of these methods are easily accomplished using standard Max
>objects, unless someone has another method that's more efficient, I
>don't see how this writing something like this in C would be any
>improvement.

1)      Yes, you can pack loads of data and unpack it at the other end. I do
this a lot if there are only a few elements. Apart from the first element,
every input to the pack object would require a bang to the first input, so
if
you have thirty inputs you have at least thirty more patchcords or trigger
(t
b i) objects totally defeating the purpose.

2) Yes you can use a funnel to label each input. This is very useful when
sending sysex as the input number of the funnel can be used as the parameter
address. However, as a way of limiting patchcords it would require a
humongous
system of gates at the other end again defeating the purpose.

Many front ends I have written for synths and samplers that I own have
faders
with number boxes to change parameters. Since I need the fader or the number
box to both change the parameter and reflect the change in its sister
object,
I end up with a set $1 message and a patchcord running from the output of
the
number box to the input of the fader. Often this is 10 to 20 patchcords, all
running from bottom to top. This is where some method of bundling these
together while maintaining clarity of what connects to what would stop my
patches looking like a 32 bit single layer PCB.
JW

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

Date:    Sun, 21 Feb 1999 11:14:10 -0800
From:    Peter Elsea 
Subject: White Queen managment

Since the University of California believes in the maxim "To stay where you
are, you have to run very fast", I am coming up for a periodic review
required to renew my appointment. Among other things, examples of teaching
materials are potential evidence that I am worthy of my job. If any of you
has found my Max tutors ( ftp://arts.ucsc.edu/pub/ems/ in word 5.1 format)
useful, particularly in a class, I would appreciate a private note to that
effect.

Peter Elsea
Electronic Music Studios
University of California, Santa Cruz
http://arts.ucsc.edu/EMS/Music/index.html
 elsea@cats.ucsc.edu

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

Date:    Sun, 21 Feb 1999 14:13:21 EST
From:    JohnBrit@AOL.COM
Subject: Re: X platform Soundfiles

In a message dated 2/19/99 21:00:49, you wrote:

>
>does anybody know which is  the best  format for  transferring a sound
>file processed on a p.c. to  a mac. platform so it would suit the Max?
>Oron Schwartz

I have this situation daily.
*.wav files can be opened in many audio editor apps and converted to SDII or
AIFF files. The easiest way is to use Wave Convert from Waves as this allows
you to do batch conversions. If you have large files to copy to and from
PC/Mac, networking the two machines using PC Maclan from Miramar systems
allows you to open windows from either machine on the other, and drag and
drop.
JW

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

Date:    Sun, 21 Feb 1999 22:14:44 +0100
From:    Peter Castine 
Subject: Re: dithering (was re: MSP resolution)

Thanks to Alex for the explanation on dithering, etc. Stuff I might have
known if I'd ever finished reading either the Moore or Roads books. Sigh.

I think the deal with MSP is that (1) as long as the signal remains
inside MSP, it's in floating point, so the question is sort of moot. (2)
Once you send something to dac~, MSP assumes you've finished processing
the signal, so headroom for further processing is not the issue (this may
all be obvious, sorry if I'm being redundant). The question of the best
way to convert a signal from float to integer (or fixed-point, for that
matter) is a trade-off between computational cost and audio quality.

In choosing between truncating and rounding, they're both in the same
computational cost ballpark, with rounding being a little more expensive
(unless Philip is correct in his analysis/guess that both can cost the
same on PPC). But the difference in audio quality is also not real big.

Dithering, on the other hand, must be (educated guesses here) a _lot_
more computationaly expensive than either truncating or rounding.
According to Alex' analysis, it buys you an approx. extra 20dB of audio
quality.

Given the capabilities of PPC chips when MSP was first developed, I think
David's decision to go for the fastest&easiest float-to-integer
transformation was the Right Thing to do. When we've all got G7
processors running at 2 gazillahertz, we'll probably be wondering how
anyone could have been so barbaric as to choose anything other than
dithering.

Whether we'll all be able to afford audio equipment where you can hear
the difference is another question. I would like to hope so, but the DAT
recorder I have today only claims 87 dB S/N.-(

Cheers,

Peter

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

Date:    Sun, 21 Feb 1999 16:31:30 -0500
From:    Stephen Kay 
Subject: Re: Patchcord conduits

John Brit said:
> 1)      Yes, you can pack loads of data and unpack it at the other end.=
 I
do
> this a lot if there are only a few elements. Apart from the first
element,
> every input to the pack object would require a bang to the first input,=

so if
> you have thirty inputs you have at least thirty more patchcords or
trigger (t
> b i) objects totally defeating the purpose.

OK, I see the problem with pack/unpack that I didn't notice in my
hasty suggestion.  However, it would be simple to write a pack object tha=
t
output its list when receiving input at any inlet, and equally simple
to write an unpack object that only sent data out of an outlet if it had
changed from previously sent data.  Therefore, you could move 1 UI object=

connected to the pack, and have 1 data item come out of the appropriate
outlet of the unpack.  Since unpackX (enhanced unpack object) is already
part of the MegaMax Collection, this would be relatively simple for me
to do.  If people think this is useful, let me know.  But I don't think
it's
necessarily any better than below:

> 2) Yes you can use a funnel to label each input. This is very useful wh=
en
> sending sysex as the input number of the funnel can be used as the
parameter
> address. However, as a way of limiting patchcords it would require a
humongous
> system of gates at the other end again defeating the purpose.

I don't see the problem where all these gates would be necessary.  Take
a look at the funnel.help file.  It shows 1 patchcord taking the place of=

5.
There are 5 objects connected to the funnel.  You move one, and 1 message=

gets sent down the patchcord, being  .  At the other end, th=
e
spray takes that single message and outputs it from the appropriate outle=
t,
where it can be sent to its destination.  No other messages come out of
the spray.  So where are all these gates that are necessary?

It seems to me that funnel/spray allows multiple sources and destinations=

to communicate using a single patchcord, without any additional problems.=

(Other than funnel only works for ints.  But a floating point or
symbol version would be relatively simple to make.)

Stephen Kay

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

End of MAX Digest - 20 Feb 1999 to 21 Feb 1999 (#1999-61)
*********************************************************