Search found 7 matches

Return

TIPP: Alte Steinberg (Wizoo)VST auf Win7 64bit installieren

Hallo an Alle,
da ich Heute wiedermal mein neues Muse-Notebook mit Cubase & co. installieren mußte,
nehme ich dieses gleich mal zum Anlaß die Hürden mit den alten Steinberg VST zu meistern.

Leider gibt es von Steinberg selber ja keine Unterstützung für diese alten VST´s :evil:

Wie immer kam beim installieren wieder gemeckere (Originale CD nicht gefunden usw.) und
das zusammengesuche bei Google ist auch nicht immer einfach, da die meisten Threads nicht zu Ende gedacht sind. :-((

So hier meine Ergebnisse : Win 7 , 64 Bit , Cubase 7

Groove Agent 1:

Cd öffnen dann die Autorun.exe im Programmkompatilitäts Modus "Windows XP (Servicepack 2) " sowie mit Adminrechten starten.
wenn alles installiert ist die GrooveAgent.dll mit Jbridger in den "passenden Steinberg 64bit Ordner kopieren "
-> läuft ohne Probleme

Virtual Guitarist 1:

Cd öffnen dann die Autorun.exe im Programmkompatilitäts Modus "Windows XP (Servicepack 3) " sowie mit Adminrechten starten.
wenn alles installiert ist die VirtualAcusticGuitar.dll sowie die VirtualElectricGuitar.dll mit Jbridger in den "passenden Steinberg 64bit Ordner kopieren "
-> laufen beide ohne Probleme

EDIT01->
Xphraze:
Wie ein Wunder lief der Installer ohne Probleme durch und Xphraze lief auch ohne Probleme.
Habe aber Xphraze vorsichtshalber mit Jbridger in den "passenden Steinberg 64bit Ordner kopiert "


Wird noch weiter Aktualisiert :-) habe noch "Hypersonic2" sowie "The Grand 2" ( beide laufen in 64bit/Cubase 7 auf dem alten Rechner)
------------------------------------------------------------------------------------------------------------------------------------
Falls jemand schon andere alte Steinberg (z.b.:Virtual Guitarist 2/Groove Agent 2 usw.) Vst´s auf Win7/Win8 64bit installiert hat, bitte hierrein :-)
by Crincy
Sun Nov 03, 2013 7:37 pm
 
Jump to forum
Jump to topic

Re: Logical Editor: Goa Bassline Macro

P A T, Super Danke!!!

hab jetzt unter anderen ein Shortcut auf das Macro gelegt was das macht wie Du es mir oben beschrieben hast. Funktioniert pipfein:)

Hier die Einzelschritte:
8tel bass to trippel bass.png


Schade das man nur Funktionen im Macro verwenden kann, die einen Tastenkürzel zugewiesen sind, die volle Tastenverschwendung...


Wenn man aus einer "0815 8tel Bassline" eine "double Bassline" machen will braucht man nur:
LocalEditor: Längen auf 32tel setzen (siehe Bild dieser Post)
LogicalEditor: Einfügen eine 16tel Später (siehe Bild3.png im 3. Post)


Sorry Pat das ich solange gebraucht habe es zu kapieren...


Eine Frage hätt ich noch:
Kann man jetzt aus der "tripple Bassline" wieder eine "normale 0815 8tel Bassline" zaubern?

Also.
1.Note weg; 2.Note bleibt; 3Note weg;
4.Note weg; 5.bleibt; 6.Note weg
u.s.w. = weg; bleibt, weg, weg, bleibt, weg, weg, bleibt, weg, weg, bleibt, weg, weg bleibt, weg usw...


Danke!!!


Lg, und wünsche Dir auch eine wunderschöne angenehme Woche. =)




