Komentowana treść: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
11.02.2009 16:36
[#1]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
Szkoda że się na tym nie znam, bo bym już sobie potestował, a tak poczekam jak będzie jakieś demo...
12.02.2009 00:59
[#5]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
@Grzegorz Kraszewski, post #4
Grzegorzu, przypomnij mi proszę, kiedy i na jakiej imprezie prezentowałeś DBPro 3 w wersji, w której nie było zróżnicowania wysokości dźwięku. A przede wszystkim proszę abyś przypomniał mi link do filmu z tej prezentacji, ponieważ chcę się odnieść do czegoś, co tam było mówione o DBPro3, co dla mnie jako muzyka było bardzo ważne, a jak prace zajdą za daleko, to może być trudno to zmienić.
12.02.2009 06:17
[#6]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
Mam rozumiec, ze DBPro3 jest juz w tak zaawansowanym stadium rozwoju, ze mozna mowic o wersji beta? Przeciez beta (w odroznieniu od alpha) powinna zawierac wszystkie elementy finalnej wersji tylko nieprzetestowane. Sprawy naprawde zaszly juz tak daleko? :)
12.02.2009 06:18
[#7]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
@CJ Warlock, post #5
Z tego, co pamiętam, był to PowerDev Meeting #5 w Chełmie, 6 września 2008. Filmy z imprezy są tutaj, DigiBooster jest na filmie nr 4. Swoją drogą to co mówisz, brzmi bardzo tajemniczo... :). Mogę powiedzieć, że prace zaszły już bardzo daleko, player jest w zasadzie kompletny na przykład.
12.02.2009 06:23
[#8]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
@MDW, post #6
Niezupełnie tak jest. Pojęcie "betatesting" się w dzisiejszych czasach nieco zdewaluowało, bo teraz betatesting robi się na końcowych użytkownikach wersji finalnej... DigiBooster nie zawiera na razie wszystkich elementów. Niemniej potrzebne są testy wydajnościowe playera, warto też wyłapać wcześnie błędy pojawiające się na platformach, do których nie mam bezpośredniego dostępu (klasyki, WinUAE, AmigaOS 4). Chcąc więc być ściśle z terminologią, należałoby to nazwać alphatestingiem.
12.02.2009 06:55
[#9]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
@Grzegorz Kraszewski, post #8
Rozumiem. Właściwie obojętne jak się to nazywa. Ważne, że praca idzie do przodu. Cieszy mnie niezmiernie ten postęp. Tym bardziej, że DBPro to w pełni amigowy produkt a nie jakiś port. Trzymam kciuki!
Dlaczego nie śpisz o tej porze. Ja to rozumiem - właśnie jadę autobusem do "ukochanej" pracy więc mogę być niewyspany. Ale Ty powinieneś spać żeby wypocząć przed kolejnym dniem rozwoju DBPro3.
Ostatnia edycja: 12.02.09 06:58:02
Dlaczego nie śpisz o tej porze. Ja to rozumiem - właśnie jadę autobusem do "ukochanej" pracy więc mogę być niewyspany. Ale Ty powinieneś spać żeby wypocząć przed kolejnym dniem rozwoju DBPro3.
Ostatnia edycja: 12.02.09 06:58:02
12.02.2009 13:29
[#11]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
No, wprawdzie do dyspozycji mam już niestety tylko uła-e, ale skoro i to może być to zaraz się zgłaszam.
13.02.2009 19:55
[#13]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
@CJ Warlock, post #12
Niestety, mimo 3-krotnego obejrzenia prezentacji DBPro3 z PowerDev Meeting 5, nie jestem w stanie stwierdzić, do czego miałem zastrzeżenie, oglądając ją pierwszy raz.
Pamiętam, że chodziło o jakąś zbyt radykalną zmianę działania składnika programu, która mi osobiście by bardzo przeszkadzała, ale teraz nie zauważyłem nic takiego w tej prezentacji.
Czy DBPro3 jest prezentowany na jeszcze jakimś innym filmie?
Pamiętam, że chodziło o jakąś zbyt radykalną zmianę działania składnika programu, która mi osobiście by bardzo przeszkadzała, ale teraz nie zauważyłem nic takiego w tej prezentacji.
Czy DBPro3 jest prezentowany na jeszcze jakimś innym filmie?
13.02.2009 22:17
[#15]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
@Grzegorz Kraszewski, post #14
Nie o to, ale chyba już wiem, o co (jedna z dwóch rzeczy AFAIR).
W DB1.8, DBPro2 i innych trackerach guziki i cały blok guzików mają jakiś stały, zakomponowany ładnie rozmiar. Przypomina mi to ładne GUI programów z peceta, gdzie guziki są graficzne i wkomponowane w jakieś graficzne tło, a nie generowane systemowym API. Mi osobiście pozwala się to tak przyzwyczaić do GUI programu, że aż nauczyć go na pamięć i klikać w zadane miejsca praktycznie bez dokładnego patrzenia (prawdopodobnie ręka czuje ile ruchu myszką wykonała). Kojarzy mi się to z wygodą obsługi.
Dlatego, jeśli by to było możliwe, to wnosiłbym o takie zakomponowanie grup guzików i gadżetów w GUI DBPro3, aby, podobnie jak w DBPro2, guziki miały stałe wielkość i odstęp.
Dopiero odstęp między grupami gadżetów by się zwiększał. Wiem, że to może dla niektórych wyglądać jak marnowanie przestrzeni ekranu, ale naprawdę, liczy się praktyczność obsługi, czyli komfort, a nie wygląd dla wyglądu.
Proponuję skalowanie buttonów i innych możliwych do skalowania gadżetów zrobić opcjonalną, wybieraną przez użytkownika.
Pozwoli to wybrać każdemu to, z czym mu łatwiej pracować.
Nie lubię jak narzędzie zmusza mnie do wykształcenia bardziej skomplikowanych nawyków użytkowania, niż to potrzebne.
Skórka "scene" moim zdaniem ładnie komponuje się z DBPro2, więc cieszę się, że DBPro3 również bedzie można oskórkować.
Czy będzie możliwość ustawienia osobnych tapet dla pól okna programu takich, jak np.pattern editor? W DBPro2 oskórkowany jest cały DBPro prócz pattern editora, w którym tło jest ciemne, jednolite. Prezentowany DBPro3 w fullscreenie wyglądał ładnie, ale czy będzie się dało zasymulować wygląd DBPro2 ze skórką "scene" lub "os2"?
W DB1.8, DBPro2 i innych trackerach guziki i cały blok guzików mają jakiś stały, zakomponowany ładnie rozmiar. Przypomina mi to ładne GUI programów z peceta, gdzie guziki są graficzne i wkomponowane w jakieś graficzne tło, a nie generowane systemowym API. Mi osobiście pozwala się to tak przyzwyczaić do GUI programu, że aż nauczyć go na pamięć i klikać w zadane miejsca praktycznie bez dokładnego patrzenia (prawdopodobnie ręka czuje ile ruchu myszką wykonała). Kojarzy mi się to z wygodą obsługi.
Dlatego, jeśli by to było możliwe, to wnosiłbym o takie zakomponowanie grup guzików i gadżetów w GUI DBPro3, aby, podobnie jak w DBPro2, guziki miały stałe wielkość i odstęp.
Dopiero odstęp między grupami gadżetów by się zwiększał. Wiem, że to może dla niektórych wyglądać jak marnowanie przestrzeni ekranu, ale naprawdę, liczy się praktyczność obsługi, czyli komfort, a nie wygląd dla wyglądu.
Proponuję skalowanie buttonów i innych możliwych do skalowania gadżetów zrobić opcjonalną, wybieraną przez użytkownika.
Pozwoli to wybrać każdemu to, z czym mu łatwiej pracować.
Nie lubię jak narzędzie zmusza mnie do wykształcenia bardziej skomplikowanych nawyków użytkowania, niż to potrzebne.
Skórka "scene" moim zdaniem ładnie komponuje się z DBPro2, więc cieszę się, że DBPro3 również bedzie można oskórkować.
Czy będzie możliwość ustawienia osobnych tapet dla pól okna programu takich, jak np.pattern editor? W DBPro2 oskórkowany jest cały DBPro prócz pattern editora, w którym tło jest ciemne, jednolite. Prezentowany DBPro3 w fullscreenie wyglądał ładnie, ale czy będzie się dało zasymulować wygląd DBPro2 ze skórką "scene" lub "os2"?
13.02.2009 22:47
[#16]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
@CJ Warlock, post #15
W DB1.8, DBPro2 i innych trackerach guziki i cały blok guzików mają jakiś stały, zakomponowany ładnie rozmiar.
A dzieje się tak z prostej przyczyny - GUI DigiBoostera 2.x ma sztywną szerokość. Proponuję odpalić DBPro 2 na ekranie chociażby 1024 x 768. Zonk... Skaluje się tylko w pionie, a nadal masz na ekranie 6 tracków. Na tym samym ekranie DigiBooster3 pokaże 9 ścieżek. Jeszcze bardziej rażąca różnica powstanie przy popularnych obecnie panoramach 1440 x 900 albo 1680 x 1050. Wydaje mi się, że dla muzyka o wiele większym udogodnieniem jest np. 16 czy 20 tracków widocznych jednocześnie na ekranie, niż guziki stałej szerokości...
Dlatego też w GUI będą ostre cięcia, np. blok przycisków "głównych" zostanie ograniczony do jakiegoś 4 x 3. To bez sensu żeby opcje używane raz na sesję z programem, albo rzeczy typu konfiguracja programu, były na przyciskach, od tego jest menu.
Inna sprawa, że to, co widać na screenshotach to jest niewielki procent całego GUI, na pewno jeszcze sporo rzeczy tam przybędzie.
Mi osobiście pozwala się to tak przyzwyczaić do GUI programu, że aż nauczyć go na pamięć i klikać w zadane miejsca praktycznie bez dokładnego patrzenia (prawdopodobnie ręka czuje ile ruchu myszką wykonała).
Jeżeli będziesz uruchamiał DBPro 3 w trybie full screen i jak sądzę zawsze w tej samej rozdzielczości, to elementy GUI będą rozmieszczone zawsze tak samo. Nawet uruchamiając w oknie, możesz zapisać pozycję i rozmiary okna.
Proponuję skalowanie buttonów i innych możliwych do skalowania gadżetów zrobić opcjonalną, wybieraną przez użytkownika.
Wykluczam taką możliwość. Zrobienie takich rzeczy w MUI znacznie skomplikuje kod budowy GUI... Tak jak już napisałem - przy pracy zawsze w tej samej rozdzielczości, wszystkie gadżety będą zawsze w tych samych miejscach co do piksela. MUI jest Magic, ale nie na tyle, żeby automagicznie guziki przestawiać...
Czy będzie możliwość ustawienia osobnych tapet dla pól okna programu takich, jak np.pattern editor? W DBPro2 oskórkowany jest cały DBPro prócz pattern editora, w którym tło jest ciemne, jednolite.
I nie jest tak bez powodu. Wsadzenie tapety w pattern w znacznym stopniu zwiększa obciążenie procesora przy skrolowaniu. To co widać na drugim screenshocie z PowerDev Meeting to zarzucony eksperyment. Kolory elementów patternu (w sumie 17 różnych kolorów) są konfigurowalne.
Prezentowany DBPro3 w fullscreenie wyglądał ładnie, ale czy będzie się dało zasymulować wygląd DBPro2 ze skórką "scene" lub "os2"?
W dużym stopniu jak sądzę. Muszę kiedyś wyrypać te tekstury z kodu 2.x i sprawdzić.
A dzieje się tak z prostej przyczyny - GUI DigiBoostera 2.x ma sztywną szerokość. Proponuję odpalić DBPro 2 na ekranie chociażby 1024 x 768. Zonk... Skaluje się tylko w pionie, a nadal masz na ekranie 6 tracków. Na tym samym ekranie DigiBooster3 pokaże 9 ścieżek. Jeszcze bardziej rażąca różnica powstanie przy popularnych obecnie panoramach 1440 x 900 albo 1680 x 1050. Wydaje mi się, że dla muzyka o wiele większym udogodnieniem jest np. 16 czy 20 tracków widocznych jednocześnie na ekranie, niż guziki stałej szerokości...
Dlatego też w GUI będą ostre cięcia, np. blok przycisków "głównych" zostanie ograniczony do jakiegoś 4 x 3. To bez sensu żeby opcje używane raz na sesję z programem, albo rzeczy typu konfiguracja programu, były na przyciskach, od tego jest menu.
Inna sprawa, że to, co widać na screenshotach to jest niewielki procent całego GUI, na pewno jeszcze sporo rzeczy tam przybędzie.
Mi osobiście pozwala się to tak przyzwyczaić do GUI programu, że aż nauczyć go na pamięć i klikać w zadane miejsca praktycznie bez dokładnego patrzenia (prawdopodobnie ręka czuje ile ruchu myszką wykonała).
Jeżeli będziesz uruchamiał DBPro 3 w trybie full screen i jak sądzę zawsze w tej samej rozdzielczości, to elementy GUI będą rozmieszczone zawsze tak samo. Nawet uruchamiając w oknie, możesz zapisać pozycję i rozmiary okna.
Proponuję skalowanie buttonów i innych możliwych do skalowania gadżetów zrobić opcjonalną, wybieraną przez użytkownika.
Wykluczam taką możliwość. Zrobienie takich rzeczy w MUI znacznie skomplikuje kod budowy GUI... Tak jak już napisałem - przy pracy zawsze w tej samej rozdzielczości, wszystkie gadżety będą zawsze w tych samych miejscach co do piksela. MUI jest Magic, ale nie na tyle, żeby automagicznie guziki przestawiać...
Czy będzie możliwość ustawienia osobnych tapet dla pól okna programu takich, jak np.pattern editor? W DBPro2 oskórkowany jest cały DBPro prócz pattern editora, w którym tło jest ciemne, jednolite.
I nie jest tak bez powodu. Wsadzenie tapety w pattern w znacznym stopniu zwiększa obciążenie procesora przy skrolowaniu. To co widać na drugim screenshocie z PowerDev Meeting to zarzucony eksperyment. Kolory elementów patternu (w sumie 17 różnych kolorów) są konfigurowalne.
Prezentowany DBPro3 w fullscreenie wyglądał ładnie, ale czy będzie się dało zasymulować wygląd DBPro2 ze skórką "scene" lub "os2"?
W dużym stopniu jak sądzę. Muszę kiedyś wyrypać te tekstury z kodu 2.x i sprawdzić.
18.02.2009 17:11
[#17]
Re: APC&TCP poszukuje chętnych do testowania DigiBoostera Pro 3
@Grzegorz Kraszewski, post #16
A dzieje się tak z prostej przyczyny - GUI DigiBoostera 2.x ma sztywną szerokość. (...)
Wiem to doskonale, zauważyłeś chyba nieproporcjonalne wymiary screenshoot-a, jaki przygotowałem. O takich rozmiarach ekran mu stworzyłem i rozciągnąłem na całą szerokość ekranu. Wiem też co to jest MUI i jak się zachowuje. Kurs programowania w MUI w MA, choć nigdy nie programowałem na Amidze, czytałem ze zrozumieniem.
To, co proponowałem, brzmi przecież prosto: zgrupowanie macierzy buttonów stało-wymiarowych po lewej, zmienny w zależności od wielkości okna odstęp, a po prawej zgrupowane te gadżety, które tam przewidziano.
Albo wycentrowane: lewy odstęp, buttony, gadżety, prawy odstęp.
To jest mój pomysł designerski i bynajmniej nie chciałbym, aby był odrzucony tylko ze względu uprzywilejowanej pozycji decyzyjnej szanownego twórcy programu. :) Innymi słowy, też mam coś do powiedzenia, jako 11-letni użytkownik DBPro, a nawet tzw. heavy-user, konstruujący na nim najdziwniejsze kombinacje nutowo-komentowe i grający z 2 sztuk DBPro tzw.live PA na imprezach (czyli test w 2 rożnych warunkach używania).
Twój argument z odpalaniem cały czas w tej samej rozdzielczości jest jak najbardziej prawdziwy.
Nie upieram się przy tym pomyśle na menu, jedynie chciałbym, aby podlegał rozważeniu i dyskusji, a nie z gruntu odrzuceniu.
To bez sensu żeby opcje używane raz na sesję z programem, albo rzeczy typu konfiguracja programu, były na przyciskach, od tego jest menu.
Myślę, że to już praktyczni użytkownicy powinni się wypowiedzieć, które butony są zbędne, które po prostu dobrze, żeby były, a które muszą być.
Dla tych rzeczy, które wypadną z buttonów, przydałoby się, aby oprócz bycia w menu miały skróty klawiszowe. W DBPro2 pamiętam, że niektóre funkcje z menu nie miały skrótów, a przydałyby im się takowe. Jeśli potrzeba mogę później określić, które to dokładnie.
Przychodzi mi na myśl taki przykład: dlaczego wielu muzyków lubi mieć prawdziwy hardware w racku, a nie emulowane efekty? Bo jest im m.in.wygodniej obsłużyć wszystko dostępnymi od ręki gałkami, a nie klikając upierdliwie myszką po gadżetach na ekranie.
Podobnie jest z buttonami menu i skrótami klawiszowymi. Stopień wygody użycia (ergonomii) jest następujący: menu, button, skrót. Włażenie do menu po coś jest najbardziej upierdliwe, posiadanie tego na buttonie gotowego i czekającego na klik jest znacznie wygodniejsze, a skrót klawiszowy jest ciut lepszy (aczkolwiek trzeba się go nauczyć).
Zauważyłem też, że wygodniej sięga się po opcje do jednego typu miejsca, niż do różnych. Jakbym miał porozrzucane opcje po buttonach i menu to bym się znużył używaniem czegoś tak nieergonomicznego. To ma być program użytkowy, czy tor przeszkód?
Myślę, że kryterium doboru i zgrupowania funkcji na buttonach powinna być ich wspólna filozofia działania i sugestie podniesione w debacie użytkowników.
Przykładowo, jeśli mam ciąg buttonów od odgrywania/nagrywania patternu, to dlaczego miałbym po funkcję np."record" sięgać wyjątkowo do menu, skoro jest to element jednej grupy funkcji? A niech i stoi sobie i ładnie wygląda, ale ma być pod ręką. Ktoś go użyje raz na sesję, ktoś inny akurat może być w specyficznej potrzebie użycia wielokrotnie. A nóż taka się trafi. I co, ma się wtedy rozdrabniać na wybór funkcji z buttonów i menu?
(tapeta w pattern editorze)
Spoko, jak dla mnie może jej nie być, byle by były linie podziału takie, jak w DBPro2, lub dość zbliżone.
