Zapis "elastycznych" zmian tempa, w danych dla formatów które to oferują (mpt, tmc, rmt), zasadza się na koncepcji wplecenia ich w główny wątek danych (dane paternów). To ma swoje plusy, ponieważ wszystko jest razem i jest bezpośrednio dostępne, ale ma i minusy. Głównie, żarłoczność pamięci, jeśli z ciągłych zmian tempa w module się korzysta (muszą się powielać w danych różnych paternów).
Budowa modułu w formacie cmc ma w dużej mierze wymiar stronicowy, skontatuję. Tzn. dane tego samego rodzaju, spora ich część, zgrupowane są w obrębie stony pamięci - patrząc od początku modułu, aby ją szczelnie wypełnić, ale aby była też barierą do niesięgania poza nią dalej. To wynika z wymogów programistycznych i samoograniczenia w korzystywaniu z zasobów, głównie pamięci strony zerowej, które założył sobie ten format (pisząc w przenośni) i właściwości 8-bit rejestrów indeksowych procesora. To tak w pewnym skrócie i uproszeniu (można się by do ścisłości tego opisu zapewne słusznie przyczepić).
Jak sobie pomyślałem, można do cmc dodać także możliwość elastycznych zmian tempa. Chodzi mi więc o zmiany wewnątrz linii song, niejako analogicznie jak w zapisie paternu, ale faktycznie (fizycznie) poza nim. To trochę już stara koncepcja dla mnie, ale w tych właśnie dniach do niej wracam (caluśki rok minął odkąd nie dotknąłem się niczego). Ta dodatkowa funkcja pasowałaby mi do wersji cmc z zapisem ścieżki dla 4 kanału (była taka). Ten zapis ścieżki napoczyna nową stronę w danych modułu, którą pasuje mi wykorzystać w całości (lub po prostu pełniej), i pozostałe lokalizacje w module dla danych (na wielkość dwóch długości pełnej ścieżki, na tej stonie) są stąd do jakiegoś wykorzystania ("proszą się", bo są wolne). Postulat elastycznych zmian tempa też się przewijał i go uznaję za wystarczająco uzasadniony.
Osobny wątek danych dla wyodrębnionych zmian tempa wewnątrz ścieżek song sprawdziłem sobie koncepcyjnie i już także praktycznie, że (chyba) działa. To się więc, przyjmuję, udało. Więc teraz taki zgrubny opis tego, jak to jest pomyślane. Czynię to, bo być może jakiś mankament, jakiś jednak błąd logiczny, coś koncepcyjnie nie przewidziałem, da się z tego opisu już zauważyć i może tym sposobem da się mnie o tym też poinformować. Albo będzie to zwyczajne podzielenie się koncepcją, jako ciekawostka. Może ktoś to rozwinie i jakimś cudem zastosuje nawet gdzie indziej. Kto wie. Poza tym, czymś chyba trzeba forum wypełniać, nawet jeśli są to tylko tego rodzaju drobiazgi. Lepsze coś niż nic.
Powtarzalne wzory zmian tempa są obserwowaną oczywistością we wszelkich modułach. Możemy je mieć wyodrębnione jako takie właśnie wzory, paterny zmian tempa, i je tylko przyporządkowywać do poszczególnych linii song, jak pasuje.
Wzory takie potrzebują, na moje rozeznawanie, tylko takie informacje jak: - zmiana tempa na zadane od aktualnej pozycji paternu, - zaznaczenie miejsca we wzorze, do którego będziemy się może jeszcze odwoływać (zamiar), w celu powtórzeń danego fragmentu wzoru, - informacja o powtórzeniu tempa (oczywiście tego ostatnio używanego) w podanej liczbie pozycji paternu, - informacja o pozycji paternu, do której mamy wracać w replikacji (części) wzorca, celem jego powtórzenia od tamtego (zaznaczonego) miejsca poczynając, a na tym (dokładnie: wcześniejszym) miejscu wzorca kończąc, - informacja o braku konieczności dalszej analizy wzorca (przypisanego linii song), ponieważ tempo ma pozostać niezmienione do końca linii song (wprowadzone dla optymalizacji szybkościowej działania).
I tak, liniom song są przypisane indeksy "wejść" do pełnej tablicy wzorców zmian temp. To przypisanie jest uporządkowane zgodnie z kolejnością linii song na jednej z 'wolnych ścieżek' (nieopisanych, ponieważ nie ma dla nich zastosowania - inaczej opisywalibyśmy ich 6, a potrzebujemy tylko 4, w tym zastosowaniu, bo zajmujemy się teraz tylko jednym pokeyem). To się więc lokalizuje na tej "napoczętej" dodatkowo stronie, o której pisałem wcześniej (wciąż jedna "ścieżka" pozostaje wolna i do innego jeszcze wykorzystania). Z tego opisu może już trochę wynikać, że brakuje miejsca na same wzorce zmian tempa (ponieważ są tylko indeksy "wejść") na tej już stronie (a reszta to może być, przede wszystkim, wykorzystana inaczej, albo możemy mieć wrażenie, że jest tego miejsca nie za dużo). Te mają się znaleźć na jeszcze jednej stronie więcej za tą z indeksami. Przewidziana jest tylko jedna strona, a nawet tylko $c0-1 bajtów tej strony, do wykorzystania dla zapisu tych wzorców. Pierwszy bajt powinien być raczej wyzerowany i nie do wykorzystania, a pozostałe brakujące $40 (do pełnej strony) wynikać z pewnych uproszczeń w kodzie, które pomogły to łatwiej może oprogramować. Mimo tego, uzyskaną przestrzeń w liczbie bajtów przeznaczoną dla wszystkich potrzebnych dla wykorzystania w module wzorców zmian tempa uważam za wystarczającą. Mogę się w tym mylić?
Teraz o samych wzorcach zmian tempa w konkretach, znaczy w podziale na kody: - 0: koniec analizy, bo wszystko już jasne (gramy aktualne tempo do końca linii song), - $01-$3f (+$40): zmiana tempa na zadane (z opcją zaznaczenia miejsca we wzorcu), - $80: w zasadzie do jakiegoś jeszcze wykorzystania (potencjalnie: nagłego skrócenia odtwrzania aktualnej linii song), - $80-$bf: pozycja paternu, przed odegraniem której (? - musze się upewnić) ma nastąpić odczyt nowej wartości z wzorca, czy to od miejsca zaznaczonego (początku sekwencji przewidzianej do wielokrotnego powielania) czy od następującego po tym; wartość pozycji paternu, w kodzie kodującym, oblicza się kasując najstarszy bit (= -$80); wzór się takim kodem nie zaczyna, ponieważ wejdzie w niekończącą się pętlę braku możliwości odczytu wartości ze wzorca, - $c0: przypadek jak dla $80 (chodzi o liczbę powtórzeń, która może być nadmiarowa; ma pewno to samo uzyska się szybszym #0),- $c0-$ff: powtarzanie ostatniego tempa na liczbie linii paternu wynikającej z działania: $100 - #kod ($ff = jedno powtórzenie).
Takie jeszcze proste zmiany tempa w symbolicznym zapisie we wzorcach:
tempo 5/6 naprzemiennie: 5,6,$bf ($bf: nigdy się pozytywnie nie zweryfikuje, więc pętla nie ustanie - ponieważ pozycja paternu uzyska wartość $bf przy ostatnim odczycie wartości 6; $bf potencjalnie można więc zastąpić dowolnie inną wartością nieparzystą, ale $bf i tak pasuje najlepiej)
kolejne tempa 5/5/5/6 w te i nazad (poprzez kolejne linie paternu) do 3/4 całości paternu, dalej już zostawiamy 6: 5,$fe,6,$b0,0
1/4 parernu tempo 5, potem naprzemienne 6/5: 5,$f1,$46,5,$bf
Te przykłady to tak bardziej z głowy bo dokładnie nie sprawdziłem czy na pewno u mnie zadziałają, ale chyba odpowiadają temu, co napisałem, że powinno działać, z teorii.
