Xenharmonic Wiki:Cross-platform dialogue: Difference between revisions

Godtone (talk | contribs)
reply to sintel abt badness
Fredg999 (talk | contribs)
Request: make Legacy Xen Wiki visually distinguishable
 
(3 intermediate revisions by 2 users not shown)
Line 362: Line 362:
:::::: -- Flora Canou, 17 Jul 2024 (imported from Facebook)
:::::: -- Flora Canou, 17 Jul 2024 (imported from Facebook)


:the badness measure is only to be taken seriously on p-limit subgroups otherwise its too easy to game. previously i did 'penalize' weird subgroups but its not very satifying to do so arbitrarily. i personally only care about temperaments that are good in common subgroups and i support weird subgroups only bc some people requested it
: the badness measure is only to be taken seriously on p-limit subgroups otherwise its too easy to game. previously i did 'penalize' weird subgroups but its not very satifying to do so arbitrarily. i personally only care about temperaments that are good in common subgroups and i support weird subgroups only bc some people requested it
:as for the comment on e.g. Petrtri, I *do* think it should have a much lower badness than meantone! look at the mapping matrix: its about the same complexity as something like Dicot, yet its errors are all ~0.05 cents! thats amazing honestly! but of course that only really matters if you take the subgroup seriously (i dont)
: as for the comment on e.g. Petrtri, I *do* think it should have a much lower badness than meantone! look at the mapping matrix: its about the same complexity as something like Dicot, yet its errors are all ~0.05 cents! thats amazing honestly! but of course that only really matters if you take the subgroup seriously (i dont)
:as for the other thing about subgroup complexity with the 256/243 example: that's actually a good point, had not noticed this before. I will investigate the cause!
: as for the other thing about subgroup complexity with the 256/243 example: that's actually a good point, had not noticed this before. I will investigate the cause!
:[[User:Sintel|Sintel]] ([[User talk:Sintel|talk]]) 21:06, 17 July 2024 (UTC) [copypasta from facebook]
: [[User:Sintel|Sintel]] ([[User talk:Sintel|talk]]) 21:06, 17 July 2024 (UTC) [copypasta from facebook]


