Atelier Démocratique « Increased comma accuracy »
 Welcome, Guest.
 You can read all messages, but to be able to post,
 please Login or Register.
Nov 19th, 2017, 9:01pm 
   Atelier Démocratique
   Sound output & effects

   Increased comma accuracy
« Previous topic | Next topic »
Pages: 1  Reply | Notify of replies | Send Topic | Print
   Author  Topic: Increased comma accuracy  (Read 4173 times)
Question: Do you support the proposal below?

Yes     8 (61.5%)
No     5 (38.4%)

Total votes: 13

Please read this before voting

     

Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 6033
Increased comma accuracy  
« on: Nov 8th, 2005, 6:19pm »
Quote | Modify

Description:
In the "turkish comma" setting, used also in microtonal adjustment and alternate tunings, increase the accuracy of the parameter (currently 100th of semitone) up to the 10,000th of semitone.
 
Difficulty:

 
Product(s):
offline

Olivier Guillion
Myriad Software
Jean-Armand Moroni
Board Senior Member
****






   


Gender: male
Posts: 1438
Re: Increased comma accuracy  
« Reply #1 on: Nov 9th, 2005, 11:33pm »
Quote | Modify

I am pretty sure nobody would be able to hear the difference. It would complicate (a little) the software for no reason.
offline
Franck Aguila
Beta-tester
Board Master
*****




Jazz'n T.A.B.

   
Email

Gender: male
Posts: 2379
Re: Increased comma accuracy  
« Reply #2 on: Nov 11th, 2005, 8:56pm »
Quote | Modify

Il y a peut-être des gens qui se servent d'Harmony pour des expériences de physique, qui sait ?
offline

Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 6033
Re: Increased comma accuracy  
« Reply #3 on: Nov 12th, 2005, 9:25am »
Quote | Modify

on Nov 11th, 2005, 8:56pm, Franck Aguila wrote:
Il y a peut-être des gens qui se servent d'Harmony pour des expériences de physique, qui sait ?

 
Il paraît que cela s'entend. En chant "Barbershop", lorsqu'un accord "juste" est chanté sur une note longue, une imprécision d'1/100e de demi-ton provoque un très lent effet cyclique dans le son.
Par exemple, sur un La à 220 Hz, le cycle est de 11 secondes. (calcul sur demande )
offline

Olivier Guillion
Myriad Software
Franck Aguila
Beta-tester
Board Master
*****




Jazz'n T.A.B.

   
Email

Gender: male
Posts: 2379
Re: Increased comma accuracy  
« Reply #4 on: Nov 12th, 2005, 12:23pm »
Quote | Modify

11 secondes pour tenir une note chantée, c'est long long long ! Le cas ne doit pas se produire bien souvent. Et ça c'est pour 1/100e de demi-ton. Tu veux bien nous refaire le calcul pour... allez, je suis gentil : un gros millième seulement ?
offline

Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 6033
Re: Increased comma accuracy   aah5th.myr
« Reply #5 on: Nov 12th, 2005, 1:21pm »
Quote | Modify

on Nov 12th, 2005, 12:23pm, Franck Aguila wrote:
11 secondes pour tenir une note chantée, c'est long long long !

La phase complète dure 11 secondes, mais on entend le décalage dès 3 ou 4 secondes, en tendant bien l'oreille.
 
Voila par exemple une note chantée à la quinte juste:

OK, il faut tendre l'oreille
 
Quote:
Le cas ne doit pas se produire bien souvent. Et ça c'est pour 1/100e de demi-ton. Tu veux bien nous refaire le calcul pour... allez, je suis gentil : un gros millième seulement ?

Quelque chose comme 10 fois plus long
« Last Edit: Nov 12th, 2005, 1:21pm by Olivier Guillion » offline

Olivier Guillion
Myriad Software
Jean-Armand Moroni
Board Senior Member
****






   


Gender: male
Posts: 1438
Re: Increased comma accuracy  
« Reply #6 on: Nov 12th, 2005, 11:04pm »
Quote | Modify

on Nov 12th, 2005, 1:21pm, Olivier Guillion wrote:

La phase complète dure 11 secondes, mais on entend le décalage dès 3 ou 4 secondes, en tendant bien l'oreille.
 
Voila par exemple une note chantée à la quinte juste

Ca s'entend effectivement très bien. Raison de plus pour préférer la gamme tempérée : on n'a pas ce genre de désagrément !
 
Des chanteurs - ou d'ailleurs n'importe-quel instrument - seraient incapables d'avoir une telle précision. Mais on peut rétorquer que l'on souhaite avoir via le logiciel le "cas idéal". Quel dilemne...
offline
awolf
Board Newbie
*





   


