1

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

2

W GoatTrackerze istnieje coś takiego, jak FunkTempo, ale zdaje się, że jest to Twój pierwszy wariant (można go chyba też realizować opóźnieniem odtwarzania nuty na pozycji przy stałym tempie utworu). Fachowcem nie jestem więc nie powiem co się stosuje.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

3 Ostatnio edytowany przez seban (2015-05-10 16:27:27)

Cześć,

Nie jestem kompetentny wypowiadać się w tej sprawie, więc się wypowiem :) Nie wiem czy cokolwiek wniosę do sprawy, ale może się przyda.

#1) czy patrzyłeś sobie np. na ten utwór Jakuba Husaka... http://asma.atari.org/asmadb/search.php?details=244

gdy zajrzysz pod $4695 zobaczysz...

4694: 38                SEC
4695: A9 0D             LDA #$0D
4697: ED AB 3E          SBC $3EAB    [$3EAB] = $07
469A: 8D AB 3E          STA $3EAB    [$3EAB]

w lokalizacji $3EAB znajduje się prędkość wywoływania player-a. A więc powyższy kod co każe wywołanie zmienia prędkość, na przemian występuje prędkość 6,7,6,7,6,7,6,7,6,7,6,7.... genialne w swojej prostocie i nie wykorzystuje żadnych dodatkowych komend zawartych w pattern-ach. Player jest w ACTION! wiec gdy go "disasemblujesz" to może dziwnie miejscami wyglądać, ale jak na kompilator i kod w ACTION! to wynikowy kod wygląda naprawdę całkiem nieźle :)

#2) gdy X-Ray pisał pod MPT i tam nie miał możliwości wykorzystania takiego tricku, po prostu znajdował jeden kanał na którym nie potrzebował używać dodatkowych kodów (np. sterujących głośnością, etc.) i zapełniał go komendami zmiany prędkości co nutę, tak jak to opisałeś wyżej. Z tego co z nim kiedyś rozmawiałem chodziło mu o uzyskanie tempa pośredniego, zamiast pisać z prędkością 1 i wstawiać nuty w odpowiednich miejscach, prościej mu było uzyskać zamierzony efekt właśnie w ten sposób. Dodam tylko że X-Ray często i gęsto pisał na prędkościach 2,3 (podczas gdy tempo wywoływania player-a wynosiło 50Hz).

4

@mono: Dzięki. Goat Tracker okazał się inspirujący i rzeczywiście rozjaśnił mi sprawę. Masz całkowitą rację rozpoznając moją propozycję ("pierwszy wariant") z posta jako Funktempo.
Pomysł z opóźnieniem odgrywania nuty przy niezmienianiu wartości tempa dla uzyskania tego samego efektu, odnotowuję, zastanowił mnie chwilę, ale nie przekonuje mnie (słusznie lub nie).

@seban: Witam. Dziękuję za "background story". Warto takie historie czytać, rzucają one światło na motywacje i powody używania różnych (względnie) niestandardowych technik.