> Wczoraj gadałem trochę z Xrayem nt. kolekcji muzycznej, którą zamierzamy wkrótce wydać. Przy okazji wyszedł pewien problem i jednocześnie jego teoretyczne rozwiązanie. W każdym bądź razie chciałbym zapytać się koderów, czy to jest sensowne i (ewentualnie) kto by to mógł zrobić...

To rozwiazanie funkcjonuje w trackmie do Syzygy 4. Zawsze sie "chwalilem", ze to najszybsze trackmo na Atari, bo zajmowale kilka/kilkanascie rozkazow.

> Wystarczy napisać programik, który przy odtwarzaniu utworu będzie zrzucał co każde wywołanie playera zawartość wszystkich rejestrów AUDC/AUDF i AUDCTL do pliku.

Ja to robilem w ten sposob, ze w playerze zamienialem sta $d200-$d207 na sta $600-$607 (+ drugi pokey + $d208 + $d20f), a specjalna procedurka co ramke (2x na ramke zaleznie od potrzeb) przenosila to "na koniec sampla" i tak w kolko. Bo zdaje sie, ze rejestry $d2xx przy odczycie daja inne wartosci, tak wiec najprosciej zmienic player.

> Wychodzi 18 bajtów dla stereo przy każdym wywołaniu playera, co dla utworu np. 2x na ramkę oznacza, że minuta muzyki będzie zajmować 108000 bajtów = 18*2*50Hz*60sek. Trochę dużo, ale bez straty jakości a poza tym - i tak mniej niż MP3... 

Prawie 100 KB/minute... Ile zajelaby muzyka z Numena?...

> Całość można by spakować np. FP. Później proces trzeba byłoby po prostu odwrócić i z odczytanego pliku przepisywać po prostu wartości do rejestrów...

Pakowanie wychodzilo dosc ladnie nawet przy zwyklych (nie specjalistycznych) pakerow, np. Flash "napisz se" pakera ;)

>Wady:
> 1. Stosunkowo duża objętość danych w porównaniu z innymi formatami przybierająca drastyczną formę 

wlasnie...

> Jeśli idea została by podchwycona, to może powstanie nowy format danych?

Wlasciwie, to nie jest to po prostu WAV/50Hz?

Myślę, że te dodatkowe bajty można uratować także przez odpowiednie ustawianie danych "strumienia" - blokami "po kanałach" np. najpierw na zmianę bajty z rejestrów AUDF1 i AUDF5 (pierwszy kanał, lewy i prawy pokey) aż do końca muzyczki, później to samo z kolejnym kanałem: AUDF2 i AUDF6 itd itd... Wydaje się, że zredukuje się sporo w ten sposób...

A nie prosciej bedzie (chodzi o skok w dowolne miejsce utworu) skoczyc do najblizszego wstecz poczatku paternu i wywolac procedure playera (moze bez zapisu rejestrow, zeby nie bylo slychac) tyle razy ile trzeba najszybciej jak sie da, by "dojechac" do odpowiedniego miejsca (oczywiscie czas "dojechania" zalezy od dlugosci procedury playera, ale one nie sa zazwyczaj dlugie, musle ze w jednym frejmie by sie wyrobilo w wiekszosci przypadkow).
Bo to, co proponujesz, to jakby strzelanie do much z armaty, specjalny player i format, tylko po to zeby mozna bylo skoczyc w dowolne miejsce....

To co pisze Pecuś ma sens...

