Sway w Waylandzie zamiast X-ów.

Z X Window System szedłem przez życie, ale odkąd pierwszy raz przeczytałem o Wayland, od czasu do czasu sprawdzałem postępy w tym projekcie. Nie, żebym miał jakieś wielkie „ale” do X-ów, jednak na moje niewielkie potrzeby ta armata zawsze wydawała mi się zbyt wielkiego kalibru.

Mijały lata, zawsze czegoś jednak brakowało. Na początku duże „desktopy” jeszcze Wayland nie wspierały, później moja karta graficzna niezbyt działała (NV3100m, bo lubię stare laptopy). Aż w końcu nouveau i kernel polubiły się z moim retro-sprzętem i jest:

Najbardziej zaskoczył mnie sway. Złapał „w locie” moją konfigurację i3 na tyle skutecznie, że musiałem sie upewnić, czy to na pewno sway.

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/tree/master

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 ;).

Update: AspeQt na Androida tutaj.

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.

Tahrpup RT spotyka Poulin Legion, Lecto i LeCab2.

Cóż mogę powiedzieć… Chyba spałem pod kamieniem zbyt długo. Mam dziś wolne od pracy (ach te wiosenne ciepłe dni, łatwo się przeziębić) antybiotyk chyba działa, bo eksperymentuje dziś z wtyczkami VST do gitary i bardzo, ale to bardzo jestem zaskoczony jakością symulacji wzmaków http://lepouplugins.blogspot.com a szczególnie Legion – urywa dupę w połączeniu z Lecab2.
poulinWszystko co potrzeba do szczęścia pod Linuksem to vsthost i któraś z ogólnie dostępnych bibliotek impulsów gitarowych. Np Gods Cab,
lecto

Tahrpup 6 z kernelem RT.

Jestem zachwycony Puppim. Żadna inna dystrybucja nie wykorzystuje w ten sposób aufs (union type filesystem). Z pendrive działa to rewelacyjnie bo wszystko z systemu bazowego ładuje się do pamięci, a kolejne warstwy dogrywane są do obrazu aufs w pamięci z plików sfs. Dzięki temu pendrive się nie zużywa, a system jest bardzo szybki w odróżnieniu od typowej konfiguracji, w której zapisy i odczyty na pendrive powodują, że całość staje się niemal nieużywalna.Do pełni szczęścia potrzebowałem jedynie kernela RT ;). Pierwsze podejście – ze względu na dostępne wersje patchy RT – oryginalne źródła kernel_sources-3.14.11-tahr_PAE.sfs (już z łatkami z Puppiego) spaczowałem 3.14.12-rt8.patch. Et voila! A mój „Pro-audio” setup wygląda tak:

#!/bin/bash
cpufreq-set -g performance
echo 2048 > /sys/class/rtc/rtc0/max_user_freq
echo 2048 > /proc/sys/dev/hpet/max-user-freq
sysctl vm.swappiness=10
sysctl fs.inotify.max_user_watches=524288
#powyższe dwie linie raczej nie są potrzebne w puppim
setpci -v -d *:* latency_timer=b0
setpci -v -s 00:1b.0 latency_timer=ff #intel audio
jackd -R -P89 -dalsa -r44000 -p128 -n2 -D -Chw:0 -Phw:0 -Xseq&
qjackctl&
/etc/init.d/rtirq start
export WINE_RT=10; export WINE_SRV_RT=5
vsthost /some/where/VST.dll

Qjackctl używam ze względu na patchbay, który automatycznie łączy wcześniej zdefiniowane wejścia i wyjścia. Można więc e-drumsy podłączać i odłączać, albo np. zrobić suspend to ram i iść na siku 😉 gr

DTX-400 i Hydrogen/VST pod Linuksem.

Mistrzowie z Yamahy zrobili DTX-400 jak należy i zestaw działa out-of-the-box pod Linuksem. Nie trzeba żadnych dodatkowych sterowników, wszystko jest w kernelu (usb-audio, testowałem na 3.18.5-1-ARCH).
hydrogen_dtx

