Double clicking .wav's rapidly enqueue's the wav instead of playing immediately

[futuremotion]

I am a LONG time Winamp user and electronic music producer. I've always used Winamp to audition single-shot samples (as well as drum/synth/bass loops). I always set the buffer length to as small of an interval as possible that I can get away with without crackles and pops so I can audition my drum samples near instantly. I also disable all fades and set the fade time to 0ms.

Now, with WACUP, I can't seem to get immediate playback working properly.

Here are the relevant command line options that appear when you run "WACUP.exe /?" in a the command line:



Here are my registry settings that define the default action ("Open") when you double click on an audio file (.wav in my case):



According to the first image, if you just pass a file to WACUP, it should clear the playlist immediately and play the file. But this isn't actually the case.

If I double click rapidly on the same wave file (or a different wave file), the wave file gets appended to the playlist and playback advances to the next entry (same wav file). I really need the default command to start playback immediately without enqueuing the file so I can audition various samples in rapid succession with as minimal of a delay as possible.

This behavior does not align with the CLI options window that states:

<file> Clears the contents of the main playlist before adding the specified 'file' at the start & then
begins playback of the first item now in the playlist.

I've created a screen recording of the behavior and attached it. If you can't open the attachment here's an Imgur link: https://i.imgur.com/l31ixfg.mp4

I've also tried changing the shell "open" command to: "C:\Program Files (x86)\WACUP\wacup.exe" /CLEAR "%1"

But the same behavior persists, even though the /CLEAR command should clear the playlist.

Can someone help me configure WACUP to not auto-enqueue files into the playlist when opening them in rapid succession? This is essential for my workflow and I need to be able to preview samples with as little delay as possible.

[dro]

I can't access anything from imgur as I'm geo-blocked by them since last year.

As for what's shown in the video, wacup is a different program to winamp so there are differences in behaviour & currently what you want it's command-line handling will not do as it's batching up requests coming in from the multiple spawned instances which was done as it helped with others double-clicking on a large selection where that otherwise would do more like you're wanting but wasn't what they wanted as it then lost files being added.

At this time wacup can't do what you need without either adding in another option to change the behaviour or for me to find a different way to achieve what is the intention of the handling whilst allowing quick additions to work. As for the /clear aspect, it does work but it's covered as part of the batch handling so it cannot do what you're currently wanting & maybe just having that not be handled by it might be the quicker way to get closer to what you're wanting but I won't know until I allocate time to look into it.

[futuremotion]

Thanks for the reply. At any rate I really appreciate if you look into this behavior. Right now I'm testing older versions of Winamp to try and achieve what I'm looking for.

[futuremotion]

So I finally found a version of Winamp that works as expected: Winamp 5.62 (x86).

Double clicking on wav samples instantly plays them with no latency at all, and doesn't enqueue the files when I rapidly switch between samples.

Hope this helps someone!

[dro]

At any rate I really appreciate if you look into this behavior.

I've had a look into this & have an initial set of changes for the next wacup build though how well it'll actually work for your needs I don't know. I've also not done any comparison testing against a winamp install as what it does really doesn't help in comparison to my code base & what I'm working with.

From what I could see under testing, wacup being slow to respond &/or duplicating things was due to how the initial batch handling is done which actually is processing the external command quickly but is causing all of the play message requests to stack up which depending on how many are made & other aspects I could easily make it take almost a minute for the wanted action to appear to finally happen. As it's trying to process every play request that's been given to it along with the related stop that goes on which slows down the ui responsiveness & makes it seem like there's no playback happening even though the play/stop is actually being processed with the stop happening before output is able to be properly constructed making it not play anything in that state (which is imho correct as it's just the handling dealing with things as quickly as it can & avoiding doing things that it's already determining aren't required as a very quick play then stop action will trigger).

What I've done is now try to check if there's already a pending play action in the message queue from any new external actions coming in & filter them to reduce the amount of reprocessing that might occur. Doing that helps avoid the unwanted adding of the items to the playlist when it should just be showing what's been added into it along with reducing the play messages that are being queued up which avoids what I described in the prior paragraph. I still don't know if that's fully resolved the extra items being added but so far I've not managed to see it occur including when using the behaviour that allows a folder to be passed & expanded so to me it seems better against what I've been able to test.

And final thing for now is that /clear <file> isn't a valid command-line action so that shouldn't have worked & seemed like it did due to what I've tried to describe above.

[futuremotion]

Really appreciate the deep-dive into the codebase to search for a solution.

I really don't know exactly why, but Winamp v5.62 definitely has the lowest latency so-far and allows for really low buffer sizes (This is very important when you are comparing thousands of samples across your SSD). With the way it's set up now, it will play a wav almost immediately (8-10ms before playback starts after double clicking or simply pressing enter with my file selected).

This is what kept me using Winamp for something like 18+ odd years. It's the only tool that let me rapid-fire playback like this so I can compare transients between different drum samples, drum loops, synth stabs, etc. For the lowest latency I could (or should) theoretically be using ASIO, but there have always been problems with Winamp's implementation of ASIO (one of which was volume control).

I tried setting up ASIO with WACUP but still get the same duplicate-loading bug anyway.

Anyway, sorry if all of this is irrelevant to you. Just sharing my experiences as a producer and why Winamp has always been my go-to. If you can figure out a way to make super small buffer sizes possible with reliable playback I'll definitely re-evaluate. But for now since nothing is broken I'm just going to stick with Winamp 5.62.