Talk:Marvel: Difference between revisions

Line 120:

:: 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.

:: 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 fourth-simplest composite odd (third-simplest in the 5-limit), after 9/8 which is very simple, 15/8 which is not usually considered to be particularly complex and 21/16 which is similar in complexity, so if 21/16 is included I don't see why 25/16 should be excluded (3*7 vs 5*5), and symmetrically, why aren't we excluding 21/16 if we're excluding 25/16? (I personally don't buy that 21/16 is more important than 25/16 musically so I'm wondering if there is a strong argument for 21/16 being preferred to 25/16 other than being maybe slightly lower complexity.)

::: (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.)

@@ Line 120: / Line 120: @@
 :: 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.
+:: 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 fourth-simplest composite odd (third-simplest in the 5-limit), after 9/8 which is very simple, 15/8 which is not usually considered to be particularly complex and 21/16 which is similar in complexity, so if 21/16 is included I don't see why 25/16 should be excluded (3*7 vs 5*5), and symmetrically, why aren't we excluding 21/16 if we're excluding 25/16? (I personally don't buy that 21/16 is more important than 25/16 musically so I'm wondering if there is a strong argument for 21/16 being preferred to 25/16 other than being maybe slightly lower complexity.)
 ::: (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.)