Mnie się wydaje, że jakiekolwiek skoki do początków patternów nie mają większego sensu, a to ze względu na ...kompozycję utworu.
Jako muzyk chcialbym zauważyć iż podczas grania patternu nieraz (autor) zmienia różne parametry, które mają wpływ na dalszy ciąg muzyki. Np.: Kiedy w połowie patternu wstawiam komędę zmiany tempa , a na początku jego odgrywania (naszym playerem omawianym) spróbuję przewinąć o kilka patternow dalej to ten dalszy ciąg bedzie grał ... no nie w tym tępie o ktore autorowi chodzilo. Poprostu komenda ta zostanie pominięta i będzie klops buuu ;(((...

Nie wiem czy dobrze się wyraziłem ale mam nadzieję, że się domyślicie. Jest piątek, po pracy ... 

dobranoc.

Metoda z przewijaniem do początków patternów może być bardziej zagmatwana niż się napi* rzoot oka wydaje. 
Problemem mogą stać się też wszystkie skoki do patternów (podczas trwania utworu) i pętle (tak jak to było w cmc) wiem, że mało kto tego używał ale było tak, że jakis fragment muzyki powtarzał się kilka razy a potem muza szła dalej.
No i ... właśnie skoki do począków patternów.... cóż nie jestem koderem więc może się mylę ale przydałoby się, żeby taki player był uniwersalny, a nie odgrywał tylko np tmc czy mpt czy jaki inny format, a wydaje mi się, że to jest rozwiązanie raczej dla konkretnego formatu...   A co jesli w muzie nie ma patternów ??   przecie jest całe mnóstwo różnych programów muzycznych, No i nie tylko programów, bo przeca mnostwo utworów było pisane w przeróżny sposób..  Fajnie byłoby aby możnabyło taką prockę zastosować do ...wszystkich sapów.  No i Na atarce tysz.
Myślę, że strumień byłby lepszym rozwiązaniem . Tylko czy wykonalnym ??

Sa SAPy "TYPE R", ktore skladaja sie z wartosci rejestrow POKEYa dla kazdej ramki.

Player w Numenie stosuje buforowanie (muzyka zajmuje >300 KB). Nie moglem odpuscic 2% mocy obliczeniowej - dlatego player MPT wykonuje sie w "wolnym czasie" (ktorego prawde mowiac wiele nie ma), a co ramke idzie prosty odtwarzacz (z tego, co pamietam, ok. 100 cykli).

Jesli chodzi o przewijanie muzyki, to nie bardzo widze sens (3 min. muzyki, to nie 3-godzinny film, ktory sie oglada na raty). A pomysl rozpisania wartosci rejestrow POKEYa na Atari jest durny. Jesli chodzi o PC, to moze WinAMP nie umozliwia przewijania SAPow (nie wiem, bo nie uzywam), ale na pewno widzialem taka mozliwosc ("Pulse Player"?), zrealizowana bardzo prosto - przy przewijaniu do przodu zapuszczamy emulacje 6502 na wiele ramek, przy przewijaniu do tylu tak samo, zaczynajac emulacje od poczatku.

Kompresja LZ77 (jak w FP) wymaga rozpakowania calej wczesniejszej zawartosci strumienia (wielkosc okna nie ma znaczenia). Dlatego w formatach umozliwiajacych przewijanie (np. MP3) sa niezaleznie kompresowane ramki. Najlepsza metoda kompresji jest zawsze taka, ktora jest dostosowana do kompresowanych danych. MPT/TMC mozna wlasnie traktowac jako skompresowanie strumienia danych, z podzialem na ramki (pozycje w songu).

Racje ma Pecus. Wplyw poprzednich patternow na nastepne jest niewielki. Na poczatku mozemy szybko przetworzyc wszystkie patterny zapisujac kilku/kilkunastobajtowy wektor stanu playera. Nastepnie szybko pomijamy pozycje w paternie i potem wywolujemy juz player. Nie potrzeba hektarow pamieci, jest to szybkie, ale oczywiscie trzeba napisac "pod player".

Nie zgadzam się. Przesluchaj sobie muzę z wlasnego dema...
Ja miałem nie raz potrzebę przewinięcia muzy bo np interesowal mnie jakis instrument który grał np gdzieś w połowie muzy. Poza tym 3 min. kawałki to sie tylko na kompoty pisze. są dłuższe i krótsze!  jak....   no wiesz co ...
Przewijanie jest bardzo przydatne (może nie Tobie) ale nie jednemu

Chciałeś kogoś obrazić ?? 
możnabyło użyć innego słowa. To było nieprzyjemne ...  dokogokolwiek miałoby być skierowane.

To sobie chyba sciągne tego playera ;P

A na tym się nie znam.

Nieraz niewielki, a nieraz kolosalny.   Chyba, że komuś słoń na ucho nadepnął.

Prima apriFOX

A mnie sie wydaje całkiem fajny i przydatny,a do czego to moze sie okaze w najblizszej przyszlosci.

Nie koniecznie, moze sie zle wyrazilem, ale mozna przeciez podzielic calosc danych na bloki (ktore ty nazywasz ramkami) o wielkosci okna (offsetu).

Mi też o to chodziło:
1. zmiana tempa
2. pętle i skoki do patternów wewnątrz utworu
3. sytuacja kiedy dajmy na to gram dzwięk który wybrzmiewa przez np 3 patterny, a przy przewijaniu zostaje pominięty ... i ... kicha.  a gdy ten instrument jest uzyty do specjalnego muzycznego patentu coby uzyskac specjalny efekt dzwiekowy na 2 kanałach ... to zacznie sie wielki fausz, zgrzyt aboco jeszcze.

Jak znajde jeszcze jakies czynniki przemawiajace przeciw tej metodzie to sie podziele.