User:BudjarnLambeth/My opinion on zeta peak indexes: Difference between revisions

BudjarnLambeth (talk | contribs)
Created page with "<div style="border: 1px green solid; background-color: #efe; padding: 0.5em 1em; margin-bottom: 1em"> __NEWSECTIONLINK__ ;(!!!) ;This is not a proper wiki page. It is NOT FACTUAL unlike the rest of the wiki, it is ONLY OPINION. ;The rest of the wiki is supposed to be 100% fact, 0% opinion. ;This page is the opposite. This page is 0% fact, 100% opinion. ;This page is only ever intended as a casual opinion column which never tries to..."
 
BudjarnLambeth (talk | contribs)
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 17: Line 17:
</div>
</div>


I ''don't'' believe that zeta peak indexes are the ''most'' mathematically perfect, optimal equal tunings possible. I don't think that there is anything especially about zeta peak indexes that sets them apart from any other stretched/compressed-octaves or stretched/compressed-tritaves tuning.
I ''don't'' believe that [[zeta peak index]]es are [[Optimization|mathematically perfect]], optimal [[equal tuning]]s. I don't think that there is anything especially about zeta peak indexes that sets them apart from any other [[Stretched and compressed tuning|stretched/compressed-octaves or stretched/compressed-tritaves tuning]].


But I still really like zeta peak indexes, because they are ''good enough'' for me. They usually approximate most of the the most important primes better than their pure-octaves/pure-tritaves equivalent edo/edt, with very few downsides.
But I still really like zeta peak indexes, because they are ''good enough'' for me. They usually approximate most of the the most important [[prime]]s better than their pure-octaves/pure-tritaves equivalent [[edo]]/[[edt]], with very few downsides.


This isn't because there's anything special about zeta peak indexes - any other method of slight equave stretching/compression would achieve exactly the same positive effects. Zeta peak indexes are probably not ''perfectly'' optimised.
This isn't because there's anything special about zeta peak indexes - any other method of slight [[equave]] stretching/compression would achieve exactly the same positive effects. Zeta peak indexes are probably not ''perfectly'' optimised.


But I don't care about perfect, I care about good enough. They are a ''good enough'' improvement upon their edo/edt counterpart that I'm happy with them.
But I don't care about perfect, I care about good enough. They are a ''good enough'' improvement upon their edo/edt counterpart that I'm happy with them.


And I like that they're very easy to name. It just looks so much cleaner to say "I used 127zpi for this track" rather than "I used 38.7cet" for this track. I like not having to just pick an arbitrary cents value.
And I like that they're very easy to name. It just looks so much cleaner to say "I used 127zpi for this track" rather than "I used 38.7[[APS|cet]]" for this track. I like not having to just pick an arbitrary [[cents]] value.


It's the same reason why I like using a big edo to tune a regular temperament: It's too hard having to choose between TOP and TE and POTE and WE and all of those. But if most of those agree that a particular edo is part of the temperament's optimal ET sequence, I'll just use that edo. I just like the simplicity of quantising to an edo, and I just can't be bothered fussing over hundredths of a cent.
It's the same reason why I like using a big edo to tune a [[rank-2 temperament]]: It's too hard having to choose between [[TOP]] and [[TE]] and [[POTE]] and [[WE]] and all of those. But if most of those agree that a particular edo is part of the temperament's [[optimal ET sequence]], I'll just use that edo. I just like the simplicity of quantising to an edo, and I just can't be bothered fussing over hundredths of a cent.


So are zeta peak indexes special? No. Any other method of octave/tritave-stretch/compression works just as well.
So are zeta peak indexes special? No. Any other method of octave/tritave-stretch/compression works just as well.