Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
Opcje wyszukiwania (Strona 11 z 35)
chciałeś napisać "kompatybilne" chyba... jak ktośnie jest zwykłym użytkownikiem i kupi sobie taką zabawkę, to ma niestety problem. Hehehehe, przekroczyłeś właśnie barierę 666 postów, mi jeszcze 59 brakuje ;P...
w tym wypadku się nie zgadzam, to jest nisza niszy niszy...
według mnie firebee mogłobyć ok, gdyby nie ten poroniony pomysł z supportem dla przestarzałych interfejsów do urządzeń typu twarde dyski, klawiatury itp (które de facto podniosły cenę samego urządzenia). Cena też odstrasza. A autorzy najpierw zrobili/zaprojektowali urządzenie, ale nie zrobili wywiadu środowiskowego typu kto to kupi i za ile. Jak zwykle skończy się na tym, że nie będzie komu na to softu robić dla tych trzech użytkowników.
Jak by była maszynka z tylko nowoczesnymi interfejsami i cena niższa o połowę to by to jeszcze dawało radę.
nie, nie jest u mnie, u providera. mam jakiś tam cpanel i dostęp do logów przez ftp. Mam włączonego spam assasina i box trappera, ale jak już pisałem nie ma nic w logach. Nic nie zmieniałem w konfiguracji od czasu otrzymania ostatnich skanów, więc problem jest gdzie indziej.
nie mam pojęcia co to może być, bo nie mam kompletnie nic w logach. Może z ten twój serwer rozsyła z partyzanta jakiś spam i został przyblokowany? Moze przeklej treść wiadomosci w PM do mnie na forum, to rzucę okiem.
a z jakiego adresu? bo u mnie nie ma śladu, ze coś było przyblokowane.
ok, GEM programmers reference już wrzucony.
sqward napisał/a:Nie widziałem, żeby ktoś pisał na "martwo" ;)
ja na przykład non stop pisze 'na martwo' zza grobu ;>
nie spodziewam się żeby Cyprian miał aż takiego pecha ;)
sqward napisał/a:To ciekawe. Spodziewałbym się więcej. Jaki masz tam zegar? 16 czy 32?
w tt jest 32.
jest wersja 27" dell U2711 monitora podobno też działa , ale niestety nie ma nikogo z tym modelem, kto mógłby przetestować.
Sqward: możesz jeszcze sprawdzić z st czy działają tryby ST-low/med/hi res. I czy obraz jest ok dla 50/60hz?
To jest mi akurat potrzebne przy odgrywaniu eventów midi z kilku ścieżek. Muszę mieć śledzenie delt dla każdej ścieżki. Jak mam dane w jednej ścieżce to z przeliczaniem delt problemu jest trochę inny (przerwania mogę zrobić rzadsze, delta eventu * okres 1 delty).
W załączniku jest log z mojego parsera dla pliku midi 1.
midi clock jest opcjonalny i jest to wysyłanie co pewien stały interwał czasu sygnału do urządzeń midi (jeden bajt, (chyba 0xf8 i parę innych) ma sens jak jest podłączonych więcej urządzeń, ja programuję pod jeden moduł. Chodzi o to, żeby n urządzeń było zsynchronizowanych w czasie.
Delty w pliku muszą być przy każdym evencie w ścieżce, nie ma innej opcji. Tak delta występuje tylko w plikach midi. Gdyby nie dało się ustalić jakiejś częstotliwości 1 delty to myślisz, że jak sekwencery obsługiwałyby te wszystkie zdarzenia?
wiem że delta nie jest stała. Delta jest relatywna w czasie do poprzednich eventów w strumieniu. Racja, tempo się zmienia w czasie i za każdym razem gdy jest zmieniane czas trwania delty także ulega zmianie. Ale nie zgodzę się, że nie da się obliczyć jej częstotliwości dla określonego tempa w danej chwili czasu.
P.S. Chyba mam już rozwiązanie, ale muszę to najpierw sprawdzić.
Cyprian: Chodzi mi głównie o częstotliwość z jaką inkrementowana jest 1 delta. Jak będę miał poprawny, stały czas update'u to będę w domu.
Cyprian: czas ćwierć nuty to nie delta. Mi jest potrzebna częstotliwość z jaką ma być inkrementacja delty, dane do rejestrów MFP na podstawie zadanej częstotliwości umiem sobie dobrać. No nic, może popiszę po autorach sekwencerów midi. Dzięki.
znam tą stronę. 500 000 to jest defaultowa wartość dla tempa (podałem to jako przykład) tak jak defaultowy ppqn jest 120. Długość ćwierć nuty jest ustawiana przez event set tempo przy odgrywaniu utworu.
Znam specyfikację formatu, mi raczej chodzi o prawidłowy sposób implementacji obsługi tempa. Przeliczanie na czas rzeczywisty eventów jest wg wzoru:
float freq=500 000(czas trwania ćwierć nuty w mikrosekundach)/1000000.0f = 0,5s; (ilość sekund na ćwierć nutę )
sekundNaTyknięcie=freq/pCurrentSequence->timeDivision (np. 120 ppqn); - ilość sekund na tyknięcie
czas delta w sekundach = czas delta eventu z pliku midi * sekundNaTyknięcie.
no i ten czas delty w sekundach musze przerobić jakoś na częstotliwość dla mfp dla 1 delty. freq=1.0f/freq; nie daje dobrego rezultatu.
Aloha,
Czy jest ktoś na tym forum kto programował replayera do plików midi i wie jak obsłużyć wysyłanie eventów na podstawie czasów delta? Jestem w stanie przełożyć delty na czas rzeczywisty, ale za bardzo nie mam pomysłu jak przełożyć to "na MFP".
Generalnie potrzebne mi jest obliczenie częstotliwości(w hercach) do zapodania mfp (ustawienia to już mam), żeby przerwanie wywoływało się co jedno tyknięcie delty.
Czas 1 delty (w przeliczeniu na czas rzeczywisty) jest obliczane w jakiś magiczny sposób za pomocą danych wyjętych z pliku midi (mam czas trwania ćwierć nuty w mikrosekundach oraz ilość tyknięć na ćwierć nutę (tzw. PPQN- pulses per quaternote)). Mam jeszcze sygnaturę czasową (np. 4/4, 4/8 etc), ale ona podobno jest raczej do niczego nie potrzebna(oprócz liczenia sobie barów).
Liczę sobie to obecnie tak:
float freq=500 000(czas trwania ćwierć nuty)/1000000.0f = 0,5s;
freq=freq/pCurrentSequence->timeDivision;
//calculate freq in [hz]
freq=1.0f/freq;
Problem w tym, że to tempo jest zdecydowanie za wolne (ok. ~4 razy). Niestety jestem dyslicznikiem z dyskalkulią czy ktoś może mnie oświecić jak uzyskać ludzkie tempo?
pzdr,
saulot
http://dbug.kicks-ass.net/ zakładka patches. Jest tam lista gier do pobrania, które zostały poprawione i odpalaja się z hd. Wiekszość gier (jeżeli została po ludzku napisana odpala się z hd po skopiowaniu plików z dyskietki)
źródła są zamknięte, replay był napisany przez tao/abyss z cream'a wieki temu, więc to nie jest tak prosta sprawa jak się wydaje.
bachoo napisał/a:przeczytam Ci na uszko jak się zobaczymy na którymś ze zlotów, kolego... Jeśli chcesz kilka razy.
Wolę nie, ale jak masz ładną, młodą siostrę to może mi wtedy poczytać.
dobrze traktowałeś, przeczytaj jeszcze kilka razy artykuł ze zrozumieniem treści.
jasne, to są tylko slajdy z prelekcji, więc podejrzewam, że na miejscu można było się duzo więcej dowiedzieć.
Jeżeli nie czytaliscie tego na DHSach. Gunstick/ULM prowadzi od jakiegoś czasu warsztaty o kodowaniu dem na Atari ST, głównie w assemblerze. Dla nie znających platformy są slajdy wprowadzające.
link: http://wiki.hackerspace.lu/wiki/AtariSTknowhow
Jeżeli ktoś nie wie to Gunstick/ULM zakodował jednego z pierwszych (jeżeli nie pierwszego) fullscreen'a na Atari ST, o ile mnie pamięć nie myli, więc zna się trochę na rzeczy. Warto rzucić okiem na slajdy i przejrzeć materiał.
Znalezione posty [ 251 do 275 z 855 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.037 sekund, wykonano 26 zapytań