Jak jest rozdzielczość DACa w Pauli. Wydaje się, że nawet jak na ówczesne czasy 14 bitów nie było poza ich zasięgiem, ale czy tak jest w rzeczywistości. Jak skalowane jest 8-bitów z sampla + 6-bitów z głośności.
Czy na A1200 której chipy są dwa razy szybsze Paula jest w stanie częściej zmieniać stan wyjścia DACa. To samo tyczy się A500. Istnieje tryb w którym CPU, nie DMA wypełnia rejestry dźwiękowe Pauli.
Na sztywno założyłem, że częstotliwość próbkowania hosta to 44100. Sam AudioReconstructor może pracować z dowolną. Tylko, że dla każdej takiej częstotliwości trzeba przygotować osobne BLEPy.
2012-04-12
hgsubversion
Nigdy więcej korzystania z czegoś takiego jakSVN na CodePlex. Tak naprawdę CodePlex nie wspiera SVN, natywnie dane są przechowywane w jakimś standardzie Microsoftu, i istnieje swego rodzaju pośrednik SVN-TFS.
Nie wiem czemu Microsoft zdecydował się na taki krok. SVN nie działa dobrze, nie wspiera wielu komend i praktycznie nie jest rozwijamy co świadczy o tym, że jest to swego rodzaju ślepa uliczka, w którą zabrnięto i wycofano się. Wycofano się do Mercurial wspieranego natywnie.
Czemu nie zdecydowano się na natywnego SVN, którym na pewno było by mniej roboty, może Microsoft liczył, że nastąpi migracja na TFS, chciał go w jakiś sposób zareklamować.
I tak oto mam repozytorium w ichnim SVN i nie ma jak danych wyciągnąć. svnsync, svn dump, svnrdump nie są wspierane.
Prośba o konwersję z SVN do Mercurial-a spotkała się z odmową, bo przykro nam bardzo, ale pana repozytorium należy do tych 5% których skonwertować nasze skrypty nie są w stanie.
Komenda hg sync jest wolna, przez całą noc nie była w stanie pobrać jednej z rewizji. I na pewno nie było tam więcej niż 50MB. Nie wiem po czyjej stronie leży błąd. hg sync albo ich SVN-ie.
Na szczęście jest jeszcze jedno rozwiązanie, tytułowe rozszerzenie do Mercurial.
Klonujemy repozytorium rozszerzenia:
W TortoiseHG odnajdujemy plik z konfiguracyjny z rozszerzeniami. Najprościej klikamy prawym w jakiś folder, w podmenu HG szukamy Settings. W oknie wybieramy Extensions, klikamy w ręczną edycję i dodajemy nowe rozszerzenie do listy, wskazujące na folder hgsubversion\hgsubversion. Zapisujemy plik.
Testujemy, że nasze rozszerzenie działa:
Teraz tylko pobieramy nasze repozytorium SVN do lokalnego repozytorium HG. Cały poces konwersji jest o niebo szybszy niż w przypadku hg sync. Może Microsoft powinien skorzystać z tego narzędzia by poradzić sobie z przypadkami trudnymi.
Skrypt który dokonuje konwersji:
No i porażka, większość rewizji jest pustych, następne do sprawdzenia: repozytorium SVN, analiza loga zatwierdzeń, pobranie wszystkich rewizji z loga, update po rewizjach, kopiowanie plików do repozytorium HG z kasowaniem w nim plików, zatwierdzenie HG z właściwym komentarzem, użytkownikiem i datą.
Jak to nie zadziała, to zakładam trzecie nowe repozytorium HG. Nie na CodePlex.
Nie wiem czemu Microsoft zdecydował się na taki krok. SVN nie działa dobrze, nie wspiera wielu komend i praktycznie nie jest rozwijamy co świadczy o tym, że jest to swego rodzaju ślepa uliczka, w którą zabrnięto i wycofano się. Wycofano się do Mercurial wspieranego natywnie.
Czemu nie zdecydowano się na natywnego SVN, którym na pewno było by mniej roboty, może Microsoft liczył, że nastąpi migracja na TFS, chciał go w jakiś sposób zareklamować.
I tak oto mam repozytorium w ichnim SVN i nie ma jak danych wyciągnąć. svnsync, svn dump, svnrdump nie są wspierane.
Prośba o konwersję z SVN do Mercurial-a spotkała się z odmową, bo przykro nam bardzo, ale pana repozytorium należy do tych 5% których skonwertować nasze skrypty nie są w stanie.
Komenda hg sync jest wolna, przez całą noc nie była w stanie pobrać jednej z rewizji. I na pewno nie było tam więcej niż 50MB. Nie wiem po czyjej stronie leży błąd. hg sync albo ich SVN-ie.
Na szczęście jest jeszcze jedno rozwiązanie, tytułowe rozszerzenie do Mercurial.
Klonujemy repozytorium rozszerzenia:
hg clone http://bitbucket.org/durin42/hgsubversion hgsubversion
W TortoiseHG odnajdujemy plik z konfiguracyjny z rozszerzeniami. Najprościej klikamy prawym w jakiś folder, w podmenu HG szukamy Settings. W oknie wybieramy Extensions, klikamy w ręczną edycję i dodajemy nowe rozszerzenie do listy, wskazujące na folder hgsubversion\hgsubversion. Zapisujemy plik.
Testujemy, że nasze rozszerzenie działa:
hg help hgsubversion
Teraz tylko pobieramy nasze repozytorium SVN do lokalnego repozytorium HG. Cały poces konwersji jest o niebo szybszy niż w przypadku hg sync. Może Microsoft powinien skorzystać z tego narzędzia by poradzić sobie z przypadkami trudnymi.
Skrypt który dokonuje konwersji:
set REP_DIR=winuae-codeplex-hg if exist %REP_DIR% goto CREATED hg init %REP_DIR% :CREATED cd %REP_DIR% :RECOVER hg recover :LOOP hg pull https://winuaeunofficial.svn.codeplex.com/svn echo errorlevel %ERRORLEVEL% if not %ERRORLEVEL% == 0 goto RECOVER :FINAL echo FINISHED pause
No i porażka, większość rewizji jest pustych, następne do sprawdzenia: repozytorium SVN, analiza loga zatwierdzeń, pobranie wszystkich rewizji z loga, update po rewizjach, kopiowanie plików do repozytorium HG z kasowaniem w nim plików, zatwierdzenie HG z właściwym komentarzem, użytkownikiem i datą.
Jak to nie zadziała, to zakładam trzecie nowe repozytorium HG. Nie na CodePlex.
Subskrybuj:
Posty (Atom)