Interesuję się w tym momencie metodologią zmian tempa w trackach na różne komputery, bo sam osobiście trochę mało widziałem, a chciałbym odnaleźć "najsłuszniejszą" formułę dokonywania takich zmian z punktu widzenia zastosowań na atari, czyli zakładam, ważnym elementem pozostaje skondensowanie przekazywanej w zapisie tracka informacji.
Najbardziej oczywistą metodą jest ta, że na konkretnej pozycji w patternie zapisuje się wartość bezwzględną tempa.
Chociaż zaspakaja ona w całości zapotrzebowanie na takie zmiany, dając pełną swobodę, to jednak jest to metoda najbardziej pamięciożerna, bo w swojej podstawowej odmianie kosztuje bajt dodatkowego argumentu, którym wyraża się nowe tempo, bezpośrednio umieszczanym w zapisie za samą komendą zmiany tempa.
Rozwiązaniem pokrewnym, ale i kompromisowym, jest to zastosowane w formacie mpt (btw. atariki jest bardzo użytecznym źródłem informacji), bo tam zmiana tempa też bezpośrednio nadawana w wartości bezwzględnej, mieści się w samej komendzie zmiany tempa (na bitach, a nie w całym bajcie).
Niemniej oznacza to zawężenie wachlarzu możliwości zmian tempa do określonego zakresu, chociaż muszę się zgodzić, że wydaje się on w pełni wystarczający. Kosztem jest poświęcenie sporej ilości komend, na co można sobie zwykle pozwolić, o ile nie bardzo jest jak je inaczej wykorzystać.
Można by więc uznać rozwiązanie z mpt za modelowe, ale chciałbym rozważyć i przedyskutować nieco inne jeszcze możliwości.
Wcześniej jednak odwołam się do innej metody stosowanej w playerach na atari, którą akurat odnotowałem, żeby trochę poszerzyć ogląd potencjalnych możliwości "w tym zakresie".
Jest tam tak, że mamy jakąś wartość bazową tempa, która determinuje tempa kolejne, będące wielokrotnością tego tempa bazowego, a kody sterujące zmianami tempa wskazują indeksy w tablicy temp tak wzajemnie uwarunkowanych. To tempo bazowe można zmienić chyba jakąś osobną komendą i uaktualnić tablicę temp o powiązane tym schematem wartości.
Plusem takiego rozwiązania w odniesieniu do tego z mtp jest to, że mamy możliwość nadania tempa znacznie wolniejszego od tego najszybszego (bazowego), na które jest zapotrzebowanie w zapisie melodycznym, przez co zapis może być bardziej w pewnych sytuacjach (kiedy w sensie muzycznym niewiele się dzieje) zwarty (nie potrzebujemy robić "pustych pozycji w patternie" - komenda $FE w mpt - , być może nawet taka komenda w ogóle nie jest przewidziana w formacie takiego rozwiązania).
Wydaje się, że to opisywane powyżej rozwiązanie jest stosowniejsze, kiedy długość patternów nie jest z góry ustalona, co nie jest przypadkiem szczególnie mnie interesującym, ponieważ rozważam zastosowania typowo trackerskie (z jasnym podziałem na z góry ustalone wielkością patterny, którym skądinąd można potencjalnie wymusić szybszy koniec poprzez odpowiednie zapisy/ kod w samym patternie).
W ten sposób dochodzę do sedna swojego wywodu. Zaczną się też za moment pytania do praktyków, którzy sami widzieli więcej i mają lepszy ogląd co w zmianach tempa jest użyteczne.
Załóżmy że możemy wykorzystać te same kody komend jakie spożytkowane są w mpt na ten sam cel ($Cx), czyli zmianę tempa. Mamy więc 16 kombinacji, dodatkowo dysponujemy "za darmo" niezależnym źródłem wprowadzenia dowolnej wartości do tempa na początek odgrywania patternu (z dalszą możliwością jego modyfikacji przed odegraniem pierwszego dźwięku już w zapisie patternu), oraz możliwością wykorzystania co najmniej jeszcze jednego dodatkowego argumentu w ramach tego "za darmo" (do jakiegoś zmyślnego wykorzystania).
Z tego powodu odnosząc się do tempa niejako"referencyjnego" będącego spoza zapisu w samym patternie, możemy potencjalnie posłużyć się względnymi wartościami (lub innym "szyfrem") w interpretacji kodów komend zmian tempa w samym patternie. To jest możliwość jaka się otwiera i którą warto uważam rozważyć.
Dlaczego.
Bo ze zmianami tempa w trackerach wiąże się co najmniej jeden typowy trick, który udało mi się podpatrzeć (choć nie znam potencjalnych wariantów jego uzasadnionego stosowania), a który polega na tym, że na każdej kolejnej pozycji w patternie znajduje się zmiana tempa, ale jest to zrobione z dwóch wartości naprzemiennie po sobie występujących i są to wartości tempa, które najprawdopodobniej zawsze dzieli 50% różnicy w generowanym sobą czasie pauzy między odczytami kolejnych pozycji patternów.
A więc chodzi o taki zapis:
pozpat Z tempo X
pozpat Z+1 tempo X+Y
pozpat Z+2 tempo X
pozpat Z+3 tempo X+Y
itd.
Byłoby dobrze znaleźć formułę skondensowanego zapisu wymuszającego takie zmiany tempa, co na pewno nie uda się zrobić posługując się interpretacją zapisów w komendach zmiany tempa wyłącznie tylko jako wartości bezwzględnej.
Wydaje się, że takie ustalenie tempa raz, obowiązuje później "dłuższą chwilę". Możemy bezpiecznie założyć że do końca patternu, a przede wszystkim od jego początku (a często na przestrzeni całego songu) i nie zajdzie potrzeba zmiany takiego ustawienia tempa, a nawet gdyby, to nie będzie problemu z jego przełączeniem na jakąś stałą wartość (gorzej w drugą stronę, czyli że wewnątrz patternu przełaczamy się na taki tryb naprzemiennych zmian tempa w cyklu).
Wydaje mi się więc że warto posłużyć się tym wspominanym wcześniej "zewnętrznym" w stosunku do zapisów patternu kodowaniem takiego tempa.
Tym samym być może (pisząc cały czas się samo koryguję w poglądach) nie jest to dostateczny powód aby traktować wartości kodów zmian temp w patternie inaczej niż wartości bezwzględne.
Muszę jednak zebrać więcej danych na temat stosowanych technik zmian tempa (co się rzeczywiście przydaje) wewnątrz patternów.
(Uwaga, zaczynają się pytania)
Wracając jeszcze do tego ostatniego "patentu", to czy możemy założyć że zawsze zmiany tempa polegają na następującej zależności:
tempo X
tempo 1,5*X
itd.?
Czy stosowane są jeszcze jakiś inne warianty? Jakie?
Czy zawsze pierwsze w tym "tricku" (na pierwszej i każdej nieparzystej pozycji patternu) jest tempo 1,5*X, czy może zdarza się (/jest) dokładnie odwrotnie (tempo X pierwsze)?
Czy znane są jakieś inne "patenty" zmian tempa? (chodzi głównie o przypadki cykliczności takich zmian)
Jak często przydają się tempa "wyższe" (tzn. dłuższe pauzy w przesuwaniu pozycji patternów) ?
czy są jakieś "dzikie" pomysły, które warto byłoby rozważyć, a związane ze zmianami tempa?
Z góry dziękuję za każdą merytoryczną odpowiedź.