Hello,
With the update to Chrome 66 it seems to have broken the “Play Sound…” action triggered by “On Mouse Click”. Upon inspection it brings up the error “HYPE-590.thin.min.js:82 The AudioContext was not allowed to start. It must be resume (or created) after a user gesture on the page. https://goo.gl/7K7WLu”
Behavior still works in Firefox, Edge and Safari in both OSX and iOS.
Screenshots attached of page inspect and Hype interface.
Any ideas?
Thank you =)
Yep , Thats crap.
I fix in the mean time is to put sound as a src in Audio tags in the innerHTML of an element.
Although you get the warnings still in Chrome 66, The Javascript command .play() still works
Thank you sir, I’ll give it a whirl!
Just put this on the click function:
//resume audio context of any Hype version
for (var key in window) {
if (key.substring(0, 9) == "HYPE_gac_"){
window[key].resume();
}
}
Update: here is an example
unlockAudioOnClickHandler.hype.zip (69,3 KB)
Hint: You only need to unlock once so if you have a splash screen with a button/tap and sound+unlock… then that should do it for the rest of the document.
Am I correct in this is not an public object /key and it has the potential to be changed by Tumult at any point.
Which could leave a live page audio broken. ?
No, this is a public key in the window context you can inspect it. It is the global audio context used by Hype. Each Hype-Version has it’s own key that’s why I am looping over them. Also this is a fix until the runtime fixes this internally and then the fix is anyway obsolete and of no consequens.
Best regards
What I mean is it is generated by the Hype runtime and the code for that could change. So potentially 'HYPE_gac_' could become 'HYPE_smac_' at any point.
Granted, but I think it needs to be made clear that this is a very temporary work around and pages should not really be left with it with the assumption that it is a permeant fix.
I am not plugging my solution but we can assume that it may be more reliable if a little more work to incorporate.
p.s and thanks for finding it, for me and my personal stuff that may come in handy in accessing the sound context.
Yes I understand what you said. Actually if Hype calls HYPE_gac ever HYPE_smac I’d rather change that on one location then not use the regular play functions on audio etc. But what I was saying is that Hype will have to fix this anyway and then it doesn’t matter if the next update renames it and all current and previous runtimes work this way and this should do the trick for them.
The good thing is now anyone reading these post will now have the warning about using it.
your welcome but we talked about this before. I sent you two articles about it… 
True, but in my opinion triggering BaseAudioContext.resume() is really of now consequence on a Hype AudioContext only if it had been put into suspense before does it matter and that is exactly what Chrome is doing now … AudioContext: resume() method - Web APIs | MDN
We have a fix* and will release it soon.
The easiest workaround is to uncheck “Preload” for the audio resource.
If preloading and the low latency of web audio is required, I think @MaxZieb’s solution is fine as long as users understand it is a temporary workaround. (I’d also conditionalize on the existence of resume – this function wasn’t common until recently and also will help verify the object is the right type). But in the general sense it is unsupported to rely on Hype variables like this.
* personally I’d call it more of a workaround; Chrome is weirdly non-standard/non-intuitive in how it is implementing audio restriction.
So do I..
Which was the point I was trying to make but checking my understanding was correct.
If you add "in a general" sense to it I totally agree but a fix is a fix is a fix… 
I was meaning the Hype "HYPE_gac_" could be handy rather than Audio context in general. Did we speak about that before ??
If this is an option do it. If not … read on
No, about unlocking audio context. Sorry for the confusion. Lost in translation.
//resume audio context of any Hype version
for (var key in window) {
if (key.substring(0, 9) == "HYPE_gac_"){
if (typeof window[key].resume == 'function') {
window[key].resume();
}
}
}
As suggested "This is a temporary workaround until Hype updates"
unlockAudioOnClickHandler.hype.zip (69,3 KB)
Kids don’t use undocumented features … let me show you something…
PS: It’s late in Germany 
Here is another example if you want to assign the temporary “fix” using a class (“unlockAudio”). Even less intrusive and easily deployable to many buttons (as one doesn’t know which unlocks first).
unlockAudioWithClass.hype.zip (81,1 KB)
Here’s my code that was working before the update of Chrome and that no longer works.
var audio = new Audio('${resourcesFolderName}/button-sound.mp3');
audio.loop = false;
audio.volume =.2;
audio.play();
@steve_wolk
If you put your code outside of an click it qualifies as “autoplay” and that is precisely what chrome wants to prevent. If you require user interaction and you put this in a function that is called by a click your code works for me?!
If you want to test if autoplay is possible (like for a background music) and can’t deploy a user interaction first read Daniels post here Chrome’s new Media Engagement Index
Max, what I have is as follows:
The page menu is a persistent symbol.
The menu is comprised of Hype text elements
Each menu (text) element has several javascript function directly attached to its mouse click event in the Hype IDE
One of the javascript functions is what I posted above
It was working (playing the sound effect) before the Chrome 66 update; but it stopped working after the update.