common.xml: specify that TUNE_FORMAT.tune is specifically MML

[peterbarker]

Only MAVProxy and ArduPilot seem to support this. And possibly something on SkyViper.

This is a breaking change for PX4-AutoPilot, and we must not merge this without getting the OK from them. PX4-AutoPilot is expecting qbasic tune strings in this field. Given that there doesn't appear to be any clients which will send QBASIC in PLAY_TUNE, and that clients could easily move to PLAY_TUNE_V2, they may be willing to accept the change. @hamishwillee

I've checked QGC, paparazzi, PX4-AutoPilot, MAVProxy, ardupilot, APMPlanner2.

It was a mistake to not specify the format for PLAY_TUNE.tune string in a standards document. PLAY_TUNE_V2 came out of that mistake, and was an even bigger mistake (resources are available on the ground to convert to/from a standardised input format)

[peterbarker]

@hamishwillee we agreed that we are quite happy with this change in ArduPilot-land.

Merging this would make QGC non-compliant with the spec as QBasic is assumed.

[hamishwillee]

@peterbarker I'll need to think on this. Likely end of next month. We don't make any flight stack non-compliant without some discussion, and the same courtesy should be given to QGC.

It was a mistake to not specify the format for PLAY_TUNE.tune string in a standards document.
PLAY_TUNE_V2 came out of that mistake, and was an even bigger mistake (resources are available on the ground to convert to/from a standardised input format)

It would certainly be easier if there was one standard format.
IMO the v2 version is better than trying to get ground to do conversions - IMO it wouldn't happen.

[peterbarker]

@peterbarker I'll need to think on this. Likely end of next month. We don't make any flight stack non-compliant without some discussion, and the same courtesy should be given to QGC.

Sorry, this should be PX4 Firmware, not QGC.

There's no client I've found except MAVProxy which sends PLAY_TUNE, and none that send PLAY_TUNE_V2.

It was a mistake to not specify the format for PLAY_TUNE.tune string in a standards document.
PLAY_TUNE_V2 came out of that mistake, and was an even bigger mistake (resources are available on the ground to convert to/from a standardised input format)

It would certainly be easier if there was one standard format. IMO the v2 version is better than trying to get ground to do conversions - IMO it wouldn't happen.

On reflection... I still don't think it's a good idea to force autopilots to understand every type of "tune format" you might want to support.

[hamishwillee]

On reflection... I still don't think it's a good idea to force autopilots to understand every type of "tune format" you might want to support.

Of course not.

A good design, IMO is to do what the web standards do. Define a mandatory "thing" to support; allow others to be supported as well, and provide mechanisms to discover what is supported. That way you end up with everyone using the same thing, and if a real need exists for a new format, it can be supported.

Given where we are, there is no standard, so the "right" think to do is to provide a mechanism to know when the tune failed or to discover the supported tune formats. I pushed for that with PLAY_TUNE_V2 but there was no interest.

FMI what do you see as the use case for this message? I've been thinking it is for a MAVLink-based system to provide custom sounds to reflect its own errors - such as a remote id that is failing.

[hamishwillee]

To summarise

• PX4 support PLAY_TUNE and PLAY_TUNE_V2 with a QBASIC_V1 payload, while ArduPilot supports PLAY_TUNE with MML payload.
• The PR proposals to make the PLAY_TUNE format standardised to MML, which would make PX4 non-compliant.
• PX4 could pehaps drop support for PLAY_TUNE since PLAY_TUNE_V2 is supported.

The main problems I see:

• We don't really know what clients are using this. I expect the main caller would actually be companion computer code.
• If we "fix" this issue in this way that leaves us with two messages and no reason/rationale for ArduPilot to work on convergence.
  I'd personally rather drop both PLAY_TUNE and PLAY_TUNE_V2 than this.

One question. QBASIC is a subset of MML. Does Ardupilot actually support the full MML - multiple channels, fade in/out, etc? Or is it actually the case that ArduPilot practically supports QBASIC? In other words, is it possible that the real supported format is actually QBASIC in both cases?

I'll add this to the MAVLink call, but perhaps worth thinking about a realistic convergence path.

[peterbarker]

* We don't really know what clients are using this. I expect the main caller would actually be companion computer code.

This is likely. But it's also used just to test tunes out.

@muramura wanted to be able to send play_tune messages at the GCS in scripting IIRC, 'though :-)

