The following texts and examples are taken from emails sent by Rod describing some existing DFS composiitons implemented in Max/MSP.
so i guess as a general overview of things
the ability to define a random amount of events. the ability to have weighted random durations, and something to account for synchronous/asynchronous individual voices
for the most part theres no more than 3 roles, though one piece has a ton of individual voices. that could be dynamic in that it could upscale to 20 or whatever, just generating more random events from the same pool
so there are 3 independent voices/parts.
on init, a random amount of sections are generated:
(all the patches have a ‘practice’ mode where all the durations and count-ins are shortened, for easy testing)
each event has a random duration, that’s weighted, so it has a tendency to bunch up over time:
and for each (randomly timed event) there is a generated “idea”:
most of the code there is to clear and cue the mini display. it basically sends a random one of these.
now each performer gets a random one of these. each performer has their own random timer, but there is a probability of them syncing up. this is defined here:
so i boiled “sync” down to a single variable. so at the start of the piece, 80% of the time we have our cues together (though not the same cue), then this drifts, then eventually drifts back together again.
the piece ends after the predefined amount of total events (defined at the start) happen. BUT it counts each individual performers event as an event (so the event count goes by quite quickly). it also only ends when the next unison change happens together. so if its a total of 50 events, we can get up to 60+ or whatever. once the 50th event happens, the NEXT unison sync (80% probability) triggers the actual END
ill put each piece in a diff email, but the rest probably wont be as detailed
same engine. random section totals, random weighted duration for each section. but 7 individual voices. no sync here, so all voices happen willy nilly, asynchronously
each role is defined like this (with a weighted likelihood for certain roles happening more than others)
Next piece, “Meta Battle”
starts of similarly, with a random amount of sections
the same RandomDuration subpatch is used for the timing, but in this piece, all performers see the same thing. so there’s only one ‘voice’ here.
each voice here is like this
there are battle pieces, with certain ones requiring a ‘leader’. that’s a sep coll with people’s names in. in the max version i predefine that, but with the new version, that can just take peoples input.
then ends a similar way. once total event amount is reached, next event ends the piece.
And the last of my pieces “Pitchy”
this one is quite diff
so one performer is designated as a ‘leader’, and everyone else is support.
the leader can hit the space bar and generate a 5 note cluster. it’s doing some random stuff, then converting freq to midi numbers, to get some weird spacing in the clusters
each performer (however many are needed) see the same chord. including the soloist.
the first 10 chords are stored in a coll and can be recalled by using the keyboard number keys (1 through 0). so hitting “1” will recall the first random chord. hitting “7” will recall the 7th random chord, etc…
you can make new chords in perpetuity, but only the first 10 are stored.
and that’s it for this piece. it’s stopped “manually”
I asked Rod to describe a little more about his concept of voices in the existing setup as that was a term he referred to.