PS: Wer sich fragt wo solche Basslines oft vorkommen b.z.w. keinen Goa-Trance kennt: (i.d.R. wird man der Bassline noch ein/mehrere Muster geben [einzelne Noten verschieben], aber fetzt auch schon so...)
http://www.youtube.com/watch?v=B__Dtk0aCpI
http://www.youtube.com/watch?v=qqDI1V5RQ88
http://www.youtube.com/watch?v=XfyO4YjK4EQ
by synthefreak
Mon Jan 13, 2014 12:27 am
 
Jump to forum
Jump to topic

Home Mastering mit Cubase

Mastering ist wahrscheinlich einer der am häufigsten missverstandenen Arbeitsschritte in der Musikproduktion. Viele denken da nur an Loudness-Anhebung. Aber das ist nur ein kleiner und nicht einmal der wichtigste Teil des Arbeitsprozesses. Während es beim Mixen um einen Song geht, um die richtige und am besten klingende Balance zwischen den Klanganteilen, geht es beim Mastern um ein ganzes Album, um die beste Balance zwischen den einzelnen Tracks des Albums. Kann man als Musiker selber mastern? Jedenfalls ist dazu eine intensive Einarbeitung in die Materie nötig.

Ich habe dazu ein umfangreiches dreiteiliges E-Book geschrieben, das Ihr kostenlos auf meiner Website herunterladen könnt:
http://www.rolanders-home.de/homerecording_neu.php

Dazu arbeite ich gerade an einer Serie von Videos , die das E-Book anschaulich unterstützen sollen. Dazu habe ich einen neuen Youtube-Kanal eingerichtet:
https://www.youtube.com/user/HomeMastering/

Das erste Video ist schon online, das zweite lade ich gerade hoch. Weitere folgen in Kürze.
by Rolander
Sun Sep 07, 2014 11:56 am
 
Jump to forum
Jump to topic

Re: Einstellung/Farbe der Automationslinie

Gibt's leider nicht. Man kann aber mittels Ctrl + Mausrad (im Projektfenster) die Farben der Automationstracks flugs verändern, wenn's mal an Sichtbarkeit mangelt.
by marQs
Mon Sep 08, 2014 6:14 am
 
Jump to forum
Jump to topic

Von Latenz, Cores, Multithreading und SMT (Hyperthreading)

Da ich krank bin, im Bett liege und ich mich gerne ablenken möchte, schreibe ich mal zusammen, was ich über diese Themen weiß.

Vorab meine Qualifikation: ich bin Softwarearchitekt und seit 2001 als Entwickler tätig, hab mich in meiner Jugend exzessiv mit x86 auseinandergesetzt (Sound- und Grafikdemoszene, falls das jemandem hier etwas sagt). Programmiere heute hauptberuflich in C#, privat auch noch in C++, Ruby und x86-Assembler.

Ich schreibe das hier deshalb, weil ich damit ausdrücken möchte, daß das nicht irgendwelche "Spinnereien" oder "Halbwissen" darstellt, sondern durchwegs auf Fakten und, wo angegeben, "educated guesses" basiert.

Threads, Cores und Scheduling

Grundsätzlich ist es so, daß Windows SELBST das Konzept des "Threads" kennt, das ist tief in der sogenannten "Win32" (heute halt "Win64") API verankert. Windows macht das grundsätzlich so, daß neu gestartete Threads auf jene Cores verteilt werden, die gerade am wenigstens zu tun haben.

Die Messung dazu basiert, wie übrigens ÄHNLICH (nicht identisch - bei DAWs ist da eine Besonderheit dabei, auf die ich später eingehen werde) auch bei Cubase, auf der Zeit, die einem Kern zwischen "Kontextwechseln" (das ist, wenn ein Kern von einem zugewiesenen Thread zum nächsten Thread schaltet) übrig bleibt. Meines Wissens nach wird das bei Windows über einen bestimmten Zeitraum ermittelt.

Nehmen wir also z.B. einen Dualcore-Prozessor her, ohne HT (um es einfacher zu halten).

Core 0 hat 70% Last, Core 1 hat 10% Last.

