You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user, I want to specify the Global reference frequency for note 0 of all tunings. After specifying the reference frequency, I want note values to reflect this change, and to be able to re-edit the Global reference frequency in the same way I specified it.
This is a 'should-do' issue, because performance scenarios are often not based on 440Hz, and analysis should reflect the performance scenario.
Approach
An explicit UI for configuration of the base frequency, e.g. toolbar icon -> dialog.
Currently, we define this as an offset from 440Hz (A)
constconfig={
...
noteRefHz: 440*(Math.pow(2,-9/12)),// C, around 261 Hz // TODO: split to be configurable
...
}
It might be helpful to provide a friendly interface to specify a reference frequency (Hz) and offsets in other units.
The UI currently shows the global reference frequency config.noteRefHz at the appropriate point above the tuning rows. So many (nearly all) UI elements depend on config.noteRefHz, so a call to renderApp() will refresh these*.
*An event-subscription pattern would also work, but that would be significant effort and change, hard to maintain, and likely less efficient in practice.
Background
In production workflows, a tuning configuration doesn't specify the base frequency of a tuning (Hz of note 0). Rather that's the responsibility of the virtual instrument, tuning controller, or controller that uses a .kbm (keyboard map file, where reference frequency is embedded).
However, a reference frequency is useful:
if XeTune develops audio previews.
if absolute frequency is important to the analysis experience, e.g. to quantify beat frequency for two playing notes.
The caveat is that XeTune is not responsible for transmitting the reference frequency, because conventional workflows assign this responsibility elsewhere, and the tuning file (in the case of .scl) cannot ordinarily carry this data. Users need to synchronize the two independent sources of reference frequency.
The text was updated successfully, but these errors were encountered:
As a user, I want to specify the Global reference frequency for note 0 of all tunings. After specifying the reference frequency, I want note values to reflect this change, and to be able to re-edit the Global reference frequency in the same way I specified it.
This is a 'should-do' issue, because performance scenarios are often not based on 440Hz, and analysis should reflect the performance scenario.
Approach
An explicit UI for configuration of the base frequency, e.g. toolbar icon -> dialog.
Currently, we define this as an offset from 440Hz (A)
It might be helpful to provide a friendly interface to specify a reference frequency (Hz) and offsets in other units.
The UI currently shows the global reference frequency
config.noteRefHz
at the appropriate point above the tuning rows. So many (nearly all) UI elements depend onconfig.noteRefHz
, so a call torenderApp()
will refresh these*.*An event-subscription pattern would also work, but that would be significant effort and change, hard to maintain, and likely less efficient in practice.
Background
In production workflows, a tuning configuration doesn't specify the base frequency of a tuning (Hz of note 0). Rather that's the responsibility of the virtual instrument, tuning controller, or controller that uses a
.kbm
(keyboard map file, where reference frequency is embedded).However, a reference frequency is useful:
The caveat is that XeTune is not responsible for transmitting the reference frequency, because conventional workflows assign this responsibility elsewhere, and the tuning file (in the case of
.scl
) cannot ordinarily carry this data. Users need to synchronize the two independent sources of reference frequency.The text was updated successfully, but these errors were encountered: