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

DTX-400 i Hydrogen/VST pod Linuksem.

Glhack, Vulture i nethack-nao.

Chyba za długo siedziałem pod kamieniem. Właśnie znalazłem w repo glhack. Że ja na to wcześniej nie wpadłem… Lepiej późno niż wcale. Idąc za ciosem, skompilowałem jeszcze Vulture:

I szczerze mówiąc, wszystkie trzy wersje: konsolowa, 2D GLHack i Vulture mają coś w sobie (nethacka ;) tak wiem). Glhack podoba mi się chyba najbardziej: ma ładne tilesy i wygodną obsługę z klawiatury jak w Uniksach (w Vulture yuhjklbn są przekręcone w rzucie izometrycznym, trzeba się przyzwyczaić ;)).

Update: aby cieszyć się ładną czcionką w stylu IBMGraphics na Linuksie potrzebne będzie nethack-nao z obsługą utf-8 i ncurses stąd i ustawienie w ~/.nethackrc:

OPTIONS=cursesgraphics
OPTIONS=windowtype:curses
OPTIONS=windowborders:3
OPTIONS=popup_dialog
OPTIONS=align_message:bottom
OPTIONS=align_status:right
OPTIONS=guicolor

Glhack, Vulture i nethack-nao.

Lua + gemlib.

Jak się spodziewałem utworzenie własnej biblioteki w C dla Lua jest bardzo proste. Póki co moja „biblioteka” to ambitna funkcja v_pline() z gemlib rysująca polilinię, z dowolnej (ile się zmieści) ilości danych przekazywanych przez stos Lua. Nauczka nr 1: nie używać malloc() z libstd PureC (wywala się), tylko Malloc() z tos.h.
gem_v_plineluagem1

 

 

 

 

Cała filozofia, to utworzenie modułu np. gemlib.c, w którym będą zdefiniowane funkcje z biblioteki w C, w tym przykładzie jest aż jedna: vpline() o definicji jak niżej:

static int vpline(lua_State *L) {
/* narysuj polilinię */
}

potem:


static const luaL_Reg gemlib[] = {
{"v_pline", vpline},
{NULL, NULL}};

LUAMOD_API int luaopen_gemlib (lua_State *L) {
luaL_newlib(L, gemlib);
return 1;
}

i dodanie: LUAMOD_API int (luaopen_gemlib) (lua_State *L); np do lualib.h oraz
{„gem”, luaopen_gemlib} do loadedlibs[] w linit.c, żeby interpreter go zarejestrował, bo moduł jest statycznie linkowany więc nie trzeba go ładować.

Wybiorę co najciekawsze funkcje GEM/VDI/AES i zobaczymy co z tego wyjdzie. Proceduralne tworzenie grafiki ze skryptu Lua może być całkiem zabawne ;).

Mam sporo przemyśleń i wątpliwości czy obsługa GUI z Lua jest do zrobienia, ale w tym cała frajda ;).

Lua + gemlib.

Gemlib.

Szkoda, że tak niewiele dobrej dokumentacji się zachowało (albo ja nie wiem gdzie szukać). Znalazłem GEM’s Programmers Reference z Abacus Software i Professional GEM, i tu jest sporo fajnych artykułów. I jeszcze to na początek i ten wątek na Atari Forum jest bardzo ciekawy. Ok, znalazłem jeszcze to. Chyba wystarczy ;).gemlib
No i API Gemlib jest chyba dość spójne, bo dla prostych przykładów można bez problemów linkować z GEM.LIB (w wersji 0.43.6) zamiast PCGEMLIB.LIB z PURE C.

gemlib_st

Zaczynam powoli zmieniać zdanie na temat ST…

Gemlib.

Lua-5.3.0 dla Atari ST (PureC).

No i wyszła wersja Lua-5.3.0. Binarka dla Atari ST tutaj. A gdyby ktoś chciał poeksperymentować wrzucam mój kompletny katalog PURE_C, wraz ze katalogiem lua530 i paroma koniecznymi nagłówkami. A w katalogu src znajduje się plik projektu lua.prj (i lamerski patch ze zmianami względem oryginalnych źródeł, już zaaplikowany). purec_lua530Jak widać powyżej, działa w Aranym. Aby skompilować, ładujemy plik lua.prj w menu Project -> Select, a potem Project -> Make all. W pliku lua.prj trzeba ustawić właściwy katalog w którym utworzona zostanie binarka (u mnie g:\build\lua\lua53.prg). lua530

Lua-5.3.0 dla Atari ST (PureC).

Partycjonowanie karty Atari Side.

Zgodnie z obietnicami, zamieszczam opis partycjonowania karty CF dla Atari Side: FAT32 posłuży do ładowania gier przez Side Loader, a FAT16 do wymiany danych z PC.

Potrzebne będa:

  • Interfejs SIO2PC i AspeQt (lub SIO2SD)
  • APT_Tools_SDFS.atr ze strony FJC.
  • W powyższym atr jest FATFS.SYS i stamtąd go skopiujemy, można go też wyciągnąć  z toolkit_rev_c.atr ze strony SDX.

Postępując jak na filmie:

Partycjonujemy kartę FDISK-iem na Atari. Moja karta ma 128MB (naprawdę mi wystarcza). W pierwszej kolejności inicjalizujemy kartę i dodajemy APT i partycję dla SDX. Jeśli chcemy skasować zawartość karty i utworzyć partycje od nowa wybieramy z menu Disk -> Initialize, jeśli chcemy dodać partycje czy dowiązanie dajemy Disk -> Open. Jeśli karta jest pusta, FDISK zapyta czy ją zainicjalizować.

Nie tworzymy FAT16/32 w FDISKU atarowym (trzeba wybrać odpowiednią opcję). Zrobimy to w następnym kroku w FDISKU pod Linuksem.

Ważne: Partycja FAT16 o rozmiarze mniejszym niż 32MB, większych sterownik fatfs.sys v0.7 nie obsługuje.

Formatujemy partycję SDX i FAT. FAT32 musi mieć powyżej 32MB, żeby mkfs.fat nie krzyczał, że ma za mało klastrów na utworzenie systemu plików. Dla starego Side Loadera dobrze aby FAT32 był przed FAT16, inaczej loader znajdzie FAT16 i nie będzie wiedział co z nim zrobić.

Dodajemy FAT16 jako „External” w atarowym FDISKU i przypisujemy mu literę.

Odpalamy FATFS.SYS i przechodzimy na D2:. Budowanie indeksu plików (oczekiwanie po DIR) może chwile potrwać, ale powinniśmy się cieszyć zawartością partycji FAT16 pod SDX (read only). FAT32 służy do odpalania gier z loadera.

Kopiowanie danych z PC do SDX jest dzięki temu dużo szybsze i wygodniejsze.

.

Partycjonowanie karty Atari Side.