Kommt nun ein Thread dazu, dann wird dieser neue Thread zuerst Core 1 zugewiesen, weil ja Core 0 ohnehin schon recht tüchtig am werken ist.

Cubase, so wie die meisten DAWs wohl, erzeugt nun für jede Spur sinnvollerweise (das hätte ich exakt auch so programmiert) einen eigenen Thread. Die Zuteilung zu Cores erfolgt standardmäßig von Windows her durch den Windows-Scheduler, es ist aber auch möglich, über die sogenannte "ThreadAffinityMask" (so heißt das Konzept in der Windows-API), Threads durch das Programm zu "schedulen".

(Scheduling = Threads einerseits auf die Cores zu verteilen und andererseits, diese auch "reihum" mit Rechenzeit zu versorgen. Ein Thread kann auch, durch sogenanntes "Yielding", selbst sagen: "herst, ich bin fertig für den Moment, ich gebe freiwillig den Rest meiner mir zustehenden Rechenzeit ab". Lustigerweise hieß die Methode in der Windows-API früher auch so. Nämlich "Yield()". Heute nimmt man eher "Sleep()" dafür.)

Wie bereits angedeutet erfolgt die Zuweisung von Rechenzeit an Threads "reihum", das heißt, daß mehrmals pro Sekunde zwischen den Threads pro Core umgeschalten wird. Das geht so schnell, daß der Benutzer (und auch der Programmierer in vielen Fällen) den Eindruck hat, daß die Threads nicht nur über Cores hinweg (dort ist es ja der Fall), sondern auch pro Core (dort wird umgeschalten) tatsächlich parallel laufen.

Die ASIO-Auslastung, die Spursynchronisation, die Divergenz zur CPU-Auslastung - und warum niedrige Latenzen übermäßig Rechenzeit fressen

Das ist ein happigeres Thema, weil hier viele Mißverständnisse vorliegen und viel Viertel- und (im Optimalfall oft) Halbwissen herangezogen werden, um ein Urteil zu bilden - und mir als Entwickler stellts dann manchmal die Haare auf, wenn ich die vielen Vermutungen lese (ist nicht böse gemeint, aber manchmal ist es wirklich schauderhaft).

Grundsätzlich zeigt die ASIO-Auslastung an, wieviel Zeit von der Zeit, die zur Berechnung eines gesamten Playbackbuffers zur Verfügung steht, tatsächlich gebraucht wird.

Rechenbeispiel:

Latenz = 10ms

Berechnungen für alle VSTis, etc... benötigen pro 10ms-Buffer 5ms ergibt eine ASIO-Auslastung von 50%.

Das wäre ja einfach. :-)

Aber:

Es gibt Abhängigkeiten. Sends, Gruppen, Sidechains. Hier muß synchronisiert werden.

Ein Beispiel:

Zwei Spuren + 1 Send.

Spur 1 braucht 1 ms, Spur 2 braucht 2 ms, beide senden auch zum Send.

Das bedeutet aber, daß der Send erst nach 2 ms überhaupt mit der Berechnung des, z.B., Halls beginnen kann. Vorher ists da zappenduster, weil der ja auf die Datenpakete der anderen beiden Threads warten muß (das nennen wir Entwickler übrigens "Threadsynchronisation", bzw. ist das das Teilgebiet "Threadkommunikation", das damit untrennbar verbunden ist).

Ist jetzt der Core, der mit dem Send beschäftigt ist, ansonsten unterbeschäftigt, dann kann es sein, daß hier sogar die ASIO-Auslastung gar nicht steigt, wenn auf diesem Core ein anderer Thread hinzukäme, weil der nur den freien Zeitslot der ersten 2 ms vor Einsetzen der Hallberechnung nutzen könnte.

Somit aber kann es sein, daß der Taskmanager unter Windows nur, hm, 10% CPU-Last anzeigt, die ASIO-Auslastung aber bereits bei 50% liegt, weil da eben, durch die Synchronisation bedingt, Rechenzeit brach liegt.

Warum aber brauchen nun niedrigere Latenzen mehr Rechenleistung?

