stemdeckapp/stemdeck v0.17.1

0.17.1

on GitHub

xattr -dr com.apple.quarantine /Applications/StemDeck.app

Which file do I download?

Pick one. Each Windows and Linux download is complete on its own: unzip and run, no installer, no toolchain. Everything else in the asset list is used by StemDeck itself - in particular the small -app files are the updater's payload and will not run on their own.

What's new in 0.17.1

Additions to the click track, the export and the sections ribbon, and a long list of things that were quietly wrong. Almost all of it came from people who reported it, and several of them did the diagnosis themselves.

Additions

The count-in can be longer than one bar

It was one bar, fixed. At 120 BPM in 4/4 that is two seconds between pressing play and the song arriving, which is not long enough to get a hand back to an instrument.

It is now a length: off, or 1 to 4 bars. Asked for by @wastedbits in #587.

The click follows odd and compound meters

The click marked exactly one beat per bar, which is right for 2/4, 3/4 and 4/4 and wrong for everything else. 7/8 was seven even clicks with no pulse to lock onto, and 6/8 sounded like slow 3/4.

The bar is now grouped, so 7/8 can be 3+2+2 and 6/8 counts in two. You can set the grouping yourself when the default is not the one your song uses.

Exports keep your transposition

Transposition happens in the browser, so a mix exported from a transposed session came back in the original key with nothing to say it had. The export now carries the per-lane semitone shift through to the file.

Asked for by @zeh235 in #592.

A section can be pinned so it cannot be nudged

Every section was a drag target across its whole width, so a pointer aimed at the waveform, or a scroll that began a few pixels too high, could slide one off the moment it marked. There is no undo for the timeline, so the repair was to drag it back by eye and hope.

A padlock now sits beside the delete cross. While it is set, the section cannot be dragged, resized or renamed, and the padlock turns red so a locked one is obvious at a glance rather than only once you try to move it and fail.

Looping over a locked section still works, since that reads it without changing it. Deleting still works too, because the cross is a deliberate press on one section rather than something the pointer does on its way somewhere else.

Asked for by @digidirt in #573.

A loop and a section can now become each other

Both are a start time and an end time on the same track, and getting from one to the other meant reading the numbers off and rebuilding the span by hand.

Press Add with a loop armed and the new section lands on the loop. Before, it appeared at the start of the track instead, wherever the loop actually was, with nothing saying why.

Click a section and the loop arms over it. A single click, so double-click is still rename.

A loop drawn across a section that already exists is refused, and says so beside the button. Sections cannot overlap, and the alternatives were to trim the new one to whatever space was free or to shove its neighbours aside. Both hand back a different region than the one you picked, and shoving could move a section you had just locked.

Asked for by @digidirt in #573 and #474.

Fixes

Renaming a section did nothing

Double-clicking a section's label is meant to turn it into a text field. It did nothing at all, on every section and every track, so there was no way to name a section.

Dragging a section takes pointer capture, which redirects the rest of the gesture to the block itself. The double-click that ends a real double-click was therefore delivered to the block, while the code listening for it sat on the label inside, and never ran.

Sending those same events by hand works perfectly, which is why this survived every check I made of it, and why I told @digidirt in September that renaming already worked. It did not. It does now, and it has browser tests for the first time.

The app opened to a window that ignored you (Windows)

If StemDeck installed cleanly and then refused to respond to anything, this is the release that fixes it.

Hovering worked. You could type in the search bar and select text. Buttons did nothing, and neither did dropping a file. The logs were clean, because nothing had failed: every request returned 200.

Windows keeps a MIME type for each file extension in the registry, and other software sometimes sets .js there to plain text. Python reads that registry when it decides how to describe a file it is serving, so on an affected machine StemDeck handed the browser every one of its JavaScript modules labelled as plain text. Browsers refuse to run a module that arrives that way, by specification. Nothing attached itself to the buttons, and what was left was a window that drew correctly and ignored you.

StemDeck now states the types it serves for itself at startup, so the registry no longer gets a vote.

Found by @DrSiemer in #617, who read the browser console, worked out the cause and posted the fix along with it. If you are on an affected machine right now, setting .js back to text/javascript in the registry gets your current install working again.

A start that fails now says why

The one above arrived as silence, and that is its own fault.

The error reporting was set up at the end of the same startup run that was failing. When the run broke early, nothing was left to write the error down, so the logs stayed clean and the screen said nothing at all.

