Audio Type seems to have no effect

[Const4ntFlux]

Allocating a local audio file to a button and activating it layers the sound multiple times (as many times as you push the button) instead of taking into account the chosen audio type. Expected behavior for me was:

Normal: button push would trigger the audio file playback. Subsequent presses would layer a new instance of the audio file on top. All triggered audio layers would play until the end of the file. Toggle: first button push activates the sound. Second press would deactivate the sound. Restart: first push activates the sound. Any subsequent presses would restart the audio file from the beginning until the audio file finished playing. Hold: button push and hold would play the audio file. Upon release of the button the audio file would stop.

[dbkynd]

The expected behavior you list is correct except for type Normal. When you spam the button with type Normal selected it will only play on the first press. Subsequent key presses won't do anything until the current track stops. (per key)

Testing locally it all seems to function properly. Can you open the Chrome Dev Tools CTRL+SHIFT+I and see if there is any error in the console when playing audio?

[Const4ntFlux]

This is in the log (see below for important note): start options.js:192 Uncaught TypeError: Cannot read property 'played' of undefined launchpad.js:133

Toggle works the first time it is called after setting up the button after that it doesn't work anymore. That is:

• click on empty pad
• open Edit Key/Audio
• browse for audio file and choose (in my case a .wav file)
• click on Type: Toggle
• press according button on Launchpad->audio plays
• press button again during first audio playback->audio stops
• press button again to start playback->audio plays
• press button again during audio playback->audio continues and an additional audio file (same audio contents) is started

[Const4ntFlux]

Is there a specific format of audio file names I must adhere to? As in: no spaces or umlauts, I mean.

[dbkynd]

It should work for any local or remote .mp3 .wav or .ogg file. It just saves the file path string to a JSON object for reference.

If the app was unable to access the file, it would have shown an warning message explaining that. If you did not get the warning message, the app can access the file correctly, spaces and umlauts included.

Do you mind sharing the .wav file you are using and I can try it?

[dbkynd]

I just pushed an update for ControlCast (0.2.4). This should handle the error you were getting in the console. But unsure if it will resolve your entire audio issue.

[Const4ntFlux]

Thanks for the update. I ran the update in app (opposed to running the setup.exe again), got confused because there is no status bar for the download, restarted the download and succeeded updating in the end. Didn't change anything concerning my issue though.

BUT I found out it is indeed a file path/umlaut combination issue. Audio file X in a directory with an umlaut in the directory path shows the issue for me from the original post. The same audio file in a directory without the umlaut in its file path works as intended. (the kill all audio switch issue from #6 is solved for audio files located in directories without umlauts in their directory path with this too).

My temporary fix obviously is to lose the umlaut in the directory name or move the audio files to a different location, but a permanent and sound solution would be to make Controlcast more compatible with different language conventions, which will probably solve #9 too.

Thanks for your help!