data structures for scores in MAX

    May 17 2006 | 1:24 pm
    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

    • May 17 2006 | 2:15 pm
      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.
    • May 17 2006 | 3:11 pm
    • May 17 2006 | 3:35 pm
      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
    • May 17 2006 | 4:10 pm
      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:
      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
    • May 17 2006 | 7:59 pm
      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
    • May 18 2006 | 11:13 am
      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,