Talk:Marvel: Difference between revisions

Line 141:

::: I feel whether your algorithm only searches patent vals is comparatively a minor issue. I felt like pointing it out but omitted it in my first reply. I mean perhaps it's highly customizable, as you said, but did you ever customize how it chooses and processes intervals from the tonality diamonds? Did you ever customize the weighting curve? Also when you said it was universally interesting and convincing I wonder who you've tested it with. Why not getting back to the XA Discord server? Everyone misses you (for a debate with you :d). [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 12:03, 17 January 2025 (UTC)

:::: Re: the missed question, sorry, yes you are right I missed it. I falsely assumed you was talking about octave-equivalents and octave-inversions; there are no duplicates counted in the weighting. 3/2 is a single interval; 6/4 and 9/6 and so on should be implicitly taken into account by how much you care about 3/2 alone, AKA as currently coded it should be a consideration of the weighting you use because it would be unintuitive for <code>odd_lim</code> to spit out duplicate intervals proportional to their occurrence. I think it's most intuitive (though I agree not the most correct) to not count duplicates though because IMO it's most similar to how a human would analyse a tuning, but it gives me an idea worth trying. Speaking of the <code>weighting</code>...

:::: Re: "A growing weight suddenly plunging to zero at the edge of the limit is a paradox becuz the limit a user cares about is supposed to be fuzzy, so that there's supposed to be a fairly smooth rolloff." I agree, that's why I highly recommend looking at multiple <code>optimal_edo_sequence</code>s and also why I allowed to customize the <code>weighting</code> parameter/curve easily for both the <code>optimal_edo_sequence</code> and <code>strict_optimal_edo_sequence</code>, but the fact remains that the user is forced to make a choice what kinds of harmony they care about in order to pick a system; this is not a flaw, it's an advantage, because you can use your own experience of what sort of things you like and care about to customize it. The default is to multiply the squared error by the odd-limit thru <code>weighting=lambda x: iv_complexity(x)</code> so that it's equivalent to taking the MSE of the (absolute (normal) or relative (strict)) error times the square root of the odd-limit as I said. There is lots of reasons to prefer a ''harsher'' weighting thru <code>iv_complexity(x)**2</code> instead but I found the results somewhat dubious because usually when one cares about for larger odd-limits one is considering more precise tuning systems and considering more harmonically forcing chords to justify those harmonies, so that the tuning fidelity required is lessened a lot compared to the dyadic tuning fidelity, but I also chose this weak weighting as a compromise towards the perspective that we shouldn't be damaging the simple intervals too much. Maybe most importantly, this weighting allows the new odds introduced to not "dominate" the previous considerations through required tuning fidelity, so that if an edo is good in some set of odds then having a bad odd won't necessarily cause it to be omitted from the sequence if the rest make up for it; by contrast, I found that MSE of error weighted proportional to the odd-limit (rather than square-root) caused a mild "complexity dominance" phenomenon, and if you don't weight it the results aren't related enough to the set of harmonies you chose so even worse than the case of "mild complexity dominance". In retrospect this is likely also an implicit way of accounting for what you mentioned. In other words, if we were looking MSE of pure dyadic tuning fidelity, the weighting would actually be quite absurd at <code>iv_complexity(x)**4</code> (cuz it's multiplied after the squaring step, maybe I should change that but it makes more sense to me to do it after so that the way the algorithm works is easy to understand cuz you won't necessarily be looking at the squared error for example). This would lead to complete dominance, thus creating the "paradox" you raised, so clearly the harmonic context required for more complex harmonies results in a reduction of tuning fidelity required to <code>iv_complexity(x)**2</code>, though I'm not sure how to prove the exact dimensionality of the reduction.

:::: If I made the weighting include duplicates in an odd-limit, the default complexity weighting would definitely need to increase to be proportional to the odd-limit complexity (which I kinda suspect is what it should be and that the reason the results weren't good enough is because of not accounting for duplicates). Would you then trust the results more? And to be clear, for the reasons I gave above having a "falloff" isn't an option as a default cuz it doesn't reflect an explicit set of targeted harmonies; that's why such a weighting option is left to the user to devise instead cuz there's lots of ways of going about it too. I do have some concerns though which I think should be addressed first, which together with everything I already said is I think are why I forgot about the duplicates:

::::: I worry that there will be an "unevenness" introduced whenever a new duplicate is implicitly introduced in an odd-limit, where suddenly an interval has double the weighting, which could cause unexpected results to the user who might not care that 15/10 = 3/2 when inspecting some subset of the 15-odd-limit including 3, 5 and 15. In other words, it's sort of assuming unnecessarily that the only context you care about is complete harmonic series otonalities, as opposed to essentially tempered chords where the duplicate behaviour likely doesn't matter at all, and which along with comma pumps and finite notes is arguably the main point of tempering to an edo. But compounding there's also a sense in which the duplicates are ''already'' being accounted for (other than the indirect way of weighting): since everything needs to obey the patent val mapping, when we introduce odd 15 to the no-7's 9-odd-limit, we are already creating more tuning constraints on 3/2 and 5/4 simply because 3/2 * 5/4 = 15/8 is required to be consistent, so the error weighting on the latter is ''already adding additional tuning fidelity'' because 15/8 is weighted more strongly than 3/2 or 5/4, so in fact every composite that can be reached will be creating more constraints on the tuning.

::::: (Also, it's pretty easy to write a trivial version of <code>odd_lim</code> yourself that doesn't exclude duplicates and then feed that in as the target.)

:::: Re "I said 25/16 was conflated with 14/9, and that no sane person would measure how off the tempered interval was from 25/16 as much as from 14/9." while it's true that often you want to destroy the harmony of more complex intervals in favour of simpler intervals, many of the best temperaments equating two intervals want ''both'' of the interpretations to be usable so that you can use the ambiguity for new progressions not possible in JI, so to reason that it's absurd to consider 25/16's mistuning as a priority is itself absurd to me when it's the simplest odd-limit equivalence other than the one I called trivial, which I didn't do for no reason either; generally I find equating two small consecutive superparticulars, in isolation of other more nontrivial consequences usually implied by them (which often require higher odd-limits!), to not lead to as many musically useful results because you are equating dissonances, for example you'd have to change from 28/15 to 15/8 or vice versa, and stacking 16/15~15/14 doesn't give a very pleasing cluster IMO. For 225/224 the otonal stacking-based equivalence would be (15/8)<sup>2</sup> = 7/2 which tbh doesn't seem very inviting or inspiring to me subjectively (tho let me know if you can think of any cool chords that use this), so the first instance of obvious "musical gold" to me is with switching between 14/9 and 25/16 interpretations in progressions.

:::: Re: "Why not getting back to the XA Discord server?" I don't really want to go back on my word and regardless I left for a variety of reasons which are kinda hard to summarize in a short message, including that I'm tired of arguing for things that seem really obvious to me like I shouldn't have to say them out loud let alone reiterate them let alone push for them; even when some agree no music gets made most of the time anyways, so I'd rather just explore the possibilities of xenharmonic music at my own pace in peace. Basically it feels like noone actually shares my perspective or cares about the things I do in tuning theory and in music making, and due to personal circumstance I have very little energy for making music so I can't be a good example to other people either (especially when I frequently waste my time talking); the launchpad noodles are about as much as I can manage, and I don't think I've seen a single person post a noodle of them trying the [[User:Godtone#Novation Launchpad isomorphic keyboard code|isomorphic keyboard code]] after months of advertising and talking about it; the soonest is in March so maybe I'll rejoin temporarily then). Even the launchpad thing is an example of my experience more generally; AFAIK (which is hard to tell cuz of complete lack of examples posted) usually people just use the launchpad as is without customizing the layout or even considering how much potential is unlocked by easily changing the isomorphic layout with a single run of a Python 3 function. Also, I'm on basically everything else anyways (feel free to invite me to something I'm not on) and I don't really agree with how XA is run so I don't feel good about encouraging it as being the "only" place to talk about xen online (other than FB which I am not touching). Also, I have kinda an increasingly bad feeling about Discord tbh, for example the new ignore feature is absolutely terrible and kinda seals the deal that the right move is to move to revolt.chat (even though it's got less features and is a little less reliable).

:::: --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 18:23, 17 January 2025 (UTC)

@@ Line 141: / Line 141: @@
 ::: I feel whether your algorithm only searches patent vals is comparatively a minor issue. I felt like pointing it out but omitted it in my first reply. I mean perhaps it's highly customizable, as you said, but did you ever customize how it chooses and processes intervals from the tonality diamonds? Did you ever customize the weighting curve? Also when you said it was universally interesting and convincing I wonder who you've tested it with. Why not getting back to the XA Discord server? Everyone misses you (for a debate with you :d). [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 12:03, 17 January 2025 (UTC)
+:::: Re: the missed question, sorry, yes you are right I missed it. I falsely assumed you was talking about octave-equivalents and octave-inversions; there are no duplicates counted in the weighting. 3/2 is a single interval; 6/4 and 9/6 and so on should be implicitly taken into account by how much you care about 3/2 alone, AKA as currently coded it should be a consideration of the weighting you use because it would be unintuitive for <code>odd_lim</code> to spit out duplicate intervals proportional to their occurrence. I think it's most intuitive (though I agree not the most correct) to not count duplicates though because IMO it's most similar to how a human would analyse a tuning, but it gives me an idea worth trying. Speaking of the <code>weighting</code>...
+:::: Re: "A growing weight suddenly plunging to zero at the edge of the limit is a paradox becuz the limit a user cares about is supposed to be fuzzy, so that there's supposed to be a fairly smooth rolloff." I agree, that's why I highly recommend looking at multiple <code>optimal_edo_sequence</code>s and also why I allowed to customize the <code>weighting</code> parameter/curve easily for both the <code>optimal_edo_sequence</code> and <code>strict_optimal_edo_sequence</code>, but the fact remains that the user is forced to make a choice what kinds of harmony they care about in order to pick a system; this is not a flaw, it's an advantage, because you can use your own experience of what sort of things you like and care about to customize it. The default is to multiply the squared error by the odd-limit thru <code>weighting=lambda x: iv_complexity(x)</code> so that it's equivalent to taking the MSE of the (absolute (normal) or relative (strict)) error times the square root of the odd-limit as I said. There is lots of reasons to prefer a ''harsher'' weighting thru <code>iv_complexity(x)**2</code> instead but I found the results somewhat dubious because usually when one cares about for larger odd-limits one is considering more precise tuning systems and considering more harmonically forcing chords to justify those harmonies, so that the tuning fidelity required is lessened a lot compared to the dyadic tuning fidelity, but I also chose this weak weighting as a compromise towards the perspective that we shouldn't be damaging the simple intervals too much. Maybe most importantly, this weighting allows the new odds introduced to not "dominate" the previous considerations through required tuning fidelity, so that if an edo is good in some set of odds then having a bad odd won't necessarily cause it to be omitted from the sequence if the rest make up for it; by contrast, I found that MSE of error weighted proportional to the odd-limit (rather than square-root) caused a mild "complexity dominance" phenomenon, and if you don't weight it the results aren't related enough to the set of harmonies you chose so even worse than the case of "mild complexity dominance". In retrospect this is likely also an implicit way of accounting for what you mentioned. In other words, if we were looking MSE of pure dyadic tuning fidelity, the weighting would actually be quite absurd at <code>iv_complexity(x)**4</code> (cuz it's multiplied after the squaring step, maybe I should change that but it makes more sense to me to do it after so that the way the algorithm works is easy to understand cuz you won't necessarily be looking at the squared error for example). This would lead to complete dominance, thus creating the "paradox" you raised, so clearly the harmonic context required for more complex harmonies results in a reduction of tuning fidelity required to <code>iv_complexity(x)**2</code>, though I'm not sure how to prove the exact dimensionality of the reduction.
+:::: If I made the weighting include duplicates in an odd-limit, the default complexity weighting would definitely need to increase to be proportional to the odd-limit complexity (which I kinda suspect is what it should be and that the reason the results weren't good enough is because of not accounting for duplicates). Would you then trust the results more? And to be clear, for the reasons I gave above having a "falloff" isn't an option as a default cuz it doesn't reflect an explicit set of targeted harmonies; that's why such a weighting option is left to the user to devise instead cuz there's lots of ways of going about it too. I do have some concerns though which I think should be addressed first, which together with everything I already said is I think are why I forgot about the duplicates:
+::::: I worry that there will be an "unevenness" introduced whenever a new duplicate is implicitly introduced in an odd-limit, where suddenly an interval has double the weighting, which could cause unexpected results to the user who might not care that 15/10 = 3/2 when inspecting some subset of the 15-odd-limit including 3, 5 and 15. In other words, it's sort of assuming unnecessarily that the only context you care about is complete harmonic series otonalities, as opposed to essentially tempered chords where the duplicate behaviour likely doesn't matter at all, and which along with comma pumps and finite notes is arguably the main point of tempering to an edo. But compounding there's also a sense in which the duplicates are ''already'' being accounted for (other than the indirect way of weighting): since everything needs to obey the patent val mapping, when we introduce odd 15 to the no-7's 9-odd-limit, we are already creating more tuning constraints on 3/2 and 5/4 simply because 3/2 * 5/4 = 15/8 is required to be consistent, so the error weighting on the latter is ''already adding additional tuning fidelity'' because 15/8 is weighted more strongly than 3/2 or 5/4, so in fact every composite that can be reached will be creating more constraints on the tuning.
+::::: (Also, it's pretty easy to write a trivial version of <code>odd_lim</code> yourself that doesn't exclude duplicates and then feed that in as the target.)
+:::: Re "I said 25/16 was conflated with 14/9, and that no sane person would measure how off the tempered interval was from 25/16 as much as from 14/9." while it's true that often you want to destroy the harmony of more complex intervals in favour of simpler intervals, many of the best temperaments equating two intervals want ''both'' of the interpretations to be usable so that you can use the ambiguity for new progressions not possible in JI, so to reason that it's absurd to consider 25/16's mistuning as a priority is itself absurd to me when it's the simplest odd-limit equivalence other than the one I called trivial, which I didn't do for no reason either; generally I find equating two small consecutive superparticulars, in isolation of other more nontrivial consequences usually implied by them (which often require higher odd-limits!), to not lead to as many musically useful results because you are equating dissonances, for example you'd have to change from 28/15 to 15/8 or vice versa, and stacking 16/15~15/14 doesn't give a very pleasing cluster IMO. For 225/224 the otonal stacking-based equivalence would be (15/8)<sup>2</sup> = 7/2 which tbh doesn't seem very inviting or inspiring to me subjectively (tho let me know if you can think of any cool chords that use this), so the first instance of obvious "musical gold" to me is with switching between 14/9 and 25/16 interpretations in progressions.
+:::: Re: "Why not getting back to the XA Discord server?" I don't really want to go back on my word and regardless I left for a variety of reasons which are kinda hard to summarize in a short message, including that I'm tired of arguing for things that seem really obvious to me like I shouldn't have to say them out loud let alone reiterate them let alone push for them; even when some agree no music gets made most of the time anyways, so I'd rather just explore the possibilities of xenharmonic music at my own pace in peace. Basically it feels like noone actually shares my perspective or cares about the things I do in tuning theory and in music making, and due to personal circumstance I have very little energy for making music so I can't be a good example to other people either (especially when I frequently waste my time talking); the launchpad noodles are about as much as I can manage, and I don't think I've seen a single person post a noodle of them trying the [[User:Godtone#Novation Launchpad isomorphic keyboard code|isomorphic keyboard code]] after months of advertising and talking about it; the soonest is in March so maybe I'll rejoin temporarily then). Even the launchpad thing is an example of my experience more generally; AFAIK (which is hard to tell cuz of complete lack of examples posted) usually people just use the launchpad as is without customizing the layout or even considering how much potential is unlocked by easily changing the isomorphic layout with a single run of a Python 3 function. Also, I'm on basically everything else anyways (feel free to invite me to something I'm not on) and I don't really agree with how XA is run so I don't feel good about encouraging it as being the "only" place to talk about xen online (other than FB which I am not touching). Also, I have kinda an increasingly bad feeling about Discord tbh, for example the new ignore feature is absolutely terrible and kinda seals the deal that the right move is to move to revolt.chat (even though it's got less features and is a little less reliable).
+:::: --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 18:23, 17 January 2025 (UTC)