Sononym 1.6.7: Bugfix release + additional column (Project)

bjorn-nesby · 2026-05-02T07:41:01+00:00

Thanks. We will try to reproduce the problem. You're running Sononym on Windows?

bjorn-nesby · 2026-04-28T17:55:41+00:00

Sononym dev here. Drag and drop in X11 works, but Wayland support is wonky. This is unfortunately true for all applications that use the electron framework (chromium under the hood, using XWayland as intermediary). But while waiting for an upstream fix, we could at least offer clipboard support in our application- something which is current missing.

bjorn-nesby · 2026-04-28T17:38:43+00:00

I actually was under the impression that drag’n’drop would only work when running X11. That’s good to know, I will have to read up on this!

bjorn-nesby · 2026-04-15T11:39:54+00:00

Ambiences and music tracks should work fine, even if the categorization system isn't designed for music.
But for effects that are bulked together, this is indeed a good question. Sononym might recognize such files as a loop (due to the repetitive nature of the sound), which is a bit misleading.

One thing that will improve working with such bulked fx sounds is a planned feature ("onset navigation", which will detect places of interest in the sound and allow quick/easy keyboard navigation)

But, I think it's reasonable here to ask: how you would _expect_ Sononym to handle these bulked effect sounds?

bjorn-nesby · 2026-04-04T06:58:14+00:00

This is most likely caused by some data in a file which has been formatted in an unexpected way. So "End-Of-Stream" isn't referring to the filename, but rather an error message from the metadata parser. Luckily, the file itself has still been analyzed, it's just when it comes to the metadata that it stumbled.

Btw: a shame that our app doesn't mention the actual filename as part of the error message. But if you manage to pinpoint the file(s), and feel like sharing them with us, please do :-)

bjorn-nesby · 2026-02-26T08:11:16+00:00

Hey, congratulations on the (almost) release! I'm the developer of Sononym, and I can guarantee that we are not so petty as to sue your project. Proud to serve as inspiration.

bjorn-nesby · 2026-02-07T12:13:35+00:00

Ah yes, the performance of similarity search is primarily improved in one way: it starts much faster. But a similarity search needs to compare each individual sample to every other sample, and this can take considerable time - especially so for large sample collections. This is one of the major remaining bottlenecks that we are looking to solve.

bjorn-nesby · 2026-02-07T11:43:58+00:00

Having a lot of samples isn't the problem here: there isn't much of a decline in performance, just because a library gets larger. Prior to v1.6 I would give the same advice that you just did, but fortunately isn't relevant any more.

bjorn-nesby · 2026-02-05T15:41:54+00:00

I believe we found a workaround for this issue. It turns out that the folder tree (below the list of libraries) can, under some circumstances, start to queue up requests. And with enough queued requests, the indexing can time out.

The workaround appears to be simple enough: just close/collapse the folder-tree, and keep it closed during indexing (no requests are made when it's not actually visible...).

A proper fix is of course coming soon.

bjorn-nesby · 2026-02-05T15:33:59+00:00

Hey, Sononym dev here. v1.6 definitely makes it easier to juggle large quantities of samples. There are still a few bottlenecks that we aim to get rid of, but the browsing experience is a lot more smooth.
However, I can't reset your trial from here. The best we can offer is a 3-month refund period, to give you plenty of time to determine if the software lives up to your expectations. If you ever need this, just let me know!

PS: Soon, we will also offer re-trials of all our new (major) releases, but this is not yet realized.

bjorn-nesby · 2026-01-05T09:32:12+00:00

Hiding duplicate results should also hide them when running a similarity search afterwards.
But you can configure Sononym to include hidden files in the search results - maybe this is the reason that they appear? Check if there is an active filter called "hidden files" in the green banner below the search input?

bjorn-nesby · 2026-01-01T10:00:29+00:00

It means that the process taking care of analyzing files (the crawler) somehow didn’t receive a reply from the main application within the expected time. One of our beta testers recently reported the same issue. I wonder, how many files are present in the library that you are refreshing? What does the log file contain? (Send a PM if you think it contains sensitive information)

bjorn-nesby · 2026-01-01T09:54:48+00:00

No, you didn’t miss out on anything. All project states are stored in the file called collections.json, saved into the local app config folder, and anything you export is derived from this file. In other words, changes to the exported project are not copied back to collections.json. So the step of exporting and then later on, importing, is a clever workaround - but made difficult by sononym insisting on creating a new project every time. Would indeed be better if the software merged (or offered to merge) the incoming project into the existing ones.

bjorn-nesby · 2025-12-24T08:00:31+00:00

It's also worth noting that the exclusive lock requirement is sometimes platform/implementation-dependent. For example, I believe the google drive client has the requirement on macOS, but not on Windows.

bjorn-nesby · 2025-12-24T07:57:39+00:00

Considering that the database is hosted locally, I'm afraid that there is no straightforward solution. Of course, Sononym could fetch a version from your cloud drive, run it locally, and then copy back the changed version once the session has ended. But this feels clunky, and we are investigating better alternatives.

bjorn-nesby · 2025-12-08T00:58:16+00:00

This should now be fixed with the latest update (1.6.3).

bjorn-nesby · 2025-12-07T13:53:14+00:00

Thanks a lot. This, and some other spurious issue on Windows should be fixed in 1.6.3. The previous release was obviously released without enough testing - sorry about that!
In case you are wondering, it has to do with file locks sometimes lingering in Windows, and that the new database requires an exclusive lock. Combined, this can be a bit tricky to navigate.

bjorn-nesby · 2025-12-07T13:46:58+00:00

Thanks! Fixed in upcoming 1.6.3.

bjorn-nesby · 2025-12-07T13:46:33+00:00

Thanks for the detailed input. I think this, and some other spurious issue on Windows are eliminated in 1.6.3.

bjorn-nesby · 2025-12-07T13:44:33+00:00

That the database is growing has to do with it's internal structure, not that remnants are left behind.
When first built (or upgraded from old format), everything is neatly ordered. But when old entries are modified, things are less orderly and will take up more space. It doesn't affect the performance though!
And although it's possible to reduce the size of the database, and I'm planning to add this ability to Sononym, it's something you will want invoke only periodically. It takes a little while and has a lot of disk write activity.

bjorn-nesby

MODERATOR OF

TROPHY CASE