data structures for scores in MAX

May 17, 2006 at 1:24pm

data structures for scores in MAX

Hi,

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.

I await your responses with interest!

Best wishes,

David Roden

#26016
May 17, 2006 at 2:15pm

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 …

($1 $2 $3 $4) – [prepend set] – []

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.

-110

#77283
May 17, 2006 at 3:11pm

#77284
May 17, 2006 at 3:35pm

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…

Lines in qlist are of two kinds:

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.

You can play a qlist or step through it.

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

Here is sample from WW quartet:

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
http://www.timara.oberlin.edu/GaryLeeNelson

#77285
May 17, 2006 at 4:10pm

A follow-up to my recent message…

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

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 200 99 45 196617 wait $1;
#P inlet 42 36 15 0;
#P message 254 169 33 196617 clear;
#P newex 42 97 62 196617 prepend set;
#P message 173 170 68 196617 append $1 \;;
#N comlet attach to qlist;
#P outlet 42 212 15 0;
#P newex 42 61 130 196617 route player wait clear;
#P newex 42 127 45 196617 prepend;
#P newex 42 150 78 196617 prepend append;
#P newex 42 173 53 196617 append \;;
#P fasten 3 2 7 0 127 87 259 87;
#P fasten 3 1 9 0 87 92 205 92;
#P fasten 3 1 5 0 87 92 178 92;
#P fasten 7 0 4 0 259 204 47 204;
#P fasten 5 0 4 0 178 199 47 199;
#P connect 0 0 4 0;
#P connect 1 0 0 0;
#P connect 2 0 1 0;
#P fasten 9 0 1 0 205 146 47 146;
#P fasten 3 3 2 0 167 119 47 119;
#P connect 6 0 2 0;
#P connect 3 0 6 0;
#P connect 8 0 3 0;
#P window clipboard copycount 10;

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 output is attached to a 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.

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

#77286
May 17, 2006 at 7:59pm

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
http://www.timara.oberlin.edu/GaryLeeNelson

#77287
May 18, 2006 at 11:13am

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.

Kind regards,

David

#77288

You must be logged in to reply to this topic.