Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The tuning problem: XT2 plans #6983

Open
1 of 4 tasks
Andreya-Autumn opened this issue Apr 23, 2023 · 5 comments
Open
1 of 4 tasks

The tuning problem: XT2 plans #6983

Andreya-Autumn opened this issue Apr 23, 2023 · 5 comments
Labels
Breaking Change In order to close this issue we need to make a breaking change (no backwards compatibility) Discussion Tuning Non-standard tuning extensions
Milestone

Comments

@Andreya-Autumn
Copy link
Collaborator

Andreya-Autumn commented Apr 23, 2023

EDIT: See comment.

This issue is meant to be a list of potential tuning UI/UX improvements we want to make for XT2.

The tuning of a given note can be resolved either by calculating frequency(key + modulation) or frequency(key) + modulation. Presently, Surge will use one out of these two behaviors across the board always, user selectable as "Apply tuning at MIDI input" vs. "Apply tuning after modulation".

For the user this basically translates into: "pitch parameters/modulations set constant offsets which apply equally to all notes" vs: "pitch parameters/modulations set offsets which cleverly follow the loaded scale". No difference at all while you stay in 12-equal, but any other scale this makes a big difference.

There is also the question of whether frequency offsets are resolved in log2-space (jives well with human musical perception, creates consistent harmonic relations, or linear space (for inharmonic bell-like funtimes etc), which we also want to support.

These things are working ok for us now, but there are some situations that we can't yet resolve in a satisfying way, leading us to consider updating the tuning api in the oscillators (and filters and anything else that's tuneable) to have not one, but three points of entry: Fixed log2 Offset, Scale-Bound log2 offset, Linear Offset.

  • Make the before/after option local, so you can have a microtuned sequencer being pitch bent with constant offset or other combinations like that. This will require some thought to not make the UX too complex. But seems like it'd be worth pursuing.

  • Make the oscillators play the scale 1/1 when keytrack is disabled.

  • Make oscillator pitch dial a bit more predictable in "after modulation" mode (at least with respect to the 1/1), by making the degrees of the loaded scale appear on the dial in the same place they would if the same interval were typed in in "apply before" mode. For unequal scales, this assumes 0=the scale 1/1. The user needs understand they won't necessarily hear the same offsets from every MIDI key, which is ok maybe? For equal scales other than 12-edo, this would just be nice though, since it would simply mean the max reach of the param in pitch is the same whether your scale has 12 notes/octave or 34. EDIT: See comment

  • Let octave dials offset by the scale repetition interval instead of 2/1. But optionally, so you can do things like 2/1 offsets in Bohlen-Pierce scales.

@Andreya-Autumn
Copy link
Collaborator Author

...this issue is a bit weird since it's a collection of thoughts after a convo we had. But it's probably the right place for this:

Recently some of us have been helping Sjoerd add MTS-ESP support to Firefly. In the latest version it became clear that tune-after can break inter-osc FM patches with pitch ratios dialed in between the oscillators. Any unequal scale will also have (often extremely) unequal timbres in such patches. Not great.

Surge would do the same today in tune-after mode, I figure the only reason we haven't had a complaint about it yet is that (unlike Firefly) Surge's inter-osc FM isn't great.

The whole experience leaves me feeling like we've probably been overthinking the tune-after thing. It probably shouldn't have been a global option (that applies to pitch sliders etc) at all, but an optional behavior of the relevant modulators only.

So instead of tuning the pitch slider (with downsides like FM breakage, #6977, point 3 above, etc) we could, optionally, tune the mod output of the pitch bend and step sequencer sources (and any others we deem relevant).

That'd keep all the pitch calculation everywhere in semitones. And RMB on pitch bend/step seq would get a fairly self-explanatory "follow tuning" in place of the less commonly understood "apply tuning after modulation".

@mkruselj
Copy link
Collaborator

That sounds like a great idea and a major improvement to me.

@Andreya-Autumn
Copy link
Collaborator Author

Right? It'd simplify code and UI both. But is a major break so probably not something we can do in XT1.

@mkruselj
Copy link
Collaborator

Yes definitely. Adding the breaking change tag.

@mkruselj mkruselj added the Breaking Change In order to close this issue we need to make a breaking change (no backwards compatibility) label Aug 28, 2024
@baconpaul
Copy link
Collaborator

what about an lfo applied to filter cutoff

filter cutoffs are in keys (or more accurately "are a 2^n frequency scale so constant distance is constant audible difference")

where would you want to apply the tuning in that case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change In order to close this issue we need to make a breaking change (no backwards compatibility) Discussion Tuning Non-standard tuning extensions
Projects
None yet
Development

No branches or pull requests

3 participants