A small script now runs before everything else, with no dependencies of its own that could fail with it, and catches whatever goes wrong. A failure during startup now shows the reason on screen instead of leaving you with a window that will not answer. #618.

Pops, crackle, and no sound at all on some setups

If StemDeck crackled through a whole track, or played the timeline with no sound, this is the release that fixes it.

The pitch stage offers one input per semitone, and it is supposed to do nothing at all when no lane is transposed. It never did. Every input was wired in the moment playback was set up, and a wired input carrying nothing still arrives as a channel of silence, so the stage built twelve pitch shifters and ran all of them, on silence, for the whole track. At zero transpose. On every track anyone has ever played.

Its cost per second of audio rises with your output device's sample rate, which is why the same bug looked like three different problems:

On a desktop at 44.1 kHz you would not have heard it, only a fan. On a laptop it was continuous pops. At 96 kHz it was audible distortion, and at 176.4 and 192 kHz the audio thread could not keep up at all and produced nothing.

It was not only wasted work. Measured against a 440 Hz tone at zero transpose, the audio coming out differed from what went in by up to half of full scale. Playback is now identical to the file, sample for sample, when nothing is transposed.

Found and fixed by @pywkt in #576, including the measurements above. @wastedbits reported the silent 192 kHz case in #575, and the detail that cracked it open was giving the exact rate at each symptom: fine at 48, distorted at 88.2 and 96, silent at 176.4 and 192. A fault that goes absent, then audible, then total along one axis is a fault whose cost scales with that axis, and that is what pointed at the real cause.

StemDeck no longer works four times harder for nothing on a high-end DAC

Chasing the above turned up something underneath it.

StemDeck ran its whole audio engine at whatever rate your output device was set to. Every stem it produces is 44.1 kHz, so on a device set to 192 kHz it was upsampling on load and then doing four times the work on samples that carried nothing the originals did not. Memory paid the same multiple: a five minute six stem track held about 2.6 GB of decoded audio instead of 606 MB, which is enough to put a browser tab under pressure before any processing starts.

The engine now runs at 48 kHz when the device asks for more, and your device still receives its own rate because the operating system converts, exactly as it already does for any 44.1 kHz file you play. At 44.1 and 48 kHz nothing changes at all, since there was nothing to gain there and a needless conversion to lose.

Audio stopped about fifteen seconds after you switched tabs

Play a track, switch to another tab, and the sound stopped shortly after. Coming back started it again, which made it look like a browser power-saving quirk rather than a bug.

Browsers do not deliver animation frames to a tab you are not looking at, and one of the things StemDeck drove from those frames was the scheduling of the next few seconds of audio. When the frames stopped, the scheduling stopped, and the twelve seconds already queued played out and ran dry.

Reported and diagnosed by @the-observer07 in #600, who forked it, found the cause and pushed a branch. The fix here is theirs in shape.

Fixing it turned up something next to it: switching tracks while one was playing left the old engine and all of its decoded audio in memory for as long as the tab stayed open. That is gone too.

Dragging a file into StemDeck opened a media player you could not leave

Dropping an audio file anywhere except the search bar was handled by the browser, which opens the file. Inside the desktop app there is no address bar and no back button, so the window was replaced by a bare player and the only way out was to quit.

A file dropped anywhere in the window is now an import, the same as dropping it on the bar. A file StemDeck cannot use says so in the bar, in red, instead of being handed to the browser to open.

Reported by @MetalMan1245 in #584.

Controls off the right-hand edge on a scaled display

On Windows display scaling above 100%, the row of controls along the bottom ran past the edge of the window into a sideways scroll that was easy to miss. At 250% on a 4K panel it overflowed by 472 pixels.

It was never really about scaling. The row was already too wide on a maximised 1080p screen at 100%; scaling only made it obvious. The click track options now reflow into a block when the row runs short of space, instead of marching off the edge. Everything stays visible and clickable.

Reported by @wastedbits in #586.

The window can no longer demand more screen than you have

Related, and worse where it bit. The minimum window size was expressed in a unit that grows with your display scaling, so at 250% the app insisted on a window larger than a 1080p screen in both directions. You could not resize it to fit, and the controls that would have helped were off the edge.

It now never asks for more than your monitor can show.

Collapse "All" took the library with it, and could not give it back

The Collapse row has All, Analysis, Sections and Timeline. Pressing All also collapsed the library, but the three buttons beside it only know about their own panels, so you could turn all three back on, watch All light up as though everything had returned, and still be looking at a collapsed library with nothing in that row able to reach it.

