OnTopic U-HE Zebra 3 Beta *** Out Now ***

[Plasmatron]

 

[Plasmatron]

Das sind die Osci Mods von Zebra 2. Ob 3 die gleichen besitzt oder teilweise durch neue OSC Modelle redundant wurde ? Heute Abend weiß ich mehr ..

 

[exitLaub]

Anhang anzeigen 272890
Anhang anzeigen 272889

Die Liste sieht in Zebra 3 so aus. Rein zahlenmässig etwas weniger, teilweise andere und neue FX und ich habe gelesen, daß manche der alten FX zu einem zusammengefasst wurden. Die Beschreibungen der FX sind dann ab Seite 36 in der Anleitung.

 

[stuartm]

 

[Inside the Void]

Was sind das denn für Kartoffel-CPU`s in den Dinger ^^

 

[Plasmatron]

Der CPU Burner ist ja mehr ein Hilfeschrei.
Subtext, wir Programmierer brauchen mehr Kontrolle über die Verteilung der CPU Last.

Urs ! Könnte man den Burner zb durch einen Bitcoin Mining Algo ersetzen ? Dann brutzelt das wenigstens nicht ganz umsonst…

Wäre mal interessant, welche DAW damit besser umgeht. Ausgerechnet Reaper hätte ich da mehr Kontrolle zugetraut.

 

[John_Doe]

Dieses Performance-Panel ist keine üble Sache, auch wenn wir denken, wir sind schon so "fortgeschritten" - sind wir nicht.

Eine DAW auf E-Kernen laufen zu lassen ist sowieso Nonsens - und auch wieder nicht, je nachdem wie die CPU damit umgeht (scheinbar nicht gut). Jedoch wird wohl jedes Umspringen auf einen anderen Kern die Performance belasten und Overhead erzeugen. Die gängigsten DAWs nutzen nur P-Kerne. Dumm nur, dass der Trend dahin geht, teilweise mehr E- als P-Kerne zu verbauen.

Unter Win könnte man dieses Problem beim Vorhandensein von E-Kernen mit Processlasso o.ä. lösen.

 

[Inside the Void]

Dieses Performance-Panel ist keine üble Sache, auch wenn wir denken, wir sind schon so "fortgeschritten" - sind wir nicht.

Eine DAW auf E-Kernen laufen zu lassen ist sowieso Nonsens - und auch wieder nicht, je nachdem wie die CPU damit umgeht (scheinbar nicht gut). Jedoch wird wohl jedes Umspringen auf einen anderen Kern die Performance belasten und Overhead erzeugen. Die gängigsten DAWs nutzen nur P-Kerne. Dumm nur, dass der Trend dahin geht, teilweise mehr E- als P-Kerne zu verbauen.

Unter Win könnte man dieses Problem beim Vorhandensein von E-Kernen mit Processlasso o.ä. lösen.

single core performance ist halt sehr wichtig

 

[John_Doe]

Da liegt wahrscheinlich aktuell Apple vorn. Weiß man aber erst konkret, wenn man selbst die Möglichkeit hat 2 identische Setups auf unterschiedlicher Plattform zu vergleichen. Die CPU-Rankings, welche aus synthetischen Benchmarks entstehen, können vielleicht grob eine Idee vermitteln, aber für den speziellen Fall könnte das auch ganz anders aussehen.

Jedoch ist Multi-Core ebenfalls wichtig. Jeder Track wird auf einem Kern berechnet. Darüber hinaus nutzen einzelne VSTs auch Multi-Core. Im Detail wird das alles jedoch nicht so transparent kommuniziert.

 

[Inside the Void]

die aktuellen x3d sind schon extrem stark, Apple ist sehr knapp vorne, wenn es um DAW allgemein geht.... Preis/Leistung weiss ich nicht... Nut Intel kackt Momentan ziemlich ab.
ÜIch zocke halt schon gerne mal ab und zu, deswegen der 9900x3d, da liegt er schon so gegen die 30% vorne, für Adobe AF was ich auch recht viel benutze, ist der Apple wieder ein weinziges stückchen vorne....

 

[roh'signal]

Ziemlich clever... da hat sich jemand Gedanken gemacht. Schon klar, evtl. nicht die perfekte Lösung (kann ich kleiner Wurm ohnehin nicht valide einschätzen)... aber immerhin mal ein neuer Ansatz.

 

[Sulitjelma]

Das sind die Osci Mods von Zebra 2. Ob 3 die gleichen besitzt oder teilweise durch neue OSC Modelle redundant wurde ? Heute Abend weiß ich mehr ..

Der Unterschied war mir auch aufgefallen. Ist die Frage, ob man deshalb weiterhin mit beiden Versionen arbeiten will, oder einem die 3er das meiste abdeckt (neben dem was hier neu ist). Aber stimmt, dann sind da ja noch die Filter....

 

[Inside the Void]

Der Unterschied war mir auch aufgefallen. Ist die Frage, ob man deshalb weiterhin mit beiden Versionen arbeiten will, oder einem die 3er das meiste abdeckt (neben dem was hier neu ist). Aber stimmt, dann sind da ja noch die Filter....

Kommt halt drauf an ob ich die patches in zebra3 nachbauen kann und ob sie auch gleich (gut) klingen, ich hab auf zebra2 sehr viele komplexe presets gespeichert, um die wäre es zu schade, und zebra2 klingt einfach schon exzellent. Ich kam leider immer noch nicht wirklich zum testen, aber das wäre das erste was ich in zebra3 machen würde, mit bisschen mehr zeit....

 

[stuartm]

 

[Cyclotron]

Der CPU Burner ist ja mehr ein Hilfeschrei.
Subtext, wir Programmierer brauchen mehr Kontrolle über die Verteilung der CPU Last.

Urs ! Könnte man den Burner zb durch einen Bitcoin Mining Algo ersetzen ? Dann brutzelt das wenigstens nicht ganz umsonst…

Wäre mal interessant, welche DAW damit besser umgeht. Ausgerechnet Reaper hätte ich da mehr Kontrolle zugetraut.

Reaper überlässt das load balancing dem Betriebssystem, sofern man das nicht in den Einstellungen ändert. Man kann aber schon einiges kontrollieren wie Prioritäten, Auswahl der Kerne oder das verschieben von Threads zwischen den Kernen. Man könnte beispielsweise nur die P-Cores zulassen - sofern man aus rausfindet, welcher Kern P und E ist. Ob das für andere Zwecke als derartige Messungen sinnvoll ist, kann ich nicht beurteilen. Weniger ist meist weniger als mehr....

Das Problem stellt sich mir nach Ansehen des Videos so dar, dass lediglich die ausgelesenen Messwerte nicht vergleichbar sind, weil man nicht klar erkennt, auf welchem Kerntyp das Plugin gerade läuft. Und wenn die Referenz nicht bekannt ist, taugt die Messung nichts. Dann kürzt man seinen Sound ggf. unnötig zusammen weil man glaubt, die Kiste sei schon am Limit. Im Alltag wird man davon eher weniger merken - der Thread mit dem Plugin wird ggf. verschoben, wenn es für einen E-Core zu viel ist. Insofern macht Reaper das schon ganz gut.

 

[Plasmatron]

Ja stimmt, wenn der E Kern von Plugins beladen ist, dann wird das gleiche passieren, als wenn man den E Kern künstlich stresst.. Also einfach genug Instanzen ! :)

 

[John_Doe]

Die einzelnen Kerne der CPU haben i.d.R. eine spezifische Nummer und sind somit eindeutig identifizierbar.

In dem Video macht Urs klar deutlich, dass die 1. Messung auf einem P-Kern läuft und die 2. auf einem E-Kern. Deshalb erzeugt er künstliche CPU-Last um sicherzugehen, dass er sich auf einem P-Kern befindet bzw. dorthin geswitcht wird.

Ich denke, dass das Umschalten eines Kernes für einen Track im laufenden Echtzeit-Betrieb zu Dropouts führen kann.

Mir ist in dem Zusammenhang jedoch nicht klar, wie ein Multicore-Betrieb eines VSTi abläuft. Man kann in einem Audiostream die Dinge wahrscheinlich nicht so einfach parallelisieren.

 

[Cyclotron]

Die einzelnen Kerne der CPU haben i.d.R. eine spezifische Nummer und sind somit eindeutig identifizierbar.

Das schon, aber P und E sind nicht gleichförmig verteilt und der Taskmanager gibt die Info auch nicht her. Aber da wird es sicher ein Tool für geben oder irgendwelche Unterlagen zum Nachlesen.

Ich denke, dass das Umschalten eines Kernes für einen Track im laufenden Echtzeit-Betrieb zu Dropouts führen kann.

Davon habe ich bislang nichts gehört / gelesen, kann es aber mangels eigener Versuche auch nicht ausschließen. Mein 265k für die Musik kommt leider erst im neuen Jahr. Mit ähnlicher Hardware (und insbesondere Reaper drauf) habe ich bislang eher positive Kommentare wahrgenommen.

Es ist aber nicht ungewöhnlich, dass Threads zwischen den Kernen verschoben werden - das wurde schon lange so gemacht, alleine schon aus Gründen des Temperaturmanagements und dauert heute nur ein paar Mikrosekunden.

Ich selbst werde zunächst die Finger von händischen Eingriffen bei der Zuordnung lassen, zumindest bei einem Endbenutzer - OS und so einer hybriden Kernarchitektur.

 

[John_Doe]

Was ein P- und was ein E-Kern ist, könnte man theoretisch mit jedem Tool herausfinden, dass eine definierte Prozessorlast erzeugt. Das sieht man oben im Video am Beispiel des CPU-Burners. Jedoch sollte man vorher den Prozess einem bestimmten Kern zuordnen.

Ich selbst finde es in der Theorie sinnvoller im Musikbereich eine CPU ohne E-Kerne zu nutzen. Wenn es in der Praxis sehr gut funktioniert, ist es ok. Aber Effizienz, Strom sparen, Performance, minimale Latenzen etc. beisst sich ganz gerne im Zusammenhang.
Unter Windows empfehlen scheinbar immer noch einige Hersteller, z.B. Hyperthreading, bei Problemen, abzuschalten. Das ist zwar eigentlich ein anderes Thema aber mit ähnlicher Problemlage.

Man kann solche Dinge ausprobieren. Wenn es eine Verbesserung bringt, ist es ok. Wenn nicht, kann man die Konstellation nochmal verändern oder alles beim Ursprungszustand lassen.

Dass bei herkömmlichen Rechenanwendungen Tasks im Regelfall die Kerne wechseln können ist klar. Aber der Bereich DAW ist sehr speziell. Darauf sind die CPUs, die man als Konsument mitbekommt nicht optimiert und die Komponenten drumherum, die das Ganze auch noch maßgeblich beeinflussen, auch nicht - außer spezielle Hardware, wie z.B. Audiointerfaces. Ja, das spricht quasi für „harte“ Klangerzeuger, aber dort tauchen dann andere Probleme auf.

Am Besten ist‘s wenn’s einfach so läuft. Wenn man jedoch die Grenzen auch mal ausloten will, stößt man zwangsläufig auf diese und die sind gar nicht so weit weg, wie uns das Marketing weissmachen will. Mit der CPU-Leistung stieg auch der Leistungshunger der Anwendungen.

 

[Plasmatron]

Ist am Ende auch egal, da die Last ja verteilt wird und das System eben eine einzelne Instanz als geringe Last erkennt und auf eine E-Kern schiebt, um Strom zu sparen. Was letztendlich nur die Messung einer Instanz interessiert. Wahrscheinlich hätte man den Burner auch einfach weglassen können..

Das einzige was mich jetzt noch interessiert ist, gibt es da eine Zeitvorteil den man messen kann..