Xenharmonic Wiki talk:Things to do: Difference between revisions
→Comma tables in EDO pages: 3 replies |
|||
| Line 291: | Line 291: | ||
:: Hmm, IMO, reducing patent vals wouldn't help. It seems your problem is the general idea of monzos being "musician-unfriendly", in which case maybe you'd prefer "musician-friendly monzos" where primes are octave-reduced and octave-complemented to be in the 0c to 600c range, and where all ratios written in the form of these "musician-friendly monzos" are octave-agnostic, with a "number of octaves" specified only if needed but otherwise deduced to be the right amount for the context. --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 22:39, 18 January 2021 (UTC) | :: Hmm, IMO, reducing patent vals wouldn't help. It seems your problem is the general idea of monzos being "musician-unfriendly", in which case maybe you'd prefer "musician-friendly monzos" where primes are octave-reduced and octave-complemented to be in the 0c to 600c range, and where all ratios written in the form of these "musician-friendly monzos" are octave-agnostic, with a "number of octaves" specified only if needed but otherwise deduced to be the right amount for the context. --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 22:39, 18 January 2021 (UTC) | ||
::: I never said monzos are musician-unfriendly, only vals aka edomappings. I think octave-complemented monzos would be too confusing. I agree you can omit the first number of a monzo if you know the cents are below 1200¢. I do this myself sometimes, especially for commas, but I'm not suggesting the xenwiki do that. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 03:57, 19 January 2021 (UTC) | |||
:: Duplication of information is a severe problem we discussed. The tendency to copy&past from table to table raises the danger of spreading errors and making much more work... That's the problem I have with all that information. I had much hope in your comments, @Kite, but to be honest, I still don't see in how far this information will be helpful for you. Just saying I like it is not enough in my opinion. Can you please explain your personal use of comma information? --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 06:31, 12 January 2021 (UTC) | :: Duplication of information is a severe problem we discussed. The tendency to copy&past from table to table raises the danger of spreading errors and making much more work... That's the problem I have with all that information. I had much hope in your comments, @Kite, but to be honest, I still don't see in how far this information will be helpful for you. Just saying I like it is not enough in my opinion. Can you please explain your personal use of comma information? --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 06:31, 12 January 2021 (UTC) | ||
| Line 307: | Line 309: | ||
:::: In terms of the risk of errors due to duplication of information in tables, this shouldn't be a problem if the tables are computer-generated or at least computer-checked. I kind of presumed they were at least in part (either generated or checked, or both)... I have some (quite unpolished) Python 3 code that could be relatively easily used to verify commas' ratios, monzos and cent sizes, but I have yet to figure out a good general-purpose way to ''find'' the commas that a rank one temperament tempers, mainly because I can't think of a good general-purpose way of thinking of what commas are meaningful/interesting, as there are many very complex commas that might be considered of interest, such as [[Tolermic_family|the tolerma]], which is interesting mainly because of the variety of commas it can combine with and the unique resulting tempered arithmetics/rank one temperaments. The only thing is the tables would have to list information in a predictable way so that code could be made that accepts text input and spits out any inconsistencies, but I presume they are mostly already in that format? Removing the "comments" column could help with this. As for "hovering", maybe we could just show the patent val and the cents and the hover can give the ratio if needed? I've seen the ratio appear as a hover in other parts of the xen wiki already, and it'd remove one of the columns, the only problem is some commas may be more easily identifiable by their ratios than their vals, and hovering doesn't (necessarily?) work on phones (and probably some other devices). Removing the "prime limit" column in favour of having rows that separate the prime limits is something I can get behind, especially if it means we can instead list commas by JI subgroup interpretations of a rank one temperament rather than just by the rather restricted (but not unuseful) "prime limits" construct. This would also be very beneficial to rank one temperaments with multiple valid JI subgroup interpretations, such as [[9edo]]. The only thing is the rows that separate different comma subgroups should be bolded or made easy to spot in some way. (Oh and BTW, my name is based on my nickname for my favourite JI interval, [[23/20]], which is just about 2 cents sharp of 1 step of 5 EDO. I was gonna mention it on my user page at some point later but I wanna get a bulk of my thoughts/theories about microtonal music written first before I talk about it.) --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 22:39, 18 January 2021 (UTC) | :::: In terms of the risk of errors due to duplication of information in tables, this shouldn't be a problem if the tables are computer-generated or at least computer-checked. I kind of presumed they were at least in part (either generated or checked, or both)... I have some (quite unpolished) Python 3 code that could be relatively easily used to verify commas' ratios, monzos and cent sizes, but I have yet to figure out a good general-purpose way to ''find'' the commas that a rank one temperament tempers, mainly because I can't think of a good general-purpose way of thinking of what commas are meaningful/interesting, as there are many very complex commas that might be considered of interest, such as [[Tolermic_family|the tolerma]], which is interesting mainly because of the variety of commas it can combine with and the unique resulting tempered arithmetics/rank one temperaments. The only thing is the tables would have to list information in a predictable way so that code could be made that accepts text input and spits out any inconsistencies, but I presume they are mostly already in that format? Removing the "comments" column could help with this. As for "hovering", maybe we could just show the patent val and the cents and the hover can give the ratio if needed? I've seen the ratio appear as a hover in other parts of the xen wiki already, and it'd remove one of the columns, the only problem is some commas may be more easily identifiable by their ratios than their vals, and hovering doesn't (necessarily?) work on phones (and probably some other devices). Removing the "prime limit" column in favour of having rows that separate the prime limits is something I can get behind, especially if it means we can instead list commas by JI subgroup interpretations of a rank one temperament rather than just by the rather restricted (but not unuseful) "prime limits" construct. This would also be very beneficial to rank one temperaments with multiple valid JI subgroup interpretations, such as [[9edo]]. The only thing is the rows that separate different comma subgroups should be bolded or made easy to spot in some way. (Oh and BTW, my name is based on my nickname for my favourite JI interval, [[23/20]], which is just about 2 cents sharp of 1 step of 5 EDO. I was gonna mention it on my user page at some point later but I wanna get a bulk of my thoughts/theories about microtonal music written first before I talk about it.) --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 22:39, 18 January 2021 (UTC) | ||
::::: I like removing the comments column. To judge a comma meaningful/interesting, why not just use some sort of taxicab distance? [[Commas_by_taxicab_distance]]. Or maybe just limit the absolute value of the numbers in the monzo. Perhaps the 2-exponent is unlimited, 3-exponent is <= 12, 5-exponent is <= 8, 7-exponent <= 6, etc. That should get all important commas. If hovering doesn't work on touchscreens, we probably shouldn't implement it. I sort of like your idea of header rows for each prime subgroup, but I fear it might be too cluttered. I imagine ordering the 7-limit prime subgroups as 2.3, 2.5, 3.5, 2.3.5, 2.7, 3.7, 5.7, 2.3.7, 2.5.7, 3.5.7, 2.3.5.7. We've gone from 3 categories to 11. And the 6 two-prime subgroups have only 1 comma in them. 11-limit adds 15 more categories, 4 with only one comma. In general, N categories expands to 2^N - N - 1 categories. That's a lot of header rows! --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 03:57, 19 January 2021 (UTC) | |||
:: The octave reduced version of (patent) vals can easily be added in EDO pages, but in this case the first value would be zero. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 06:31, 12 January 2021 (UTC) | :: The octave reduced version of (patent) vals can easily be added in EDO pages, but in this case the first value would be zero. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 06:31, 12 January 2021 (UTC) | ||
| Line 313: | Line 317: | ||
:::: This kind of argumentation does not convince me at all. We don't need to redefine a well-known concept to justify a non-zero cell in a table. If we have the tables about prime intervals (and we have and will have even more of it) all that information will be obvious. I'm planning a layout which has two separate rows (original values and octave-reduced ones i.e. <code>v % edo</code>), it's somewhat like the table in [[User:Xenwolf/Fifthspan#Separate mod steps]] (without the ''fifthspan explained'' rows). It's possible to produce tables like this automatically. The only thing (after implementing fifthspan calculation in Lua, after having it done in Python) is to figure out appropriate coloring or border styles for better orientation in the then bigger table. IOW: let the [[patent val]]s be as they are: we will have a more obvious presentation of the information you wish. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 07:32, 15 January 2021 (UTC) | :::: This kind of argumentation does not convince me at all. We don't need to redefine a well-known concept to justify a non-zero cell in a table. If we have the tables about prime intervals (and we have and will have even more of it) all that information will be obvious. I'm planning a layout which has two separate rows (original values and octave-reduced ones i.e. <code>v % edo</code>), it's somewhat like the table in [[User:Xenwolf/Fifthspan#Separate mod steps]] (without the ''fifthspan explained'' rows). It's possible to produce tables like this automatically. The only thing (after implementing fifthspan calculation in Lua, after having it done in Python) is to figure out appropriate coloring or border styles for better orientation in the then bigger table. IOW: let the [[patent val]]s be as they are: we will have a more obvious presentation of the information you wish. --[[User:Xenwolf|Xenwolf]] ([[User talk:Xenwolf|talk]]) 07:32, 15 January 2021 (UTC) | ||
::::: Wow, your user page is quite impressive! Did you do it manually or by computer? I like the format you have with two separate rows for unreduced and reduced vals. Prime 2 being reduced to zero is absolutely no problem in this format. You might want to change the row label from "mapping" to "nearest mapping". I do think fifthspans should be allowed to be negative, just like the errors are. --[[User:TallKite|TallKite]] ([[User talk:TallKite|talk]]) 03:57, 19 January 2021 (UTC) | |||
== Improve accessibility of wiki and present info in a non-technical way == | == Improve accessibility of wiki and present info in a non-technical way == | ||