Audio Type seems to have no effect about controlcast HOT 6 CLOSED

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?

from controlcast.

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

from controlcast.

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

from controlcast.

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?

from controlcast.

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.

from controlcast.

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!

from controlcast.