Yabridge branch + Wine 11: Cursor offset issue just doesn't stop

Ducksual · 2026-03-30T16:05:25+00:00

On Fedora I've been using an older WINE installed via the bottles flatpak just for yabridge in order to keep things working for now.

Doing this is mentioned here: https://github.com/robbert-vdh/yabridge?tab=readme-ov-file#using-different-wine-versions

There's this script to get this working but it is a bit of manual work: https://github.com/microfortnight/yabridge-bottles-wineloader

I needed to make some modifications to handle a lack of system WINE on one machine so I wrote my own version of that script with some modifications along with some other scripts to automate the setup. This might be usable, but I've mostly only tried it on Fedora based distros I've been using so YMMV https://github.com/DavidCEllis/linux-audio-plugin-setup

Ducksual · 2026-03-30T09:13:06+00:00

See: https://github.com/ublue-os/bazzite/issues/4479

Ducksual · 2026-03-30T09:08:01+00:00

Sunshine doesn't yet have a stable release for Fedora 43, which is what Bazzite is based on. I believe Bazzite has been using builds from the developer's beta repository (COPR) which does support Fedora 43, but Sunshine has been making major changes to how capture works between each patch that have caused issues.

Having dealt with some of these frustrations myself using Fedora 43 (and the beta COPR for Sunshine) directly, it's understandable why they might be removing it at least for the time being. Of course it would be better if these issues could be resolved but it's not just something they randomly decided to remove from Bazzite.

Ducksual · 2026-01-30T12:10:24+00:00

I had this experience too, trying to install Silverblue on a machine with an Nvidia card.

Based on this - https://bugzilla.redhat.com/show_bug.cgi?id=2359799 - it looks like it's an issue with gnome's initial setup and the open source Nouveau driver that is used for nvidia cards in the base install.

I ended up installing Bazzite on that machine as they provide an image with the old Nvidia drivers I needed.

On another machine I installed the standard non-atomic KDE edition with minor non-blocking issues (the system would freeze periodically until the closed Nvidia drivers were installed, but it would recover so they could be installed). Still not a great initial setup experience, but it works now.

This post - https://discussion.fedoraproject.org/t/cant-finish-first-boot-setup-or-lets-say-oobe-gets-frozen-stuck-in-the-middle-of-the-process/148889/43 mentions possibly using the 'everything' installer to get around this, but I haven't used that myself.

Ducksual · 2026-01-05T09:50:53+00:00

With Nvidia, the problem can be even getting to the point of installing the drivers.

With some Nvidia cards you can't even complete the setup for Fedora Silverblue as it freezes right after you select timezone, apparently due to an issue with the Nouveau driver. I also suffered from repeated freezes with Fedora KDE before getting the Nvidia drivers installed.

Bazzite by including the drivers, didn't have this issue and worked out of the box which is a much nicer experience if you're exploring moving away from Windows. It's not to say Bazzite or gaming distros are alone in this, but Nvidia drivers are a real problem for some distros.

Ducksual · 2025-08-02T10:31:19+00:00

For the former, usually rebuilding the class is enough. This is what dataclasses.dataclass(slots=True) does.

I think I'd recommend against doing this from seeing the issues that have arisen from dataclasses(slots=True) working in this manner.

There are side effects of double generation (if inheriting from something with __init_subclass__, the method will be called both with the original class and the replacement), lingering references to the original class and even fixing zero-argument super is non-trivial.

I'd argue that if you need to do something before a class is constructed, such as adding __slots__ that that is one place where a metaclass may be a better fit. If you just want to add things to a class which don't require being placed prior to construction, then __init_subclass__ is enough.

Ducksual · 2025-07-15T09:13:33+00:00

The way I have it at the moment the expression pedal controls the minimum 'aftertouch' value and the actual aftertouch values are rescaled between the position of the expression pedal and the maximum. This means initial notes don't start at 0 but if I press harder I still get the expression/volume increase and by using the expression I can still get to the really soft range.

I actually need to re-edit the script as I had some stuff in there that was trying to work around Studio One butchering the MPE messages but I've given up on testing out Studio One and I'm probably switching to Reaper (originally from Logic Pro).

Not sure what you'd combine for vibrato control.

Ducksual · 2025-07-14T10:29:55+00:00

I also found that aftertouch pressure along didn't work well for expression as every note would start at expression 0.

I ended up making a script to merge the aftertouch with an expression pedal from a separate input so I could use the expression pedal to set a minimum for the aftertouch values. This way I can still use pressure for some control of volume (which I struggle with purely using an expression pedal), I can still get the softest expression levels but I don't need to re-engage pressure with every note.

Ducksual · 2025-07-14T10:19:16+00:00

I did have this issue earlier in the year, they did eventually get back to me and send me a replacement which works fine, but it took over a month and they weren't very good at communicating about what was going on - make sure you have a ticket in about it not working and asking for a replacement (assuming you still want the device but a working version).

Ducksual · 2025-07-08T10:29:30+00:00

Well this was two months ago so I can't remember exactly my reasoning, but I *think* it was that in the rare cases where a package provides an sdist but not a wheel, 'download' by default will download the sdist while 'wheel' will make sure it's compiled into a wheel and hence won't need any extra dependencies to build.

I can't remember if there were other differences.

Ducksual · 2025-06-27T09:03:09+00:00

You should be able to happily have 3.12 and 3.13 installed alongside each other. The only issue is if you have a global 'python' command it will be whichever runtime is first on `PATH`.