Das hat folgende Gründe (ich HOFFE, die Liste ist erschöpfend, bin mir da aber nicht zu 100% sicher):

1. Kontextwechsel (umschalten zwischen Threads) kosten Zeit durch Umladen der CPU-Register, Cache-Thrashing, etc... (früher sprach man auch noch vom hierzu nötigen Interrupt, aber heute lacht man über die paar Clockcycles, nebenbei bemerkt - die Pipeline des Cores muß auch neu befüllt werden, das ist aber nicht so schlimm, weil das eigentlich nur einem Branch Prediction-Miss entspricht, der zwar auch ungünstig, aber "zu überleben" ist)
2. Manche (nicht alle) DSP-Algorithmen sind effizienter, wenn sie "durchgehalten" werden über größere Datenblöcke (wegen der Rechenzeit, die für die Initialisierung der Berechnung eines neuen Datenblocks benötigt wird)
3. Der Sychronisationsaufwand steigt, wenn häufiger sychronisiert werden muß
4. Unter bestimmten Umständen kann (muß aber nicht) auch die Kommunikationsinitialisierung mit der Audiohardware Rechenzeit fressen (da sind RME ziemlich vorn, die haben einfach ASIO direkt in die Hardware implementiert, was ich ziemlich leiwand finde, ich werde auch nie wieder was anderes kaufen)

SMT (Hyperthreading)

Was macht jetzt also Hyperthreading?

Nun, es ist so, daß der limitierende Faktor bei heutigen CPUs (pipelined, "superskalar", RISCish, etc...), was die Ausführungseffizienz betrifft, eher auf der Seite des "architectural state" als bei den tatsächlich befehlsausführenden Einheiten zu suchen ist.

Soll heißen:

So eine CPU kann ur schnell z.B. multiplizieren - auch mehrere Multiplikationen auf einmal (das nannte man früher "superskalare Architektur"), aber die "Anlieferung" der CPU-Befehle und der innere Zustand der CPU (Register, Pipeline) sind hier limitierend.

Um jetzt die Ausführungseinheiten (z.B. eben so eine Multiplikatorschaltung) besser auszulasten, tut die CPU so, als wäre da nicht 1 Core, sondern gleich 2 Cores, wo in der Realität aber nur 1 Core vorhanden ist (der "architectural state" ist also 2x vorhanden, die Ausführungseinheiten bleiben aber gleich von der Zahl her).

Somit schaut eine 2-Core-CPU wie eine 4-Core-CPU aus.

Natürlich kann man damit nicht die volle Leistung einer mit doppelt sovielen echten Cores ausgestatteten CPU erreichen, aber man kann die Ausführungseinheiten besser auslasten (die stehen dann nicht einfach nur mit Zigarette und Bierflasche herum, sondern hackeln wirklich was) und so einiges an Leistung rausholen.

FRÜHER (!) war das ineffizient umgesetzt, sowohl im Betriebssystem (die frühen Scheduler kannten den Unterschied zwischen "echten" und "simulierten" Cores nicht und haben nicht darauf Rücksicht genommen, heutige Scheduler tun das aber), als auch in der CPU - darum war, in der PC-Bronzezeit (Mitte der Nullerjahre), Cubase OHNE HT besser dran.

Aber mit den heutigen Sandy Bridges, etc... ist das alles kein Thema mehr. Da würde ich eher mal ausprobieren, wie sich die eigenen Projekte mit HT verhalten. Bei MIR ists MIT HT wesentlich besser, aber das liegt wohl definitiv an der Projektstruktur.
by TheNavigator
Wed Sep 17, 2014 9:40 am
 
Jump to forum
Jump to topic

Re: Quick Control (Quellparameter finden)

Andreas, Danke für die Info.
Ich hatte das Handbuch schon durchgeschaut und bin daher auf die Frage gestoßen. Dort sehe ich schön wie ich einen Quick Control einrichte. Leider ist das zurückfinden zum eigentlichen Parameter ein Herumsuchen.

