kongeor
commented
1 year ago That's is an interesting view on this and something that I've spent a significant amount of time to pick the current approach.
Disclaimer: Significant number of evolutionary algorithms details ahead.
A few details on this: The initial iteration has just random notes from each measure chord. There are other ways to generate the initial set of solutions, e.g. completely random, based on the scale, repeating notes etc. The problem with those approaches is that it will take way more iterations for the process to reach a decent melody match. Users most likely would get bored way before reaching the end. The measure chord provides something that sounds in most cases ok and a bit boring. Then the algorithm will push the next solutions onto two paths (that's the way I see it), improving them by getting better root/relative note matches, short/good passing notes etc. or just missing root notes, getting awkward out of key notes etc. Still, the later can provide useful chunks when crossover-ed with other solutions, or if mutation can alter the notes even more and hit the spot. The process will maintain 30% of the best solutions of the previous iteration (that's hardcoded) with a tournament selector of 5 solutions, which means it will not keep always the best, but will likely mix them with less good solutions. In summary, my intention is to maintain a diverse set of solutions for each next iteration.
To prevent bias, to some extent at least, users will get each iteration solutions shuffled (deterministically, so after each refresh the order is preserved). I think it's highly unlikely that someone will listen to the entire solution set of each iteration, and that just a few tracks will get a listen. In that sense, clicking around isn't necessary unless you are very good at reading sheet music :)
The reason why rating is only allowed for subsequent instances is that only those can be taken into account for the evolution process. Rating past tracks can still provide some statistical value, but for now it's disabled so users can change the fitness evaluation.
Maybe a "palate cleanser" would serve? I'm not sure I got what you mean. Could you elaborate please?
I hope this explains some details of the process in more detail.
It is also probably obvious that as many of the things are subjective and boil down to personal taste, some of the design decisions will not match the preference of some users. I hope I get enough data to see how close is the evaluation of the current fitness to what users thing sounds nice or not.
Thank you for your kind words. I'm open for suggestions and will be welcoming PRs, just please note that I need to maintain the current feature set as it is for ~three months, so I can produce some statistical results.
After the feature freeze I'm keen to investigate radically different setups and extend the current set of options.
I'm pretty sure when I listen to subsequent instances, with the same key, progression, etc, they sound 'better', because those musical expectations are 'preloaded' in my brain. I know I run into the problem when composing by hand (or with aleatoric methods).
If I could evaluate completely at random, I'd trust my ratings better, but if I do the somewhat tedious clicking-around to simulate this randomness, I'm probably introducing other biases. In fact, my suggestion might be strictly worse, favoring the parameters that lend themselves to this style of generation (which is too 'bouncy' for anything but a major key and lots of fifths, to my ears so far). Maybe a "palate cleanser" would serve?
PS. Very cool project! I've been wanting to do some stuff along these lines for a long time, and Clojure is my favorite language; maybe I'll find time to contribute!