Gender: male
Posts: 39
Re: Increased comma accuracy  
« Reply #7 on: Sep 23rd, 2006, 10:34pm »
Quote | Modify

If it were just to 10ths of a cent, that could be cool.  Past 10th of a cent is needlessly complex and nobody will ever hear a difference.  10ths of a cent are something though.  Top-level strobe tuners are accurate to 10ths of a cent, and that's somewhere around the limit that people can really hear at.  I would STRONGLY support 10th cent accuracy, but no further.
 
Edit: Ok, while I still say that you can go neverending toward higher and higher resolution, and it is not necessary, I will say this:
The phrasing of 10,000th of a semi-tone is biased and led me toward seeing that as excessive.  But 100ths of a cent doesn't seem crazy, although I'd be happy with 10ths of a cent.
 
Fact is, anyone interested in tuning at all is not thinking about semi-tones, but of cents.  Discussing tuning as portions of semi-tones is misrepresentative.  It sounds biased toward ignorant users who don't understand the idea of tuning and just think in semitones.
 
I'd support 100th cent accuracy, definitely.
« Last Edit: Sep 27th, 2006, 1:49am by awolf » offline
COMALite J
Beta-tester
Board Full Member
***





   
Email

Gender: male
Posts: 793
Re: Increased comma accuracy  
« Reply #8 on: Sep 25th, 2006, 9:34am »
Quote | Modify

Jean-Armand, you're correct nobody could hear the difference in individual notes, but they certainly can hear the difference in multiple notes played simultaneously -- in other words, a chord. The slightest discrepancy causes "beats" to occur and destroys the effect of precise Barbershop (and most other JI) tuning.
 
Basically, the minimum acceptable accuracy is that which would, for the highest audible harmonic of the highest MIDI note, result in an absolute pitch discrepancy of no more than a fraction of a Hz. The discrepancy should be such that the reciprocal of the fraction of the Hz should be a time interval of no less than four times the longest note duration likely to be used.
 
In other words, if the tuning discrepancy is such that a note intended to be 440Hz sounds instead at 440.1Hz, that means that if the two frequencies sounded at the same time, the note would have to last for 1/4th of 10 seconds before you could start to notice the "beats," since in this case the "beat cycle" would be a full ten seconds, and you really don't notice it until about a fourth of that has passed (due to the shape of the sine wave formed by the beats).
 
But, the note in question would also have a harmonic at 880Hz, with the discrepancy at 880.2Hz. That doubles the beat cycle to five seconds, meaning that a note of not much more than a single full second would show noticeable beats. And, of course, there are higher harmonics still.
 