Das Beispiel oben ist evtl. kompliziert, weil man wissen muss, dass das M dort Modulationsmatrix bedeutet.
Gibt es noch andere Kurzzeichen die man wissen sollte?
Sonst wenn man einzelne Drehregler oder Zahlenfelder zuweist kann man sich leichter zurückhanteln.
Trotzdem ist es kompliziert und unlogisch.

Beispiel:
Wenn im Quick Control Assignment der Parameter "MegaTrig: ConditionLine1.Operator" steht muss man wissen, dass es sich dabei im MegaTrig links oben um den zweiten AND/OR Operator handelt. (nicht um den ersten)
Vermutlich werde ich diesen Parameter nie auf einen QC legen, aber es zeigt wie kompliziert das zurückfinden von QC zum Quellparameter eigentlich ist. Als früherer Softwareentwickler weiß ich, dass Array-Variablen mit 0 beginnen, aber ein "normaler" Anwender wundert sich, dass Line1 die zweite Zeile ist. Das Zurückfinden bleibt daher leider immer ein Suchen und ein Herumprobieren ob man wohl den richtigen Parameter gefunden hat.

Nochmal Danke für deine Info! Jetzt blick ich schon etwas besser durch. :-)
lg Wolfgang
by Wolf359
Tue Nov 11, 2014 1:57 pm
 
Jump to forum
Jump to topic

Re: Halion5: Unterschied Auron Trium Voltage

mein hochgehen wurde durch folgende Zitate von Euch beiden ausgelöst:
Wolf359 schrieb:
"Jetzt wundert es mich, dass es solche Instrumente gibt wie Auron, Trium, Voltage, etc.
Denn diese Instrumente bieten nichts Neues , was man nicht mit dem Halion5 o hnehin machen könnte ."
und "die Instrumente sind nur deshalb da , weil sie in der Registerkarte "Makro" schöne bunte Regler haben "
und "Die Instrumente bieten keine erweiterten Klangfunktionen die nicht in Halion5 selbst erstellt werden könnten"

P A T schrieb:
"Die speziellen Synths von HALion bringen aus meiner Sicht rein klanglich nichts Neues zu dem, was man nicht auch mit H5-Bordmitteln zu Fuß programmieren könnte"

und bei dem "Mehrwert" hab ich mcih einfach schlicht verlsen, nämlich "kein" statt "ein" :oops:

ich hab da nur rausgelesen, daß sie Euch "stören", weil sie klanglich nix Neues bieten, was man nicht mit Halion5 selbst könne. und es ist ja auch logisch, daß sie klanglisch nicht mehr können, denn sie sollen einfach nur zeigen was mit den Bordmitteln möglich ist und das finde ich wird eindrucksvoll gezeigt!
mit eigenen Samples usw. geht natürlich viel mehr, dies möchte aber Steinberg wohl dem User überlassen...

inwieweit ihr aus den Makros lernen könnt, kann ich nicht beurteilen, weil halt nur Sonic2-User

nochmal: aus den von mir fett markierten Stellen spricht halt Ablehnung... ich bin froh, daß die Teile dabei sind und ihr seid ja nicht gezwungen sie zu nutzen
und in Kontakt5 sind auch viel zu viele Samples in der Factory-Lib die ich nicht benutzen würde, aber sie waren "gratis" dabei, also überspringe ich die dann einfach und das könnt ihr doch auch einfach machen ;)
aber warum es Dich Wolfgang wundert, daß es sie gibt, kann ich nicht verstehen -> sie sind einfach BEISPIELE und/oder Presetschleudern als Dreingabe

der persönliche Angriff gegen Euch Zwei war nicht so gemeint , aber ihr habt halt so wie viele User (bei diversen Produkten) zur Zeit schreiben, SORRY

so, und nun peace ,
The Sarge!
by The Sarge
Mon Nov 24, 2014 10:38 am
 
Jump to forum
Jump to topic