On 12/17/16 4:48 AM, ddw_music wrote:
Lance Bantham wroteTuning.all.put(\sixteenppo, Tuning.new([1/1, 25/24,10/9, 9/8, 32/27, 6/5, 5/4, 4/3, 25/18, 45/32, 3/2, 25/16, 5/3, 16/9,9/5, 15/8].ratiomidi)); Scale.new((0..16), 16, tuning: \sixteenppo).stepsPerOctave; It says there are 12 steps Per Octave.Oh. It's a bug. Tuning assumes 12 chromatic steps.
No, it doesn't.
stepsPerOctave { ^octaveRatio.log2 * 12.0 }
octaveRatio is an instance variable that very well might not be 2.0. See the stretched/shrunk Tuning examples at the bottom of Scale.sc.
And Scale asks the tuning for its stepsPerOctave. That's... well, I'm speechless. Really? We did that?? Despite this really rather incredible oversight in the programming interface
This method is exactly analogous to Event.stepsPerOctave, and is used in its place when the event contains a Scale object. Event needs to know the the stretched/shrunk octave amount *in semitones* to calculate ~midinote and therefore ~freq. What's so "incredible" about that?
I find the name "stepsPerOctave" to be misleading ("semitonesPerOctave" might be better), but it long predates Scale/Tuning.
> , degreeToKey nonetheless does the right thing: This is not a coincidence. _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: https://listarc.bham.ac.uk/marchives/sc-users/ search: https://listarc.bham.ac.uk/lists/sc-users/search/