Subject: MAX Digest - 2 May 1999 to 3 May 1999 (#1999-134)
Date: Tue, 4 May 1999 00:00:03 -0400
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 10 messages totalling 416 lines in this issue.

Topics of the day:

  1. ! NEW authorization bad bugs !
  2. Pulse sequencing [Re: Reinventing the wheel?]
  3. MAX Digest - 29 Apr 1999 to 30 Apr 1999 (#1999-131)
  4. bleues usb interfaces ?? (2)
  5. MAX and knox video switcher
  6. New OTUDP and OpenSoundControl objects
  7. supersonics (2)
  8. Wheels within wheels (live performance sequencers)

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

Date:    Mon, 3 May 1999 09:45:15 +0100
From:    Roland Cahen & Ruth Sefton-Green 
Subject: ! NEW authorization bad bugs !

In the last month I had two quite similar new bugs I 've never had before.
I wanted to change one max intallation from a 5200 to a 5300
and another from a 7600 to a G3/300
As expected, I couldn't de-install them from the previous machines.
(which is already very unpleasant)

But what is new : I couldn't authorize the new machines.
Even if I have got a correct number of authorization left,
(because after having lost all of them with the ancient disks
I bought new key disks.)

So I have to use the key disk each time I want to use Max.
And as you must know as well, using key disk is also a pain
because if you don't put it in the drive before lauching Max,
and wait for the message that asks for it, it crashes the Macintosh badly.

Pace, let us in peace

Roland Cahen

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

Date:    Sun, 2 May 1999 16:14:21 -0000
From:    Nick Rothwell 
Subject: Pulse sequencing [Re: Reinventing the wheel?]

> I'm using coll for a couple reasons: I want each note of a pattern (and
its
> associated velocity and duration) to be independently controllable by a
> Peavey PC1600 (like an analog step sequencer), I want to be able to use
> patterns that cycle over several measures, and I want to be able to have
> several of these going at once, each on its own channel. The coll object
> fits my requirements in every respect except one: switching the data it
> contains to a different pattern.

When faced with similar design decisions year or two ago, I concluded
that the coll object fitted none of my requirements at all.

There are two issues here: the algorithmic behaviour of an interactive
sequencer, and the storage of its configuration.

Behaviour: I ended up coding the sequencer from scratch in C. This is
because I'd designed a semantics for creating and combining sequences
and pulses and the semantics is highly operational.

Motivation: I was convinced that interactive sequencing and
arpeggiation were very similar processes, so I wanted to identify a
lower-level algebra which would support either, as well as
combinations of interactive and preprogrammed behaviour. I was
also interested in controller data (both for input and output). And I
wanted something which would be easy to program and yet generate
unexpected (but reproducable) results.

Brief overview: a sequence is a finite list of notes which might
contain gaps (EMPTY values). A pulse is an object which outputs
numbers at certain times. There are a few predefined sequences (such
as the currently-held notes on a keyboard) and some predefined pulses
(such as the object's input fed from a tempo object, or a clock
divider like a chunk slave, which in itself is a topic for another
day).

There's a kind of pulse which cycles a sequence, resulting in pulsed
output values, and there are programmable rules which determine how
it cycles along the sequencer, how it loops, and so on. Clearly the
output from this can be fed into another pulse, or output as notes or
controllers.

There are several built-in pulses, like fanouts and things. There are
several built-in sequences, like indexers on other sequences,
fixed-length sequences of random numbers, single-item sequences
representing a fader-box setting, and so on.

Sequences and pulses are named, and the name resolution is dynamic, so
I can flip from

        sequence P = pitches:KEYBOARD1

to

        sequence P = [60, 60, 72]

or

        sequence P = append(transpose P0 12, pitches:KEYBOARD2)

and so on. Rebindings take immediate effect.

So much for the sequencing stuff. I decided a long time ago that what
MAX was missing was a way of storing project-specific settings for
generic, library components. Presets don't work because they tie state
into specific object instances. Colls don't work because they are
naive and only have a flat structure. (Stephen's solution works in
simple applications, but doesn't scale, compose or abstract.)

I implemented an object called a Registry. Like colls, registry
objects can share a common data structure which is mapped to a file. A
registry structure is basically a directory tree; each directory has
named entries (much like coll rows) and sub-directories. A registry
can be declared with a pathname into a shared data structure, and can
happily manipulate a sub-tree of the structure. This means that
library components can be declared with path arguments, and the paths
can be cascaded for nested library objects (very useful with
bpatchers). There are bpatchers for creating pop-up menus over
directories, getting preset-like behaviour, and so on.

How does this relate to sequencing? The pulse sequencer is attached to
a registry, using a bpatcher:

        [pulseseq Project.reg MainSequence]

This makes the pulse sequencer instance talk to directory

        /pulseseq/MainSequence/

and all the sequences live in

        /pulseseq/MainSequence/sequences/

the pulses in

        /pulseseq/MainSequence/pulses/

and so on.

There are various other objects (controller binders and scalers, and
sysex librarians) which attach state into project registries as well;
I won't go into the details.

The registry object is available with documentation on the web
site. I'd make the pulse sequencer available as well, but there was so
little interest in the registry last time I announced it that I don't
see a lot of point until/unless I get a chance to write this stuff up
properly and get it published. I'll try to get it online at some
stage, but right now I'm far too busy actually using it all...

--

            Nick Rothwell                  Cassiel.com Limited
            nick@cassiel.com                   www.cassiel.com
            systems - composition - installation - performance

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

Date:    Mon, 3 May 1999 17:58:08 +0200
From:    »yvind Brandtsegg 
Subject: Re: MAX Digest - 29 Apr 1999 to 30 Apr 1999 (#1999-131)

Max runs nicely on my PB540,
I'm not familiar with the PB145 but I think someone on the list
mentioned using it
with max, without any particular trouble.
If you can run Max (68k or FAT) on your machine, and your patches are
well
debugged, I guess your problem have to do with how you compile the patch
into an app. When making a collective, look closely for error massages,
as
these might indicate if some of your externals are corrupted, or if max
is
unable to find some parts of your patches.
Also, when compiling a standalone, you could try using either 68k or
FAT,
and see if that makes any difference for you.
Sorry for the rather sketchy reply, feel free to ask if something is
unclear... the explaination is off the top of my head as I don't have
max
in my office right now.
Oeyvind

Keay wrote:

> Hello All,
>   Have any of you had experience trying to run simple sequencing Max
> Apps on older powerbooks?  Specifically PB145?  I have MAX 3.5.8 and
> have built an application (using the 68k option) and it doesn't fly.  I
> assume it is because the PB isn't a 68k machine?  But, I think I have
> heard of people using this machine with MAx in the past.  Please advise
> on any possible solutions/options.
>
> Thanks,
> keay@hooked.net

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

Date:    Mon, 3 May 1999 10:07:41 +0100
From:    Roland Cahen & Ruth Sefton-Green 
Subject: bleues usb interfaces ??

>From:    v a u g h n 

>
>        has anyone actually used any of the usb midi interfaces that were
>just released?

It is said that it would be preferable to use a usb/serial converter than
the interfaces which would not be as nice as they pretend to be.
Des someone knows more about this ?

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

Date:    Mon, 3 May 1999 20:55:06 +0200
From:    hc gilje 
Subject: MAX and knox video switcher

Anybody have experience on controlling a knox video routing switcher
through serial communication using MAX?

I am able to control it from a pc with a simple serial communication
program, but need the "intelligence" of MAX for making sequences and rapid
switches.

hc

piXel
Hans Christian Gilje
Nedre M=F8llenberggt 9
N-7014 Trondheim
Norway
mob.93497088
http://kit.trdkunst.no/stud/hc
mailto:hc@pobox.com

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

Date:    Mon, 3 May 1999 11:54:33 -0700
From:    Matt Wright 
Subject: New OTUDP and OpenSoundControl objects

I've released new versions of my OTUDP and OpenSoundControl externals,
available for download here:

        http://www.cnmat.berkeley.edu/OSC/clients/max-objs.html

(You can get to all CNMAT Max goodies at http://www.cnmat.berkeley.edu/Max)

OTUDP lets you send UDP packets from, or receive UDP packets to Max, via
Apple's "Open Transport".  It knows nothing about the format of the bytes it
moves around, and does not make any assumptions about what protocol you're
using to format those bytes.  Because Max has no way to represent a buffer
of arbitrary binary data, this object communicates via *pointers* to
buffers,
expressed as Max ints.  So there's not much you can do with this object by
itself in Max; you need another external to format/parse the packets
according
to whatever protocol you want to use.

OpenSoundControl is such an external.  It translates Max data into binary
buffers in the OpenSoundControl protocol, and also parses incoming
OpenSoundControl packets to produce Max data.

The main difference in this release is the use of Open Transport in
"asynchronous" mode, which doesn't change the interface to Max, but seems to
make everything more stable.  There are other reliability-related bug fixes
and some "cosmetic" improvements.

Download and enjoy!

-Matt

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

Date:    Mon, 3 May 1999 19:48:09 +0200
From:    Michael Wieser 
Subject: Re: supersonics

Hi!

Just one more information to make it a little bit more difficult:

It _is_ possible to make AD-Conversations with more then the half AD-sample
rate. And it is  possible to bring out a high quality-signal without much
confusion, if the measured signal is a continous signal (no Jazz-bigband,
more like oscillating amp during development...).
For this kind of sampling-ADCs you will need a very exact timing and
trigger-circuit, a high preamp-bandwith, and some computerpower to put the
sampled informations correct together.
This kind of AD is used for example in ultrahigh frequencies-Oscilloscopes
(some GHz Bandwith). And of course you need some money to buy it, its not a
cheap one....

But ist is not possible to make a DA with the same technic AFAIK.

hth

Michael Wieser
m.k.w@magnet.at

Service and Audiodesign

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

Date:    Mon, 3 May 1999 16:08:05 -0400
From:    Stonewall Ballard 
Subject: Re: supersonics

A sampling oscilloscope is a special case since it *exploits*
aliasing in order to reduce the frequency of a waveform down to the
point that the tube can display it. Analog sampling scopes multiply a
narrow pulse waveform by the input waveform, which produces the sum
and difference frequencies. The difference is what's being filtered
and displayed.

Digital sampling scopes like the Fluke ScopeMeter do this to reduce
frequencies up to 100MHz (for the one I have) down to the point that
they can be run through an A/D and stored in relatively inexpensive
RAM. Costs about $1-2K.

None of this violates sampling theory. It works essentially by
throwing away information.

You can use a D/A to produce frequencies much higher than the Nyquist
limit. Just put a band-pass filter at the right place and use a
narrow pulse instead of a sample & hold on the output of the D/A.
Same principle.

   - Stoney

At 7:48 PM +0200 5/3/99, Michael Wieser wrote:
>Hi!
>
>
>Just one more information to make it a little bit more difficult:
>
>It _is_ possible to make AD-Conversations with more then the half AD-sample
>rate. And it is  possible to bring out a high quality-signal without much
>confusion, if the measured signal is a continous signal (no Jazz-bigband,
>more like oscillating amp during development...).
>For this kind of sampling-ADCs you will need a very exact timing and
>trigger-circuit, a high preamp-bandwith, and some computerpower to put the
>sampled informations correct together.
>This kind of AD is used for example in ultrahigh frequencies-Oscilloscopes
>(some GHz Bandwith). And of course you need some money to buy it, its not a
>cheap one....
>
>But ist is not possible to make a DA with the same technic AFAIK.
>
>hth
>
>Michael Wieser
>m.k.w@magnet.at
>
>Service and Audiodesign

  ---------------------------------------------------
Stonewall Ballard                    Stonetics, Inc.
sb@stonetics.com           http://www.stonetics.com/

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

Date:    Mon, 3 May 1999 23:16:08 +0200
From:    Peter Castine 
Subject: Re: bleues usb interfaces ??

On around 3-5-99 11:07, Roland Cahen & Ruth Sefton-Green said something
like:

>It is said that it would be preferable to use a usb/serial converter than
>the interfaces which would not be as nice as they pretend to be.
>Des someone knows more about this ?

Except that most USB-to-serial converters won't support an externaly
clocked serial port, which means they won't do any of the
widely-available MIDI interfaces.

Leastaways, that's what I read in the newspapers.

Cheers,

Peter

----------------- http://www.prz.tu-berlin.de/~pcastine/ -----------------
Dr. Peter Castine          | I am very pleased to announce that the
4-15 Music & Technology    | 26th International Computer Music Conference
                           | will take place in Berlin in the year 2000.
                           | We look forward to seeing you here!

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

Date:    Mon, 3 May 1999 20:18:29 -0700
From:    Charles Lyons 
Subject: Wheels within wheels (live performance sequencers)

Chris Tignor: I found your description of your own approach to live
performance sequencing very intriguing. When I get further along (ie, I
have something up and running) I'd be interested in comparing notes if you
are.

Wolf: Thanks - I have that object from somewhere, but had forgotten about
it because it's not covered in my manual. It may still come in handy, now
that I know what it's good for.

Charles.

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

End of MAX Digest - 2 May 1999 to 3 May 1999 (#1999-134)
********************************************************