Hydrogen to nie Superior Drummer, ale pokombinuje z ustawieniami bo soft ma duże możliwości, startuje szybko i zajmuje mało miejsca (SD2 ma z 30GB sampli), a przykładowy Sonor Designer Kit zajmuje niecałe 6MB. Trzeba tylko trochę „uczłowieczyć” odgrywanie próbek.

Odkąd pierwszy raz zobaczyłem Hydrogena, miałem marzenie żeby pograć na elektronicznej perkusji pod Linuksem. Marzenie się spełniło ;). Nie wiem tylko czy poniżej nie przekombinowałem z opcjami „Swing” i „Humanize” na wyjściu (a może tylko ja tak gram ;P).

Obsługa MIDI pod Linuksem daje spore możliwości: można sobie ścieżki MIDI nagrywać w Ardour lub Rosegarden, a potem kombinować dowolnie z brzmieniem i instrumentami. Nic tak nie oddaje krzywo grającego „perkusisty”, jak sam krzywy perkusista ;). Na keyboardzie czy z klawiatury komputera nie da się tego zrobić.

Poeksperymentuje też na pewno z fsthost i wtyczkami VST. Skoro drumkit widziany jest jako urządzenie MIDI, będzie działać wszystko…

UPDATE: dssi-vst + jackd z opcją -Xseq działa bardzo ładnie :). Wtyczka VST SD2 działa po prostu idealnie, lepiej jak pod Windows. A o zaletach jackd pisać nie będę, bo to każdy użytkownik dobrze wie: jackd to perełka. Więcej o jackd i MIDI z Alsa tutaj, ale uruchomienie VST niemal nie wymaga konfiguracji:

1. Odpalamy jackd -R -dalsa -r44000 -p128 -n2 -D -Chw:0 -Phw:0 -Xseq (karta intela w laptopie daje rade). Można też uruchomić jackd bezpośrednio z qjackctl:
qjackctl2. Odpalamy vsthost ~/VST/Plugin.dll.
3. Łączymy wyjście z DTX Drums Midi z wejściem MIDI wtyczki (zakładka Alsa w Qjackctl->Connect, można też to zrobić na stałe w Patchbay).

Assembler 6502 na Linuksie.

No i w końcu mi się udało poeksperymentować. W tym celu kupiłem to małe 8-bitowe szare cudo techniki sprzed trzydziestu lat. Zacząłem czytać kurs assemblera 6502 z Tajemnic Atari (nr 3/91) i zastanawiałem się tylko, jakiego assemblera by tu (czytaj pod Linuksem)  użyć. Zarówno xasm jak i mads działają w wine, jednak każdorazowe uruchomienie wine trwa dość długo.

Okazuje się, że źródła mads kompilują się, co zresztą jest opisane w kodzie i dokumentacji, pod free pascal compilerem: fpc -Mdelphi -vh -O3 mads.pas. Tak utworzona binarka uruchamia się i generuje kod maszynowy Atari pod Linuksem błyskawicznie.

Po co? Bo zawsze chciałem to zrobić :). A swoją drogą artykuły w TA są super. Szkoda, że kiedyś byłem nieco za młody (czytaj głupi) żeby je dobrze zrozumieć.

Arch + Gnome3.

Instalacja po iPlusie CDMA chwilę trwała, ale muszę przyznać, że jestem bardzo pozytywnie zaskoczony. Skonfigurowałem wifi przez netcfg (nie chcę widzieć networkmanagera ani wicd już nigdy więcej), zainstalowałem Xorg, Gnome3 bez Gnome-extra… Poinstruowałem kernel żeby startował po cichu i mocno się zdziwiłem. System wstaje bardzo szybko, na tyle szybko, że używanie suspend to ram traci sens. Poza tym, sam Gnome 3 – moje odczucia od pierwszych testów live-cd się nie zmieniły – rewelacja. Prosto, intuicyjnie, a przede wszystkim szybko. A to dopiero wersja 3.0.2. Trochę nie rozumiem oburzenia co poniektórych użytkowników KDE i Gnome 2. Owszem, jest to coś nowego, ale środowisko jest na tyle proste, a nowe rozwiązania tak intuicyjne, że nie ma efektu WTF?!, jak w przypadku KDE4. Ale może to ze mną jest coś nie tak, bo w sumie w środowisku graficznym zwykle używałem skrótu Alt+F2 do uruchamiania terminala :).