QAndroidJniObject. To naprawdę działa!

Jakby ktoś się zastanawiał, to walczę dalej z portem aspeqt na Androida, a dokładniej z obsługą czipu FTDI na Androidzie. Sterownik ftd2xx od FTDI to totalna porażka (segfault goni segfault) i z tego co widzę nie ma szans na obsługę FTDI za pomocą tego sterownika bez roota i modyfikacji obrazu systemu.

Na szczęście jest jeszcze libftdi.

Ale i tutaj nie jest tak różowo. W pierwszej kolejności musiałem skompilować libusb na Antka, potem samo libftdi, a to wszystko, żeby się przekonać, że standardowe libusb nie potrafi otworzyć urządzenia bo nie ma do tego uprawnień. I choćby nie wiem jak kombinować z uprawnieniami w Manifest.xml, nic  to nie da.

Jest alternatywne podejście: najpierw z poziomu Javy należy otworzyć urządzenie i uzyskać uprawnienia do usb. Potem przekazać deskryptor pliku urządzenia do libusb. To ponoć działa na delikatnie zmodyfikowanej wersji libusb (mam już ją skompilowaną na Antka).

Mój plan był prosty: z poziomu QT wywołuje klasę Javovą, która otworzy urządzenie i poprosi o uprawnienia, a potem zwróci do QT deskryptor pliku. Plan planem, ale JNI w QAndroidJniObject nie chciało mi działać. Teraz już wiem dlaczego :). Przykład Bogdana Vetry zawierał rozwiązanie problemu w pierwszym komentarzu: plik źródłowy w Javie, umieszczamy w katalogach odpowiadających strukturze pakietu, ale w android/src. Jak pakiet utworzę w android to nie zadziała ;).

Czyli:
1. Tworzymy nowy projekt QT Android.
2. W pliku .pro dodajemy:

QT += core gui androidextras
ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android/

W katalogu projektu dodajemy katalog android/src/net/greblus/MyJavaClass.java:

package net.greblus;

public class MyJavaClass {
     public static int fibonacci(int n)
    {
        if (n < 2)
            return n;
        return fibonacci(n-1) + fibonacci(n-2);
    }
}

i wywołujemy w C++ z QAndroidJniObject w ten sposób:

ret = QAndroidJniObject::callStaticMethod<jint>("net/greblus/MyJavaClass", "fibonacci", "(I)I", n);

Dwa wieczory spędziłem nad tym brakującym src, ale dzięki temu sporo się nauczyłem ;). QT5 to dla mnie w tym momencie toolkit nr 1.

libusb mam już skompilowane, teraz tylko mała modyfikacja libftdi i można próbować z otwieraniem urządzenia z Javy ;).

QAndroidJniObject. To naprawdę działa!

Aspeqt na github.

Aktualny deweloper Aspeqt pokłócił się z paroma osobami na forum Atari Age i dostał tam bana. W odwecie usunął wszystkie wprowadzone przez niego zmiany od wersji 0.6 do 1.0 i postanowił rozwijać to dalej w zaciszu swojego forum, udostępniając za opłatą. Szkoda.

Wrzuciłem ostatnie udostępione na AAge źródła 1.0.0 preview 6 do repo na Github.

https://github.com/greblus/aspeqt

Nie mam jakichś wielkich planów, chciałbym kompilować od czasu do czasu aby działało na aktualnych wersjach bibliotek. Fajnie by było też zrobić nowe gui, bo aktualne jest beznadziejne, zwłaszcza na małych ekranach, ale to w wolnych chwilach.

Pierwszy pomysł jest taki: minimalna geometria okna i dynamiczne dodawanie slotów:

mini_aspeqtUpdate:

Tak sobie niezobowiązująco myślę… Jest port QT5 na Androida: http://doc.qt.io/qt-5/android-support.html muszę się więc zaznajomić z Android NDK. Nawet gdyby trzeba było Gui zrobić od nowa, zdecydowanie jest to do zrobienia.

FTDI też działa: http://www.ftdichip.com/Android.htm (sprawdzałem na tablecie z 4.2.2 i faktycznie, wygląda że to działa out-of-the-box).

Myślę, że przy odrobinie wolnego czasu można by to ze sobą pożenić. Jest w TME nawet FTDI w wersji zintegrowanej z kablem. SIO2PC zmieści się we wtyczce SIO. Dałoby się z tego zrobić coś fajnego ;).

 

Aspeqt na github.

Yamaha DTX-400 i Krigg Triggera.

Postanowiłem wymienić KU-100 (silent kick pedal) Yamahy na mechaniczny pedał stopy z triggerem piezoelektrycznym. Wybór padł na Krigg Triggera + tani pedał stopy Basix PD-600 V3. Pedał bardzo fajny z napędem łańcuszkowym, a co najważniejsze – oddzielnym uchwytem bijaka. Po zdemontowaniu, jak widać na zdjęciach poniżej, zostaje tylko uchwyt łańcuszka. Wygląda na niezniszczalny.

Działa świetnie ;). Tylko trochę ciężko się samemu nagrać.

