Hotone Ampero II Setup под Linux — рабочая сборка (Steam Deck, ThinkPad, без Windows и без Steam)

Автор: metallcorn июля 27, 2026

TL;DR — если ты просто искал, как это запустить

Официальный редактор патчей Hotone (Ampero II Setup V1.5.1) — только под Windows. Я собрал полностью автономный Linux-бандл: пропатченный Wine/Proton + готовый префикс с уже установленным и уже пропатченным редактором. Ничего дополнительно ставить не надо — ни Steam, ни отдельный Wine, ни компилятор.

Что внутри и что уже исправлено:

краш при подключении из-за реального бага в HTUSBTools.dll самого Hotone — пропатчен бинарно;
чёрный экран / графический мусор из-за DXVK — DXVK не используется вовсе;
зависание на подключении педали ("бесконечная загрузка") — это отдельный неприятный баг, воркэраунд ниже;
проблема с 32-битным лоадером на хостах без i386-рантайма (обычный современный Ubuntu/KDE neon) — обойдена.

Проверено: Steam Deck и обычный ThinkPad T14 Gen3 (KDE neon 24.04, AMD GPU, Wayland/XWayland). Требования:x86_64 Linux с графической сессией, ядерные модули xhci_hcd/snd-usb-audio (они и так есть почти везде по умолчанию), 32-битный рантайм не нужен.

Запуск:

./launch.sh

Скрипт сам ретраит запуск при зависании хендшейка (см. ниже, почему это нужно) — обычно этого даже не замечаешь.

Ссылки:

Исходники / патчи / скрипты, если хочешь собрать сам под свой Wine: github.com/metallcorn/ampero2-linux
Готовый бандл целиком (~2.2GB, ничего доустанавливать не надо): ссылка на mega

Дальше — как я до этого докатился и что было по пути, если интересно.

Как это вообще случилось

Я не разработчик — 20 лет в ИТ, из них 15+ на Linux, но писать код не умею и не умел. Купил Hotone Ampero II Stage — процессор классный, придраться не к чему. А вот софт под него — только Windows, и точка. Ни линуксовой версии, ни веб-редактора, ничего. С учётом того, насколько хороша сама железка, это ощущалось как досадная проблема, и я решил проверить, смогу ли я её закрыть сам.

Я использовал Claude Code (Opus 4.8) для работы с кодом (внутренности Wine, патчинг DLL и всё такое). Между этим и упрямством я всё-таки добился того, чтобы редактор реально запускался под Wine/Proton и общался с педалью по MIDI.

Легко не было. По пути вылезло как минимум три отдельных, никак не связанных друг с другом бага.

Баг №1: чёрный экран / радужный мусор вместо интерфейса

Классика — X11DRV_vkCreateWin32SurfaceKHR: Application requires child window rendering, which is not implemented yet!. DXVK не умеет в этот способ рендеринга окна, который использует Flutter-приложение (а редактор Hotone, судя по всему, написан именно на Flutter). Лечится просто — не использовать DXVK вообще для этого приложения. С обычным wined3d интерфейс рисуется нормально.

Баг №2: краш при подключении педали — реальный баг у Hotone

Отдельная беда, не имеющая отношения к Wine вообще — в HTUSBTools.dll, который сам Hotone поставляет с редактором, есть баг, из-за которого приложение падает при подключении устройства. Это не проблема совместимости, это баг в их коде, который проявляется и под настоящей Windows (просто там реже ловится, видимо из-за других таймингов). Пришлось бинарно патчить DLL.

Баг №3: "бесконечная загрузка" после подключения педали — самый неприятный

Это тот баг, который я до конца не победил, только обошёл. При хендшейке редактор запрашивает у педали ~20 кусков конфигурации. Иногда один ответ просто пропадает — и редактор никогда не переспрашивает этот конкретный адрес, поэтому весь хендшейк виснет навсегда.

Что я реально проверил, а не предположил: снял сырой MIDI-трафик через aseqdump и сверил байт в байт с логом самого приложения.

Педаль всегда отправляет ответ. На каждом зависании, что я поймал, полный SysEx-ответ был на проводе, целиком, корректно оформлен.
ALSA его тоже не роняет — ноль ошибок аллокации, ноль overrun'ов, Wine исправно продолжает выдавать буферы приложению всё это время.
Значит, ответ теряется где-то между тем, как Wine отдаёт данные, и тем, как приложение их разбирает. Что бросается в глаза: приложение читает MIDI-вход буферами всего по 112 байт, а один ответ — это 2-3 килобайта, размазанные по 15+ кускам. Есть где ошибиться при сборке.
Что я проверял и отбросил (парными A/B-замерами, а не на глаз): включение трейсинга Wine, второй слушатель на MIDI-порту, нагрузка на CPU, лимиты очереди ALSA, HTTP-запрос "проверка обновлений" на сервер Hotone в середине хендшейка — ничего из этого стабильно не меняет процент успеха. А сам процент успеха скачет от ~20% до ~90% между сериями замеров по причинам, которые я так и не нашёл.

Раз чистого фикса нет — сделал скрипт, который следит за логом, и при зависании убивает и перезапускает сессию, пока не подключится. Обычно подключается за 1-2 попытки, в плохие моменты может понадобиться 4-5.

Баг №4 (бонус, не про софт): 32-битный лоадер там, где его нет

На SteamOS всё работало из коробки, а на обычном Ubuntu-based хосте без i386-рантайма — сразу падало с /lib/ld-linux.so.2: could not open. Оказалось, используемая сборка Proton (старого типа WoW64) при старте безусловно переисполняется в 32-битный лоадер, даже когда сам целевой .exe — чисто 64-битный (а Ampero II.exe именно такой). Через strace нашёл, где именно это происходит, и обошёл через WINELOADERNOEXEC=1 — Wine остаётся в уже запущенном 64-битном процессе и не пытается переисполниться в 32-битный.

Известные ограничения бандла

Имя пользователя deck зашито в некоторые пути внутри префикса (prefix/drive_c/users/deck/...). Обычно это не мешает, Wine это разруливает на лету, но если увидишь странности с профилями/настройками — вот откуда.
winedmo.so не грузится, если на хосте FFmpeg 5+ (например, стоковый Ubuntu 24.04) — сам редактор эту библиотеку не трогает, так что на практике ничего не ломается, но если когда-нибудь понадобится Media Foundation внутри Wine — оно тихо не сработает.
Приложение действительно ходит в сеть (community.hotoneaudio.com.cn, проверка обновлений в середине хендшейка) — не обязательно для работы, но добавляет паузу, поэтому таймауты в скрипте настроены с запасом.
Это снэпшот рабочего состояния на 27.07.2026 — само не обновляется (это фича: ничего тихо не сломается), но и новых версий редактора/фиксов Proton само по себе не подтянет.

Если пригодилось

Буду рад, если это сэкономит кому-то те же пару недель, что съел у меня этот процессор. Багрепорты, тесты на других дистрибутивах, вопросы — welcome, пишите в комментариях или в issues на GitHub.

Поиск по этому блогу

Во имя OpenSource