Generative System with built-in constraints
Hello,
I have a fairly complicated idea that I've been attempting to realise through generative systems but cannot get anything to work. Bare with me, I'll try explain as best I can!
The system follows the decimal series of pi and generates a midi output (say to be played on the diskclavier) that "flows" (sounds cohesive, from one 'segment' (say, bar) to another whether that be melodically, harmonically, etc.). To do this, I have paired each digit of the decimal series with the immediate succeeding digit to form these 'segments.' These two-digit combinations determine how many notes are played in each segment, and how many times it is played.
I.e., 3.14159... {14} - 1 note, 4 times; {41} - 4 notes, 1 time; {15} - 1 note, 5 times.
I need the system to do two things:
creative a cohesive "flow" from segment to segment, so it doesn't sound like a random jumble of notes
remember the segments that have come before (so that it can create this cohesion) but to also recognise when the two-digit combination appears again, so that it immediately "plugs-in" what had been already written (but importantly, not use that plugged-in bar to then influence the cohesion of the segments that immediately succeed).
The idea of the work is that as the decimal series is played through, the "flow" will begin to falter as more and more two-digit combinations re-appear.
Any tips? Or perhaps an example of a similar concept that I can try and alter to produce this idea? Any insight would be great.
sounds like a Markov chain
instead of note events and their commonness, store transitions (which note follows which) and their commonness (in percent).
I was definitely looking into Markov chains and just eliminating the possibility to move backwards
https://cycling74.com/forums/generative-system-with-built-in-constraints#reply-6a8f4cb916d57a74bd335d17 can you elaborate a little more on this? I'm unsure how I'd go about adding their commonness
the storing and replaying is not much different from the note statistics you were talking of. you distinguish between different events and then count how often they appear in total.
to find the value for the "chance" parameter you divide the number of each event by the total number of events: 100 notes, among them 5 C3, so C3 will be stored somewhere - including the information that it appears with a chance of 5% or 1:19.
instead of finding C3 and counting how often C3 appears ("60") you will count how often C3 appears right after a E3.
say the first note of the input material is a 64, the second note is a 60.
you will write down "64 60". that is your event.
after analysis is done, you will add the chance, for example write down "64 60, 5.0;" in a [coll]
64 is the state. 64 60 is the transition. 5% is the chance.
if you play from it, that is a first order markov chain.