David Roden

I'm planning to use the coll object to process 'scores' which control a 

large number of performance related parameters in a complex patch.

The idea is to have an entry on each list stored in coll which could 

determine which part of sequence to play, another to start the relevant 

sequencer, others to determine which devices are synch'ed with what, another 

to control javascript programs which manipulate note arrays. Inputting the 

index would cause coll to output the instructions to the rest of the patch. 

The list could also feed probabilities to a prob object to be used in a 

Somethinng like this seems at first sight to be a good answer to the problem 

of how to control a lot of parameters in performance. For example, the same 

score could be used for different improvised note sequences - so some 

One potential drawback is that my lists would probably need to have about 50 

elements. So I'll probably need to design a score editor to cope!

However, I was wondering if other's have gone down this path or have decided 

on a different philosophy of performance.

I'm planning to use the coll object to process 'scores' which control a 
large number of performance related parameters in a complex patch.

The idea is to have an entry on each list stored in coll which could 
determine which part of sequence to play, another to start the relevant 
sequencer, others to determine which devices are synch'ed with what, another 
to control javascript programs which manipulate note arrays. Inputting the 
index would cause coll to output the instructions to the rest of the patch. 
The list could also feed probabilities to a prob object to be used in a 
markov chain.

Somethinng like this seems at first sight to be a good answer to the problem 
of how to control a lot of parameters in performance. For example, the same 
score could be used for different improvised note sequences - so some 
flexibility could be preserved.

One potential drawback is that my lists would probably need to have about 50 
elements. So I'll probably need to design a score editor to cope!

However, I was wondering if other's have gone down this path or have decided 
on a different philosophy of performance.

data-structures-for-scores-in-max

you said you need to edit the lists ... where 

i often use a 2 messagebox system ... one dynamic 

box and the other one set by the first one ...

the second one is the one i bang when i need 

coll is slow ... what about [mtr] or [mslider] 

to store the values? or even messageboxes?

multisliders can be cool bc they give you visual

feedback, even when put in a sub ... mtr can

be cool for playing data bc it can "play two notes

you said you need to edit the lists ... where 
do you edit them?

i often use a 2 messagebox system ... one dynamic 
box and the other one set by the first one ...

the second one is the one i bang when i need 
the current status ...

coll is slow ... what about [mtr] or [mslider] 
to store the values? or even messageboxes?

multisliders can be cool bc they give you visual
feedback, even when put in a sub ... mtr can
be cool for playing data bc it can "play two notes
at a time" without custom programming.

I am currently working on a similar project and have found qlist to be

valuable. You'll want to look at the references but briefly...

If the line begins with a word (symbol) it is understood to be the name of a

If the line begins with a number it represents a delay time between

The main advantage I have found is that it has eliminated lots of routing

clarbassoon attackSequence 1 0 2 0 1 -2 1 0;

flute, oboe, clarinet and bassoon are receive objects. Tutti is a receive

that sends messages to all of them. Clarbassoon - well you get the idea.

By using rewind and next messages I can sequence blocks of data. Here there

are two blocks. With next, the lines beginning with numbers function as

data block delimiters. The wait mess gets send to an object that wait some

number of beats before issuing a next message to qlist.

I am currently working on a similar project and have found qlist to be
valuable.  You'll want to look at the references but briefly...

If the line begins with a word (symbol) it is understood to be the name of a
receive object somewhere in your patch.

If the line begins with a number it represents a delay time between
messages.

The main advantage I have found is that it has eliminated lots of routing
and parsing of data.

tutti chaosSeed 0.5 3.9;
tutti beatSubdivisions 8;
tutti beatDenominator 4;
tutti pitchSieve 0 1 4;
tutti dynamicShape 0.5 0.8 0.6;
tutti pitchShape 0.8 0.;
tutti tempo 90;
tutti phraseBeats 13;
tutti attackSequence 1 0 2 0 1 -2 1 0;
tutti maximumDuration 2;
tutti start;
wait 16;
16;
clarbassoon chaosSeed 0.5 3.9;
clarbassoon beatSubdivisions 4;
clarbassoon beatDenominator 4;
clarbassoon pitchSieve 0 4 7;
clarbassoon dynamicShape 0.5 0.8 0.6;
clarbassoon pitchShape 0.8 0.;
clarbassoon tempo 90;
clarbassoon phraseBeats 13;
clarbassoon attackSequence 1 0 2 0 1 -2 1 0;
clarbassoon maximumDuration 2;
clarinet attackSequence 1 0 1 1 1;
bassoon attackSequence 1 1 0 1 1 0 1;
clarbassoon start;
wait 13;
13;
flute start;
wait 2;
2;
oboe start;

flute, oboe, clarinet and bassoon are receive objects.  Tutti is a receive
that sends messages to all of them.  Clarbassoon - well you get the idea.
By using rewind and next messages I can sequence blocks of data.  Here there
are two blocks.  With next, the lines beginning with numbers function as
data block delimiters.  The wait mess gets send to an object that wait some
number of beats before issuing a next message to qlist.

Cheers,
Gary Lee Nelson
TIMARA Department
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson


It was tedious to have to retype the names of receive objects so I made a

It parses out the words player, wait and clear. Player gets prepended to

all other messages that come through. Wait generates two lines in the

The input is text. For small sets of data I use a message box with commas

to separate. I use text objects to gather blocks of messages and then dump

them into the qlist through the abstraction above. I prefer text over coll

because I don't need the pesky ";" at the end of each line. In addition, I

am generating some of these messages sets algorithmically with programs

It was tedious to have to retype the names of receive objects so I made a
little abstraction to help:

It parses out the words player, wait and clear.  Player gets prepended to
all other messages that come through.  Wait generates two lines in the
qlist. 

The input is text.  For small sets of data I use a message box with commas
to separate.  I use text objects to gather blocks of messages and then dump
them into the qlist through the abstraction above.  I prefer text over coll
because I don't need the pesky ";" at the end of each line.  In addition, I
am generating some of these messages sets algorithmically with programs
external to max.

My reflection on coll is that it is great for some things but clumsy for

sequencing. See my recent posts about qlist.

My reflection on coll is that it is great for some things but clumsy for
sequencing.  See my recent posts about qlist.
Cheers,
Gary Lee Nelson
TIMARA Department
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

Many thanks to all the respondents to this post(so far) for sharing their 

experiences - you've already given me a lot to think about.

Many thanks to all the respondents to this post(so far) for sharing their 
experiences - you've already given me a lot to think about.

data structures for scores in MAX