All now covers exactly the three panels it names. The library keeps its own button in the rail.

Reported by @wastedbits in #588.

Section markers pointed at the wrong part of the song when zoomed

The section ribbon did not zoom with the waveform underneath it. As soon as you zoomed in, it carried on describing the whole track across the visible width while everything below it described a slice, so the two disagreed. On an eleven minute track at 2.7x, the first boundary sat 775 pixels away from the moment it marked.

Dragging a section was wrong in the same way: the block followed the cursor, and landed on a time further through the song than where you dropped it.

Both are fixed, and the ribbon now scrolls with the waveform.

Closing StemDeck could leave a process holding your GPU (Windows)

Force Quit, Task Manager or a crash during a separation could leave the worker running with nobody to collect its result, holding the graphics card until you found it yourself.

There has been a watchdog for exactly this since #519. On Windows it never fired. It asked the operating system whether the parent process still existed, and Windows kept answering yes long after the parent was gone, because a process record survives until everything holding a reference to it lets go. The case where nothing lets go is a process that was killed rather than closed, which is the exact case the watchdog exists for.

macOS and Linux were never affected.

Linux with an NVIDIA card: first launch that looked frozen

Reported by @raniaamina in #502, who rebuilt from source repeatedly and sent the logs that found four separate faults.

Setting up GPU acceleration downloads several GB on first launch. It said nothing while it did, so there was no way to tell a slow download from a dead one. It now reports what it is downloading and how far along, on screen and in setup.log.

Underneath that were three more, all found in those logs:

The install gave up on healthy downloads. Each step had twenty minutes, measured on the clock, whatever it was doing. The Linux CUDA runtime is about 3 GB, so that was an undeclared requirement for a sustained 2.5 MB/s that nothing told you about. Their two runs are the proof: the same file took 921 seconds and was killed while still downloading, then 193 seconds on a better connection. Nothing was fixed in between. It now gives up when nothing has arrived for a while, so a slow transfer is left alone and only a stopped one is stopped.

A model file cut short by a dropped connection was trusted forever. Both model libraries check only that the file exists, never that it loads, so a partial download became a permanent one. Their beat detection had been quietly falling back to the simpler tracker on every job since install, with nothing saying so. Their own directory listing showed it plainly: one model complete, two cut to a fraction of their size, over the same connection in the same hour. A file that fails to load is now discarded and fetched again.

The karaoke split was broken on the newest CUDA installs. One of the libraries behind it ships compiled pieces that register themselves against one exact build of torch. Setting up CUDA moved torch to a newer line and left that library on the old one, so the registration never happened and the split failed with operator torchvision::nms does not exist the first time anything called it. Separation was unaffected, which is why it looked like a karaoke problem rather than a broken install. Windows was affected as well as Linux, on any machine new enough to take the latest CUDA build.

On RTX 50 series: the build StemDeck installs does verify on a current driver, confirmed on a 5070 Ti and on an RTX 3080 here. If a driver and the available build genuinely disagree, StemDeck falls back to CPU cleanly and writes down why. #502 stays open until the karaoke fix above is confirmed on that hardware.

Upgrading

Windows and Linux can update in place from Settings. This release does not change the Python runtime, so the in-app updater can offer it.

There is one exception, and it is the release's own headline fix. If your install is the Windows boot failure described at the top, the Settings button does not respond either, so the updater is out of reach. Two ways round it: download the package for your platform from the table above, or set .js back to text/javascript in the registry, which makes your current install work again and lets you update from Settings as usual.

Thanks

Almost everything above was found by people running StemDeck on hardware I do not have, or in ways I did not think to try.

@pywkt arrived with the diagnosis, the measurements and a working fix. @the-observer07 did the same: forked it, found the cause and pushed a branch. @raniaamina rebuilt from source more than once and sent logs that turned one reported fault into four fixed ones. @DrSiemer took a dead window, opened the console, and came back with the cause and the fix in the same message. @wastedbits reported four separate things here, one of which was precise enough to be the key to someone else's bug. @digidirt wrote up the sections ribbon as four separate asks rather than one, which is most of why all four got done. @MetalMan1245 and @zeh235 reported the rest.

None of this would have been found by me. Please keep reporting things, especially the ones that feel too vague to write up. "It crackles" and "no sound at 192" turned out to be the same bug, and "I cannot click on anything" turned out to be a line in the Windows registry.