Muzyka, projekty i narzędzia do przeglądarki
Autorskie utwory według daty powstania oraz własne remixy i covery.
Otwierająca dyskografię, tajemnicza kompozycja oparta na przestrzeni i niedopowiedzeniu, w której ciche odgłosy deszczu przeplatają się z oszczędną melodią. Jako pierwszy muzyczny eksperyment zachowuje swoją pierwotną, surową formę otwartego szkicu – bez wygładzonego masteringu i zamkniętej struktury. Wizualnym dopełnieniem utworu jest autorskie zdjęcie chmur burzowych uchwycone z pokładu samolotu.
Drugi utwór, powstały krótko po debiutanckim Unsolved. Choć technicznie wciąż zachowuje surowość pierwszych prób i prosty mastering, stanowi wyraźny krok naprzód. Brzmieniowo nawiązuje do klimatu Minecrafta, przełamując spokojne tło bardziej dynamicznym refrenem, a na okładkę trafił kadr z gry przedstawiający wioskę w deszczu.
Trzeci utwór powstały na fali tego samego przypływu weny co dwa pierwsze nagrania – spokojne, inspirowane stylem C418 brzmienie z delikatnym deszczem w tle łączy melancholię z nutą nadziei, a przed premierą będzie jeszcze dopracowywane. Obecna okładka to wyśniony kadr z Far Lands przerobiony na pikselową mapę, choć w planach jest jej potencjalne odświeżenie na zupełnie nowe ujęcie, wciąż utrzymane w motywie mapy.
Kompozycja zainspirowana klimatem podwodnej bazy w kopułach, zbudowanej ze znajomymi na serwerze Minecrafta. Pierwsze szkice powstały późną nocą pod wpływem chwili, a sam projekt przeszedł od tego czasu wiele wersji i zmian wtyczek. Jako jeden z pierwszych utworów stworzonych w 100% w FL Studio stanowi mocny przeskok jakościowy – obecnie wciąż jest w produkcji na etapie dopieszczania detali oraz finalnego miksu.
Wersja dramatyczna na fortepianie (Dramatic Piano Cover)
Dramatyczna, fortepianowa reinterpretacja piosenki „What Went Wrong” z trzeciego sezonu Helluva Boss. Ciężkie, nasycone emocjami akordy w niskim rejestrze, narastające napięcie i surowa ekspresja skupiona w całości na brzmieniu fortepianu.
Wersja orkiestralna epicka (Epic Orchestral Cover)
Monumentalna, orkiestralna aranżacja kultowego tematu z finału pierwszego Dark Souls (oryg. Motoi Sakuraba). Zamiast oszczędnego, samotnego fortepianu z oryginału – pełny rozmach symfoniczny z potężną sekcją smyczków, dętymi blaszanymi, chórem i uderzeniami perkusji budującymi epicki klimat.
Unsolved to otwierająca dyskografię, tajemnicza kompozycja oparta na przestrzeni i niedopowiedzeniu. Ciche odgłosy deszczu w tle przeplatają się tu z oszczędną melodią, tworząc gęsty, nieco deszczowy klimat. Wizualnym dopełnieniem utworu jest autorskie zdjęcie chmur burzowych uchwycone z pokładu samolotu.
Utwór narodził się z potrzeby przełożenia długo odkładanych pomysłów na pierwsze realne brzmienia. Jako pierwszy muzyczny eksperyment zachowuje swoją pierwotną, surową formę – bez wygładzonego masteringu i zamkniętej struktury. Zgodnie ze swoim tytułem („Nierozwiązany”), zostaje otwartym szkicem, od którego wszystko się zaczęło.
Far Lands to druga kompozycja w dorobku, wyraźnie skręcająca w stronę nostalgicznej estetyki inspirowanej ścieżką dźwiękową z Minecrafta. Utwór łączy wyciszoną, przestrzenną bazę z bardziej zdecydowanym, dynamicznym refrenem, który przełamuje spokojny bieg melodii i nadaje całości wyraźniejszy rytm. Klimat nagrania dopełnia okładka – kadr z gry przedstawiający skąpaną w deszczu wioskę.
Utwór powstał niedługo po Unsolved, przez co wciąż zachowuje surowy charakter wczesnych nagrań i brak zaawansowanego szlifu w masteringu. Mimo niewielkiego odstępu czasu oraz zbliżonego zaplecza technicznego, Far Lands stanowi wyraźny krok naprzód względem debiutu – to znacznie bardziej spójna i dopracowana próba uchwycenia klimatu, który stał się głównym kierunkiem dla kolejnych projektów.
Nadchodzący utwór
Roboczy fragment – przed premierą utwór będzie jeszcze dopracowywany.
Unfinished Maps to spokojna, wyciszona kompozycja, która najpełniej zanurza się w estetyce inspirowanej twórczością C418 oraz klasycznym klimatem Minecrafta. Utwór balansuje na granicy lekkiego smutku i głębokiej nostalgii, przełamując je jednak subtelną nutą nadziei. W tle ponownie słychać bardzo cichy szum deszczu, który spaja przestrzeń i nadaje melodii intymny, refleksyjny charakter. Na obecnej okładce wykorzystano ten sam kadr deszczowej wioski co w Far Lands, przetworzony w estetykę mapy z gry – z charakterystyczną obwódką, dostosowaną paletą barw i niższą, pikselową rozdzielczością. W planach jest jednak potencjalne odświeżenie oprawy wizualnej na zupełnie nowe ujęcie, całkowicie niezależne od Far Lands, ale wciąż utrzymane w motywie mapy.
Kompozycja powstała w krótkim odstępie czasu po dwóch pierwszych nagraniach, stanowiąc część tego samego, intensywnego okresu twórczego i pierwszych muzycznych poszukiwań. Szczególną historię ma tutaj dotychczasowa grafika – pomysł na przekształcenie kadru z Far Lands w stylizowaną mapę pojawił się we śnie i został zrealizowany od razu po przebudzeniu. Sam projekt nie ma jeszcze zamkniętej formy: przed oficjalną premierą brzmienie utworu będzie jeszcze dopracowywane i szlifowane, a wraz z nim może pojawić się nowa wersja okładki.
Utwór w trakcie
W produkcji od
Roboczy fragment – utwór jest w produkcji i może jeszcze ulec zmianom.
Submerged to głęboko klimatyczna kompozycja przenosząca słuchacza pod powierzchnię wody – bezpośrednio do wnętrza podwodnej bazy zamkniętej w kopułach. Utwór oddaje unikalny, wyciszony nastrój głębin oraz kojące poczucie spokoju, jednocześnie wyróżniając się znacznie bogatszą przestrzenią, głębią i dojrzalszym brzmieniem na tle wcześniejszych publikacji.
Impulsem do stworzenia utworu była podwodna baza zbudowana w kopułach na wspólnym serwerze Minecrafta ze znajomymi. Panujący w niej klimat był na tyle wyjątkowy, że pewnej nocy zrodził się pomysł, by przełożyć tę atmosferę bezpośrednio na dźwięki – to właśnie wtedy powstały pierwsze szkice kompozycji. Od tamtej pory projekt przeszedł długą ewolucję, obejmującą wiele wersji, testowanie nowych wtyczek i przebudowę brzmień. Jako jeden z pierwszych utworów zrealizowanych w stu procentach w FL Studio, Submerged stanowi wyraźny przeskok jakościowy względem pierwszych nagrań. Utwór wciąż znajduje się w fazie produkcji, gdzie przechodzi dobór finalnego miksu oraz szlifowanie ostatnich detali.
Cover · Helluva Boss (Sezon 3)
· Wersja dramatyczna na fortepianie · Wersja robocza (niedokończona)
Wersja robocza – niedokończona: utwór jest jeszcze w trakcie prac i stanowi nieukończony szkic aranżacji fortepianowej.
Dramatyczna aranżacja fortepianowa piosenki „What Went Wrong” z trzeciego sezonu Helluva Boss. Cały ciężar utworu został przeniesiony na pojedynczy fortepian – głębokie, rezonujące akordy w dolnym rejestrze kontrastują z wyrazistą linią melodyczną, budując gęste, emocjonalne napięcie.
Udostępnione nagranie to wersja robocza i niedokończona. Szkic powstał jako próba uchwycenia dramatycznego charakteru oryginału w surowej, czysto fortepianowej formie i wciąż czeka na domknięcie wybranych partii, dopracowanie artykulacji oraz finalny miks.
Cover · Dark Souls
Wersja orkiestralna epicka (Epic Orchestral Cover)
Pełna aranżacja orkiestralna stworzona w 100% ręcznie w DAW (No AI).
Epicka, symfoniczna reinterpretacja motywu „Gwyn, Lord of Cinder” skomponowanego oryginalnie przez Motoiego Sakurabę na finał pierwszego Dark Souls. Podczas gdy oryginał zaskakiwał gracza wyciszonym, kameralnym fortepianem, ta wersja przekształca rozpoznawalny trzyczęściowy temat w monumentalne starcie z pełną orkiestrą.
Kompozycja otwiera się narastającym napięciem smyczków, do których stopniowo dołączają potężne dęte blaszane, chór oraz ciężka sekcja perkusyjna. Zachowując melancholijny rdzeń melodii z gry, aranżacja nadaje jej rozmach finałowej bitwy i gęstą, filmową przestrzeń.
Narzędzia działające w przeglądarce oraz dłuższe teksty o rzeczach, które buduję.
Artykuł · Czerwiec 2026
Zbudowałem model, który z jednego zdania tworzy kompletną stronę albo grę w jednym pliku HTML. Wytrenowałem go na własnym zbiorze 806 przykładów, na jednej karcie RTX 5060 Ti z 16 GB pamięci. Opisuję, jak to wyglądało i co po drodze poszło źle.
STARK-WEB 12B dostaje krótkie polecenie, na przykład Make an HTML snake game in 1 file, i zwraca gotową stronę lub grę: HTML, CSS i JavaScript w jednym pliku. Poniżej ten sam prompt wpisany do Gemini 3.5 Flash i do wczesnej wersji mojego modelu (v0.9). Gemini jest tu punktem odniesienia, bo na jego odpowiedziach uczyłem STARK-WEB.
Gemini napisał poprawną, ale prostą grę. Mój model sam dobrał neonowy motyw i dodał w kodzie wykrywanie ekranu dotykowego. To jeden prompt, więc traktuję to jako ilustrację, nie dowód. Pomiar jest niżej, w sekcji o wynikach.
Zacząłem od Gemma 4 4B, czyli modelu z 4 miliardami parametrów. Prostą stronę albo kalkulator pisał poprawnie, ale przy dłuższej logice w JavaScripcie, na przykład w grze 3D albo systemie okien w przeglądarce, zaczynał się gubić. Brakowało mu pojemności.
W tym samym czasie pojawiła się Gemma 4 12B, trzy razy większa, więc na nią przeszedłem. Rozwiązało to problem pojemności, ale wymusiło też powiększenie zbioru treningowego: z około miliona tokenów do 12,3 miliona.
Zbiór nazywa się STARK-WEB v1.3. W przeliczeniu to około 39,3 mln znaków: przeciętny przykład ma około 48 800 znaków, najdłuższy około 135 500. Mniej więcej 90% przykładów jest po angielsku, reszta po polsku.
Kod do zbioru generował Gemini 3.5 Flash, a mój model uczył się go odtwarzać (to się nazywa destylacja wiedzy). Każde polecenie przechodziło przez Gemini co najmniej dwa razy: w drugim przebiegu model dostawał swój pierwszy wynik i prośbę o znalezienie błędów oraz poprawienie struktury i wyglądu. Każdy gotowy plik odpaliłem sam w przeglądarce i sprawdziłem wygląd, animacje i działanie, zanim trafił do zbioru.
Do każdego przykładu potrzebowałem jeszcze zapisu rozumowania (o nim niżej). Pierwszą wersję tych zapisów generował skrypt przez API Google. Gdy odblokowałem dodatkowe środki w Google Cloud, wygenerowałem je od nowa dla całego zbioru mocniejszym wariantem, Gemini 3.5 Flash High.
Pełne dostrajanie modelu 12B nie zmieściłoby się na domowej karcie, więc użyłem LoRA. Wagi modelu bazowego zostają zamrożone, a uczą się tylko małe macierze dodane do wybranych warstw. Dla macierzy 4096 × 4096 daje to około 524 tys. trenowanych parametrów (rząd r = 64) zamiast ponad 16 mln. Adapter obejmuje siedem typów projekcji: q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj i down_proj.
Kontekst treningowy ma 43 000 tokenów, co jak na 16 GB jest dużo. Mieszczę go dzięki dwóm rzeczom. Gradient checkpointing przelicza aktywacje w locie zamiast trzymać je w pamięci, co daje około 60% oszczędności VRAM. Paged AdamW 8-bit przenosi nieaktywne stany optymalizatora do zwykłego RAM-u.
Model nie zaczyna od kodu. Najpierw pisze plan w osobnym kanale (<|channel>thought), w dziewięciu ustalonych krokach, od zrozumienia celu po końcową kontrolę. Dopiero po znaczniku [END_OF_THINKING] generuje właściwy plik HTML.
Sztywny schemat wprowadziłem, bo przy swobodnym rozumowaniu model wpadał w pętle: planował w kółko i nigdy nie dochodził do kodu. Znacznik końca działa jak twardy warunek stopu. Skutek uboczny był taki, że zwykłe programy do czatu wyświetlały plan razem z kodem, więc napisałem własny interfejs. Jego parser strumieniowy na bieżąco kieruje fragmenty planu do zwijanego panelu, a na ekranie zostaje sam kod.
Przykładowy plan dla polecenia o Snake’u:
<|channel>thought
000) i kontrolki mobilne.localStorage.<canvas>, pasek akcji i przyciski kierunkowe.#07090e, neonowy cyjan i zieleń z poświatą box-shadow, układ we Flexboksie, przyciski kierunkowe ukryte na desktopie przez media query.shadowBlur na Canvasie.e.preventDefault()) i skalowanie planszy na małych ekranach.--- [END_OF_THINKING] <channel|>
<!DOCTYPE html> …
Pierwsza publiczna wersja testowa była trenowana z dużą skalą LoRA (alpha 128 przy r = 64) i bez dropoutu. Chciałem, żeby model możliwie wiernie odtwarzał kod ze zbioru. Odtwarzał go aż za wiernie: style CSS wychodziły świetnie, ale przy nowych poleceniach w JavaScripcie pojawiały się literówki, martwe przyciski i pusty ekran. W moim benchmarku dostała 65,0 pkt, czyli mniej niż model bazowy bez żadnego dostrajania (66,5).
Wersja v1.1 miała odwrotny kłopot: przy tempie uczenia 2e-5 model zapominał logikę JavaScriptu, choć HTML i CSS były w porządku. Poprawiła to dopiero v1.2: obniżyłem alpha do 64 i tempo uczenia do 1e-5, a do tego dodałem lora_dropout = 0.05 oraz weight_decay = 0.01. W v1.3 dołożyłem jeszcze 77 trudnych zadań algorytmicznych: CRUD, asynchroniczność, interaktywne tabele i gry planszowe.
Po treningu adapter trzeba scalić z modelem. Za pierwszym razem scaliłem go z modelem skompresowanym do 4 bitów (NF4) i dostałem model, który zachowywał się, jakby niczego się nie nauczył. Poprawki z adaptera były mniejsze niż krok siatki kwantyzacji i zaokrągliły się do zera. To zjawisko bywa nazywane „vanishing LoRA”.
Scalanie w pełnej precyzji BFloat16 potrzebuje ponad 24 GB, a karta ma 16, więc zrobiłem je na procesorze i w RAM-ie (device_map = cpu). Poprawność sprawdziłem, porównując normę L2 wag (torch.norm()) przed scaleniem i po nim.
Osobny problem pojawił się przy eksporcie do 4-bitowego formatu GGUF. Zwykła kwantyzacja po treningu zacierała znaczniki kończące myślenie i model mylił [END_OF_THINKING]. Pomógł trening uwzględniający kwantyzację (QAT): za bazę wziąłem google/gemma-4-12B-it-qat-q4_0-unquantized, który symuluje szum kwantyzacji już w trakcie uczenia. Przy eksporcie musiałem jeszcze załatać konwerter w llama.cpp, bo nie znał klasy Gemma4UnifiedForConditionalGeneration.
Na końcu każdej epoki train_loss, który wcześniej trzymał się około 0,2, skakał do 2,3. Wyglądało to na zniszczenie modelu. Przyczyną był błąd w bibliotece Hugging Face Transformers przy akumulacji gradientów: w ostatniej, niepełnej paczce danych dzielnik używany w logach miał złą skalę. Wagi były liczone poprawnie, nieprawidłowy był tylko zapis w logach.
Do porównywania wersji zbudowałem własny benchmark. Zestaw promptów spoza zbioru treningowego, od prostych komponentów interfejsu po rozbudowane aplikacje z logiką w JavaScripcie, ocenia zewnętrzny model Gemini w skali 0–100. Liczą się cztery kryteria: poprawność HTML i CSS, działanie logiki JavaScript, estetyka interfejsu i zgodność z poleceniem. Wynik to średnia ważona. Ocenia model, nie człowiek, więc służy mi głównie do porównywania wersji między sobą.
Wersja v1.3 wypada o 6,0% lepiej niż model bazowy. Pionowa kreska na wykresie oznacza wynik modelu bazowego.
STARK-WEB 12B zostanie udostępniony za darmo na Hugging Face, na licencji Apache 2.0, która pozwala na użytek prywatny, naukowy i komercyjny.
Następny krok to ta sama metoda na większym modelu, Gemma 4 26B, trenowanym w chmurze na kartach NVIDIA A100. Zakładam, że większa pojemność pozwoli usunąć drobne błędy w złożonej logice, na przykład w obsłudze okien w systemach typu Browser OS.
Wgrywasz eksport danych z Facebooka (plik JSON), a skrypt liczy wszystko lokalnie, w przeglądarce. Zobaczysz, kto pisał z tobą najwięcej w minionym roku. Narzędzie jest darmowe.
Czat jest prywatny: działa tylko na zaufanych urządzeniach i dla osób, którym dałem dostęp.
Napisz do mnie, kim jesteś. Jeśli cię znam i lubię, może dam ci dostęp.
Pytanie o narzędzie, pomysł albo prośba o dostęp do czatu – napisz.
Situus · situus.plMuzyka i narzędzia