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.