Talk:Marvel: Difference between revisions

Line 113:

: [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 08:27, 16 January 2025 (UTC)

:: In response to the choice of odd-limits/tonality diamonds, the answer is very simple: we assume pure octaves so that all octave-equivalents and octave-inversions of every interval in the tonality diamond is included implicitly with equal weighting. In other words, part of the rationale for using pure octaves is that it makes the use of odd-limits perfectly natural because there is no bias to specific octave-equivalents or octave-inversions, so that we can truly just think about the approximations of pairs of odd numbers which vastly simplifies analysis (the usefulness of which should not be underestimated). This is also important because any nonzero tempering of the octave causes an infinite number of intervals of any odd-limit to become arbitrarily inconsistent, though in practice this usually doesn't matter. In other words, it's a far clearer direction to optimize for an explicit set of harmonies and then consider octave-tempering afterwards than first allowing octave-tempering and then being unnecessarily paralysed by choice, which IMO causes things like TE to look artificially natural as solutions because they accept the fact that the choice becomes very arbitrary if you allow tempered octaves to justify a disembodied method of optimization that is purely in terms of the basis. That's not to say such a scheme of optimization has no value of course, but it's important to acknowledged the limitations and especially the assumptions of any optimization scheme.

:: In response to "all complexity weighting faces the paradox that a growing weight suddenly plunges to zero at the edge of the limit" - this is not a paradox, this is completely expected, and this is exactly why I showed a large range of different odd-limits you could consider, to show that generally the same systems appear for basically all the 7-limited odd-limit targets one might want to consider practically.

:: In response to "makes no sense for marvel as 25/16 is already conflated with 14/9. If I may propose an odd limit to look at, I'd say 21", it kinda feels like you ignored my paragraph explaining why 25/16 is important to consider as the minimum odd-limit for judging how truly optimized a marvel tuning really is.

:: In response to "pls stop citing it as if it was some kind of objective metric", it's highly customizable and in my experience the lists it gives are pretty universally both interesting and convincing, so I encourage anyone interested in tuning optimization to explore with it (and to raise any concerns on my talk page) as I think most of the lists produced are better and more practically useful than the current standard on the wiki (depending on the exact settings used ofc, but I tried to create the most neutral default I could think of); you are doing the same thing with the metric you wrote, no? And more importantly, I don't think it's reasonable to assume all readers are interested in the optimization philosophy you are proposing where only the simplest intervals are cared about by the optimizer, and I don't even think 25/16 is that complex; it's clearly musically relevant and corresponds to the third-simplest composite odd, after 9/8 which is very simple and 15/8 which is not usually considered to be particularly complex.

::: (And before/in case you ask, yes I am aware that it only searches patent vals; you can edit the val used for an edo manually thru EG <code>patent_vals[80] = val(lim(255),ed(80),'koprsuvBC')</code>; I don't have the skill or energy to write code that auto-deduces the best val and plus that process seems to be something that requires human judgement anyways IMO so it seems better to leave it up to the user to "fix" the vals from patent in whatever way they deem reasonable/optimal; plus the best val depends on the set of target harmonies, meaning that the val would have to be deduced every time the function is run potentially which I suspect would slow down the search a lot as I don't think a proper solution to the problem of finding the right val would be light on computation (I don't think that simply taking the patent thru a stretched octave is the right solution in general, even if it usually gives the right results). Plus, I'm admittedly suspicious of using warted vals by default because of two considerations: for small edos, warting the val causes implausibility amounts of damage, and for large edos, one would hope that the edo is good enough that you don't need to use a non-patent val, except for warting maybe one prime, and if it really is that good then you'd hope that it can afford to take the damage from using the patent mapping for that prime and still appear in whatever <code>optimal_edo_sequence</code> you are considering.)

:: I'm okay with leaving the page as is at the time of writing though; I just wanted to respond to your points.

:: --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 17:51, 16 January 2025 (UTC)

@@ Line 113: / Line 113: @@
 : [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 08:27, 16 January 2025 (UTC)
+:: In response to the choice of odd-limits/tonality diamonds, the answer is very simple: we assume pure octaves so that all octave-equivalents and octave-inversions of every interval in the tonality diamond is included implicitly with equal weighting. In other words, part of the rationale for using pure octaves is that it makes the use of odd-limits perfectly natural because there is no bias to specific octave-equivalents or octave-inversions, so that we can truly just think about the approximations of pairs of odd numbers which vastly simplifies analysis (the usefulness of which should not be underestimated). This is also important because any nonzero tempering of the octave causes an infinite number of intervals of any odd-limit to become arbitrarily inconsistent, though in practice this usually doesn't matter. In other words, it's a far clearer direction to optimize for an explicit set of harmonies and then consider octave-tempering afterwards than first allowing octave-tempering and then being unnecessarily paralysed by choice, which IMO causes things like TE to look artificially natural as solutions because they accept the fact that the choice becomes very arbitrary if you allow tempered octaves to justify a disembodied method of optimization that is purely in terms of the basis. That's not to say such a scheme of optimization has no value of course, but it's important to acknowledged the limitations and especially the assumptions of any optimization scheme.
+:: In response to "all complexity weighting faces the paradox that a growing weight suddenly plunges to zero at the edge of the limit" - this is not a paradox, this is completely expected, and this is exactly why I showed a large range of different odd-limits you could consider, to show that generally the same systems appear for basically all the 7-limited odd-limit targets one might want to consider practically.
+:: In response to "makes no sense for marvel as 25/16 is already conflated with 14/9. If I may propose an odd limit to look at, I'd say 21", it kinda feels like you ignored my paragraph explaining why 25/16 is important to consider as the minimum odd-limit for judging how truly optimized a marvel tuning really is.
+:: In response to "pls stop citing it as if it was some kind of objective metric", it's highly customizable and in my experience the lists it gives are pretty universally both interesting and convincing, so I encourage anyone interested in tuning optimization to explore with it (and to raise any concerns on my talk page) as I think most of the lists produced are better and more practically useful than the current standard on the wiki (depending on the exact settings used ofc, but I tried to create the most neutral default I could think of); you are doing the same thing with the metric you wrote, no? And more importantly, I don't think it's reasonable to assume all readers are interested in the optimization philosophy you are proposing where only the simplest intervals are cared about by the optimizer, and I don't even think 25/16 is that complex; it's clearly musically relevant and corresponds to the third-simplest composite odd, after 9/8 which is very simple and 15/8 which is not usually considered to be particularly complex.
+::: (And before/in case you ask, yes I am aware that it only searches patent vals; you can edit the val used for an edo manually thru EG <code>patent_vals[80] = val(lim(255),ed(80),'koprsuvBC')</code>; I don't have the skill or energy to write code that auto-deduces the best val and plus that process seems to be something that requires human judgement anyways IMO so it seems better to leave it up to the user to "fix" the vals from patent in whatever way they deem reasonable/optimal; plus the best val depends on the set of target harmonies, meaning that the val would have to be deduced every time the function is run potentially which I suspect would slow down the search a lot as I don't think a proper solution to the problem of finding the right val would be light on computation (I don't think that simply taking the patent thru a stretched octave is the right solution in general, even if it usually gives the right results). Plus, I'm admittedly suspicious of using warted vals by default because of two considerations: for small edos, warting the val causes implausibility amounts of damage, and for large edos, one would hope that the edo is good enough that you don't need to use a non-patent val, except for warting maybe one prime, and if it really is that good then you'd hope that it can afford to take the damage from using the patent mapping for that prime and still appear in whatever <code>optimal_edo_sequence</code> you are considering.)
+:: I'm okay with leaving the page as is at the time of writing though; I just wanted to respond to your points.
+:: --[[User:Godtone|Godtone]] ([[User talk:Godtone|talk]]) 17:51, 16 January 2025 (UTC)