User:Contribution/Chanofreq Project: Difference between revisions

(26 intermediate revisions by the same user not shown)

Line 1:

== WARNING! ==

'''WARNING!''' The Chanofreq project has been replaced by the [[User:Contribution/Chanopif Project|Chanopif project]]!

== Chanofreq Project ==

'''Objective:''' The Chanofreq project seeks to create a standardized file format that allows precise tuning of each note on every MIDI channel to a specific frequency. The aim is to achieve this using a minimalistic data structure that prioritizes efficiency and simplicity.

Line 51:

Line 54:

Note: Even if 128-bit precision is used for internal calculations, the output frequencies can be rounded to 64-bit float for compatibility with software and hardware devices.

'''Question:'''

* Would it be advisable to offer modes B and C, given that significant errors can arise with 64-bit floats when using large exponents?

'''Answer:'''

* It should be fine to use 64-bit float, as long as no rounding is applied, we stay within the human hearing range, and the number of notes remains reasonable. For example, if [[125000edo|125,000-EDO]] is programmed from a base frequency (20 Hz) and a factor (1.000005545192819) with exponents to map the entire multi-channel keyboard, after 10 octaves (20480 Hz), one phase error occurs every 2.04 days between two adjacent 64-bit float factor values. For the [[402653184edo|402,653,184-EDO]] tuning scheme within chanofreq using factor and exponents, the phase precision between 64-bit float steps is only 78.9 seconds: 1/(440*(2**(-69/12))*1.0000000017214499**(402653184*(32/3)) - 440*(2**(-69/12))*1.0000000017214496**(402653184*(32/3))) = 78.9 seconds.

In comparison, the phase precision between 32-bit steps in 402,653,184-EDO is 12.86 hours, as calculated here: 1/(440*2**((127-69)/12)*2**(1/402653184)-440*2**((127-69)/12))/(60*60) = 12.86 hours.

This shows that even with 64-bit floating-point precision, the factor and exponent solution is far less efficient than other tuning methods, but remains practical for moderately sized musical scales up to approximately [[125000edo|125,000-EDO]], a size that still ensure a precision equivalent to 6 decimal places rounding in cents. However, using Mode B or C as a mediator for [[402653184edo|32-bit MIDI tuning]] should be avoided.

'''Open Questions:'''

* ~~Would it~~ be ~~advisable~~ to ~~offer modes B~~ and C, ~~given that significant errors can arise with 64~~-~~bit floats when using large exponents?~~

* Should cents or intervals be allowed as an alternative to frequencies? In this case, a base frequency, base note, and base channel would be required. Refer to the .kbm format for guidance. For chanofreq, only a single file should be used to define the full multi-channel keyboard mapping.

* Should hexadecimal representation of frequencies be allowed as an alternative to decimal?

* Should the bitfreq workaround be maintained, or should the standard align with OddSound’s 64-bit floating-point format?

* Mode B and C could use cents.}}

}}

== Syntax ==

@@ Line 1: / Line 1: @@
+== WARNING! ==
+'''WARNING!''' The Chanofreq project has been replaced by the [[User:Contribution/Chanopif Project|Chanopif project]]!
 == Chanofreq Project ==
 '''Objective:''' The Chanofreq project seeks to create a standardized file format that allows precise tuning of each note on every MIDI channel to a specific frequency. The aim is to achieve this using a minimalistic data structure that prioritizes efficiency and simplicity.
@@ Line 51: / Line 54: @@
 Note: Even if 128-bit precision is used for internal calculations, the output frequencies can be rounded to 64-bit float for compatibility with software and hardware devices.
+'''Question:'''
+* Would it be advisable to offer modes B and C, given that significant errors can arise with 64-bit floats when using large exponents?
+'''Answer:'''
+* It should be fine to use 64-bit float, as long as no rounding is applied, we stay within the human hearing range, and the number of notes remains reasonable. For example, if [[125000edo|125,000-EDO]] is programmed from a base frequency (20 Hz) and a factor (1.000005545192819) with exponents to map the entire multi-channel keyboard, after 10 octaves (20480 Hz), one phase error occurs every 2.04 days between two adjacent 64-bit float factor values. For the [[402653184edo|402,653,184-EDO]] tuning scheme within chanofreq using factor and exponents, the phase precision between 64-bit float steps is only 78.9 seconds: 1/(440*(2**(-69/12))*1.0000000017214499**(402653184*(32/3)) - 440*(2**(-69/12))*1.0000000017214496**(402653184*(32/3))) = 78.9 seconds.
+In comparison, the phase precision between 32-bit steps in 402,653,184-EDO is 12.86 hours, as calculated here: 1/(440*2**((127-69)/12)*2**(1/402653184)-440*2**((127-69)/12))/(60*60) = 12.86 hours.
+This shows that even with 64-bit floating-point precision, the factor and exponent solution is far less efficient than other tuning methods, but remains practical for moderately sized musical scales up to approximately [[125000edo|125,000-EDO]], a size that still ensure a precision equivalent to 6 decimal places rounding in cents. However, using Mode B or C as a mediator for [[402653184edo|32-bit MIDI tuning]] should be avoided.
 '''Open Questions:'''
-* Would it be advisable to offer modes B and C, given that significant errors can arise with 64-bit floats when using large exponents?
+* Should cents or intervals be allowed as an alternative to frequencies? In this case, a base frequency, base note, and base channel would be required. Refer to the .kbm format for guidance. For chanofreq, only a single file should be used to define the full multi-channel keyboard mapping.
 * Should hexadecimal representation of frequencies be allowed as an alternative to decimal?
 * Should the bitfreq workaround be maintained, or should the standard align with OddSound’s 64-bit floating-point format?
-* Mode B and C could use cents.}}
+}}
 == Syntax ==