Do pełni szczęścia trzeba ustawić w DTX-400 charakterystykę prędkości na 3 (Song + Kit potem 5 i 1, kick i wpisać wartość 3) żeby było głośno i wyraźnie nawet przy lekkim graniu. Odstęp między mocowaniem łańcuszka a przetwornikiem ustawiłem na 4-5mm, a punkt styku mocowania łańcuszka z gumą przetwornika podkleiłem taśmą izolacyjną (zostają ślady po uderzaniu metalu o gumę).

Yamaha DTX-400 i Krigg Triggera.

DIVMMC/ESXDOS na MIST.

Bardzo mnie ucieszyła ta zmiana w rdzeniu ZX Spectrum dla MIST:

The DIVMMC/ESXDOS combo provides easy and fast access to spectrum games stored on SD card. With release r877 the zxmmc has been replaced by a DIVMMC implementation in the spectrum core.

ESXDOS aims to be the ultimate firmware for the DivIDE/DivMMC interface. Here’s a list of current features:

    • DivMMC: Supports MMC/SD/SDHC devices
    • Device and filesystem abstraction layer
    • Full FAT16/FAT32 read/write support (no extended partitions, no LFN).
    • Virtual Disk support (up to 4 devices)
    • Betadisk/TR-DOS emulation using (trimmed) .TRD files
    • Provides extended BASIC commands
    • BASIC files integration using +3DOS headers for FAT filesystems
    • Support for seamless IM2 loading/saving, from BASIC and machine code
    • System commands loaded from /BIN dir of system drive
    • TAPE emulator supports reading/writing from/to TAP files. TAP attaching functions are available to external programs.
    • POSIX-based API usable by .commands, external programs and NMI.SYS. Functions available on rst $08: open, read, write, close, opendir, readdir, seek, sync, fstat, getcwd, chdir, unlink…
    • Possibility of getting absolute LBA sector and device on an opened file (for direct I/O)
    • Kernel loads modules (.KO files) on demand
    • NMI.SYS support (NMI system is independent, ESXDOS kernel just provides services)

„Zawsze chciałem mieć takie coś”, bo Spectrum to pierwszy komputer, jaki na oczy zobaczyłem.

DIVMMC/ESXDOS na MIST.

Fsthost-svn + Hybrit + Lecab2 na Tahr Puppy (RT) :)

Fsthost-svn da się skompilować bez GTK i lash:

make GTK=0 LASH_PRESENT=0 PLAT=32

a mimo to, dodanie opcji -l -s plik.fps i potem kill -SIGUSR1 <pid> zapisuje stan wtyczki :) (wielkie dzięki dla autora za wskazówki i cierpliwość).

chrt -f -p 89 `pidof jackd`
export WINE_RT=10; export WINE_SRV_RT=5
set_rlimits /usr/bin/fsthost -s ~/fsthost/brit.fps ~/poulin/HyBrit.dll&
set_rlimits /usr/bin/fsthost -s ~/fsthost/lecab.fps ~/poulin/Poulin_LeCab2_Rev1.dll&

i na wszelki wypadek:

pids=`pidof fsthost.so`
for pid in $pids; do chrt -f -p $pid; done

DSP load na poziomie <20% i brak xruns :). Co ciekawe, jak obciążę procesor np. klikoma pustymi pętlami while 1: pass, DSP run spada do 10-11%. Nadal uważam, że to zdecydowanie za dużo. Vsthost z dużym pluginem, typu GR5 generuje DSP load do 3% przy znacznie większej liczbie uruchomionych efektów… Ale raczej pozostanie to jako zagadka. Faktem jest, że te pluginy pod Linuksem działają lepiej jak pod Windows.

set_rlimits, bo w Puppim nie ma pam i /etc/security/limits.conf, a wine z łatką rt ma problem z priorytetami bez tego (trzeba przeedytować /etc/set_rlimits.conf).

Fsthost-svn + Hybrit + Lecab2 na Tahr Puppy (RT) :)

Wysoki DSP load dla wtyczek VST Win32.

Staram się ograrnąć temat VST pod Linuksem i pomimo że nie jest najgorzej, zauważyłem dziwne zjawisko: wysoki DSP load i xruns w Ardour przez vst-bridge lub w Carli, przez jej własny bridge dla wtyczek VST. Dwa dni kombinacji i udało mi się zejść do nieco poniżej 50% (przez winetricks zainstalowałem gdiplus i vcrun205{08,10}, choć nie wiem czy to pomogło, dodałem też  i915.do_wbinvd=no do parametrów kernela, bo podobno sterowniki grafiki dają w kość, ale to dalej nie to! choć jeszcze wczoraj load skakał do 70-90%).

Najdziwniejsze jest to, że na starym vsthost z projektu dssi-vst DSP load jest na poziomie max 2-3% dla tych samych wtyczek. 

Ciekawe czy autor Carli, KXStudio i aktualny deweloper dssi-vst, Filipe Coelho aka falkTX, coś odpowie.

vst_host_low_dsp_loadardour_vst_bridgecarla_vst_bridgeCiekawe, że vst-bridge również cierpi na to samo „schorzenie”, choć działa nieco inaczej.

Update: zmieniłem IR loader na keFIR i da się żyć. DSP load na poziomie <40% xruns sporadycznie. Brzmienia darmowych symulacji wzmaków z dobrymi odpowiedziami impulsowymi cabinetów są lepsze od wszystkiego co słyszałem do tej pory w GR5.

Wysoki DSP load dla wtyczek VST Win32.