feat: add SignalSmith keylock engine by acolombier · Pull Request #15902 · mixxxdj/mixxx

acolombier · 2026-01-25T02:19:13Z

This adds a new stretching engine, based of Signal Smith.

Quality appears to be as good as RB3, potentially even better, but performance looks way better, easily allowing 4 stems playing without drops.

I still haven't managed to come up with an elegant solution to address the latency, leading to desync at the moment.

If anybody has some ideas in mind, I am all hears!

edit(ronso0) requires setting the CMake flag SIGNALSMITH

daschuer · 2026-01-25T13:30:54Z

I have not had a closer look, but in case of the other time stretchers, the timing need to controlled by the output. The filter needs to be settled with enough samples that we can fetch instantly the output samples we need. Refilling is than done on demand to keep the filter settled. I think in this case it is input + output latency. A problem is always changing settings. parts of the buffer needs to be flushed or we need to predict the behaviour. This was a bit of a challenge with the other stretchers.

daschuer · 2026-01-25T13:40:57Z

+    SignalSmith_LIBRARY
+    "${CMAKE_INSTALL_LIBDIR}/${CMAKE_STATIC_LIBRARY_PREFIX}signalsmith${CMAKE_STATIC_LIBRARY_SUFFIX}"
+  )
+  ExternalProject_Add(


This does not work with debian. We either need to contribute a debian folder for signal smith or copy signalsmith to our lib folder.

What is the issue with debian? I guess the copy option could be viable.

They do not allow to download third party software during the build process.

Oh this is going to be a pain for #15888. Though TagLib merged to contribution this morning and I assume will likely release this in the next version, Debian will likely not upgrade to it till the next major release (same goes for Ubuntu).

Not a problem for SignalSmith tho, so let's discuss that there. Is there any objection with using submodules? The SignalSmith stretcher internally relies on submodules too.

Submodule do not really fit to the modular concept of vcpkg, Debian and RPM.
Having them in our lib folder is IMHO an unnecessary hassle. We don't have submodules yet. I prefer a literal copy in that case.

I can try to contact the author to see if he has any interest.

That's fair, but if we have the opportunity to centralise one in a single place, I guess this is better.

It depends. Currently while it is under active development a lib folder copy is better.
When I look after years to Rubberband and Soundtouch the VCPKG and Linux Distro maintained version is "better". Original we had Soundtouch in our lib folder and have removed it as soon a suitable version was found in all distros.

The Linux maintainer anyway try to rip off everything from our libs folder. So we need to keep an eye on the distro maintained version anyway.
See also the mess with "libshout"

In case of taglib we can also decide if we want to ship it via lib folder or PPA.
The same is an issue with Portaudio which has now Pulse support, but is not yet released to use it.

Thanks for the explanation.

They do not allow to download third party software during the build process.

same for fedora/rpms afaik.

Note that Geraint (the library author) came back to me and mentioned they haven't had interest to maintain a Debian package at present, but were happy for us to vendor the code and add a copy to lib. They also offered to double license the library in case MIT wasn't ideal, but I believe we should be fine with the current license.
I will capture that as an issue. It should be pretty straight forward to setup if we want to make SignalSmith stretch part of the stable release, but this solution allows us to easily update during the trial.

acolombier · 2026-01-25T14:06:20Z

the timing need to controlled by the output

Thanks for the tip. I am just trying to rework it now so this is done like so.

acolombier · 2026-01-25T18:06:25Z

Here is some heavy load test.

Screencast.From.2026-01-25.17-22-23-10MMB.mp4

The cheaper preset is "almost" capable of working with no under-runs, in this maxed out setup!

(Note the very annoying unrelated bug with the spinny scratch mode remaining enabled after release - which I reckon has been fixed...?)

SignalStretch comes with the advantages to perform really well with slowdown track, all the way to zero (see the web-based demo), so I have updated the engine to allow this keylock engine to go beyond the currently set limits.

However, there seem to be a cross-faded silence buffer mixed on top, between the [0.1; 0] range which is not allowing to use the full capability of this new feature. Perhaps @daschuer you would know which one I missed?

daschuer · 2026-01-25T23:29:12Z

There seems to be a loudness reduction when lowering the tempo. This also happens with Rubberband but way less. I think we have the acquirement that the loudness does not change by the tempo.

acolombier · 2026-01-25T23:31:00Z

There seems to be a loudness reduction when lowering the tempo.

I don't think this is the case. You can test it by manually set the tempoRate in the scaler to 0 and you would hear a "zero" BPM sound with the normal loudness, similarly to how you would hear it on the web-based demo

acolombier · 2026-01-25T23:38:41Z

I took this new stretcher for a live set - performance and quality are reeeeally good! There still seem to be some offset occasionaly happening so I will need to investigate that.

daschuer · 2026-01-25T23:51:14Z

I have build this Branch and play a track, crank up the gain to just no clip. With +50 % tempo it starts to clip. This does not happen with the other stretchers or without key lock.

When I do instant doubles and remove key lock from one track, I here a small timing offset as a double beat. This must not happen, because you will also hear this double beat in transitions. The issue is also a pending issue with Soundtouch at extreme tempos changes. Rubberband does not suffer this issue.

daschuer · 2026-01-26T12:37:10Z

+            // the next retrieval. If we are at EOF this serves to get
+            // the last samples out of the scaler.
+            for (int ch = 0; ch < getOutputSignal().getChannelCount(); ch++) {
+                SampleUtil::clear(m_buffers[0].data(frameRead), frameRequired - frameRead);


This can also be out of bounds write.

This should now be covered by the the verify assert above. Note that the maximum buffer size is still well under the maximum value, and maximum tempo rate is 4, with a static assert safety in EngineBuffer.

An explicit verify assert would be nice to not zero the area behind the buffer which is a hard to find bug.

Sorry, I cannot quite get my head around this. Could you clarify how you would like this verify assert to work?

acolombier

There still seem to be some offset occasionaly happening so I will need to investigate that.

When I do instant doubles and remove key lock from one track, I here a small timing offset as a double beat.

This should be fixed now. I had missed on the doc that the input latency needs to be computed with the stretch factor.

With +50 % tempo it starts to clip.

I realised that you are not supposed to use seek (now outputSeek that handles more for us) repeatedly as you would end up smashing samples in flight for process. I have now corrected this and now use both the outputSeek has a "best effort" + a correction factor and I couldn't see any obvious clip. I did take this for a big test yet tho so I could be missing some more issues.

acolombier · 2026-01-27T00:00:52Z

+            // the next retrieval. If we are at EOF this serves to get
+            // the last samples out of the scaler.
+            for (int ch = 0; ch < getOutputSignal().getChannelCount(); ch++) {
+                SampleUtil::clear(m_buffers[0].data(frameRead), frameRequired - frameRead);


This should now be covered by the the verify assert above. Note that the maximum buffer size is still well under the maximum value, and maximum tempo rate is 4, with a static assert safety in EngineBuffer.

acolombier · 2026-01-27T00:10:24Z

+    SignalSmith_LIBRARY
+    "${CMAKE_INSTALL_LIBDIR}/${CMAKE_STATIC_LIBRARY_PREFIX}signalsmith${CMAKE_STATIC_LIBRARY_SUFFIX}"
+  )
+  ExternalProject_Add(


Note that Geraint (the library author) came back to me and mentioned they haven't had interest to maintain a Debian package at present, but were happy for us to vendor the code and add a copy to lib. They also offered to double license the library in case MIT wasn't ideal, but I believe we should be fine with the current license.
I will capture that as an issue. It should be pretty straight forward to setup if we want to make SignalSmith stretch part of the stable release, but this solution allows us to easily update during the trial.

daschuer · 2026-01-27T08:36:16Z

+            return tr("Signal Smith Stretch (Cheaper)");
+        case KeylockEngine::SignalSmithDefault:
+            return tr("Signal Smith Stretch (Default)");


It is Signalsmith is spelled as one word. Cheaper is the used mode like R3 not our hint in ().
The term Default can be dropped, I think.

Suggested change

return tr("Signal Smith Stretch (Cheaper)");

case KeylockEngine::SignalSmithDefault:

return tr("Signal Smith Stretch (Default)");

return tr("Signalsmith Stretch Cheaper");

case KeylockEngine::SignalSmithDefault:

return tr("Signalsmith Stretch");

Not quite. "cheaper" and "default" are two provided presets. Since we said there is no need to make that user friendly yet, lets keep them align for now.

daschuer · 2026-01-27T08:46:19Z

+    // output to real time.
+    // However, this method will reset the buffer so it can only be used right after a reset
+    if (m_currentFrameOffset == 0 &&
+            m_currentFrameOffset < m_expectedFrameLatency


For my expectation we alwasy need this m_currentFrameOffset == m_expectedFrameLatency.

That's correct, but due to limit listed in the comment, we may not be able to correct this in a single process round (e.g because we have now a too large offset compare to the new latency, but we can only correct by iOuputBufferSize).
This means there is no expectation that these value are equal at the end, there is expectation that they will be closer tho, so I can put an assert which capture this (like if we start with values that differ, we expect them to have move closer by the end of the process)

daschuer · 2026-01-27T09:01:11Z

+            // the next retrieval. If we are at EOF this serves to get
+            // the last samples out of the scaler.
+            for (int ch = 0; ch < getOutputSignal().getChannelCount(); ch++) {
+                SampleUtil::clear(m_buffers[0].data(frameRead), frameRequired - frameRead);


An explicit verify assert would be nice to not zero the area behind the buffer which is a hard to find bug.

ronso0 · 2026-01-29T17:01:22Z

Wow, this performs really well! I merged it into my isolate-cpu working branch and I could finally halve the latency to 5ms without getting underruns with the default version
(note: I didn't check the counter but at least I didn't notice any as I would with RB3 @ 5ms).

Regarding the quality:
I had the feeling it's better when I did a b2b session with shifts of up to +- 24%. IIRC RB3 always sounded a bit muddy on low-res/low-fi tracks with RB3 (low like the samples used, not the encoding).
I'll do a side-by-side comparison with RB3 this week (run an AutoDJ list with RB3, then with SignalSmith)

ronso0 · 2026-01-29T17:02:06Z

Btw let's use SiS as short name, so we have ST, RB2, RB3, SiS

acolombier · 2026-01-31T14:59:49Z

Could you clarify where you would like to see this abbreviation?

ronso0 · 2026-01-31T15:09:40Z

I mean, In the GUI we use the full name, so SiS is just for code comments, discussion etc.

ronso0 · 2026-02-05T23:05:08Z

Sooo, instead of the AutoDJ test I went for a real 1:1 test.
This commit 969766f allows picking independent scalers for deck 1-4
--> this is a hack, samplers are not considered -> default to ST, and other things may misbehave, too

On deck1 I loaded ST, RB2, RB3 and on deck2 SiS
load a track in deck1, setup a loop or enable repeat, play
clone to deck2 (required me to nudge as there often was an offset)
use the crossfader to switch between decks (a sharp curve -> Const.Pwr + Scratching is very convenient for this)

I tested with a high-res vocal track as Flac Olicía - Zwei
-> short loop near the start with vocals and sparse guitar
and SignalSmith is the clear winner. I'll skip the comparison with ST and RB2, they just suck in comparison to SiS. So here's what the quick test vs. RB3 revealed:

much better performance (5ms vs. 10/20ms for RB3)
much less reverb'ish vocals fragmentation at -40%
better vocal compression at +40%: RB3 shows over-attenuation of trailing "d"/"t" which gives unnaturally hard/harsh sounds (maybe it's overshooting while trying to preserve details?), SiS sounds smoother and still natural in that regard

acolombier · 2026-02-06T11:01:27Z

Thank you for that detailed benchmark @ronso0!

…retch

acolombier · 2026-02-09T08:48:34Z

I have fixed the conflict now. Let me know if there anything that still needs updating @daschuer

ronso0 · 2026-02-14T17:40:05Z

Just a headsup:
I noticed that SiS seems to have issues at loop in/out crossovers. The first times the noise occured mildly I thought it's simply shitty low-res tracks, but then I noticed it with a Flac track and made these recordings.
First SiS, then I switched to RB3 -> no noise, then back to SiS -> noise back
-- I didn't manage to reproduce it today, with the same track/loop

SiS vs. RB3: you can hear the crackling at the crossover, vs. no issue with RB3
loop_SiS_noise-at-crossover.mp3
loop_RB3.mp3

Any idea what might be causing this?
It happened mid-session, like 2 hours into the mix.

daschuer · 2026-02-14T18:41:43Z

There is a CMake warning:

CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

    project(ProjectName)

  near the top of the file, but after cmake_minimum_required().

  CMake is pretending there is a "project(Project)" command on the first
  line.
This warning is for project developers.  Use -Wno-dev to suppress it.

daschuer · 2026-02-14T20:37:48Z

I can confirm the looping issue:

This is a 440 Hz sinus track looped.

daschuer · 2026-02-14T20:53:47Z

I think this is a settling issue. This is a short start and stop recording and 90 ms latency.

You can see the steady ramp when stopping. However the ramp is bend when starting. I think this is cause because the filter needs some settling samples before correct samples are received. Maybe this cause the clicks when looping?

This is three short start stop recordings with 5 ms latency:

You see here the latency independent settling time as well.

daschuer · 2026-02-14T21:10:16Z

+    if (m_currentFrameOffset == 0 &&
+            m_currentFrameOffset < m_expectedFrameLatency


Can this become:

Suggested change

if (m_currentFrameOffset == 0 &&

m_currentFrameOffset < m_expectedFrameLatency

if (m_currentFrameOffset == 0

#15902 (comment)

The m_expectedFrameLatency is always > 0 and therefore is the second condition redundant.

Yes but m_currentFrameOffset is not always zero, as you have assumed

daschuer · 2026-02-14T21:10:52Z

+                        std::min(m_expectedFrameLatency - m_currentFrameOffset,
+                                SINT(MAX_BUFFER_LEN))));
+        m_stretch.outputSeek(m_bufferPtrs.data(), frameRead);
+        m_currentFrameOffset += frameRead;


Suggested change

m_currentFrameOffset += frameRead;

m_currentFrameOffset = frameRead;

The current code is correct. frameRead contains the relative offset, but m_currentFrameOffset is absolute

m_currentFrameOffset is 0 here. Therefore the + operation is redundant.

No, see other thread

You have probably missed that we are her in the if (m_currentFrameOffset == 0 && block.

daschuer · 2026-02-14T21:12:02Z

+                        std::min(m_expectedFrameLatency - m_currentFrameOffset,
+                                SINT(MAX_BUFFER_LEN))));


Suggested change

std::min(m_expectedFrameLatency - m_currentFrameOffset,

SINT(MAX_BUFFER_LEN))));

std::min(m_expectedFrameLatency, SINT(MAX_BUFFER_LEN))));

No, the current code is correct - m_currentFrameOffset contains the current offset, but we need to see how much more (or less) frames we need to adjust the offset.

It is always zero.

No it is not. It is zero only on first process, then it contains the input latency of the previous process.

FYI, I have tested all your suggestion and they don't work.

acolombier · 2026-02-14T23:36:30Z

There is a CMake warning

This is a warning related to the SiS project itself. I'll look to issue a patch upstream in the future.

acolombier · 2026-02-14T23:38:42Z

Thank you for your indepth test @ronso0 and @daschuer !

I have pushed the changes that were applicable now. I appreciate it is not all perfect, but I'd like to go ahead with Daniel's suggestion here and merge this as an early experiment.

daschuer · 2026-02-15T11:22:48Z

There is a CMake warning

This is a warning related to the SiS project itself. I'll look to issue a patch upstream in the future.

Why not vendor the library now. We want to do it anyway, right? This way we get also rid of the unnecessary cmake changes and solve the PPA build right away-

daschuer · 2026-02-15T11:31:21Z

Why is the filter reset when the track is paused? I think we need only reset the filter in case we have a seek. Looping is handled inside the 'readAheadManager::getNextSamples()' so the resampler should work independent form looping. Do you have an idea why this is not the case?

Maybe both issues are source by the same bug?

acolombier · 2026-02-15T11:33:42Z

This is an experiment and I don't want to clutter the repo for now. It is clear that we will need to rework library distribution ahead of making this feature globally available, but there is no need to do it for the experimental phase.

JoergAtGithub · 2026-02-15T11:43:13Z

This is an experiment and I don't want to clutter the repo for now. It is clear that we will need to rework library distribution ahead of making this feature globally available, but there is no need to do it for the experimental phase.

Before we can merge a PR it must be mature. Thats the principle of Continious Code integration!

I suggest to create another PR which just adds the signalsmith-strech code to the lib folder first. This would be a no-brainer that we could easily merge before this PR.

acolombier · 2026-02-15T19:30:57Z

I suggest to create another PR which just adds the signalsmith-strech code to the lib folder first. This would be a no-brainer that we could easily merge before this PR.

Done: #15986

ronso0 · 2026-02-15T19:46:54Z

Just a heads-up as I have the impression that fact is not obvious:
the SignalSmith stretcher requires the CMake flag SIGNALSMITH set true

JoergAtGithub · 2026-02-16T07:48:23Z

I suggest to create another PR which just adds the signalsmith-strech code to the lib folder first. This would be a no-brainer that we could easily merge before this PR.

Done: #15986

Why you marked it as [Don't merge] and experimental ? It's only purpose is to merge it before this PR, to get rid of the problematic code in this PR.

acolombier · 2026-02-16T23:46:51Z

Why you marked it as [Don't merge] and experimental ?

Because SiS is not recommended for stable use yet, as a few issues have been highlighted in this PR. Some of those issues are releated to upstream problem, so why it is experiemental, I want to keep the git fetching to easily pin new version. Since the source is composed of two indirections of git submodules, it is quite a pain to take a new snapshot on every changes.

Just a heads-up as I have the impression that fact is not obvious:
the SignalSmith stretcher requires the CMake flag SIGNALSMITH set true

Thanks @ronso0! Indeed, when we decide that SiS is ready, we can merge #15986 and consider setting SIGNALSMITH=true to make it available by default.

daschuer · 2026-02-17T08:05:25Z

Since the source is composed of two indirections of git submodules, it is quite a pain to take a new snapshot on every changes.

Which part is a pain. I consider it just a tree replace operation in you favorite file explorer.

Some of those issues are releated to upstream problem

Which one? This one already performed way better than Rubberband. The only issue it the missing filter settlement. Which can be fixed in our code.
The looping issue is probably also our issue and kann be fixed here.

I also share the concerns to merge this premature.
This is already usable so let's fix the remaining issues and enable it for all users.

acolombier · 2026-02-17T08:52:07Z

Which part is a pain [?]

I answered previously, the multiple indirection of git modules.

Which one?

The CMake warning for example

I also share the concerns to merge this premature.

Great, let's just block this feature then.

daschuer · 2026-02-17T12:23:21Z

Does this mean you have no interest to look into the looping and setting issue?

acolombier · 2026-02-17T13:15:06Z

Not in the immediate term. I consider that to be enhancement, which could happen once we consider this experiment mature enough to distribute in the development branch.
I am not planning to invest more work here as it looks like this feature is heading to a potential deadlock.

ronso0 · 2026-03-14T15:57:49Z

Despite the rare issue with loop wrap-around I've been using this for the last weeks and I'm pretty happy with it.

responsive, punchy hotcue play, transients/kicks preserved 🥁
can safely lower the buffer to 2.6 ms 🎉 (before I had 10 ms with RB3 just to play it safe)
-> note that this is with Engine thread CPU isolate, though the reduced CPU impact likely applies to all environments

edit hmm, the loop pops also affect short looprolls, so I need to be very cautious when using them

However, this reveals an issue with the latency_usage meter and the audio_latency_overload indicator:
when I lower the buffer to 1.3 ms the meter may rise to ~50 % (green) but I see the overload indicator flash occasionally.

0cwa · 2026-08-12T16:21:36Z

The branch and this comment were prepared with ChatGPT assistance. I pushed a separate SignalSmith follow-up branch: https://github.com/0cwa/mixxx/tree/feat/signalsmith-stretch-followups

It contains two SignalSmith-specific commits:

5a4e966: output-buffer correctness
bdfee01: scaler-buffer hardening

Each commit was built in the mixxx-build distrobox and its focused engine suite passed 14/14. Bungee, Rekordbox, and unrelated selector changes were intentionally excluded.

github-actions Bot added engine build controller backend labels Jan 25, 2026

daschuer requested changes Jan 25, 2026

View reviewed changes

acolombier commented Jan 25, 2026

View reviewed changes

Comment thread src/engine/enginebuffer.h

acolombier added 2 commits January 25, 2026 21:32

feat: add SignalSmith keylock engine

224c6f3

chore: bump up the minimum CMake version to 3.24

b39a8e7

acolombier force-pushed the feat/signalsmith-stretch branch from 47e17e8 to b39a8e7 Compare January 25, 2026 21:32

acolombier marked this pull request as ready for review January 25, 2026 21:32

daschuer reviewed Jan 25, 2026

View reviewed changes

Comment thread CMakeLists.txt Outdated

daschuer requested changes Jan 26, 2026

View reviewed changes

acolombier added 2 commits January 27, 2026 02:03

fixup! feat: add SignalSmith keylock engine

b3cfe16

fixup! chore: bump up the minimum CMake version to 3.24

dabeac9

acolombier commented Jan 27, 2026

View reviewed changes

daschuer requested changes Jan 27, 2026

View reviewed changes

fixup! feat: add SignalSmith keylock engine

2e00ee3

acolombier requested a review from daschuer February 1, 2026 02:55

Merge remote-tracking branch 'upstream/main' into feat/signalsmith-st…

044935a

…retch

daschuer requested changes Feb 14, 2026

View reviewed changes

fixup! feat: add SignalSmith keylock engine

2244ee5

acolombier requested a review from daschuer February 14, 2026 23:38

acolombier marked this pull request as draft February 17, 2026 08:52

ronso0 mentioned this pull request Apr 17, 2026

Add Bungee Stretching/Keylock Engine 0cwa/mixxx#5

Open

fixup! feat: add SignalSmith keylock engine

600e262

ronso0 mentioned this pull request Jun 15, 2026

Add Bungee keylock scaler integration #16435

Draft

ronso0 mentioned this pull request Jul 20, 2026

Add rubberband R3 single window support #16752

Merged

		if (m_currentFrameOffset == 0 &&
		m_currentFrameOffset < m_expectedFrameLatency

	if (m_currentFrameOffset == 0 &&
	m_currentFrameOffset < m_expectedFrameLatency
	if (m_currentFrameOffset == 0

	m_currentFrameOffset += frameRead;
	m_currentFrameOffset = frameRead;

		std::min(m_expectedFrameLatency - m_currentFrameOffset,
		SINT(MAX_BUFFER_LEN))));

	std::min(m_expectedFrameLatency - m_currentFrameOffset,
	SINT(MAX_BUFFER_LEN))));
	std::min(m_expectedFrameLatency, SINT(MAX_BUFFER_LEN))));

Uh oh!

Uh oh!

Conversation

acolombier commented Jan 25, 2026 • edited by ronso0 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

daschuer commented Jan 25, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

acolombier Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daschuer Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

acolombier commented Jan 25, 2026

Uh oh!

acolombier commented Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

daschuer commented Jan 25, 2026

Uh oh!

acolombier commented Jan 25, 2026

Uh oh!

acolombier commented Jan 25, 2026

Uh oh!

daschuer commented Jan 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

acolombier left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

acolombier commented Jan 25, 2026 •

edited by ronso0

Loading

acolombier Jan 25, 2026 •

edited

Loading

daschuer Jan 25, 2026 •

edited

Loading

acolombier commented Jan 25, 2026 •

edited

Loading

acolombier Jan 27, 2026 •

edited

Loading

ronso0 commented Jan 29, 2026 •

edited

Loading

ronso0 commented Feb 5, 2026 •

edited

Loading

ronso0 commented Feb 14, 2026 •

edited

Loading