z_tuning (tuning mod for norns)

Oootini · April 28, 2022, 11:10pm

@doomglue are you using this with sines?

doomglue · April 29, 2022, 5:53am

Yes in 20 characters.

Oootini · April 29, 2022, 6:49am

Huh. Ok weird. It’s definitely not working for me.

doomglue · April 29, 2022, 7:00am

Did you activate the mod and also changing the scale requires a reload or at least a nudge of the freq (haven’t tried that yet)?

moono · April 29, 2022, 11:19am

@zebra @delineator maybe some noobish question and without any deeper understanding of both the underlying concepts: wouldn’t it be great if pitfalls and z_tuning somehow could be merged/combined?

zebra · April 30, 2022, 3:16am

i’m not sure what that would mean. the two projects have little in common save that both have something to do with tuning. they serve quite different purposes:

z_tuning is a simple plumbing utility, with exactly one feature: it allows arbitrary, pre-defined tuning algorithms to be applied to norns scripts system-wide. this makes tuning configuration totally separate from script development. this is how i like it.
pitfalls on the other hand, is a script with many features that enable the interactive construction and development of tunings using a particular construction method/theory (an EDO division, combined with a set of intervals to create a scale.)
i should also mention the fretwork script by @synthetivv which is similar to pitfalls in that it also provides a rich feature set for exploring and manipulating a different tuning theory (that of Just Intonation, complete with routines to generate Johnston notation and so on.)

z_tuning is not creatively ambitious in the manner of those scripts. (for me, the work of tuning theory investigation doesn’t need to be done interactively with visual feedback; writing a lua routine to generate ratio sets is the perfect level of abstraction for me.)

instead, the mod’s single feature aims to be implemented in a complete and flexible way, allowing all types of tuning theories to be applied (and certainly many types of algorithms i haven’t thought of. for example: though the most obvious and - probably - common way to add a new tuning definition is by generating a set of ratios per degree, it is additionally possible to provide any function to perform note->hz conversion; it need not even be “determenistic” or “repeatable”…)

i’ll give a concretre exampe: the z_tuning factory files include an edo_augmented tuning definition which is one of the family of tunings covered by pitfalls. (i use a lot more JI than EDO but threw this in there as an example.)

github.com

catfact/z_tuning/blob/main/lib/data/edo8_augmented.lua

--- a chromatic scale constructed from EDO8/EDO16

-- EDO8 ratios are applied to chromatic degrees closest in pythagorean tuning
-- intermediate degrees are interpolated with EDO16

local phi8 = math.pow(2, (1 / 8))
local phi16 = math.pow(2, (1 / 16))
local deg8 = {1, 3, 4, 6, 7, 9, 10, 12}
local deg16 = {2, 5, 8, 11}
local r = {}
local theta = 1
for _, deg in ipairs(deg8) do
   r[deg] = theta
   theta = theta * phi8
end
for _, deg in ipairs(deg16) do
   r[deg] = r[deg - 1] * phi16
end

return { ratios = r }

i didn’t formulate it this way, but this can be expressed in the “EDO interval” notation: the division is EDO16, and the interval pattern is… uh… {2, 1, 2, 1, 1, 2, 1, 1, 2, 1, 1}, i think. a helper function to generate this kind of ratio set might look like:

-- @param division: division of the octave defining the smallest interval
-- @param intervals: set of intervals to use in constructing this tuning
function edo_interval_ratios(division, intervals)
  local ratios = {1}
  local r = 1
  local phi = 2.0 ^ (1/division)
  for _,interval in ipairs(intervals) do
    r = r * (phi ^ interval)
    table.insert(ratios, r)
  end
  return ratios
end

(i could add a special Tuning constructor of this form… but honestly i don’t see the need: the ratio set is what matters here, and there are an infinite number of ways to generate or describe those. )

anyways… one place i can imagine having useful interoperabilithy between this mod and scripts like pitfall or fretwork, would be to give those scripts the abinlity to export tunings in z_tuning's format; then other norns scripts can use them. (although i think fretwork can already export scala files? so maybe that’s already done.)

another point worth considering: something thing that z_tuning conspiciuously lacks is interpretation of scala keyboard mapping files (or any other concept of a “keyboard mapping” as distinct from tuning or temperament.) i went into the project fully intending to support these, but decided that the model doesn’t actually make musical sense to me (e.g. i don’t see why root frequency should be associated with keyboard->scale degree mapping) and i find it just as easy to create the tuning directly for the desired scale in the first place.

