interesting little list generation challenge...
okay, so I'm building a dynamic quantizer system, and we're basing it on [M4L.PitchScale.bpatch] - have a look if you want, it's really a neat implementation of otherwise simple stuff. This uses live.grid to emulate Live's own Scale device, and it looks the business.
Okay, so far so good. Now, I have a system from which I'd like to be able to output a little list like "0 3 7" and have this be enough to properly format the live.grid for the full octave.
Ideally I'd have "0 3 7" come out as "0 0 0 3 3 3 3 7 7 7 7 0", if you follow my drift? A reference to a substitution for each note, in a way, and it can be seen as a type of "upsampling" of a list, I guess.
So far I've made what I believe to be the first part of the equation: measuring how far apart the notes in my little triad are from each other, so that I can "pad it out" with duplicate notes. This is where I am, and this is where I'm stuck:
Any input from The Gang would be much appreciated. I'm afraid this is a much needed patch for us, and the available abstractions/externals aren't exactly what we need - Chris Muirs and VJ Manzos stuff is great, though, but the project has some very specific requirements.
Again, thanks for your ideas, people.
This solution isn't pretty, but it works for the case in your post, and the one in your patch (and for another case I added). That said, it wasn't entirely clear exactly what transformation from input list to output list you where expected to occur. A fun challenge nonetheless.
This is an edit of Util.GenerateQuantizeTables from ScaleMaster2
brilliant - both of you! I am so close I can almost smell it, hehe.
Now, with both solutions there is the same little idiosyncracy, like if I put in "0 4 7 9" I get:
0 0 0 0 4 4 4 7 7 9 9 0
and
0 0 0 0 4 4 4 7 7 9 9 9, respectively.
Now, in a normal quantizer wouldn't you want the minor third quantizing to the the major third instead of the root?
This is one of the things I've been trying to crack, and I'm dying to have this work in a way that a quantizer would expect.
I'm thinking that the list once would work - then you'd get the 0 on the 11th step, which would be ideal, too - but only in some cases... jeez, this is making my head explode a bit.
thanks again for your time... loving watching this come together!
how about this way (not sure if addresses all your concerns):
It certainly looks like it does! I'm cobbling together a test patch with an interface, hope to get testing this weekend!
if it doesn't do exactly what you want, you might try tweaking this bit [expr ($i1+$i2)/2.].
at the moment it just gets the mean of two scale degrees, (and uses that value to decide if the pitch is closer to one or the other quantizing degrees) but you might get more useful results if you add or subtract a small fraction to the mean (no more than 0.5). haven't tried it myself but
Here's another approach using fuzzy logic - it doesn't do the octaves at the moment and may need some tweakingt.
Basically the list at the top is a fuzzy set that defines how closely a test value matches a particular scale degree. This is the set for zero so zero scores 1.0, 1 scores 0.833 and so on. If you rotate the zero set you get the sets for the other degrees.
So when you input a chord, each scale degree (0 to 11) is tested to see how nearly it approaches each degree of the chord. This produces a list and when you take its maximum you get the member of the chord that the current degree most closely resembles. This goes to [zl group 12].
a simple maximum may not be quite what you want.
Richard
thanks again, guys. I finally got something to work as I planned in this process, hehe. It feels good, I gotta say.
here's like a 19 second demo of it working. Patch will be open and available as soon(tm) as it's done.
https://www.youtube.com/watch?v=Hy3PAUUfz6o