:: Why not just penalize it so that [subgroup].p has increasing badness for increasing complexity of p? Or if that leads to a strange normalizer for whatever reason, why not just have all [subgroup].p have equivalent badness assuming that p is unconstrained in all of them? I don't think "the exact normalizer expression that would make all extensions equal badness assuming everything else stays the same" is arbitrary. --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 18:38, 3 October 2024 (UTC)
:: Why not just penalize it so that [subgroup].p has increasing badness for increasing complexity of p? Or if that leads to a strange normalizer for whatever reason, why not just have all [subgroup].p have equivalent badness assuming that p is unconstrained in all of them? I don't think "the exact normalizer expression that would make all extensions equal badness assuming everything else stays the same" is arbitrary. --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 18:38, 3 October 2024 (UTC)
::: I attached another piece of information below. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 18:46, 3 October 2024 (UTC)
: Sintel Microtones Why don't you try your metric on the "monzo" version of logflat badness? Just use the L2 norm on the multimonzo for complexity and simple badness, and this problem may partly solve itself. I think it'll be the same thing you have, but times the subgroup determinant raised to some slightly different power than what you are currently doing.
: When you say that you are mainly trying to compare p-limit subgroups, are you also trying to compare subgroup temperaments of different ranks, or different codimensions, or what? Or just like, 5-limit vs 7-limit meantone, for instance? Because I noticed some weirdness also with p-limit subgroup temperaments - it rates 7-limit meantone as much worse than 5-limit meantone, which is another thing I'm not sure I agree with, as 5-limit meantone practically gives you all of these ratios of 7 for free, with barely no added error!
: -- Mike Battaglia, 18 Jul 2024 (imported from Facebook)
:: Regarding meantone, since septimal meantone is about twice as complex as 5-limit meantone with virtually the same avg error, it should be normal that septimal meantone has about twice the badness.
:: -- Flora Canou, 20 Jul 2024 (imported from Facebook)
:: I noticed if instead of
:: U = W/det(W)^(1/d)
:: you go for
:: U = W/det(W)^(1/r)
:: and thus
:: C = ||M(W)||/det(W)
:: you get invariant complexities and therefore invariant badnesses on the same kernel in arbitrary subgroups. However comparison of temps across ranks/dimensionalities no longer make sense now, so some other factor needs to be introduced.
:: -- Flora Canou, 20 Jul 2024 (imported from Facebook)
::: right, this is the metric I was talking about above regarding the "monzo" version of logflat badness. This is a pretty good start already, but now we have this issue of normalizing things of different rank.
::: The starting point is: how can one meaningfully assign a complexity to two arbitrary JI *subgroups* of different rank? This is useful not just for ranking subgroups themselves to derive temperaments from, but also ranking kernels, which are also just JI subgroups. We could use the Tenney norm of the multimonzo of the subgroup - this is the weighting matrix determinant you have been using - but now we're comparing lengths to areas to volumes, etc, so how do we do that?
::: This is something I put together many years ago but just haven't put on the Wiki, although I never put it all together into any combined metric. But basically the way I did it is to start with what's called the "theta function" or "theta series" of the subgroup as a lattice, but using the L1 norm instead of the L2 norm. We instead just look at the subgroup as a set of intervals, rather than as any kind of geomeric object. The theta function associated to any lattice is all points of the form Sum 1/(n*d)^s on all n/d in the subgroup, where s is a free parameter determining how much we care about more complex intervals. The s is a free parameter that determines how fast complex intervals should roll off, similar to with the zeta function. This can be thought of as representing a kind of "strength" for the subgroup, so that its inverse is a kind of complexity.
::: We do a bunch of analysis with rational approximations at s -> 0 and derive the "lambda function" for the subgroup, which is basically the multimonzo norm/subgroup determinant, but normalized in a certain magic way that makes it all work out. There is one free parameter that simultaneously measures how fast complex intervals should roll off, how much you care about rank, how much you care about larger chords, how simple a new JI interval should be for it to be worth it if you go up a rank and add it, and even the base of the logarithm. There is a closed-form expression relating all of these things and I had some recommended values for this one parameter.
::: Anyway, if you're interested I can write this all up at some point, but if you want to start playing around, you can do so right now just by taking what you already have but changing the base of the logarithm.
::: -- Mike Battaglia, 20 Jul 2024 (imported from Facebook)
== Proposal to promote more admins ==
Over the past few months, the prospect of adding more admins to the wiki has been heavily discussed in the #wiki channel of the Xenharmonic Alliance Discord server.
Several people (myself included) have said they would like to see this happen, and no one on the Discord was against it. However, we do also recognise that many wiki editors do not have access to Discord, including those who actually have the authority to make such a decision, and we think it's essential that everyone be included in such an important discussion as this, not just people on Discord. So that's why I'm writing this, to post on Facebook and on the cross-platform collaboration page on the wiki itself.
The main reason why we would like to see more admins, is that many of the current admins are not online on the wiki very often. No one blames them for this, as they are unpaid volunteers and have lives outside the wiki. However the result of this is that all of the burden of the wiki's day to day administrative tasks falls on the shoulders of the one or two active admins, which isn't really fair on them. They need more hands on deck to help them out.
At the moment, a lot of low-priority admin tasks (like some of the ones in the admin Todo category) just sit gathering dust for years because the few active admins have to spend all their time keeping on top of day-to-day maintenance and don't have the breathing room to get to those. This does harm the overall quality of the wiki. It also has the potential to lead to admin burnout, which would be an existential risk to the wiki given how few active admins we currently have.
There has been a lot of discussion on the Discord about who these new admins should be. Several names were floated of experienced editors who we think would be up to the task. We asked each of those experienced editors whether they would be happy to volunteer as admins, and three of them said yes: Fredg999, Lériendil, and ArrowHead294.
For each of these people, several others commented in favour of their nomination, and no one commented against. I will outline the reasons why we nominated each of these people.
We believe Fredg999 would make a good admin because he has many years' experience as an active editor on the wiki. He has made extensive contributions towards making the wiki more accessible by consolidating existing work into a more navigable structure, and by quality-checking new work and ensuring it meets the wiki's existing standards and conventions. He has made extensive improvements to the category system, merging duplicate categories, categorising uncategorised articles and other improvements along those lines. In short, he has consistently demonstrated the attention to detail, the willingness to do repetitive maintenance work, and the calm, cautious and diplomatic demeanour which are the hallmarks of a great admin. Our existing admin tean exhibits all those qualities, so I think Fredg999 is a very natural addition.
We believe Lériendil would make a good admin because of their dedication to improving existing articles, especially neglected articles like individual temperament pages, and edonoi (nonoctave equal tuning) pages. Lériendil created, and maintains, the temperament infobox, which helps elevate temperament pages to the same level of importance and navigability as EDO pages, a very welcome addition for RTT fans. Lériendil is the founder of, and a highly active contributor to, WikiProject TempClean, which has been doing great work expanding and beautifying pages on individual regular temperaments to give them the quality and depth of coverage they deserve, for such an important component of regular temperament theory (the temperaments themselves!) In WikiProject TempClean, Lériendil has demonstrated the ability to unite, inspire, and organise fellow editors to carry out coordinated maintenance work on neglected pages. This ability is something very valuable to have on an admin team. I think that Lériendil could breathe a lot of life and goodwill into the wiki.
We believe ArrowHead294 would make a good admin because of his extensive maintenance work. He has written documentation for dozens of templates on the wiki, helping other editors to understand how to utilise those templates, and how to debug them. He has also done the painstaking word of renaming dozens of articles to use the correct capitalisation, the correct hyphenation, etc. to match the wiki's conventions, which makes the wiki much easier to search for readers (they don't have to try to remember what capitalisation or what symbol to type into the search box). ArrowHead294 has also worked to locate several instances of wanted pages (lots of red links to the same place), which are actually just different names for existing pages, and has created the necessary redirects to make them worj. It goes without saying how much that has helped improve navigability. ArrowHead294 has also coded, drafted, published and maintained several modules and several templates, which have been a big help in automating the more monotonous parts of page creation, so that editors can be freed up to spend more time writing the main body of the page. This has allowed the relatively small wiki community to punch above its weight in terms of the scale of its ambition amd comprehensiveness. As with Fredg999 and Lériendil, ArrowHead294's willingness to do the mundane, often uncelebrated, but essential day-to-day maintenance work that elevates the wiki to the next level, makes him an excellent candidate for admin.
So, our proposal (the wiki editors on Discord), is that Fredg999, Lériendil and ArrowHead294 should be promoted to admin. For the reasons stated above, we believe they would make great additions to the admin team. Would you be in favour of this too?
—[[User:BudjarnLambeth|BudjarnLambeth]] ([[User talk:BudjarnLambeth|talk]]) 01:19, 5 February 2025 (UTC)
== Request: make Legacy Xen Wiki visually distinguishable ==
I would like to request the implementation of at least one change in the visual aspect of the Legacy Xen Wiki to help visitors distinguish it from the regular Xen Wiki and ensure they are actually browsing the version of the wiki they think they are browsing. For instance, the logo could be made slightly different by adding a "LEGACY" text over the original logo (e.g. at the top or at the bottom), The [[Legacy:Main Page]] could also be edited to make it more obvious that it is on the legacy version, ideally with a link back to the regular version, for example by adding a [[Template:Mbox|message box]]. I don't plan on creating an account on the legacy wiki, so this is why I am requesting the change here. --[[User:Fredg999|Fredg999]] ([[User talk:Fredg999|talk]]) 05:51, 18 February 2025 (UTC)