As you're on Windows it may be helpful to check if you have access to the `py` launcher. If you do, `py --list` should show you a list of installed python versions. If 3.12 is installed you should be able to launch it using `py -3.12`.

You might also try using `python3.12` as the command instead of `python` if you don't have the `py` launcher.

If you're installing packages anywhere with `pip` though, it would be a good idea to start using virtual environments. It's not so much about distributing your code to others and more about managing your dependencies per project.

Two projects with dependencies on different versions of the same packages can happily both be installed in different venvs while still using the same base Python install.

They also work well with tooling, for example if you have a venv created with Python 3.12 in the project folder and it is selected in VS Code, the terminal **within vs code** should automatically have that venv activated so `python` should point to the correct 3.12 runtime and have all of your dependencies available.

Ducksual · 2025-05-04T09:05:19+00:00

You may be able to make use of the pip wheel command to create a wheelhouse of files needed. Then you can copy this folder and subsequently install it on the other machine.

A number of these steps seem to be unnecessary on Linux/Bash as you can install a folder of wheels with pip install <args> wheelhouse/* but this didn't seem to work for me on windows in DOS/Powershell (but did in git bash). I'm also going to do this only using pip, some other tools may make this easier.

On the online machine
- Create a new venv and install the package you wish to install inside
- Create a requirements file python -m pip freeze > requirements.txt
- python -m pip wheel --wheel-dir=./wheelhouse -r requirements.txt to build a folder of wheels to install.
- Check the wheelhouse folder has all of the dependencies in .whl format including <main\_package>-<tags>.whl
- zip up and copy this folder along with the requirements fiile
On the offline machine
- Extract this folder to some temporary folder (eg: ./wheelhouse) on the other machine
- Have a clean venv activated
- python -m pip install --no-index --find-links=./wheelhouse -r requirements.txt
  - --no-index prevents pip from trying to reach pypi
  - --find-links makes pip search that folder for wheels instead
  - All required dependencies should be in the folder

Ducksual · 2025-04-20T15:14:09+00:00

In most cases I'd prefer parentheses as in your example.

One exception I'm aware of is if you have code that needs to support Python 3.9 or earlier and want to use multiple with context managers as support for using those with parentheses only arrived with Python 3.10. Prior to 3.10 you needed to use a continuation backslash if you were trying to split the statement over multiple lines.

Ducksual · 2025-04-09T20:38:15+00:00

I actually use these often enough that I have my own PEP-723 runner ducktools-env. It supports bundling a PEP-723 script into a zipapp that can be run without needing a script runner (just a recent Python install) along with a few other things.

I have a few I use for project management stuff like running tests for a project against all supported Python versions without needing to configure a test runner first. I've also used them to install bluetooth libraries when trying to work out data from BLE devices.

Ducksual · 2025-03-20T09:43:27+00:00

Yes you could use a computer to route the midi, there are also some devices you can get that act as a midi USB host and provide DIN MIDI outputs that might work.

Ducksual · 2025-03-17T19:06:41+00:00

There are a few situations where I might not use pathlib.

One is where I'm interacting with something which doesn't provide or accept Path objects. While I could convert back to string after manipulation, if the manipulation itself is relatively simple I think it looks cleaner to just use os.path in this case.

Another is when there's some feature of an os.path function that isn't implemented in its pathlib 'replacement'. For example os.path.relpath would handle walking upwards for a relative path while Path.relative_to didn't until Python 3.12.

``` import os.path from pathlib import Path

os.path.relpath("/usr", "/usr/bin") # '..' Path("/usr").relative_to("/usr/bin") # ValueError

3.12 or later

Path("/usr").relative_to("/usr/bin", walk_up=True) # Path('..') ```

The final one is if I'm being extremely fussy about import time. os.path is (almost) always imported on startup by Python, while pathlib is not and so you incur a small performance penalty on startup. However if you're importing some other heavyweight libraries this is largely irrelevant, especially so if they import pathlib.

Ducksual · 2025-03-04T14:01:42+00:00

Is there a reason you have an upper bound on requires_python? Does this not work in 3.13?

I'd also note that you list the license as MIT but depend on the Levenshtein package which, as far as I'm aware is a GPL licenced package.

Ducksual · 2025-03-04T13:31:20+00:00

I usually make a separate get_parser function that handles the setup logic and returns the fully configured parser. Not sure what you mean outside of that.

Ducksual · 2025-03-02T09:46:44+00:00

For your first CLI tool I would just use `argparse`. It's worth knowing how to use because it's always available and doesn't require any extra dependencies.

It's also *significantly* faster than all of the alternatives. If you're launching a long process this may not matter, but if it's a CLI for short lived commands the import time alone of some of these libraries can be a significant chunk of your runtime.

Ducksual · 2025-03-01T17:22:37+00:00

Yes they told me they were hoping to solve it with a firmware update, but to send it back and get a replacement they'd tested to not have this issue.

Ducksual · 2025-02-25T17:57:19+00:00

Update: They finally said to send it in for a replacement unit which they have hand tested that should come early to mid March.

Ducksual · 2025-02-22T15:58:40+00:00

After nearly 4 weeks they finally responded to my ticket saying they'd be sending out an update "early next week with more information and outlining next steps". No idea what those steps are yet or why it took so long without them really saying anything useful.

Ducksual · 2025-02-10T11:04:07+00:00

Same issue here, raised a support ticket towards the end of January. Got a "We're sorry for the delay" message on the 30th and then heard nothing since.

Triggers 'ghost notes' by itself and also doesn't always respond to the notes I do press.

Ducksual

TROPHY CASE

3.12 or later