Paradoksalnie, z czasem te problemy rozwiązują się same. Robi się to poprzez zmiany generacyjne procesorów CPU. Stary niezoptymalizowany software działa szybciej na nowszych procesorach co po przekroczeniu pewnego pułapu wydajności nie ma znaczenia dla większości użytkowników. Powoli dochodziny do tego momentu w świecie komputerów. Przynajmniej jeśli chodzi o programy DAW. Naturalnym ograniczeniem jest muzyka, która jest naturalnie ograniczona ilością ścieżek. Nie tak jak w grafice 3D, że zawsze można wykorzystywać moc do szybszego renderu w czasie rzeczywistym. W audio to tak nie działa, wykorzystywane jest tylko tyle ile potrzeba.
Thanks Anton. As I made more detailed research in terms of Asio Guard, I found that ASIO Guard was active (normal lvl). So my table shows wrong info. Cubase did not work on 512 ASIO, it worked on higher secured buffer (So with no AG, Cubase reaches significantly lower results). In my new video, I will correct that info and I will add results for non-AG mode, and AG modes levels separately.
@@OZD_Official If you want to switch off ASIO Guard for testing, then you should switch Samplitude VIP-Biffer to minimal value. Because VIP-buffer do the same thing (in a different ways of course). And Studio One have some kind of built-in "ASIO Guard" feature, but they didn't make ON/OFF option. Don't know about Reaper and Ableton. So your testing becomes a little more complicated)
Hi. I found your comment right now. In Samplitude, no VIP buffer was used. There was ASIO 512 sample buffer in this test. Same for rest DAWs. If extra buffer were used, there is note in the table. Exception is a Cubase. It worked with extra buffer called ASIO Guard, which is my oversight and there is no note about that. With no ASIO Guard result for Cubase would be significantly lower. I will make new test with all this details included. ✌️
I did a test today with just one vst instrument playing two notes and the than duplicate the tracks. I had the best result with cubase but the UI gets sluggish with more tracks. In reaper and studio one the sound sound of the tracks started phasing with more tracks.
Dlaczego nie sprawdziłeś Pro Toolsa w pełnej wersji po prostu jako demo? To duża strata. Wszystkie użyte wtyczki użyłbyś w PT, bo mają swoje wersje AAX. To jest istotna sprawa, bo ponoć ich silnik AAX64 pracuje dużo lepiej od standardu VST, tym się kiedyś mocno chwalili i pamiętam, że znajomy sam to potwierdzał już nawet porównując pracę do RTAS. Zrób taki film jeszcze z tymi samymi wtyczkami i sesją, które tu użyłeś, ale w Pro Tools. Na pewno sporo luda także chce się dowiedzieć, jak on wypadnie vs konkurencja. :)
Jak tylko będzie czas, na pewno taki test zrobię. Sam jestem ciekaw efektów. Niemniej takie testy wymagają dużo czasu i przygotowań. Z pewnością wrócę z tematem.
Hi. Thanks for comment. The 44.1 that is visible is only active for video take recordings with commentary. Because capturing software does not accept changing clock during recordings. All tests were made before video recordings with 96k, with no other, CPU's loading app in background.
Świetny test, ale niekompletny :) Zabrakło tutaj bowiem informacji dlaczego niektóre DAW - w tym teście Live i Bitwig - nie mają podwójnego bufora? Otóż jest to świadoma decyzja deweloperów, wynikająca ze specyfiki tych DAW. Jeżeli DAW używa podwójnego bufora, to ten "większy" bufor jest stosowany do ścieżek, które nie są uzbrojone do nagwyania ("record armed"). W praktyce taki DAW przed rozpoczęciem odtwarzania i w "wolnych chwilach" przelicza sobie audio z tych ścieżek do przodu, bo tam się nic nie może zmienić. Natomiast w takim np. Bitwig-u jest wiele elementów, które mogą zmienić to co jest odtwarzane: - clip launcher może zmienić kompletnie i w dowolnej chwili aranżację na pojedynczych ścieżkach lub na całym projekcie, niezależnie od tego czy ścieżki są uzbrojone do nagrywania czy nie; w tym może się to odbywać losowo (tzw. "next actions") - parametry natywnych urządzeń i wtyczek innych deweloperów mogą być zmieniane za pomocą modulatorów (obwiednie ADSR, LFO, sekwencery krokowe, MSEG, fomuły matematyczne, kluczowanie z audio i MIDI, itp), z których bardzo wiele jest losowych i/lub zależnych od stanu innych modulatorów, sygnałów MIDI i audio również z innych ścieżek - ww. modulatory w Bitwigu chodzą w częstotliwości audio projektu, w tym wiele z nich może śledzić nuty MIDI co umożliwia np. modulację cześtotliwościową filtra (filter FM) czy dowolnego innego parametru, który ma sens (lub nie ma, ale fajnie brzmi :D) - jest cała masa natywnych urządzeń, które w sposób stochastyczny uwalniają MIDI i sample audio, co jest idealne do muzyki generatywnej i/lub deterministycznej (np. jakaś nuta się pojawia losowo, ale jej stan determinuje kolejną sekwencję) - w wersji 5 (obecnie w becie) pojawiły się modulatory działające na poziomie całego projektu, które np. mogą zmieniać wysyłki czy ...tempo projektu To wszystko powoduje, że wdrożenie podwójnego bufora w DAW takim jak Bitwig jest bardzo trudne, o ile w ogóle możliwe. Oczywiście ktoś może powiedzieć, że jeżeli w Bitwig-u nie korzysta z clip launchera, z modulatorów, z losowych narzędzi do wyzwalania audio i MIDI to powinien mieć taką samą wydajność jak Reaper czy Cubase. Ale 1) zapewne trudno jest śledzić które i ile z tych funkcji dany projekt wykorzystuje i dynamicznie modyfikować silnik audio i - co ważniejsze - 2) jeżeli ktoś nie używa tych rzeczy, to nie wiem po co używa Bitwig-a. Tradycyjne DAW-y są o wiele lepsze do liniowej, powtarzalnej (w sensie zawsze brzmiącej tak samo) muzyki ;) :D A co do słabego wyniku Live'a - to tu niestety pokutuje dodatkowo baza kodu sprzed 20+ lat oraz połączenie z Max For Live, który jest potężny, ale bardzo CPU-chłonny. Robiłem kiedyś prosty test, z którego mi wyszło że zwykłe LFO z sinusoidą w Live zjada mniej więcej tyle CPU, co 30-40 LFO w Bitwigu.
Dziękuję Ci za ten informatywny komentarz. Mój test jest prosty, nie ruszający specyfiki jednego programu DAW. Nie włączyłem nawet automatyki. Chciałem sprawdzić czy tak proste ścieżki audio/MIDI wykażą różnicę generowane w różnych hostach. I jak się okazuje, nawet bez złożonych układów te różnice są. W przyszłości zrobię bardziej zaawansowany projekt, podobny tradycyjnej piosenki z mixem. Jestem ciekaw czy procentowe poziomy różnić zostaną zachowane lub w jakim stopniu się zmienią. Pozdrowienia :)
@@OZD_Official Spoko. To nie miała być krytyka, tylko uzupełnienie informacji przez dodanie kontekstu. Uwierz mi, że wiele osób na codzień używających Bitwig-a czy Live-a nie rozumie tych niuansów (bo w sumie nie musi). Świetny test i wideo :)
@@Artek604 Zgadza się. Zauważyłem, że większość użytkowników nie interesuje się kwestiami technicznymi, które stoją za wydajnością danego programu. Jest to domena raczej starych wyjadaczy, którzy wraz z rozwojem technologii uczyli się jej od podstaw. Ta wiedza naprawdę czasami się przydaje, aby poprawnie skonfigurować sobie narzędzia do pracy. Dzięki za cenne komentarze.
One more thing: if you want to do retest, please, show every DAW's internal preferences (internal buffers and so on), show plugin's preferences (multithreading on/off). Without this data on video, there are wide field for mistakes and manipulations (of course i did not blame you for anything right now) Thanxx, regardless.
Thanks for watching. Your suggestion is resonable and easy to realise. In next tests I will include setup screens to make them more informative and transparent. I did the tests with no favorisung any of DAW .
Dziękujemy za te badania. To naprawdę interesujące, że tak doświadczeni wydawcy aplikacji nie poprawili jeszcze swojej optymalizacji. Дякую !
Paradoksalnie, z czasem te problemy rozwiązują się same. Robi się to poprzez zmiany generacyjne procesorów CPU. Stary niezoptymalizowany software działa szybciej na nowszych procesorach co po przekroczeniu pewnego pułapu wydajności nie ma znaczenia dla większości użytkowników. Powoli dochodziny do tego momentu w świecie komputerów. Przynajmniej jeśli chodzi o programy DAW. Naturalnym ograniczeniem jest muzyka, która jest naturalnie ograniczona ilością ścieżek. Nie tak jak w grafice 3D, że zawsze można wykorzystywać moc do szybszego renderu w czasie rzeczywistym. W audio to tak nie działa, wykorzystywane jest tylko tyle ile potrzeba.
Kurde odkryłem Twój kanał święte filmy robisz !
Cieszę się bardzo. Zapraszam ponownie: )
❤ Nice test!! Thanks for taking the time and effort to explain the test!! Very useful information!
Thank you for watching :)
Kolejny świetny materiał Lukas. Temat mega interesujący. Czekam na kolejne filmy.
Great presentation.
Thanks ✌️
1,5 tempa i bardzo fajnie sie ogląda
😛👌
Was the Asio Guard switched on in Cubase? It's similar to Anticipate Processing, VIP Buffer, etc...
Thanks Anton. As I made more detailed research in terms of Asio Guard, I found that ASIO Guard was active (normal lvl). So my table shows wrong info. Cubase did not work on 512 ASIO, it worked on higher secured buffer (So with no AG, Cubase reaches significantly lower results). In my new video, I will correct that info and I will add results for non-AG mode, and AG modes levels separately.
@@OZD_Official If you want to switch off ASIO Guard for testing, then you should switch Samplitude VIP-Biffer to minimal value. Because VIP-buffer do the same thing (in a different ways of course). And Studio One have some kind of built-in "ASIO Guard" feature, but they didn't make ON/OFF option.
Don't know about Reaper and Ableton.
So your testing becomes a little more complicated)
Hi. I found your comment right now. In Samplitude, no VIP buffer was used. There was ASIO 512 sample buffer in this test. Same for rest DAWs. If extra buffer were used, there is note in the table. Exception is a Cubase. It worked with extra buffer called ASIO Guard, which is my oversight and there is no note about that. With no ASIO Guard result for Cubase would be significantly lower. I will make new test with all this details included. ✌️
I did a test today with just one vst instrument playing two notes and the than duplicate the tracks. I had the best result with cubase but the UI gets sluggish with more tracks. In reaper and studio one the sound sound of the tracks started phasing with more tracks.
Cubase has several levels of ASIO Guard, so could you check what lvl have you selected? My test was at default settings - normal.
Dlaczego nie sprawdziłeś Pro Toolsa w pełnej wersji po prostu jako demo? To duża strata. Wszystkie użyte wtyczki użyłbyś w PT, bo mają swoje wersje AAX. To jest istotna sprawa, bo ponoć ich silnik AAX64 pracuje dużo lepiej od standardu VST, tym się kiedyś mocno chwalili i pamiętam, że znajomy sam to potwierdzał już nawet porównując pracę do RTAS. Zrób taki film jeszcze z tymi samymi wtyczkami i sesją, które tu użyłeś, ale w Pro Tools. Na pewno sporo luda także chce się dowiedzieć, jak on wypadnie vs konkurencja. :)
Jak tylko będzie czas, na pewno taki test zrobię. Sam jestem ciekaw efektów. Niemniej takie testy wymagają dużo czasu i przygotowań. Z pewnością wrócę z tematem.
@@OZD_Official też czekam
Hey man in the sampltude example I see 44.1 at the top, is that supposed to be like that?
Hi. Thanks for comment. The 44.1 that is visible is only active for video take recordings with commentary. Because capturing software does not accept changing clock during recordings. All tests were made before video recordings with 96k, with no other, CPU's loading app in background.
Świetny test, ale niekompletny :)
Zabrakło tutaj bowiem informacji dlaczego niektóre DAW - w tym teście Live i Bitwig - nie mają podwójnego bufora? Otóż jest to świadoma decyzja deweloperów, wynikająca ze specyfiki tych DAW. Jeżeli DAW używa podwójnego bufora, to ten "większy" bufor jest stosowany do ścieżek, które nie są uzbrojone do nagwyania ("record armed"). W praktyce taki DAW przed rozpoczęciem odtwarzania i w "wolnych chwilach" przelicza sobie audio z tych ścieżek do przodu, bo tam się nic nie może zmienić.
Natomiast w takim np. Bitwig-u jest wiele elementów, które mogą zmienić to co jest odtwarzane:
- clip launcher może zmienić kompletnie i w dowolnej chwili aranżację na pojedynczych ścieżkach lub na całym projekcie, niezależnie od tego czy ścieżki są uzbrojone do nagrywania czy nie; w tym może się to odbywać losowo (tzw. "next actions")
- parametry natywnych urządzeń i wtyczek innych deweloperów mogą być zmieniane za pomocą modulatorów (obwiednie ADSR, LFO, sekwencery krokowe, MSEG, fomuły matematyczne, kluczowanie z audio i MIDI, itp), z których bardzo wiele jest losowych i/lub zależnych od stanu innych modulatorów, sygnałów MIDI i audio również z innych ścieżek
- ww. modulatory w Bitwigu chodzą w częstotliwości audio projektu, w tym wiele z nich może śledzić nuty MIDI co umożliwia np. modulację cześtotliwościową filtra (filter FM) czy dowolnego innego parametru, który ma sens (lub nie ma, ale fajnie brzmi :D)
- jest cała masa natywnych urządzeń, które w sposób stochastyczny uwalniają MIDI i sample audio, co jest idealne do muzyki generatywnej i/lub deterministycznej (np. jakaś nuta się pojawia losowo, ale jej stan determinuje kolejną sekwencję)
- w wersji 5 (obecnie w becie) pojawiły się modulatory działające na poziomie całego projektu, które np. mogą zmieniać wysyłki czy ...tempo projektu
To wszystko powoduje, że wdrożenie podwójnego bufora w DAW takim jak Bitwig jest bardzo trudne, o ile w ogóle możliwe. Oczywiście ktoś może powiedzieć, że jeżeli w Bitwig-u nie korzysta z clip launchera, z modulatorów, z losowych narzędzi do wyzwalania audio i MIDI to powinien mieć taką samą wydajność jak Reaper czy Cubase. Ale 1) zapewne trudno jest śledzić które i ile z tych funkcji dany projekt wykorzystuje i dynamicznie modyfikować silnik audio i - co ważniejsze - 2) jeżeli ktoś nie używa tych rzeczy, to nie wiem po co używa Bitwig-a. Tradycyjne DAW-y są o wiele lepsze do liniowej, powtarzalnej (w sensie zawsze brzmiącej tak samo) muzyki ;) :D
A co do słabego wyniku Live'a - to tu niestety pokutuje dodatkowo baza kodu sprzed 20+ lat oraz połączenie z Max For Live, który jest potężny, ale bardzo CPU-chłonny. Robiłem kiedyś prosty test, z którego mi wyszło że zwykłe LFO z sinusoidą w Live zjada mniej więcej tyle CPU, co 30-40 LFO w Bitwigu.
Dziękuję Ci za ten informatywny komentarz. Mój test jest prosty, nie ruszający specyfiki jednego programu DAW. Nie włączyłem nawet automatyki. Chciałem sprawdzić czy tak proste ścieżki audio/MIDI wykażą różnicę generowane w różnych hostach. I jak się okazuje, nawet bez złożonych układów te różnice są. W przyszłości zrobię bardziej zaawansowany projekt, podobny tradycyjnej piosenki z mixem. Jestem ciekaw czy procentowe poziomy różnić zostaną zachowane lub w jakim stopniu się zmienią. Pozdrowienia :)
@@OZD_Official Spoko. To nie miała być krytyka, tylko uzupełnienie informacji przez dodanie kontekstu. Uwierz mi, że wiele osób na codzień używających Bitwig-a czy Live-a nie rozumie tych niuansów (bo w sumie nie musi).
Świetny test i wideo :)
@@Artek604 Zgadza się. Zauważyłem, że większość użytkowników nie interesuje się kwestiami technicznymi, które stoją za wydajnością danego programu. Jest to domena raczej starych wyjadaczy, którzy wraz z rozwojem technologii uczyli się jej od podstaw. Ta wiedza naprawdę czasami się przydaje, aby poprawnie skonfigurować sobie narzędzia do pracy. Dzięki za cenne komentarze.
One more thing: if you want to do retest, please, show every DAW's internal preferences (internal buffers and so on), show plugin's preferences (multithreading on/off). Without this data on video, there are wide field for mistakes and manipulations (of course i did not blame you for anything right now)
Thanxx, regardless.
Thanks for watching. Your suggestion is resonable and easy to realise. In next tests I will include setup screens to make them more informative and transparent. I did the tests with no favorisung any of DAW .