I remember when sound notifications were added to Glk.
The current glk spec has a test you can run to see if the interpreter has all the sound features. It returns 1 if it does and 0 if it doesn’t. (Glk: A Portable Interface Standard for IF)
But what if it’s an interpreter from that pre-notification time? Is it going to return 0 because it doesn’t have the newer notifications, even though it could play sound? Could this be teased out with the old tests? The ones described as ‘Earlier versions of the Glk spec defined separate selectors for various optional capabilities. This has proven to be an unnecessarily confusing strategy, and is no longer used. The following selectors still exist…’ etc
glk_schannel_play_ext was part of the first version of the Glk sound API (0.5.2), so there was never a “pre-notification” time. But not all interpreters supported the notification events.
Rather than testing gestalt_Sound2 just test gestalt_Sound. That lets you know if the basic sound functions are supported.
My understanding is that any interpreter which supports sound notifications will return true for either Sound2 (the full suite is available) or SoundNotify (that particular component is available), so you might as well check both.
I don’t know if any implementations would return true for Sound2 but not for SoundNotify, which would be non-standard, but the extra call has no real cost.
But it was such a vivid time! I remember how I used to laugh and dance and play in the fields in my carefree pre-notification world!
I suppose I can test this myself, but I still don’t know what will happen if I dug up an interpreter that supported sound, but not notifications, and checked gestalt_Sound2.
You might be thinking of volume notifications, which were added later on.
If it’s not being naughty then it would return 0 when testing gestalt_Sound2.
(Parchment is a little bit naughty because it returns 1 for gestalt_Sound2 and gestalt_SoundMusic even though it doesn’t actually support MOD files. But that’s what Zarf advised.)