Change how outputs are assigned to partitions

[ieure]

I wanted to run a re/design decision past you before I started hacking on it.

Currently, behavior of outputs when dealing with partitions works as follows:

• When a partition is created, it has no outputs at all.
• After calling moveoutput, the partition has just the output that was moved to it (out of all outputs known to MPD).
• Output indices change based on the partition, and are always numbered from 1, with no gaps. So if you move output index 2 from partition foo to a new partition bar, its index is 2 in the foo partition, but 1 in the bar partition.
• In the partition it was moved from, the output remains, but is disabled and has its output driver changed to dummy.
• The moveoutput command works on the active partition, but the global output list.
• moveoutput requires the output name as an argument, but all other output commands require an index. Presumably this is due to the output index changing from partition to partition.

I think a conceptually simpler approach would be:

• Outputs are implicitly global, meaning they're visible on every partition at all times.
• Output enable state is per-partition. An output may only be enabled on one partition at a time.

I think this would be a simpler & more consistent way to deal with partitions, from the user/client developer perspective. I'm not sure what the actual implementation would look like.

Do you agree that this is a reasonable approach? Would you be open to a PR implementing it?

I don't know if I have the bandwidth to actually do it, but I definitely don't have the bandwidth to do it if it's not something agreeable enough to merge.

[jcorporation]

As a mpd client developer I would prefer your approach.

[sevmonster]

As it stands, partitions feel like an add-on feature not part of the main MPD ecosystem, and I think these changes would definitely make them more approachable and fit in better with other MPD features.

While this may be the scope of another issue, something that makes partitions worse to use is how they are completely invisible to the config file: Every MPD restart, you must connect with a client to set up partitions again, and if the outputs in the config ever change, so must your workflow/automation. With your proposed changes to partitions, I think it would be very reasonable to also add a new partition config value to outputs, so that partitions can be enabled on partitions explicitly without any external tooling.

You may also want to check out https://github.com/MusicPlayerDaemon/MPD/discussions/1520 for ideas about partitions retaining state, which they currently do not.

[jcorporation]

As it stands, partitions feel like an add-on feature not part of the main MPD ecosystem

I agree with it. I opened two other discussions (#1521 and #1520) with issues that I has discovered.

If all this issues are solved, I will implement this in the myMPD client. There is also an issue that waits for more partition features: https://github.com/jcorporation/myMPD/issues/440