atarionline.pl Mono Double CMC - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthormono
    • CommentTime5 Oct 2020
     
    Matosimi zrobił nową wersję CMC. Analogicznie, jak w przypadku Stereo Double CMC (by Datri) odgrywa instrumenty 2x na ramkę, ale tym razem utwór jest ciągle odgrywany na jednym POKEY-u.
    ->link<-
    • 2: CommentAuthor0xF
    • CommentTime6 Oct 2020
     
    Czym to się różni od CMC DoublePlay Grega?
    • 3: CommentAuthormono
    • CommentTime6 Oct 2020
     
    Grega gra na DLI pełny player. MDCMC analogicznie jak SDCMC gra dwa razy instrumenty po sobie, bez żadnego interwału czasowego.
    • 4: CommentAuthorxxl
    • CommentTime6 Oct 2020
     
    a nie lepiej by bylo jakby drugie wywolanie instrumentow zapisywalo wartosci do bufora ktore na dli kopiuje sie do pokeya?

    zrobilem takiego moda do rmt i calkiem ok to dziala.
    • 5: CommentAuthorMq
    • CommentTime6 Oct 2020
     
    Ja nie w kwestii technicznej, ale chciałem zauważyć, że bardzo fajna ta muzyczka jest:-)
    • 6: CommentAuthor0xF
    • CommentTime6 Oct 2020
     
    Czyli:

    1. W CMC DP ustawiamy 2x większą wartość tempa, niż w MDCMC. Co daje nam większą precyzję regulacji tempa.

    2. CMC DP gra instrumenty równo co pół ramki, a w MDCMC "słupki" instrumentów trwają na przemian 1/4 i 3/4 ramki (zakładając 72 linie wg informacji z aage).
    • 7: CommentAuthormono
    • CommentTime6 Oct 2020 zmieniony
     
    Tak. Byłem zaskoczony tym jak Datri to zrobił (a teraz Matosimi), ale daje to nienajgorsze efekty.
    • 8: CommentAuthorxxl
    • CommentTime6 Oct 2020
     
    skoro jest mod na stereo to czy jest szansa na edytor w wersji quad?
    • 9: CommentAuthor0xF
    • CommentTime6 Oct 2020
     
    Z tak "szybkim" playerem nie wiem, czy Atari wyrobi. Chyba, że Pinokia. ;)
    • 10: CommentAuthorxxl
    • CommentTime6 Oct 2020
     
    a plajer Richarda Muncha zajmuje ... maksymalnie 4 linie ;-)
    • 11: CommentAuthortebe
    • CommentTime6 Oct 2020
     
    LZSS DMSC Player, użył go ostatnio Rensoup ->link<-
    • 12: CommentAuthormarok
    • CommentTime6 Oct 2020
     
    W wersji MadTeam'u była adnotacja, że wartość tempa musi być wielokrotnością wywołań playera. Zasadniczo są to zgodne ze sobą wersje (Grega i Madteam'u), a ja nie zastanawiałem się głębiej skąd i dlaczego takie zastrzeżenie. Próbuję teraz tej sztuczki (zmiana tempa na wart. nieparzystą w module .DMC) i wszystko wygląda w porządku.

    Może to był wymóg pod kompozera? Chodziło o to, żeby zawsze pierwsze wywołanie (potencjalnie najdłuższe, bo obsługujące jeszcze progresję linii song) występowało w najdogodniejszym momencie ramki, aby wszystko się dobrze z ekranem synchronizowało?

    Definicja obwiedni pewnie może być mniej lub bardziej zorientowana na różnicę w długości wybrzmiewania dźwięku.

    Tak poza wszystkim, nigdzie chyba nie jest napisane (i pokazane na przykładzie zastosowania), że wersja Grega była tworzona z myślą (tym bardziej wyłącznie) o równych wywołaniach playera w ramce. To założenie wydaje mi się dość wątpliwe, zważywszy że sama faza kompozycji (i odsłuchiwania) odbywa się w wywołaniach jedno po drugim w ramce.

    Przykład różnicy w brzmieniu mogę wskazać (załączam jeden tylko moduł .DMC). Jest w asma sap wersja tego modułu z odgrywaczką cmc (playerem) przerobioną w stylu MDCMC i jest ten moduł. Teraz wystarczy oba przesłuchać pod (W)Asap i przekonać się o ewentualnych różnicach we wrażeniu. Moim zdaniem nie ma przewagi odgrywania muzyki równo nad tą odgrywaną po kolei w ramce. Jeśli moduł był komponowany świadomie pod granie z wywołaniami po kolei w ramce, to będzie on prawdopodobnie mógł brzmieć nawet lepiej właśnie z takim wywoływaniem.

    Może 72 linie to są maksima? Nie wiem jak to jest sprawdzane (chętnie bym się dowiedział). Ale biorąc pod uwagę, że śmigają jeszcze wersje do CMS na bardzo podobnym kodzie (z dwukrotnie takim obciążeniem), wydaje się to trochę zawyżone.

    Z moich ustaleń wynika, że można przyspieszyć player do CMC, trzymając się tych samych założeń i ograniczeń, które są od początku, by okazał się sprawniejszy od TMC, RMT i MPT (poza playerem Foxa). To tak na marginesie, by się tak łatwo nie poddawać, jeśli chodzi o ten format.
    • 13: CommentAuthorpoison
    • CommentTime6 Oct 2020
     
    hmmm, Prodigy, nice music :)
    • 14: CommentAuthorxxl
    • CommentTime6 Oct 2020
     
    czasy innch plajerow:

    • 15: CommentAuthormarok
    • CommentTime7 Oct 2020
     
    Z tym tempem dostosowanym do liczby wywołań, sprawa w sumie jest prosta (jak sobie uświadomiłem, chociaż mogłem jeszcze to sprawdzić). Chodzi tylko o to, żeby tempo było miarowe przy sposobie wywołań playera w ramce jedno po drugim. W przeciwnym wypadku mamy (w najlepszym razie) do czynienia z tempem typu swing (jak objawił mi nazwę tego rodzaju temp swego czasu Mono - bo publicznie o to zapytałem).

    Z tego wyciągam dalszy wniosek. Otóż, dowodem pośrednim choć nie bezwzględnym tego, że w formacie DMC powstawały utworki przeznaczone do grania także równo w ramce (co 156 linii rasta) powinna być obecność modułów z tempem nieparzystym. Jeśli zaś nie znajdzie się taki przypadek ani razu, może to pośrednio wskazywać na fakt, że format ten od początku był przewidywany raczej wyłącznie do takiego użytku, jaki jest zastosowany także w MDCMC w aspekcie sposobu wywołań playera (jedno po drugim).
    Jeśli zaś tak na to spojrzymy, to pomijanie części wstępnej procedury (od progresji linii song) w co drugim przerwaniu i tym samym mniejsza o połowę nominalna wartość tempa, jest rozwiązaniem lepszym niż odwrotnie (w ujęciu ogólnym procka szybciej działa, dając identyczny efekt).
    • 16: CommentAuthormarok
    • CommentTime9 Oct 2020
     
    Taki programik, który mierzy i dość dokładnie przedstawia czas przeznaczony w danej ramce na wykonywanywanie procedury odgrywającej. Czym większe obciążenie (dłuższy czas wykonywania) tym dalej od początku strony naliczają się do przodu liczniki. Są to osobne liczniki dla wartości VBLANK zwracanej po powrocie. Starałem się zróżnicować sytuację, kiedy jest to wartość linii w istocie parzysta a kiedy nieparzysta (najmłodszy bit nie jest widoczny, ale można go stwierdzić).
    Programik odgrywa muzyczkę w dość krótkich interwałach, a potem robi sobie krótką przerwę (więc się wtedy nie wiesza). Chodzi o możliwość prostego zarchiwizowania danych z ekranu (na emulatorze), z możliwością późniejszego porównania do innych wyników, z możliwością później też przeliczenia tego nawet na wartości liczbowe (jak ktoś jest w stanie), gdyby było potrzeba, bo tutaj uprościłem sprawę (dla siebie) w wizualizacji tych wartości.

    W przypadku tej pierwszej prezentacji jest to podpięte pod dobry player. Jestem ciekaw, ale umówmy się, bez zaglądania do kodu pod emulaterem, kto będzie skłonny zgodzić się z tym, że jest to bardzo szybki player, a kto uważa trochę inaczej - na postawie tylko tego, co widzi na ekranie (a widać całkiem już sporo).

    To może tyle; napisane dzisiaj.
    • 17: CommentAuthormarok
    • CommentTime10 Oct 2020
     
    Porównanie playerów CMC, MPT i DLT na jednej kompozycji (powinno być dzięki temu w miarę obiektywne). Konwersja do MPT jest oczywiście Caspera - nic w niej nie zmieniałem, choć podjąłem próbę (nieudaną) podmiany zawartości tablicy częstotliwości na bliższe oryginałowi. Pewnie nie wszystko "skumałem", więc nie dało się tego zrobić. Odnośnie konwersji muzyki na format DLT, było to możliwe, zupełnie niespodziewanie, po udostępnieniu przez Mikera (wczoraj lub przedwczoraj) tego konwertera, którego nie znałem. Fajnie działa (ładnie się komunikuje), nie wiem wszak, czemu nie zawsze wszystko udaje się (względnie) idealnie (bo z konwersjami ciężko o idealne wyniki). Podmieniłem nieco tablice (tam gdzie wszystko wskazuje że trzeba), ale wciąż brzmi to daleko od ideału. Także dziwnie skonwertowały się songi, bo nie ma między nimi przerwy, ale jedna idzie po drugiej i nie ma już pętli powrotnej. Może przeładowanie paternów i konwerter sobie nie do końca mógł dać radę. Od strony brzmienia, jest to dalekie od ideału, ale porównujemy wydajność playera, więc to nie jest aż tak bardzo istotne dla tego celu.
    • 18:
       
      CommentAuthormiker
    • CommentTime10 Oct 2020
     
    DELTA nie wspiera 16-biowego basu. Tu chodziło o jak najszybszy player i niektóre ficzery zostały zapewne celowo pominięte. Także ten kawałek nie zagra dobrze.
    • 19: CommentAuthormarok
    • CommentTime12 Oct 2020
     
    Dzięki Miker za cenne wskazanie i to uświadomienie. (Może nawet kiedyś o tym już wiedziałem, coś mi się teraz tak zaczyna kojarzyć - ale niestety nie spamiętałem do teraz.)

    Rozumiem też, że to jest jedyne oczywiste ograniczenie tego playera, a wszystko inne, co oferuje 'prosty' cmc, jest w nim już w pełni dostępne (i podlegające konwersji). Jeśli coś do tego można dodać, to ewenatualnie prosiłbym o dopisanie tego do listy takich ograniczeń.
    • 20: CommentAuthorxxl
    • CommentTime20 Oct 2020
     
    z takim pewnym niedowierzaniem.... ale wkoncu sprobowalem tego MDCMC i jestem bardzo pozytywnie zaskoczony !!! moje ucho jest zadowolone :-)
    • 21: CommentAuthorxxl
    • CommentTime21 Oct 2020
     
    ->link<-

    czy sa alternatywne procedury playera? te na pierwszy rzut oka nie sa optymalizowane ani pod wzgledem szybkosci ani rozmiaru...
    • 22: CommentAuthormarok
    • CommentTime21 Oct 2020
     
    Myślę, że są.

    Z tym, że zawsze można w tych kategoriach zrobić coś lepiej, więc to wszystko jest trochę względne (i płynne, jeśli jest na bieżąco rozwijane chociażby).

    Z tego, co mi wiadomo, Sun, z którym masz chyba kontakt, może Ci odstąpić kilka różnych wersji (ma, niniejszym, prawo to uczynić, ponieważ sam mu je podesłałem).
    • 23: CommentAuthormarok
    • CommentTime2 Nov 2020 zmieniony
     
    Przedkładam 3 wersje muzyczek z doklejonymi 2 (bardzo nieznacznie) różniącymi się wersjami playera do cmc/cmx. To puszczone pod tą samą "nakładką" jeszcze do obrazowania obciążenia pracy playerem procesora, co wcześniej (żeby nie było, powiedzmy, rozczarowań). Każda z muzyczek gra z inną liczbą wywołań w ramce, choć oczywiście dzieją się one pod rząd (co w cmc jest już raczej pewną tradycją).
    Te muzyczki to "Delirium Tremens", "P6MONdbl" i "Trans", podane w tej kolejności, zgodnie z rosnącą liczbą wywołań (w jednej ramce), przy czym dwie ostatnie są na jednej wersji playera, a pierwsza na osobnym (bez obsługi multi wywołań w ramce).

    Player, jako taki, wydaje się już całkiem szybki (ponownie to piszę, bo ponownie osiągnięty został postęp). I to głównie w ostatnim tygodniu udało mi się coś w nim (istotniejszego pod tym względem) pozmieniać jeszcze, od ostatniej wersji, którą tu wcześniej zamieszczałem. Dlatego dokładnie nie wiem, na tą chwilę, na ile tą werję uda się za jakiś czas może nie pozmieniać więcej, chociaż pewnie zmierzam już do finału tych prac i granicy swojej tego rodzaju percepcji. Wymaga ona bowiem od nas pewnej spostrzegawczości, uwagi, licznych rozważań czy porównań różnych alternatywnych rozwiązań. Zasadniczo nie każdy pewnie się w tym odnajduje (kwestia natury czy temperamentu), bo nie każdy lubi się zajmować czasem nadmiernie detalami. Mnie to całkiem zajmuje (chociaż czasem każdy może odczuć, więc i mnie się to zdarza, czy przesyt, czy pewne już znużenie, wypatrując raczej zwieńczenia i niechętnie już myśląc o przesłankach dla racjonalności dalszych jeszcze takich działań).

    "Wracając na ziemię" (po tych rozważaniach ogólnych) napiszę jeszcze o planach i o niektórych szczegółach związanych z playerem do cmc/cmx.

    Planuję raczej takie wersje playera:
    - player mono, w pełni zastępowalny i imitujący wręcz idealnie (choć nie idealnie, ale tą jedyną różnicę, o której mi wiadomo, poczytuję mu za wartość dodaną, jest ona świadoma) działaniem zwykły player do cmc, z obsługą tylko jeszcze takiej wersji modułu cmx, która to ogranicza się do podstawowych zmian w formacie danych paternu (chodzi tu tylko o obsługę dodatkowo kodów $C0-$FE, które odpowiadają parom $40-$7E + $80) i jeśli o niczym nie zapomniałem, to wszystko na jego temat (prosta podmiana playera "ze starego" powinna zadziałać więć bez najmniejszych nawet niespodzianek, wyrażających się koniecznością jakiś dostosowań w kodzie obsługującym player),

    - player mono z funkcją multi wywołań w ramce, taki odpowiednik MDCMC i pokrewnych (w. Grega, Madteam'u). Tutaj sprawa wygląda tak, że pewnie wszystko zostanie po staremu (jeszcze to sobie rozważam), czyli będzie i część od basica i pozostawione dodatkowe zabezpieczenia (zepewniające jego uniwersalność), takie jak sposobność bezproblemowego (niezależnie od specyficznych "kondycji") używania go poza wywołaniem z przerwania (CLD w kodzie głównym playera) i wszystko inne, co stanowi o pewnej specyfice playera cmc (począwszy od zapisywania i odtwarzania za każdym razem stanu 4 bajtów ze strony zerowej, które używa player, przed i po wywołaniu - jest to spore obciążenie, od którego można by w innych wersjach na pewno odejść). Osobna wersja i nie można nią zastąpić tej pierwszej, ponieważ chociaż może obsłużyć moduł z jednym wywołaniem na ramkę, to jednak ze specyfiki kodu, dość znacząco się w tym względzie jego wydajność pogarsza. Więc doszedłem do mocnego przekonania, że to jednak musi być osobna wersja playera pod obsługę wyłącznie dla mono (nie multi) wywołań. (Dopisuję jeszcze, że odmiennie niż w CMS, zdecydowałbym się jednak na inny kod do określania liczby wywołań w ramce: zamiast $A7 przeszedłbym na wygodniejsze do wykorzystania $7F.)

    No więc te dwie wersje playera to są zasadniczo te dwie, które są przy tym modułach, które dzisiaj wykorzystałem do demonstracji możliwości tych playerów.

    Jakie inne wersje playera mogą jeszcze wchodzić w grę?

    Za dużo nie powinienem dla dobra sprawy mówić (bo to może zaszkodzić mojej zdolności do koncentracji na przyszłych pracach), więc tylko z grubsza.

    Na pewno wersja multi wywołań w ramce na multi pokeye. Piszę od razu na multi pokeye, bo z moich prób wynika, że można i chyba łatwiej tak będzie, sporządzić efektywnie (bo efektywniejszą) taką wersję, która będzie miała w prosty sposób możliwość zarządzać kilkoma pokeyami i to specjalnie nie uczyni różnicy w kodzie (iloma by miała konkretnie), który miałby to obsłużyć. Zasadza się to na koncepcji "po kolejnych" traktowań obsługi każdego z pokeyów osobno (w warstwie zasadczniczego przetwarzania danych na wartości końcowe do rejestrów). Skoro więc idą one kolejno po sobie (te operacje obsługi każdego pokeya), to może iść ich 'dowolna' ilość, co w praktyce oznacza tylko, że poza obsługą modułu dla stereo, będzie można obsłużyć pod quad (i to pomiędzy) bez trudu. Ta wersja będzie już z automatu nie miała pozostawionej części kodu do obsługi basica, co zbiega się z pewną zauważalną (i naturalną) tendencją ograniczania tej możliwości w wersjach od Datriego playera dla modułów CMS (cmc stereo). Dodatkowo trzeba będzie chyba się zdecydować na porzucenie tej specyfiki playera cmc, o której pisałem wcześniej, ponieważ nie jest ona niezbędna "a swoje waży" i tyleż kosztuje (wypowiadam się - w cyklach).

    Oprócz tego, na pewno jeszcze jedna wersja na mono pokey z dodatkowymi możliwościami, których zakres i lista w tej chwili nie są ustalone. Z grubsza może to być wersja, która będzie nieco odchodzić już od standardu i pełnej imitacji playera cmc (nie wszystkie zapisy do rejestrów pokeya nawet słychać, a są one imitowane w wersjach dotychczasowych). Format modułu będzie poważniej rozbudowany. Być może powstaną z tego osobne wersje, gdyby udało się dotknąć jakoś problematyki dźwięków wykorzystujących poza syntezą także (krótkie) sample. Byłoby fajnie gdyby to ostatnie (na razie to tylko wyłącznie koncepcja) dało się sterować na przerwaniach irq (gdyby się tak nie dawało, to inaczej nie ma to dla mnie sensu).

    Co do formatu CMX i jego ogólnego rozwoju to, rzecz ma się mniej więcej tak.
    O zmianach w formacie danych paternów w odniesieniu do kodów $C0-$FE już napisałem.
    Kody $1A-$33 to kolejne instrumenty. Kody $34-$3f jest pomysł, żeby je wykorzystać na identyfikację instrumentów dźwięków samplowanych.

    Co do struktury modułu.
    Pierwsza para stron od początku modułu w cmc definiuje nam adresy paternów i instrumenty. Druga taka para (a nawet trzecia i czwarta) może definować nam dalsze paterny i intrumenty (co do trzeciej i czwartej pary to sprawa ma się z kolei tak: definiować one mogą numery paternów $80-$FE i osobne dla tych paternów instrumenty; wtedy odwołania do instrumentów w tych wyższych paternach miałyby odnosienie do tego drugiego "banku intrumentów"; jeśli zaś chodzi o to, że rozkazy specjalne z linii song częściowo pokrywają się z tymi samymi wartościami i numerami paternów, też przecież tam umieszczanymi, to sprawa sprowadza się do ograniczenia możliwości umieszczania tych 7+1 wartości w pierwszym songu, gdy określamy patern).

    Dochodzi bowiem kod $7F do definicji liczny wywołań w playerze (i może czegoś więcej, ale na razie nie mam konkretnej propozycji, jak wykorzystań przestrzeń jaką daje pełny bajt, a w teorii są przecież jeszcze w odwodzie dwa kolejne z dwóch kolejnych pozycji song, ale to już mniej kusząca perspektywa).

    Później, na kolejnej stronie (format cmc jest ciekawie pomyślany bo osadzony na stronach właśnie) w formacie cmc mamy definicję linii song. Mieści się tych linii $55, bo po sobie idą definicje dla każdej ze ścieżek song, których są 3. Jeśli mamy moduł CMS to, idzie nam definicja dla kolejnego pokeya tego samego (ścieżek). Więc jeśli mielibyśmy to powtórzyć za CMS w CMX (nie przesądzam tego, ale raczej powinno to się tak zrobić, także dla zachowania tej ciągłości i potencjalnej kompatybilności z modułami CMS playera od CMX), to i dla 3 i 4 pokeya definicje ścieżek song iść powinny kolejno. W wersji mono jest to jednak rzecz pomijalna (choć pamiętajmy o tym tak w ogóle).

    Więc, wracając zupełnie do wersji mono, po tej definicji scieżek song, pierwszych ich $55 linii, możliwa jest definicja dla kolejnych linii song i jeszcze kolejnych, czyli łącznie $FF. Oczywiście nie zawsze (albo prawie nigdy) tyle nie będzie aż potrzebne w zastosowaniu, ale opcjonalnie moduł może zawierać definicję aż tylu linii song i player może być przygotowany do obsługi tego.

    Jak już po tym widać, dużo zmiennych i format musi się trochę "uelastycznić". Dobrze jest więc znaleźć miejsce na jakąś ewentualną konfigurację, chyba żeby zdać się na jakieś sprytne rozpoznawanie danych o złożoności i położeniu poszczególnych części modułu (co może jednak być już trochę za trudne).

    Co do playera dla rozbudowanego formatu CMX w wersji także mono (pokey), to moduł taki, z założenia może będzie musiał mieć drugą parę definicji paternów z obligo, nawet gdyby nic tam nie miał mieć zapisane. Wtedy (zawsze) mamy pierwsze $14 bajtów z tej drugiej pary stron ($200-$213) do dyspozycji, które mogą być bajtami do konfiguracji playera (co jest w module i gdzie tego szukać, bo już orientujemy się po tym, że do czynienia mamy z rozbudowaną formułą modułu CMX). Ale, ponieważ player powinien mieć zachowaną zdolność obsługi zwyklejszych modułów CMX i CMC to, wpadłem na taki wstępnie pomysł, żeby zaczynał swoje ustalenia od adresu $200 (i ew. $201) właśnie. Bo na podstawie zawartości tego lub tych bajtów, można będzie z przekonaniem rozpoznać się czy ma się do czynienia z taką czy inną postacią modułu (rozbudowaną czy nie).
    Więc skoro tam, w zwykłych modułach CMC, mamy pierwszą wartość definicji ścieżki song 0 (i w kolejnym ścieżki 1), więc pomyślałem, że może byłoby dobrze, gdyby pewną niespotykaną kombinacją, nigdy w definicji songu w linii 0, to sygnalizować właśnie. Do ustalenia pozostaje jaka to może być kombinacja, ale na pewno taka się musi znaleźć (przyszło mi do głowy: kod skoku w górę linii song o niezerową wartość, która definiuje już sobą jakiś parametr).

    Oprócz tego jest jeszcze kilka możliwych definicji danych potencjalnie koniecznych do zmieszczenia w takim module, na które trzeba by znaleźć odpowiednie miejsce i na co trzeba by pewnie wskazać w bajtach konfiguracji. Warto się trzymać rozmieszczania specyficznych danych na stronach, dzięki czemu przemieszczania się między nimi poprzez przełączanie w kodzie playera poprzez ich adresowanie (także w obszarze danych konfiguracyjnych) jest dużo prostsze.

    Dużo napisałem, za co przepszam (bo może nie potrzebnie aż tyle).
    • 24:
       
      CommentAuthorKaz
    • CommentTime2 Nov 2020
     
    Marok - nie przepraszaj za długi wywód, bo to bardzo ciekawe i fajnie, że się rozpisujesz! Można się dowiedzieć nie tylko o szczegółach technicznych i coś nauczyć, ale również o procesie Twojej pracy nad projektem, a to też interesujące. Trzymam kciuki za powodzenie w realizacji planów.
    • 25:
       
      CommentAuthorsun
    • CommentTime2 Nov 2020
     
    @marok: wersja na multi pokey, to obecnie:
    1. stereo - to minimum
    2. quad - na to czeka cały świat :)
    • 26: CommentAuthorxxl
    • CommentTime2 Nov 2020
     
    zalacznik nie dziala.
    • 27: CommentAuthormarok
    • CommentTime2 Nov 2020
     
    @xxl: Dzięki "za cynk". (A szkoda, że dość późno reaguję.)

    Zdaje się, że polskie znaki są problemem dla systemu zarządzania załącznikami.

    @Kaz: Dziękuję za dobre słowo z "same góry" (tak wyrażoną poniekąd akceptację dla tych konkretnie moich poczynań, bo nie piszę koniecznie o ich całokształcie).

    @Sun: Z wersjami jest tak, że nie wszystkie się okazuje (nawet gdy już są), bo czeka się lepszych okazji (i doprowadzenia ich do formy wydającej się względnie już w pełni dojrzałej).
    • 28:
       
      CommentAuthorsun
    • CommentTime2 Nov 2020
     
    @marok: przetestuję co podeślesz :)
    • 29: CommentAuthormarok
    • CommentTime7 Nov 2020
     
    Wersja podstawowa (na mono), referencyjna dla pozostałych, lekko się mi zmieniła (wcześniej o czymś dość istotnym zapomniałem; w pewnym miejscu coś jeszcze udało się poprawić). Na razie nie aktualizuję (pod jakąś muzyczkę), tylko tak wspominam.

    Odnośnie wersji innych niż na mono, dołączam coś, co gra w quad(ro). To jest tzw. double stereo wersja muzyczki. Ale to nie zmienia faktu, że gra to realnie na quad pokey, bo proces przygotowywania danych dla każdego pokeya przebiega oddzielnie (dla d-stereo player wykonuje tą samą pracę dwa razy, czyli nieefektywnie, ale w ten sposób określić można ile mocy procesora wymaga od modułów na quad).

    Wybrałem jedną muzyczkę, dodałem player (jeden). Są jednak trzy wersje z tego. Jedna wersja (jak i pozostałe) to d-stereo (czyli quad) i jedno wywołanie na ramkę. Druga wersja różni się tym, że jest dwa razy na ramkę (moduł oryginalnie w stereo jest dostosowany do takiej właśnie gry). Trzecia wersja różni się od poprzedniej tylko formatem zapisu paternów, dzięki czemu moduł trochę się skraca (ten jest zwięźle opisany we wcześniejszym poście). Każda więc z wersji różni się zawartością samego modułu (a nie playera).

    Działa ten player jak działa, w sensie "poboru mocy" (pokazuje to program - ten sam co zwykle). Jeszcze jest to wersja na starych zasadach, tzn. za każdym razem cztery bajty na stronie zerowej są archiwizowane i zwracane po powrocie z wywołania (to na pewno powinno się jeszcze zmienić). Player nie ma żadnej zdolności konfiguracyjnej - to konceptyjnie trzeba dobrze przemyśleć (jestem otwarty na pomysły z zewnątrz).
    • 30: CommentAuthormarok
    • CommentTime8 Nov 2020
     
    Wyraziłem kilkukrotnie nazbyt śmiało swój niepoparty specjalnie niczym pogląd (zbyt często tak robię), że player do RMT nie należy do szybkich, zestawiając go z innymi popularnymi formatami (a zwłaszcza z mpt).

    Wypada mi się dziś poważnie z tego swojego stanowiska wycofać, po sprawdzeniu lepiej czasu, w jakim wykonywane są muzyczki na tym playerze (zasadniczo sprawdziłem teraz tylko jedną, ale to już mi wystarcza do rewizji poglądu).

    Wprowadzałem w błąd (jeśli ktoś zwracał uwagę na moje słowa), więc wypada mi się z tego w ten sam sposób również wycofać (na forum).

    Teraz więc uważam, że RMT ma player, ogólnie rzecz biorąc (abstrahując od możliwości dźwiękowych), porównywalnie wydajny, co inne popularne formaty, a kto wie, czy może nie najlepszy z nich, szczególnie jeśli mierzyć wydajność i odnosić ją jeszcze (choć w minimalnym stopniu) do możliwości kreacji dźwięków, jakimi dysponuje. Dobrze jest więc napisany, z tego tylko wnosząc (tak wnioskując). Format zdaje się nie być nazbyt złożony (czego można by się obawiać), by całość jakoś szczególnie spowalniała, więc i on jest także dobrze przemyślany.
    • 31: CommentAuthormarok
    • CommentTime10 Nov 2020
     
    Chciałem tym razem zestawić, jak działa w porównaniu player Datriego do CMS, z tym co zrobione jest na teraz (choć to może już z grubsza mniej więcej tak zostać jeśli chodzi o osiągi) przy optymalizacji czasowej playera do CMC/CMS/CMX. Ta wersja optymalizowana (a także każda pochodna) też nosi numerację 2.2, jak niektóre inne (choćby ten wątek tego dowodzi), więc może dojść do pewnej konfuzji czy innych nieporozumień, ale to już trudno (biorę to na siebie).
    W paczce umieściłem moduł CMS, ten sam (przy zmianie w nim tylko jednego bajtu - kod $A7 jest przemianowany na $7F w jednym przypadku) z oboma tymi playerami. Dodatkowo jest jeszcze jedna muzyczka (znów od Poisona) "w rozmiarze" CMC na tym samym playerze ("flex") oraz na playerze specjalnie skrojonym do wyłącznie CMC modułów ("na wielkość", bo paterny mogą już być zmodyfikowane wg standardu CMX, choć oczywiście nie muszą).
    Wszystko to dla celów porównawczych.

    Co do playera, który jest jakby do wszystkiego (ten "flex"), jest on dostosowany do gry na quad, stereo i mono (i 3 pokeye). Dodając go do modułu, powinien się dostosować do gry na odpowiednią liczbę pokeyów, o ile moduł odpowiada mniej więcej architekturze CMC czy CMS. W tej chwili jest to wersja mocno wstępna jeśli chodzi o kod rozpoznający rodzaj modułu (i w ogólę konfigurację). Testowałem tylko czy zadziała rozpoznanie standardu CMS i CMC (jest to prymitywnie rozwiązane, ale działa).


    Może się zdarzyć, że poprzednio umieszane pliki będę zamieniał na inne wersje, aby aktualizować player do wersji, która jest pozbawiona jakiś niedociągnięć (już się tak działo i wciż mam to na uwadze).
    • 32: CommentAuthormarok
    • CommentTime11 Nov 2020
     
    Złożyłem wersję demonstracyjną z poprawianego playera ("flex") i tego programu, którego tu niezmiennie używam, ale teraz w nowszej trochę wersji. Demonstracja polega na odgrywaniu jednym playerem w tym samym czasie (równolegle) 4 modułów cmc połączonych w jeden duży (pojemny) moduł. Ale zamiast na quad pokey (jak ma iść to docelowo) idzie to do bufora (tymczasowa "poprawka" w playerze), z którego dopiero wyborem klawisza ustala się, który to moduł, a więc docelowo pokey, ma być "mapowany" na dwa podstawowe pokeye (lub jeden). Wtedy słychać te moduły (i jakby z tych pokeyów), które wybraliśmy, a reszty nie słychać, ale są odtwarzana niejako w tle (gotowe w każdej chwili "na przełączenie").
    Taki manewr pozwala zorientować się, czy aby na pewno moduł składowy, jako osobny taki "voice", gra zgodnie z tym, czego się po nim spodziewamy, czy coś może jednak jest nie tak. Ponieważ gra w jednym momencie wszystkich składowych modułow na raz (poza tym, że trudna do osiągnięcia "sprzętowo") byłaby często trudna w jednoznacznej tego ocenie.

    Klawiszologia. Klawisze cyferek od 1 do 0 (topograficznie patrząc) to gra kolejno: na jeden pokey z 1, 2, 3 i 4 modułu; 2-0: 6 kombinacji gry na dwa pokeye: 1+2, 3+4, 1+3, 2+4, 1+4, 2+3.
    Klawisz "M" przyda się, jak ma się tylko jeden pokey - przełącznik ala mono/ stereo. Spacja (o ile była użyta jako ostatnia) daje nadzieję na wstrzymanie odgrywania po dojściu liczników do zera (czyli działa to wtedy jak dotychczas) - inaczej będzie grało bez zatrzymywania "okresowego".

    Moduły były dobrane na szybko, byle odpowiadały kryterium ograniczoności w potrzebie edycji ręcznej linii song. Chodzi bowiem o to, że pierwszy moduł jest "sterującym" i tam gdzie ma "luki" w liniach (są umieszczone rozkazy specjalne z linii song), to na adekwatnej pozycji pozostałych modułów trzeba by dodawać puste linie (insertować). Ale tak samo wszystkie rozkazy specjalne z linii song, z tych pozostałych modułów, siłą rzeczy nie wiodących, chociaż te specjalne rozkazy z linii song nie byłyby wykonywane, to jednak ich numery byłyby brane fałszywie za wskazania numerów paternów do odtworzenia, więc też trzeba by to usuwać (DEL-ować) w liniach song (a nawet wówczas mamy już do czynienia z inaczej zachowującym się modułem, bo jednak rozkazy coś zmieniają w ich grze). Zbyt dużo roboty więc, dlatego chodziło o takie najprostsze konstrukcje modułów, gdzie takich rozkazów zwyczajnie nie ma. Drugim kryterium była zgodność tempa głównego.
    W takim zamiarze wszedłem do katalogu muzyczek Poisona i na szybko dobrałem (nie chodziło o wybór najlepszych, czy ani nawet dobrze do siebie pasujących) wszystkie 4, których użyłem do przykładu ("Asylum", "Cannon", "Agony", "Bad Drome").
    • 33:
       
      CommentAuthorsun
    • CommentTime11 Nov 2020
     
    stestuję.
    • 34: CommentAuthormarok
    • CommentTime15 Nov 2020
     
    Wersja demonstracyjna playera cmc zdolnego do korzystania (a przynajmniej śmielej) z czwartego kanału pokeya. Tzn. załadowywuje i, w razie gdy kanał jest zwolniony, odgrywa osobne paterny (przypisane dla 4 ścieżki). Inaczej dźwięk z tej ścieżki jest (musi być) przyblokowany.

    Nie jest to zupełnie nowa rzecz, bo kilku osobom pierwszą wersję demonstracji (w postaci sap pliku) już przesyłałem, więc niektórzy inni też już może coś słyszeli? (jeśli wieść się nieco rozeszła, a było to już jakiś czas temu)

    Demonstracja gra sobie i pokazuje te liczniki, co zwykle. Jest w tym dużo chaosu, ale po prostu są losowo wpisywane numery paternów do tej osobnej (4) ścieżki.
    Aktywne klawisze (ale dopiero z chwilą dotarcia do końca odliczania licznika głównego - jest on umieszczony przed kursorem w lewym górnym rogu, dwu znakowy), to:
    - spacja (jako ostatni klawisz) - chwilowe wstrzymanie odgrywania;
    - tab (j.w.) - podmiana paternów na nowy układ losowych wartości (tylko takich, które są obecne w module).

    Ogólnie, od tego ostatniego razu, kod tej specjalnej wersji playera poprawiłem także w wymiarze (zawsze) prawidłowej gry na tym czwartym kanale (był jednak błąd wynikający ze złego schematu logicznego rozwiązania, które uprzednio przyjąłem, choć nie rzucał się on w oczy i dobrze, że samo to jakoś wyszło, bo się tego sam nie domyśliłem).

    Dla nieco zainteresowanych technikaliami, moduł jest ten sam, co oryginalnie, poza tym, że adres modułu został obniżony o stronę (bez relokacji adresów w samym module), a tą brakującą stronę (same $FF) zapisałem za stroną danych z liniami song (czyli offset $300) a przed zapisem paternów (one muszą "adresowo" pozostać na swoim miejscu).
    Dopiero w tym programie obsługującym odgrywanie (saw..) jest wstawka wypełniająca obszar modułu przeznaczony na deklarację ścieżki 4.

    Ta deklaracja jest analogiczna do ścieżek 1-3, przy czym zapis znajduje się w miejscu strony jakby dla kanału 3 (czyli od $AA do $FF). Reszta strony jest niewykorzystana.

    To raczej ciekawostka (nie wiążę z tym wielkich nadziei), ale player jest do wykorzystania w razie, gdyby ktoś skomponował utwór w cmc korzystający w zamyśle z czwartej ścieżki.