i’d be interested in hearing suggestions for how to manage keyboard mappings that isn’t a big headache. but i’m more inclined to provide helper functions and architecture for constructing “tunings” on the fly that fit the desired scale.

ah right, maybe this is already clear, but

as far as i can tell, pitfalls doesn’t use the musicutil note->hz conversion routines. so z_tuning will not affect it at all, and nothing more needs to be done.

aaanyways, what i really wanted to say here is that i bumped the z_tuning version to 0.1.0 and updated the top post with thew new readme contents.

the main new feature is the addition of parameters. so now diferent scripts can use different tunings via PMAPs.

one oddity of these parameters that you may notice is that there are multiple ways to adjust the root note. they are detailed in the readme, but the _pivoting mode is maybe worth special mention since i don’t know anyone else who likes to do this.

having these different modes as parameters is pretty nice. it allows, for example, a pattern i’ve enjoyed for a long time in playing JI modulations, where one keyboard plays notes and a second keyboard changes the temperament root in
realtime (using either the _adjusting or _pivoting modes.)

i also added that bend table thing. i recommend using this instead of pointlessly recalcluating the bend offset for each degree every time a note is played.

also added an API function to create and add new tunings on the fly. not so sure about this, it runs into some awkwardness with the implementation of the option param type, i haven’t tested it much, and maybe there are nicer options (like, say, ability to specifiy current tuning in RAM without messing with the options list.)

anyways, this is alpha 2, LMK if you spot weirdness.

oh right which reminds me

sorry! i can’t reproduce any problems beyond the UX oddness pointed out above (an artefact of the way the sines script works.) the predictable debug questions apply: does the mod work with other scripts? in what way is it “not working?” (many of the tunings differ only subtly unless you’re pretty used to hearing them.) are there other matron messages indicating success / failure? etc.

eigen · April 30, 2022, 4:52pm

ah yeah, sorry for not being explicit: pitfalls does get conflicted by the midi out pitch bend feature to z_tuning I had been toying with.

i’ll look into porting it to the new release, maybe look into MTS as well and submit a PR

Oootini · April 30, 2022, 7:27pm

Thank you!! I’ll dig in when I get a chance

moono · April 30, 2022, 7:54pm

thx for your exhaustive answer, which goes way above my understanding of the whole matter. from now on i will remain in astonished silence and leave the field to the professionals ; )

edit: when i reread the second part of my above answer, i realize that it might come across a bit snippy - which was not my intention. anyway - thanks again for your clarification. and hey - i think, now i know, why you are the “deletor” ; )

steveflato · May 1, 2022, 12:10am

for some reason i cannot for the life of me find the fretboard script. anyone have a link?

zebra · May 1, 2022, 12:42am

My bad, it is actually called fretwork

…except actually maybe this is not what I was thinking of either. Or I hallucinated the Johnston notation stuff

… ah! the mystery is solved. the stuff i was looking at is on a different branch. i’ll leave any further discussion of that to kenji (and sorry for discussing it prematurely)

steveflato · May 1, 2022, 1:41am

thanks @zebra – do we have a thread for fretwork yet or is it just on github? I’m having some trouble loading it and didn’t want to hijack this thread.

synthetivv · May 1, 2022, 4:12am

Hello! Yes, sadly the fret* family of scripts has been languishing for a while in a state that could reasonably be described as both half-baked and overcooked, but I’m gratified to hear they’re on your radar, or indeed anyone’s. This is a well-timed nudge, as I believe I’ve finally hit upon a living situation that will give me the time & brain space to work on such projects again.

There’s some feature overlap with z_tuning – most notably, both fretwork and fretboard include their own Scala interpreters. Now that z_tuning exists (thank you @zebra !) I’m gonna want to revisit that. But like you said, these are scripts and z_tuning is a mod that helps other scripts do new things.

The Johnston notation feature wasn’t a hallucination, but I don’t think it’s in a very useful state at the moment, and I suspect I would have written a lot of that code differently if I were to do it all again. I was really into metatables at the time, and everything looked like a nail. But if anyone’s interested in using that script (or any other unreleased/sketchy ones on my GitHub account), DM me anytime.

this sounds fun as hell.