1

Temat: Steem +Cubase +problemy z zapisem

Bawię się Cubase (2.01 i 3.1) pod Steem (3.9.2) na Windowsie (7) i mam katalog jako dysk HDD.

Wszystko chodzi sobie elegancko w obu Cubase'ach, mogę też zapisywać pliki zarówno jako song, jak i jako mid i w ogóle wszystkie zapisy działają poprawnie, ale jak próbuję zapisać plik nadpisując już istniejący, to Cubase zgłasza najpierw że plik już istnieje i proponuje replace albo cancel. Chcę zrobić replace i jak zrobię w Cubase 2, to okienko znika ale plik nie zapisuje się, tylko pozostaje ten, który był. Z kolei jak zrobię to samo w Cubase 3, to po kliknięciu replace wyskakuje mi "create error" i plik też się nie zapisuje, więc efekt jest w sumie ten sam w obu Cubase'ach.

Myślałem, że coś z uprawnieniami może w Windowsie, ale nie, bo pod GEM-em jak normalnie skopiuję plik z jednego miejsca w inne nadpisując istniejący plik, to jest wszystko w porządku. Save w grze Monkey Island przykładowo też działa poprawnie i nadpisuje plik bez problemu.

Jakieś pomysły, sugestie?

Problem jest bardzo poważny, bo chcę sobie muzę porobić trochę, więc chcę często robić save, i teraz muszę za każdym razem robić to jako nowy plik...

Edit: sprawdziłem jeszcze, że kwestia nie jest związana z samym Cubase'm, bo przetestowałem właśnie, że te same wersje na żywym Atari nie robią tego problemu, wszystko jest w porządku i da się normalnie zapisywać nadpisując pliki. Czyli kłopot z tym jest tylko w emulatorze. Co prawda już mi to mocno kamień z serca zdjęło, bo chcę się docelowo bawić na żywym Atari, więc problem jakby znika, ale jednak fajnie było by wiedzieć czy da się to jakoś zrobić, żeby działało również w Steem.

Ostatnio edytowany przez Mq (2019-03-15 09:00:09)

Odp: Steem +Cubase +problemy z zapisem

Może to problem piratów?

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

3

Odp: Steem +Cubase +problemy z zapisem

Tak, używam piratów Cubase w tym przypadku. Może to mieć związek, nie wykluczam, ale dziwny był by to chyba objaw, bo tak jak napisałem w obu wersjach Cubase problem ten nie występuje na prawdziwym Atari, tylko w emulatorze Steem.
Teraz sprawdziłem jeszcze na Hatari i też problem nie występuje. Ale z kolei Hatari nie obsługuje za bardzo MIDI, więc musi być Steem do Cubase.

4

Odp: Steem +Cubase +problemy z zapisem

Witam
Co prawda nie jestem użytkownikiem Cubase, i wcale sie na nim nie znam, ale wydaje mi sie, że jest to kwestia blokowania dostepu do pliku przez Windows.
Skoro plik jest zaczytany, to Windows traktuje go jako w użyciu i nie pozwala na zmianę, czy nadpisanie.
A spróbuj, w momencie jak dostajesz komunikat z Cubas'a, że nie możesz nadpisać pliku, przejść do folderu który jest dyskiem Atari i chociażby zmienić pod Windowsem nazwę pliku na inną.
Najprawdopodobniej sie tez nie da, gdyż ten plik jest w rozumieniu Windows użyciu.
Z tego co mi się wydaje, to Hatari jako dysk wykorzystuje plikopartycję, a nie fizyczne foldery Windows i dlatego to zjawisko nie występuje.
Tak ja to widzę.  

5

Odp: Steem +Cubase +problemy z zapisem

Nie, w Hatari jest tak samo, że mam folder windowsa jako dysk i tam się normalnie da nadpisać plik, więc to nie Windows przeszkadza.

Naturalnie, że pod Windowsem nie da się zmienić nazwy pliku w czasie kiedy jest on otwarty przez Steem w Cubase. Jednak gdyby nie dało się zapisywać w emulatorze plików otwartych do edycji w jakimś programie, to przecież cały emulator działał by wtedy tylko do odczytu, no to trochę z lekka bez sensu, nie?:-) Z resztą jak w windowsie otworzysz jakiś plik do edycji np. plik tekstowy w notatniku, to możesz go zapisać z powrotem do tego samego pliku. Tak samo powinno być w Steem, czyli otwiera on plik w Windowsie i go zapisuje. Dziwne to wszystko...

Podniosłem jeszcze wersję Steema do najświeższej Steem.SSE.3.9.4.Win32.D3D, ale jest dokładnie tak samo, bez zmian.