> The chromatic scale is a special case of a symmetric scale which cannot be transposed.
I would not agree here. I think you can transpose a chromatic scale, but you end up with the same "set" of pitches. (So you _can_ transpose, but if you only consider the _set of pitches_ you end up with a invariant.
But scales are not just a set of pitches, but also have a root note.
You can establish the key of C and play a chromatic scale from c' up to c'' and there would be the feeling to accept C as the root of the scale.
So the chromatic scale is kind of a _total_ (all 12 pitch names) and _trivial_ example, as you pointed out, very symmetric and usually not so interesting for analysis if you want to detect and describe structure.
In general it depends on the music. If the music is based on diatonics, then a major scale or it's modes will be a fitting primitive for analysis, considering chromatic notes something like side notes.
On the other hand 12-tone music uses a chromatic scale as a basis, negating the structure and hierarchy of diatonic scales.
So I don't see a problem with transposing a chromatic scale, it's useful and necessary for mathematical sound systems (helpful for computation) to define operations, even if there is no direct gain (functionally speaking - identity / mempty etc.) :
I join you in the frustration around the bad adoption and low interest in the X.org->Wayland transition, but I cannot agree with most statements of your rant. Thus I want to make some comments.
1. Change is hard. No one will write their program to support protocols that are not widely adopted in the first place. At the same time, no one will switch to wayland, if there are no or not enough applications supporting it.
In some transitioning state there will be a point where two protocols would have to be supported, if you want to serve your software (although for Wayland there are several workarounds to run X-applications in Wayland).
Also we are seeing some momentum finally and big desktops/distros adopt wayland as their default. So the boss battle you talked about seems over, as X.org will no longer be actively developed. Now it's the question how to smoothly transition.
2. I want everything to work out of the box and not care about the internals. ("Do Windows users care what Microsoft calls its own display manager? Do Mac users care about theirs? Android users? No one cares. They care that they can watch videos and play games.")
If you really only care about that, Mac might be a better choice for you. I enjoy linux because of it's transparency here and the opportunity to dig into some code, understand the internals and modify stuff to your liking. A sound protocol would be the basis for that.
There are still some reasons, why you should care:
- If developing software is easier, you will obviously benefit in the long run. Especially with open source software. It will be easier to contribute to projects like window managers.
- It's okay, if you don't care about DPI, but you do care if your hiDPI does not look good, which seems to be an issue for X.org in multi-monitor setups (which are quite common).
Personally, I am more surprised that the whole _let's replace X.org_ effort was such a niche project, although a sound window server is just such a fundamental aspect of a OS that supports GUIs. So you might rant about, why are there only one monolith and one possible alternative - and why do we have a fundamental part of the system which is so hard to replace and not abstracted by a more general protocol. The real critique that points to why getting wayland to work would point more to the past in my opinion.
In that regard it's also no surprise that it is taking so long. You realize that so many basic things (clipboard, screenshots, window managers) where directly bound to a specific display server because it allowed most things you wanted due to it's _wild_ freedom.
So for your wishes I think it goes like this:
1. Replace X.org with a sound protocol (I can only see Wayland) - getting rid of X.org and establish a protocol
2. Let's have competing protocols from there on, or let's just have the major interest in Wayland and developed it together. If we're over X.org, there will be a natural interest and hopefully development and adoption will be quicker from then on.
Starting with restrictive security and take the struggle of seeing how far you get is something, you as a user should appreciate. You talk about all the other security issues, but if all the other devs would also have that mindset, maybe things would work out to be more secure.
As security is mostly hidden from users (even techie users), I cannot support the statement _functionality > security_. Set security=0 and you're always on the right track?
For every feature where you have to sacrifice security, you should be able to give good reasons. A single security issue could make _all_ features of the program insecure.
In a good security model you will also be able to hand over permissions, so I expect Wayland to make it possible for me as a superuser to allow for some apps to have some permissions (like screenshot apps to access the rendering of other applications) or some apps to log your keystrokes - but once entering to a password field, Wayland could also take those permissions back...
For all of these things, having a secure and restrictive starting point and work on from there is necessary.
P.S: I do not know the wayland protocol in detail, so I don't know if the right choices have been made. But I like that they did not chose the easier part of starting with: We need to support exactly the same as X.org does (which would probably lead to similar problems) but to make the window server part right and enforce other parts of the systems to change as well, where things are just not the job of the window server.
I would not agree here. I think you can transpose a chromatic scale, but you end up with the same "set" of pitches. (So you _can_ transpose, but if you only consider the _set of pitches_ you end up with a invariant.
But scales are not just a set of pitches, but also have a root note.
You can establish the key of C and play a chromatic scale from c' up to c'' and there would be the feeling to accept C as the root of the scale.
So the chromatic scale is kind of a _total_ (all 12 pitch names) and _trivial_ example, as you pointed out, very symmetric and usually not so interesting for analysis if you want to detect and describe structure.
In general it depends on the music. If the music is based on diatonics, then a major scale or it's modes will be a fitting primitive for analysis, considering chromatic notes something like side notes.
On the other hand 12-tone music uses a chromatic scale as a basis, negating the structure and hierarchy of diatonic scales.
So I don't see a problem with transposing a chromatic scale, it's useful and necessary for mathematical sound systems (helpful for computation) to define operations, even if there is no direct gain (functionally speaking - identity / mempty etc.) :
1 + 0 = 1