* If we "fix" this issue in this way that leaves us with two messages and no reason/rationale for ArduPilot to work on convergence.
  I'd personally rather drop both PLAY_TUNE and PLAY_TUNE_V2 than this.

One question. QBASIC is a subset of MML. Does Ardupilot actually support the full MML - multiple channels, fade in/out, etc? Or is it actually the case that ArduPilot practically supports QBASIC? In other words, is it possible that the real supported format is actually QBASIC in both cases?

Only difference I've spotted is that we support "V" for changing the volume. And it looks like that's the only thing that PX4 doesn't do. The code is... rather similar.

https://en.wikipedia.org/wiki/Music_Macro_Language seems to say that AP is doing all that's required to be "MML" - but it seems to be even less of a standard than MAVLink :-)

I'll add this to the MAVLink call, but perhaps worth thinking about a realistic convergence path.

Shifting PX4 to support (or just ignore) volume would be a simple convergence path. PLAY_TUNE_V2 could simply be removed at that point.

[hamishwillee]

EDITED: It certainly makes sense for PX4 to support or ignore V if that allows us to align the PLAY_TUNE. I'd still prefer we moved to V2 though - I know you disagree, but I think it is a better message. Not my call though - will take to the dev call.

OK, so created place in PX4 for discussion PX4/PX4-Autopilot#26224

• Only difference is support for V and R.
• I don't think ArduPilot complies with any definition of MML. It is more like "QuickBasic1.1" with support for V and R (but note, different to the way that iterations of QBasicDo it).

I'm going to push for that change, but I would prefer we

• Update PLAY_TUNE to define the format as QBASIC1.1 + V and R rather than as MML - unless you can find a definition of MML that matches what has been done here
• Update PLAY_TUNE _V2 to state the default format is QBASIC1.1 + V and R and that this is mandatory to be supported. Delete the second suggested format since ArduPIlot does not support that definition.
• Discuss in MAV call whether we work to convince PX4 to drop the V2 message or ArduPilot to upgrade to the new message.

[peterbarker]

* I don't think ArduPilot complies with _any_ definition of MML. It is more like "QuickBasic1.1" with support for `V` and `R` (but note, different to the way that iterations of QBasicDo it).

That Wikipedia link I supplied as v and r under "Modern MML" :-)

* Update PLAY_TUNE to define the format as QBASIC1.1 + V and R rather than as MML - unless you can find a definition of MML that matches what has been done here

I've no idea what was used as a reference for the "MML" used in AP.

[julianoes]

Note that V2 allows the ground station to query what is supported, at least in theory: https://mavlink.io/en/messages/common.html#SUPPORTED_TUNES

[hamishwillee]

* I don't think ArduPilot complies with _any_ definition of MML. It is more like "QuickBasic1.1" with support for `V` and `R` (but note, different to the way that iterations of QBasicDo it).

That Wikipedia link I supplied as v and r under "Modern MML" :-)

Hmmm. Ah, that does indeed match, though it is a bit imprecise compared to what ArduPilot and PX4 do - specifically both have case-sensitivity (require upper case) and here "R" is seen as a sometimes equivalent to "P".

PX4 provides a more clear definition in https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/tunes/tune_definition.desc.

We had a discussion on this topic in dev call. We'd prefer deprecation of this message and migration to the new messages. But either way we hope to align the definitions as discussed so that a ground station can send the one format to both flight stacks. Essentially discussion is on hold until next dev call.

[hamishwillee]

PX4 merged PX4/PX4-Autopilot#26224 so now is compatible with "modern MML" - i.e. it won't crash on a tune with the v and r chars in main, though it doesn't respect V - it just ignores it.

However I am still adverse to this proposal, since it makes PX4 incompatible for all released versions. In some years we might update it though.

We might consider clarifying exactly what will succeed and fail here though.

I still think ArduPilot should migrate to PLAY_TUNE_V2 and https://mavlink.io/en/messages/common.html#SUPPORTED_TUNES - as that allows us to remove this incompatibility entirely - and is a better approach anyway. WIll be discussing in the MAV call.

[hamishwillee]

20260408-Dev-Meeting discussed this. We don't think it is a good idea. Recommend ArduPilot update to the new messages so that one day we can deprecate and remove this.

@peterbarker This should be closed since we don't want to unalign further.