I long ago suggested a much better way to resolve this (read more about it, and vote on it, here: http://myriad-online.com/cgi-bin/workshop/YaBB.pl?board=request;action=d isplay;num=1149826236;start=0). Rather than mess with the Turkish Commas, leave them as they are, but add a new basic Note Parameter called "Fine Tuning." (I believe that there's a Democratic Workshop wish already on the subject.) In MyrScript, it would be "symbol.FineTuning". Unlike the Tuning Offset of Turkish Commas and other tuning methods currently available, Fine Tuning would accept floating point numbers.
 
Think about it: what characteristic of a note is more basic and fundamental than its very pitch? That's at least right up there with such basic characteristics as start time and duration! Right now, though, we consider alterations to the basic pitch to be an "effect," not an actual basic fundamental characteristic of the note itself!
 
Sometimes, pitch alterations really are an effect, such as pitch bends, guitar pulls, vibrato, etc., but when the basic frequency of the note is being changed, to even a slight degree, that is still a fundamental characteristic being changed. It is not an "effect" and shouldn't be treated like one.
 
Turkish Commas should no more be an "effect" than sharps and flats are. After all, those, too, alter a note's pitch by a smaller amount than changing the whole scale degree does. Are they not an "effect"? No. G# is not the same note as G. Bb is not the same note as B. So why should a differently-tuned note be considered the same as the untuned note with just an "effect" added?
 
Moreover, this would make the Barbershop MyrScripts I've been working on for years much easier. At present, to tune a note in MyrScript, I have to check for the presence of an existing Turkish Comma or Guitar Bend or Guitar Pull or any other effect (Ornament in MyrScript) that can possibly alter pitch (I also have to check for Frequency Curve control points). I have to remove any such things if found to affect that note. I then have to add a Turkish Comma Ornament, and set it to its desired value, which has to be an integer even though I really need to assign a real (floating-point) value.
 
How much easier it would be to be able to simply say, "currentNote.FineTuning = {calculated value in real cents}" and be done with it!
 
With my proposed Fine Tuning parameter applied, the frequency of the note as defined by its Coarse Tuning (note name and octave, with accidentals or key signature applied as needed) and Fine Tuning becomes the base frequency of the note. All other pitch-altering effects, including Turkish Commas themselves, as well as Guitar Bends / Pulls, Frequency Parameter Curves, Slurs Played Smooth, and of course Vibrato, would apply their alterations to this base frequency, just as they currently do to the Coarse Tuning frequency alone.
 
Oh, in case I didn't make it clear: the unit of Fine Tuning is in cents, but it can be fractional cents due to the floating-point nature of the parameter. This allows the tuning to be accurate to whatever the underlying playback engine is. The Myriad Digital Soft Synth, Virtual Singer, and MIDI would likely have different levels of accuracy, but at present we can't fully access any of them. I know that MIDI using ordinary everyday MIDI Pitch Bend events (the ones sent by the Pitch Bend wheel on typical MIDI keyboards) defaults to having 40.96 times more accuracy than Turkish Commas, Frequency Curve points, etc. allow users of Myriad programs to access, and that resolution can be doubled by a simple SysEx. The MIDI Tuning Spec approved by the MMA (the people in charge of the MIDI standard, sort of like how the W3C is in charge of World Wide Web standards) would allow resolution far greater than that.
 
If the MMA (consisting of the makers of all MIDI gear, and also of many major musicians and composers) thought that almost 41 times the whole cent resolution of Myriad products wasn't anywhere near good enough resolution, do you honestly think that you know more than they do on the subject of what's enough?
 
At the present time, Myriad products cannot even export to MIDI with sufficient resolution, using ordinary Pitch Bends!
« Last Edit: Sep 25th, 2006, 9:37am by COMALite J » offline
Jean-Armand Moroni
Board Senior Member
****






   


Gender: male
Posts: 1438
Re: Increased comma accuracy  
« Reply #9 on: Sep 25th, 2006, 9:39pm »
Quote | Modify

on Sep 25th, 2006, 9:34am, COMALite J wrote:
Jean-Armand, you're correct nobody could hear the difference in individual notes, but they certainly can hear the difference in multiple notes played simultaneously -- in other words, a chord. The slightest discrepancy causes "beats" to occur and destroys the effect of precise Barbershop (and most other JI) tuning.

Yes, I understood that when Olivier explained it, and posted an example. My answer (above, in French) was "It is clearly audible. One more reason to prefer tempered scale: you do not get into such trouble! "
« Last Edit: Sep 25th, 2006, 9:40pm by Jean-Armand Moroni » offline
kHz_Robert
Beta-tester
Board Junior Member
**




U.S.A. Pop, Jazz, Folk, Classic

   


Gender: male
Posts: 323
Re: Increased comma accuracy  
« Reply #10 on: Sep 26th, 2006, 10:21pm »
Quote | Modify

     
 I know in design that some things must occur before other things can occur.  
    COMALite J says " Rather than mess with the Turkish Commas, leave them as they are,..."
   But COMALite J,  Would the Turkish coma solution be a good start from this point in time?  We could at least begin to listen to the results.
    I mostly suport you COMALite J , as your the  most devoted of the users for a solution and a barbershopist.  
    I do hear the beat or out of tune of the sample.  I have not developed an ear to listen for babershop.   I can only imagine how out of tune it sounds for barbershopers.  
     
 
     
« Last Edit: Sep 26th, 2006, 10:54pm by kHz_Robert » offline
COMALite J
Beta-tester
Board Full Member
***





   
Email

Gender: male
Posts: 793
Re: Increased comma accuracy  
« Reply #11 on: Sep 27th, 2006, 5:03am »
Quote | Modify

on Sep 26th, 2006, 10:21pm, kHz_Robert wrote:
     
 I know in design that some things must occur before other things can occur.  
    COMALite J says " Rather than mess with the Turkish Commas, leave them as they are,..."
   But COMALite J,  Would the Turkish coma solution be a good start from this point in time?  We could at least begin to listen to the results.
    I mostly suport you COMALite J , as your the  most devoted of the users for a solution and a barbershopist.  
    I do hear the beat or out of tune of the sample.  I have not developed an ear to listen for babershop.   I can only imagine how out of tune it sounds for barbershopers.

Well, they do give this only one star of difficulty. But I can't see how they'd do it without breaking compatibility with older files. Integers require less storage space than floating-point values (two bytes for a "short" integer ranging from either -32,768 to +32,767 or from 0 to 65,535 vs. four bytes for a "short precision" real number), and the interpretation of the data in those bytes is drastically different.
 
To handle this, they'd have to specifically modify the data in incoming files from older versions, changing the stored Tuning Offset parameters of existing Turkish Comma Ornaments on-the-fly from integers into floating-point values.
 
If they increased the resolution of other existing tuning methods, the same thing would be true.
 
On the other hand, using my method means creating a new parameter that doesn't exist (and indeed cannot exist) in older files, so no conversion is necessary. A MyrScript may be written to allow a user to convert Turkish Commas into Fine Tunings if they want, but it would not be automatically done because maybe the composer actually wanted them to be true Turkish Commas, not just a handy way to do microtuning.
 
There's also the small matter that Turkish Commas are visible ornaments, and so have to be made invisible but still playable before printing for professional purposes, if you're just using them for microtuning. That's extra work. Fine Tuning, being a basic note parameter, would be invisible.
 
Then there's the whole conceptual matter: the pitch of a note is a basic parameter, not an effect. It shouldn't be treated as an effect. As it is, past versions of the software, for instance, forgot to take Turkish Commas into account when playing Slurs set to "Play It Smooth." They later fixed this, but that would've broken any song from a previous version wherein the composer worked around that bug, perhaps by using Frequency Parameter Curves.
 
With Fine Tuning as a basic parameter that's added to the coarse pitch of the note to produce its basic pitch, all other pitch-altering effects would automatically be given that basic pitch as their starting points. No need to check lots of other things for unplanned interactions, such as the above problem.
 
As I see it, my method would be easier to develop, have fewer compatibility issues both with scores from previous versions and with existing features, is more logically and rationally proper, and far easier to work with especially from MyrScript.
 
Tuning a Barbershop Major Third in a Scale Root (I) Chord, using MyrScript: currentNote.FineTuning = -13.6862861351652
 
Or, if you want to actually calculate it: currentNote.FineTuning = (log(5/4)/log(2))*1200 - 500
 
Or, using a Function that I wrote in my MyrScripts that I've been working on:
 
currentNote.FineTuning = JI2centsFromET(5,5/4) -- "5" for Semitone #5 from the Root (a major third), and "5/4" (1.25) for the desired Barbershop Major Third Just Intonation ratio.
 
Or, using some Tables to look up the desired values given a string containing the desired position of a desired chord type (in this case, an empty string denoting a standard Barbershop Major Triad, and the second entry therein to denote the Major Third of that chord type):
 
currentNote.FineTuning = JI2centsFromET(chordParts["" ][2][1],chordPosJI[chordParts[""][2][2]])
 
Now, imagine the work it would take to do that with Turkish Commas. As I said before, first I have to check to see if any Ornament attached to the note is any of the six Turkish Comma types. So, I have to loop through the Ornaments, then through the six Turkish Comma types. If I find one, I have to change its value, and check to see if there are any others that might override it. If I don't find one, I have to add one, then set its value.
 
And that doesn't even take into account handling the other ways that a note might be microtuned. For instance, if you import a MIDI file that uses MIDI Pitch Bends for microtuning (a common practice), the Pitch Bends don't come in as Turkish Commas (rounded to the nearest integer cent). They either come in as control points in a Frequency Parameter Curve if your Global Setup / MIDI Import settings have the "Compute parameter curves from: Pitch bend" checkbox checked, or as Guitar Pull marks with a Delay and Rise Time of 0 (and, of course, the Tuning Offset rounded to the nearest integer cent) if that box is unchecked. So, I'd have to check for the existence of those as well.
 
Fine Tuning is just so much easier and better for all concerned. It's what we in America call a "win-win" solution.
« Last Edit: Sep 27th, 2006, 5:04am by COMALite J » offline
ajourdane
Board Newbie
*






   
WWW | Email

Gender: male
Posts: 41
Re: Increased comma accuracy  
« Reply #12 on: Jan 31st, 2008, 11:21pm »
Quote | Modify

Mais si je ne m'abuse, le côté cyclique est voulu, c'est un effet recherché dans la musique orientale, de la construction des oeuvres aux notes elles-mêmes. Cela correspond à l'équilibre.
 
Perso, je m'arrête aux 9 commas par ton alors 100e de 1/2 ton, ça suffit amplement.
offline

A. JOURDANE
Pages: 1  Reply | Notify of replies | Send Topic | Print

« Previous topic | Next topic »

« Atelier Démocratique » Powered by YaBB 1 Gold - SP 1.1!
YaBB © 2000-2002,
Xnull. All Rights Reserved.

Top of page
Legal information Last update:  (c) Myriad