Fragen zu Template Erstellung in Cubase

[Realist]

Hi,
ich habe jetzt jahrelang fast ausschliesslich "in the box" gearbeitet. Da bin ich immer mit einer Buffersize von 512 zurechtgekommen.
Gitarren habe ich über mein Nux oder Boss aufgenommen und über RME Totalmix abgehört bei der Aufnahme.
Ich hatte dann immer ein DI Signal mit aufgenommen.
Templates habe ich nicht genutzt, sondern immer das geladen, was ich gerade brauchte.

Für ein Projekt, welches ich jetzt beginnen wollte, stellt sich die Ausgangslage etwas anders dar.
Ich möchte meine alten Songs aus den 80ern neu und auch anders aufnehmen. Ich werde da wohl auch das ein oder mal selbst singen. Ich ändere gerade dementsprechend die Songs, da unser damaliger Sänger höher und klarer gesungen hat.
Der Stil geht jetzt eher in Richtung Carpenter Brut, Scandroid oder Gunship. Der frühere Stil war eher so Rock mit Prog Rock Anleihen.

Ich habe jetzt angefangen mir eine Art von Live Template zu erstellen, so dass ich meine alten und neueren Synths mit einbinden kann. Mit der Buffersize wollte ich auch runter um gleich in Cubase das Monitoring zu machen. Dadurch kann ich erstmal keine rechenintensiven Plugins nutzen.
Zur Zeit kommen nur die Drums aus der Dose um einen gewissen Groove zu haben.
Mein Plan ist, erstmal ein Grundgerüst zu erstellen, wo ich singen kann und dann später das Ganze mit höherer Buffersize wie früher auszuarbeiten.
Dafür habe ich mir jetzt erstmal Ordnerspuren erstellt:
ARCHIV - Das sind Aufnahmen die ich roh mit aufnehme und vielleicht nochmal Verwendung finden.
REC - Da liegen meine Eingangskanäle für DI, Reamping, Gesang drin.
DRUMS - Logisch, da sind die Drumplugins und Gruppe der Drums drin. Auf der Gruppe liegt ein ProC 2 um etwas zu verdichten.
BASS - Da habe ich die Spuren für Bass und eine Gruppe mit Comp ähnlich wie Drums.
INST - Da sind zur Zeit alle meine Synths drin, gehen auch auf eine Gruppe mit Comp. Midi und Audio Eingänge zusammen. Ich hatte das erst getrennt, aber wenn man einen Synth muten möchte dann ist das ziemlich umständlich.
GUIT - Gleiche Spiel wie die anderen Ordner.
VOX - Ebenfalls.
FX - Da liegen meine Sendeffekte plus Gruppe. 9 Stück an der Zahl. Kleiner, mittlerer, grosser Raum, Blackhole für Ambiengitarren oder Synths, 2 Delays etc.
MASTER - Da habe ich auch einen Comp drauf, eine Tuner für die analogen Synths, Voxengo Span, Super Vision und einen Pro Q 4.

Was ich festgestellt habe, dass ich die Comps auf den Gruppen brauche, weil die Hardware Synths schon noch dynamischer sind, als Plugins.
Oftmals arbeitet man ja auch mit Samples oder Libraries die schon komprimiert sind.
Das Template scheint zur Zeit latenzfrei zu arbeiten und ich bin bei 128 mit der Buffersize.
Wie schon geschrieben, haben mich Templates all die Jahre nicht wirklich interessiert, aber ich denke bei diesem Projekt macht das jetzt doch Sinn.

Ich erhoffe mir jetzt irgendwie noch Tipps und Tricks, wie ihr so vorgeht bei Aufnahmen, gerade in Verbindung mit Hardware?
Vielleicht bin ich jetzt schon mit all den Ordnern und Gruppen über das Ziel hinaus und habt noch den ein oder anderen Tipp?
Danke schonmal.
Hier noch ein Screenshot von einem "Testprojekt".

 

[fender_rhodes]

Vielleicht bin ich jetzt schon mit all den Ordnern und Gruppen über das Ziel hinaus

Nein, ganz sicher nicht. Ich finde umfangreiche Templates bei wiederkehrenden Aufgaben sehr sinnvoll. Ich habe oft Projekte, bei denen ich nicht genau vorher weiß, wohin die Reise geht. Wenn ich dann im Laufe der Arbeit denke, ich brauche ein paar Orchester-Instrumente und muss die dann erst suchen, laden, gruppieren, einen passenden Hall suchen usw. dann bremst mich das total aus. Wenn ich dagegen nur den entsprechenden Ordner aufklappen muss und alles ist da, dann bleibe ich im Flow. Auch etliche Spuren mit Standard-Sounds, um schnell Dinge ausprobieren zu können, sind sehr hilfreich für mich. Wenn die Grundideen stehen, kann man sich immer noch stundenlang mit der Soundsuche beschäftigen, wenn man Bock darauf hat. Aber im kreativen Teil hält mich das eher auf.
Also für mich sieht das gut aus. In der Praxis merkt man dann schon welche Ordner/Gruppen wo und wie sinnvoll sind und kann das ja dann am Template anpassen.
Buffer von 128 habe ich in der Regel auch bei mir eingestellt und normal muss ich auch in der Einspielphase nichts erhöhen. Falls die Latenz beim Einspielen mit internen Instrumenten zu hoch ist, kann man jederzeit mit einem Klick den Latenzausgleich einschränken (die Schaltfläche kann man sich in der unteren Zeile im Projektfenster anzeigen lassen). Dann werden die VST-Effekte mit großen Latenzen auf Bypass geschaltet. Ist für mich ganz hilfreich.

 

[akl]

Ich arbeite immer mit Template.
Bei vielen Spuren würde ich sie genauso in Ordnern organisieren und mit Gruppenspuren arbeiten.
Vermutlich regelst Du am Ende auch am liebsten alles im Projekt mit Gruppenspuren.

Was ASIO-Buffer-Size anbelangt: Was für eine Kombination RME‑Recording-Interface und Rechner hast Du?
Ich komme mit einer ASIO‑Buffer size von 128 Samples bei single-speed (44,1/48 kHz) problemlos aus.
Damit beträgt die volle RTL (Round Trip Latency; A/D … DAW … D/A) i.d.R. immer unter 10ms.
Mit einem UFX III 7,3 ms, bei meiner jetzigen Kombination aus HDSPe MADI FX und M-1620 Pro sogar nur 6,7 ms.
Damit kann man locker Gitarre einspielen und andere Dinge.

Hier mal ein paar RTL zum Vergleich:

RTL comparison of different RME products (EN/DE) - TONSTUDIO FORUM - Raumakustik, Recording, Mixing, Mastering

Überblick Blogartikel und zugehörige Artikel / overview blog articles and related articles:tubeheats Blog - Artikelübersichtfür die Deutsche Übersetzung bitte runterscrollenadded chapter latency comparisonIntroductionLow latency is of great interest for…

www.tonstudio-forum.de

Wenn der PC gut eingestellt ist (gute Treiber, geringe RTL) und es hergibt, dann kann man selbst ein 400‑Spuren-Cubase-Projekt mit 2 VSTs pro Spur und 3 in der Stereo-Summe, also insgesamt 803 VSTs, ohne Audioaussetzer abspielen. Es funktioniert auch bei double speed (88,2/96 kHz) und auch egal, ob USB‑ oder PCIe-basiertes RME Recording-Interface (UFX+, RayDAT)

RME UFX+ / RayDAT and Cubase 9.0.10 - Performance Test - 400 Audio Tracks (DE/EN) - TONSTUDIO FORUM - Raumakustik, Recording, Mixing, Mastering

Überblick Blogartikel und zugehörige Artikel / overview blog articles and related articles:tubeheats Blog - ArtikelübersichtEDIT:Resultate für RME RayDAT via AES to phones@ADI-2 Pro; VST performance Werte für UFX+ ergänzt.Added time for Cubase and…

www.tonstudio-forum.de

Ich kann Dir, falls Du einen Windows-PC hättest, ein ausgezeichnetes Tool aus dem RME-Forum empfehlen, das die wichtigsten Windows-Einstellungen überprüft und zum Optimieren anbietet:

[2.0.0]I built a free Win optimization tool for audio/video production (Page 1) — Tips & Tricks — RME User Forum

[2.0.0]I built a free Win optimization tool for audio/video production (Page 1) — Tips & Tricks — RME User Forum —

forum.rme-audio.de

Was das Arbeiten mit Templates angeht: Wenn man die gleiche Aufnahmesituation hat, dann wäre es schön, wenn Cubase und Nuendo den Record-armed-Status der Spuren speichern und wiederherstellen würden, wie es andere DAWs auch tun (Studio One, Fender Studio Pro). Presonus macht das, aber Steinberg* nicht.
Als Bug haben sie es nicht akzeptiert, es ist zu einem "Feature Request" geworden, ziemlich enttäuschend.
Ich mache hier immer die gleichen Gitarren-Overdubs und wenn man das Instrument auf dem Schoß hat, möchte man möglichst nicht lange in einer blöden Haltung vor dem PC sitzen, sondern schnell zur Aufnahme kommen. Stattdessen darf man "Moorhuhn schießen" spielen und erst einmal die richtigen Spuren scharfschalten. Ich finde das ätzend unkomfortabel. Nicht gerade bedienerfreundlich.

Falls Du das auch lieber so hättest wie ich, mach doch mal einen Case auf, vielleicht kommt dann was Dynamik rein.
Dann wird vermutlich auch wieder das Gegenargument kommen: Designentscheidung, Feedbackvermeidung.
Gut, wunderbar, aber wenn man die Sache durchdenkt, dann werde ich sicherlich nicht ein Template mit eingebautem Feedback speichern. Da sehe ich eher die Gefahr, dass man "in der Eile" sich ein Feedback hineinbaut, als ein 100‑% passendes Template aufrufen zu können, wo alles bereits bestens vorbereitet ist.
Und letztlich sollte man es dann ggf. in den Preferences einstellen können, was einem lieber wäre.
Dann halt die defensive Voreinstellung "Record Armed Status von Templates" nicht laden und der Fall wäre zur Zufriedenheit aller gehalten. Aber dazu ist Steinberg* anscheinend nicht in der Lage. Wer es eleganter haben möchte, muss zu Studio One wechseln.
Also … ruhig mal einen Case bei den Steinis öffnen, dass ein Template wieder zu einem vollwertigen Template wird, ohne Bevormundung durch den Hersteller.

 

[Ran]

Für mich war in der Hinsicht ein Game-Changer, dass ich nicht verwendete Spuren anfangs komplett deaktiviere und erst bei Bedarf aktiviere. Damit kann dann ein recht pompöses Template erstellt werden, was trotzdem flott lädt und wenig Resourcen frisst.

 

[Realist]

Was ASIO-Buffer-Size anbelangt: Was für eine Kombination RME‑Recording-Interface und Rechner hast Du?
Ich komme mit einer ASIO‑Buffer size von 128 Samples bei single-speed (44,1/48 kHz) problemlos aus.
Damit beträgt die volle RTL (Round Trip Latency; A/D … DAW … D/A) i.d.R. immer unter 10ms.
Mit einem UFX III 7,3 ms, bei meiner jetzigen Kombination aus HDSPe MADI FX und M-1620 Pro sogar nur 6,7 ms.
Damit kann man locker Gitarre einspielen und andere Dinge.

Ich habe auf meinem alten Rechner noch eine RME Hammerfall verbaut. Auf den neuen Rechner konnte ich die damals nicht mitnehmen. Habe mir erst eine Focusrite* Scarlett 18i20 gekauft, aber das war latenzmässig eine Katastrophe.
Ich habe mir dann eine RME Digiface USB gekauft und das Scarlett läuft jetzt über ADAT am Digiface. Much better.
Die Treiber von RME sind einfach erste Sahne.
Mein Rechner ist nicht die Höllenmaschine, nutze den aber ausschliesslich für Audio.
Es ist ein AMD Ryzen 5700G und Windows 11 als Betriebssystem.
Ich nutze nicht die interne Grafik, sondern eine nVidia 1030 oder so.
Ein bisschen getweakt habe ich schon und Latencymon zeigt eigentlich gute Werte.

Cubase ist die neueste Version, also die 15 Pro. Ich hatte in der Vergangenheit auch immer mal wieder Kontakt mit dem Support.
Bei mir ging es aber um die Midi Remote. Einige User und ich hatten Probleme mit den Zuweisungen und das Zurücksetzen von Scripten. Ich hatte dem Support sogar geschrieben, wann diese Fehler auftreten. Man muss sagen, dass der Mitarbeiter sich immer zurückgemeldet hat, aber man hatte das Gefühl, dass das Prblem nicht richtig verstanden wurde.
Bis auf einmal ein Bugfix kam, der den Fehler zumindest teilweise behoben hat.
Das war aber ein halbes Jahr hin und her schreiben.
Deswegen bin ich da erstmal geheilt bzgl Support.
Wo man noch etwas bewirken kann, ist im englischen Cubase Forum. Wenn sich da genug Leute dem Thema annehmen, hat man gute Chancen gehört zu werden.

Für mich war in der Hinsicht ein Game-Changer, dass ich nicht verwendete Spuren anfangs komplett deaktiviere und erst bei Bedarf aktiviere. Damit kann dann ein recht pompöses Template erstellt werden, was trotzdem flott lädt und wenig Resourcen frisst.

Ja so in der Art hatte ich mir das auch gedacht. Zumindest, dass ich die Channels schonmal alle einrichte und dann bei Bedarf aktiviere.
Es gibt ja auch diese Funktion, dass man deaktivierte Spuren ausblenden kann, aber da hätte ich ein bisschen Angst, dass ich das vergesse.

Vielen Dank schonmal für Eure Rückmeldungen.

 

[akl]

Das war aber ein halbes Jahr hin und her schreiben.

Ja, diese Erfahrung habe ich auch gemacht.
Ich dachte beim Kauf von Nuendo, dass man dann vielleicht ein wenig mehr Priorität eingeräumt bekäme, aber Pustekuchen.
Es ist unglaublich, wie viel Energie man da hineinstecken muss, und dann kommt noch nicht mal etwas Positives dabei heraus.

Erst wird ein Case wochenlang nicht angefasst. Am besten ruft man an und beklagt sich darüber.
Dann wird krampfhaft versucht, aus einer Bugmeldung einen Feature-Request zu machen.
"Das wäre halt vom Design her so gewollt" oder "Da müsste man die Sache mal im Forum vorstellen".

Tja, und im Forum agiert dann dieser sogenannte "erfahrene User" Steve auch zum Vorteil von Steinberg*. Bugmeldungen werden umgetaggt als Feature-Request. Ich finde, sowas gehört sich einfach nicht.
Und wenn man sich darüber beklagt, dass gewisse Dinge einfach zu kompliziert oder unlogisch sind, dann argumentiert er dagegen und kommt mit noch komplizierteren Kniffen, die von der Bedienung her jenseits von Gut und Böse sind, und meint allen Ernstes, dass damit doch alles geklärt sei.

Steinberg* schiebt’s ins Forum und im Forum biegt dieser Steve alles im Sinne von Steinberg hin, dass die am Ende gut dastehen.

Deshalb: Mit dem Forum habe ich komplett abgeschlossen und mit dem Support auch so gut wie.
Ich habe auch schon sehr freundliche, motivierte Mitarbeiter erlebt, aber letzten Endes muss ich feststellen, dass die Sachen, die mir wichtig sind, in der Regel so gut wie immer unter den Tisch fallen. Es sei denn, es ist mal ein wirklich handfestes, messbares Performanceproblem.

Wirklicher Kundendienst funktioniert anders. Da hat man einen kompetenten Ansprechpartner, der ein Problem versteht, bewerten kann und dann auch was dran tut, anstatt einen ins Forum weiterzuverweisen.

Deswegen bin ich da erstmal geheilt bzgl Support.

Ich ignoriere die Fehler jetzt auch lieber, alles andere kostet zu viel Zeit und leider auch Nerven.

Wo man noch etwas bewirken kann, ist im englischen Cubase Forum. Wenn sich da genug Leute dem Thema annehmen, hat man gute Chancen gehört zu werden.

Na ja, siehe Steve und einen Haufen "Regulars", die da regelmäßig abhängen, die sich anscheinend schon an die Macken von Cubase/Nuendo gewöhnt haben und meinen, es ginge nicht anders. Das Forum kann man auch vergessen.

Am besten man erwartet nicht zu viel und hofft, dass das nächste Update einige Dinge fixt.

Ich wünschte mir so manches Mal mehr Bugfixes als nur neue Features.

 

[Realist]

Ich wünschte mir so manches Mal mehr Bugfixes als nur neue Features.

Geht mir auch so.
Ich brauche eigentlich nicht ein Unterwasserplugin oder ein Vocalchainplugin oder ein Shimmerplugin was wie Hölle an Leistung zieht.
Ich meine, okay, einige Plugins sind, dafür das sie dabei sind schon ziemlich gut. Da haben andere DAW Hersteller eher nicht so eine gute Auswahl.
Auch Vari Audio ist klasse.
Aber manche Sachen scheinen einfach nicht zuende gedacht.
Z.B. der Halion ist ein genialer Sampler, der u.a. auch verschiedene Formate laden kann, aber die Bedienung ist einfach eine Qual.
Oder halt die Midi Remote. Geniale Idee, aber leider voller Bugs, die man mit Workarounds umschiffen muss.
Und Du hast recht, im Forum gibt es einige Kollegen die sehr leidensfähig sind und alles irgendwie schönreden.
Ich würde mir z.B. auch eine modernere Variante der Midi Devices wünschen, aber das Thema Midi für externe Geräte scheint auch nicht mehr so die Priorität zu haben, obwohl es ja mittlerweile durchaus wieder etliche Hardware zu kaufen gibt.
Aber klar, jeder hat da wohl seine eigenen Präferenzen und im Grossen und Ganzen bin ich mit Cubase zufrieden.
Ich habe immer mal wieder andere DAWs getestet, aber irgendwie ist da der Funke nicht übergesprungen.

 

[akl]

[...]
Ich habe immer mal wieder andere DAWs getestet, aber irgendwie ist da der Funke nicht übergesprungen.

Geht mir auch so

 

[akl]

Im Übrigen sind auch die Videos von Holger aka tsching sehr hilfreich.

 

[C14 - frag mich]

Bugmeldungen werden umgetaggt als Feature-Request. Ich finde, sowas gehört sich einfach nicht.

Da komm ich mal wieder aus dem Grab gekrochen, in das ich mich eigentlich schon gelegt hatte.
Im Forum geht es bei den Tags "issue" und "feature-request" darum, was Steinberg intern als Bug und was als Featurewunsch ansieht. Da Steve als Moderator das besser einschätzen kann, als manche Forenteilnehmer, ändert er (und auch andere) das bei Bedarf entsprechend ab.
Da man nach Tags filtern kann, können sich Steinberg-Mitarbeiter bei Bedarf einen besseren Überblick verschaffen.

Es tut mir leid, wenn Dich das stört, aber ich habe seltenst erlebt, dass eine nachträgliche Änderung des Tags ungerechfertigt war.

Es gibt übigens eine sehr einfache Regel dafür, was ein Bug ist: Wenn etwas in Cubase nicht so funktioniert, wie Steinberg das geplant hat. Dazu muss man natürlich wissen, was Steinberg eigentlich geplant hat. Da kommen dann Steve und ein paar andere ins Spiel.
Diese beiden Tags sind also eigentlich für Steinberg gedacht.

Ich hoffe, es hilft ein wenig zu verstehen, warum Tags geändert werden. Meistens werden Tags hinzugefügt, manchmal auch gelöscht.

PS: Ich schaue mal, dass ich den Service von damals für Cubase 14 auch für die Version 16 wieder anbieten kann.

 

[akl]

Da komm ich mal wieder aus dem Grab gekrochen, in das ich mich eigentlich schon gelegt hatte.
Im Forum geht es bei den Tags "issue" und "feature-request" darum, was Steinberg intern als Bug und was als Featurewunsch ansieht. Da Steve als Moderator das besser einschätzen kann, als manche Forenteilnehmer, ändert er (und auch andere) das bei Bedarf entsprechend ab.
Da man nach Tags filtern kann, können sich Steinberg-Mitarbeiter bei Bedarf einen besseren Überblick verschaffen.

Es tut mir leid, wenn Dich das stört, aber ich habe seltenst erlebt, dass eine nachträgliche Änderung des Tags ungerechfertigt war.

Es gibt übigens eine sehr einfache Regel dafür, was ein Bug ist: Wenn etwas in Cubase nicht so funktioniert, wie Steinberg das geplant hat. Dazu muss man natürlich wissen, was Steinberg eigentlich geplant hat. Da kommen dann Steve und ein paar andere ins Spiel.
Diese beiden Tags sind also eigentlich für Steinberg gedacht.

Ich hoffe, es hilft ein wenig zu verstehen, warum Tags geändert werden. Meistens werden Tags hinzugefügt, manchmal auch gelöscht.

PS: Ich schaue mal, dass ich den Service von damals für Cubase 14 auch für die Version 16 wieder anbieten kann.

Sorry, aber die heile Welt, die Du mir gerade verkaufen möchtest, habe ich so noch nicht erlebt

Es zeigt gewisse Parallelen, die ich im Steinberg-Forum immer wieder erlebe: dass einige Leute anscheinend so auf das Produkt eingeschworen sind, dass Fehler nicht mehr als solche wahrgenommen und erst mal Steinberg als auch das Produkt in Schutz genommen werden.

Mein Fazit bleibt: Die Case-Bearbeitung dauert zu lange, ist zu zäh, Bugs werden kleingeredet oder als Designentscheidung "verkauft" nur um es in einen Feature-Request ummünzen zu können. Ebenso halte ich es für unakzeptabel, Steinberg nicht als alleinigen Ansprechpartner zu haben, sondern vom Support aufgefordert zu werden, Dinge im Forum durchzudiskutieren.

Das sehe ich als zahlender Kunde nicht als meine Aufgabe an. Da ist für mich derjenige Supportkontakt, bei dem ich auch für die Produkte gezahlt habe. Und ich habe der Firma Steinberg in den vergangenen 26 Jahren schon eine Menge Geld überwiesen (Cubase, Nuendo, SpectraLayers, HALion).

Ich habe in den ersten 23 Jahren den Ball flach gehalten, weil im Grunde alles so weit funktioniert. Das ist ja schon mal schön.
Jedoch: vor 1-2 Jahren nervten mich ein paar Dinge und da ist es dann doch enttäuschend, zu sehen, wie zäh das doch alles ist.
Ich habe an der Stelle aufgegeben und werde Steinberg lieber nicht mehr involvieren, spart Zeit, schont die Nerven.

Aber nicht, dass wir uns falsch verstehen: Ich werde Steinberg-Produkten weiterhin treu bleiben.
Es sind gute Produkte, sonst hätte ich mir nicht so viel von denen gekauft.
Nur bin ich mit dem Support nicht zufrieden.

 

[Realist]

Es gibt übigens eine sehr einfache Regel dafür, was ein Bug ist: Wenn etwas in Cubase nicht so funktioniert, wie Steinberg das geplant hat. Dazu muss man natürlich wissen, was Steinberg eigentlich geplant hat. Da kommen dann Steve und ein paar andere ins Spiel.
Diese beiden Tags sind also eigentlich für Steinberg gedacht.

Ich möchte Dich natürlich nicht vergraulen und ich weiß wir nölen manchmal auf hohen Niveau.
Hier mal ein Beispiel meines letzten Bugs, den viele andere User auch hatten bzgl Midi Remote:
Die Midi Remote in Cubase ist genial und lief bei der Einführung ganz okay.
Ich habe ein Oxygen Pro Keyboard und ein Korg Nano Key Studio als Midi Remote eingerichtet, was auch erst super lief.
Irgendwann nach einem Cubase Update bei Version 14 wurden die Zuweisungen der Midi Remote vergessen.
Es gibt einen ellenlangen Thread dazu im Cubase Forum und es betraf wirklich sehr viele User auf beiden Plattformen also Mac und PC.
Wir haben dann herausgefunden, dass Cubase die Zuweisungen im Midi Remote Ordner einfach löscht. Es gibt dort zwei Dateien. Die eine Datei ist für die Zuweisungen und eine andere Datei in einem anderen Ordner ist für das Script zuständig.
Ich kenne mich mittlerweile sehr gut mit dem Auslesen und ändern der Dateien aus. Warum? Weil ich mich über unzählige Stunden damit befassen musste. Es ist zwar schön etwas Neues zu lernen, aber die Progrmmierung oder Änderung von Scripten gehört für mich nicht dazu. Ich bin kein Programmierer und war nur froh, dass es dort kompetente User gab, die das können und mir Sachen erklärt haben. Viele User, mich eingeschlossen, haben den Support angeschrieben und auf den Thread hingewiesen. Ich habe sogar mal den Quellmann gegängelt, was absolut nicht meine Art ist.
Was ich sagen will. Passiert ist lange Zeit nichts.
Manche User waren so leidensfähig, die Zuweiungen bei jedem Start von Cubase neu zu machen. Ehrlich.
Jemand hatte dann einen Workaround. Einfach die beiden Dateien backuppen und wenn die Zuweisungen weg sind die Dateien wieder zurückzuspielen.
Irgendwann zum Ende von Cubase 14 Update Cyclus wurde geschrieben, dass der Bug behoben wurde.
Alle User waren überrascht, hatte sie doch gar nichts vom Support gehört.
Problem: Der Bug war NICHT behoben.
Warum? Wenn man ein neues Projekt erstellte, ging es über Umwege. Hat man ein altes korruptes Cubase 14 File geladen, wurde wieder gelöscht.
Das führt mich zu der Vermutung, dass die meisten Beta Tester oder die Programmierer immer mit neuen Cubase Files arbeiten und keine "alten" Projekte nutzen, wie es normalerweise der Fall ist.
Das Problem ist, dass die Midi Remote so programmiert ist, dass Cubase die Zuweisungen ändern kann, was irgendwie auch sinnvoll ist, aber es sollte die Zuweisungen nicht löschen. Ein weiteres Problem ist, dass es Globale und Projektbezogene Zuweisungen gibt, was das Ganze verkompliziert. Cubase schreibt die Zuweisungen auch in die CPR. Wenn man dann ein korruptes CPR lädt, zerhaut es dir die EInstellungen.
Seid ihr noch da?

Desweiteren gibt es Probleme der Midi Remote mit sogenannten "Duplikaten", so haben es die User in unzähligen Threads getauft.
Das bedeutet: Deine Midi Remote. In meinem Fall das Oxygen taucht zweimal auf. EIne Midi Remote geht, die andere nicht.
Ich habe Screenshots gesehen, wo User 10 oder mehr "Duplikate" hatten.
Dieses Verhaten ist auch noch in Cubase 15 zu beobachten und unter Windows und "selbst erstellten" Midi Remote Scripts.
Der Grund ist:
Im Forum wird geraten, die Duplikate einfach zu löschen. Das scheint bei richtig "programmierten" Scripts von Novation und Co zu funktionieren. Nicht aber bei selbst erstellten.
Wenn man ein Duplikat löscht, werden in der Zuweisungsdatei, die Midi Ports der korrekten Midi Remote gelöscht.
Die Midi Remote wird dadurch beim nächsten Start nicht mehr erkannt, da die Ports fehlen.
Das hat nichts mit der Einführung des neuen Midi Services unter Windows 11 zu tun.
Die Lösung wäre einfach. Steinberg müsste dafür sorgen, dass es ein "schonendes" Löschen der Duplikate gibt.
Oder einfac sicherstellen, dass es logischerweise nur diese eine Midi Remote geben kann, welche zu besagten Port gehört.
Das kann eigentlich nicht so schwer sein.

Desweiteren gibt es den Bug, wenn man ein Projekt über "Neu" erstellt, die Duplikate wieder erscheinen.
Ein Workaround ist folgender:
Templates nutzen die funktionieren.
Wenn man alte Projekte öffnet, muss man ein Cubase 15 Projekt laden, welches ein funktionierendes Template oder eine CPR Datei enthält.
Danach kann man ein altes Projekt laden, darf es aber NICHT aktivieren. Man speichert dann das nicht aktivierte Projekt unter einem neuen Namen und es sollte dann unter Cubase 15 funktionieren.
Das sind alles Workarounds die User im Cubase Forum oder ich selber herausgefunden und geteilt habe.

Das Löschen der Zuweisungen passiert in Cubase 15 nicht mehr so oft. Da wurde nachgebessert.
Die letzte Version von Cubase 14 hat aber noch diese Bugs. Da wurde nichts mehr nachgebessert, was mich gezwungen hat auf Cubase 15 zu gehen, was ich ehrlich gesagt ziemlich unschön finde.

Über Ostern habe ich mir in stundenlanger Arbeit mal die Zeit genommen und alles per Screenshots zu dokumentieren und zu beschreiben.
Der Support hat auch zurückgeschrieben und nach anfänglichen Standard Antworten auch noch andere Sachen geschrieben.
Zu keinem Zeitpunkt hat der Support die Programmierer informiert, obwohl es unzählige Threads zu der Midi Remote und dessen Bugs im Cubase Forum gibt.
Das bringt mich zu dem Punkt, dass Steinberg das aussitzt und man mit diesen "Workarounds" leben muss, möchte man wirklich eine selbst erstellte Midi Remote nutzen.

Man merkt auch, dass die Programmierer selbst sich aus dem Forum zurückgezogen haben. Wahrscheinlich eine bewusste Entscheidung.
Der Support scheint ehrlich gesagt auch überfordert, man muss aber zugute halten, dass sich mein Mitarbeiter immer mal wieder gemeldet hat. Bei rumgekommen ist trotzdem nichts, Andere User berichten, dass ihre Anfragen irgendwann einfach geschlossen wurden. Meine scheint noch offen zu sein, aber ich bin mittlerweile so genervt, dass ich da nicht mehr schreibe.
Vielleicht hat aber nur der Support vergessen, den zu schliessen.

Sorry für den Rant.

 

[akl]

Sorry für den Rant.

Kein Grund für eine Entschuldigung, im Gegenteil: Danke dafür. Es ist eine Erleichterung, zu lesen, dass es anderen genauso geht.

Einer meiner Fälle: Der Record-Arm-Status lässt sich in Templates nicht speichern, beim Aufrufen eines Templates wird er nicht wiederhergestellt. Andere DAWs können das ohne Weiteres, unter anderem Studio One.

Die Antwort des Supports: kein Bug, sondern eine Designentscheidung. Man wolle verhindern, dass es zu einem Feedback-Loop kommt. Aus dem Bug-Report wurde damit ein Feature-Request.

Diese Begründung trägt einfach nicht:

1. Ein Template legt man bewusst an und testet es vorher. Wer Spuren aufnahmebereit ins Template speichert, hat sich das überlegt, genau wie Eingänge, Monitoring und Routing. Und ein Template lädt man ebenso bewusst. Es öffnet sich nicht von selbst.
2. Spätestens vor der Aufnahme müssen die Spuren ohnehin scharf geschaltet werden. Das Risiko verschwindet also nicht, es wird nur um ein paar Klicks nach hinten verschoben.
3. Cubase überlässt genau diese Entscheidung an anderer Stelle längst dem Anwender. In den Programmeinstellungen unter „Bearbeitungsoptionen – Projekt und MixConsole“ gibt es „Aufnahme auf ausgewählter Audiospur aktivieren“ bzw. die entsprechende Option für MIDI-Spuren: Spur anklicken, Spur ist scharf. Dazu kommt der Tastaturbefehl „Alle Audiospuren aufnahmebereit“ in der Kategorie „Mixer“. Wenn das Feedback-Argument wirklich zählen würde, dürfte es beides nicht geben.

Die Lösung wäre trivial, und genau das macht es umso unverständlicher und frustrierender.
Man hätte den Record-Arm-Status einfach ins Preset speichern sollen. Dann hätte man nur noch über eine Preset-Einstellung regeln müssen, ob „Record Armed“ restored werden soll oder nicht. Am besten mit der gesunden Default-Einstellung, es zu restoren, wie es gespeichert wurde. Was denn auch sonst? Das ist doch der Sinn eines Templates!
Damit wäre in jedem Fall auch gelöst gewesen, dass man die Templates später nicht noch einmal anpacken muss, egal, was in den Preferences eingestellt ist oder war.

Man sollte schon dem Anwender so viel zutrauen, selbst entscheiden zu können, was er im Template braucht.
Im laufenden Betrieb steht schließlich auch niemand daneben, der ihn vor Fehlbedienungen schützt.

Zum Use-Case: Wenn ich Gitarre aufnehme, sitze ich ohnehin in ungünstiger Haltung vor dem Rechner. Man muss lange Arme machen, damit die Gitarre nicht an die Tischkante knallt. Da ist man über jede Optimierung dankbar, die weniger Maus- (oder auch) Tastaturarbeit bedeutet. Ein Template fürs Recording zu haben und darin trotzdem vor jeder Aufnahme wieder alle Spuren scharf schalten zu müssen, ist genau das Gegenteil davon.

Im größeren Setup wird es absurd: Orchesteraufnahme mit 40 oder 50 Spuren, Template steht, und vor jeder Session geht das Scharfschalten von vorn los.

Das ist mein Blues an der Sache: zum einen die fehlende Funktion an sich, zum anderen die Umdeklaration eines offensichtlichen Defizits zur Designentscheidung. Als zahlender Kunde fühle ich mich damit im Support nicht ernst genommen. Und ich frage mich, was in Beta-Test und QA eigentlich priorisiert wird. Das Wichtigste ist zuerst eine intuitive und effiziente Bedienung. Alles andere kommt danach. Bei Designentscheidungen sollte man auch die richtigen Leute involvieren, damit nicht so ein offensichtlicher Murks dabei herauskommt.

 

[C14 - frag mich]

Sorry, aber die heile Welt, die Du mir gerade verkaufen möchtest, habe ich so noch nicht erlebt

Warum schreibst Du das?
Ich habe beschrieben, wofür die Tags "issue" und "feature--request" da sind und warum diese manchmal von Moderatoren geändert werden.
Inwiefern verkaufe ich Dir etwas und wo ist hier die heile Welt?

Die Antwort des Supports: kein Bug, sondern eine Designentscheidung. Man wolle verhindern, dass es zu einem Feedback-Loop kommt. Aus dem Bug-Report wurde damit ein Feature-Request.

Ich will nichts zu der Begründung des Support-Mitarbeiters sagen, aber dieses Beispiel zeigt genau das auf, was ich vorher beschrieben habe. Du bist der Meinung, das der Arm-Track-Status gespeichert werden sollte und wenn das nicht geschieht, ist das als Bug anzusehen.
Der Support-Kollege schaut in die Feature-Spezifikation und sieht, dass es vom Entwickler-Team nicht vorgesehen ist, dass der Zustand gespeichert werden soll.
Das ist dann also kein Bug. Dabei ist nicht entscheidend, wie Du das siehst, es geht hier um die Einordnung von seiten Steinberg. Es handelt sich nicht um eine fehlerhaft ausgeführte Funktion sondern um eine, Deiner Meinung nach, schlecht gestaltete Funktion. Du erwünschst eine Umgestaltung, das ist dann ein Feature-Request.

Letztendlich ist es allerdings für das, was danach passiert, völlig Banane, ob Issue oder FR. Dein Feedback wird danach gleichsam behandelt. Es lohnt sich also nicht, darüber den Schlaf zu verlieren.

Hier mal ein Beispiel meines letzten Bugs, den viele andere User auch hatten bzgl Midi Remote:

Kann ich alles verstehen. Die Probleme hatte ich auch und der Frust war groß. Auch als Beta-Tester bin ich nicht immer mit Steinbergs Entscheidungen einverstanden oder glücklich über die Prioisierung, wann welches Problem angegangen wird.
Ich habe mich aber lediglich zu dem Mißverständnis bezüglich der Tags äußern wollen. Denn bei den anderen Themen kommen wir schnell an den Punkt, wo mein NDA greift.

 

[akl]

Warum schreibst Du das?
Ich habe beschrieben, wofür die Tags "issue" und "feature--request" da sind und warum diese manchmal von Moderatoren geändert werden.
Inwiefern verkaufe ich Dir etwas und wo ist hier die heile Welt?

Weil Du den Vorgang so beschreibst, als sei damit alles in Ordnung. Genau das ist es aus meiner Sicht nicht. Wie die Tags gemeint sind und warum Moderatoren sie ändern, ist mir klar.

Vorweg, damit wir uns die Grundlagen sparen können: Ich habe einen soliden IT-Hintergrund als Dienstleister bei Enterprise- und Datacenter-Kunden. Die ganze Palette: Beratung, Betriebsunterstützung, (Integrations-)Design, Projektmanagement, Softwareentwicklung, Prozessoptimierung; insgesamt rund 35 Jahre Berufserfahrung.

Wie solche Prozesse ablaufen, ist mir vertraut. Mir ist auch klar, dass Du als Beteiligter teils eine andere Sichtweise haben wirst. Es geht hier aber weniger um richtig oder falsch und auch weniger darum, wie Du oder Steinberg die Dinge sehen. Es geht um die Außenwirkung: wie das in Richtung Kunde kommuniziert wird, wie es dort ankommt und ob sich am Ende für den zahlenden Kunden etwas tut.

Zur Rolle der Moderatoren: Ich möchte niemandem böse Absichten unterstellen. Wenn eine Meldung aber mit Kenntnis interner Spezifikationen umetikettiert wird, die für Anwender nicht einsehbar sind, dann ist das aus Anwendersicht keine Moderation unter Gleichen mehr, sondern Teil des offiziellen Supportprozesses. Dann sollte es auch so kommuniziert werden. Wenn jemand als unabhängiger User dargestellt wird, zugleich aber weitreichende Admin-Rechte hat und User-Requests umlabelt, passt die Beschreibung nicht zur Rolle.

Ich will nichts zu der Begründung des Support-Mitarbeiters sagen, aber dieses Beispiel zeigt genau das auf, was ich vorher beschrieben habe. Du bist der Meinung, das der Arm-Track-Status gespeichert werden sollte und wenn das nicht geschieht, ist das als Bug anzusehen.
Der Support-Kollege schaut in die Feature-Spezifikation und sieht, dass es vom Entwickler-Team nicht vorgesehen ist, dass der Zustand gespeichert werden soll.
Das ist dann also kein Bug. Dabei ist nicht entscheidend, wie Du das siehst, es geht hier um die Einordnung von seiten Steinberg. Es handelt sich nicht um eine fehlerhaft ausgeführte Funktion sondern um eine, Deiner Meinung nach, schlecht gestaltete Funktion. Du erwünschst eine Umgestaltung, das ist dann ein Feature-Request.

Die Regel "Ein Bug liegt vor, wenn etwas nicht so funktioniert, wie Steinberg es geplant hat" ist in sich schlüssig, klammert aber genau den Fall aus, der in der Praxis am meisten stört: Die Funktion tut zwar exakt das, was die Spezifikation vorgibt, jedoch ist die Spezifikation selbst das Problem. Ein Bedienungsdefizit bleibt ein Defizit, und das muss auf den Tisch. Alte Designentscheidungen schön und gut, aber wenn es einfach nicht passt, dann muss solch eine Entscheidung noch einmal auf den Prüfstand. Mein Beispiel dazu steht weiter oben, das muss ich nicht wiederholen.

Letztendlich ist es allerdings für das, was danach passiert, völlig Banane, ob Issue oder FR. Dein Feedback wird danach gleichsam behandelt. Es lohnt sich also nicht, darüber den Schlaf zu verlieren.

Das sehe ich anders. Feature-Requests bekommen in jeder Organisation, die ich kenne, eine andere Priorität als Bugs, und ich sehe keinen Grund, warum das ausgerechnet hier nicht so sein sollte. Wäre die Einordnung wirklich folgenlos, bräuchte es sie nicht und nachträgliches Umtaggen erst recht nicht. Der Aufwand wird betrieben, also hat er offenbar einen Zweck.

Hinzu kommt: Wenn Du Leuten einen Haufen Feature-Requests zum Review vorlegst, dann werden die das auch eher als Feature-Request behandeln. So viel zu der Annahme, ein späterer Review gleiche das wieder aus.

Dazu kommt die Außenwirkung, und die ist mir wichtiger. Beim Kunden kommt an: "Mein Punkt wurde heruntergespielt".

Natürlich schönt so etwas auch die Bug-Statistik. Sei es in internen Case-Tools (Innenwirkung) oder auch im Forum (Außenwirkung), wenn zu Bugs weniger Hits gezeigt werden. Es entsteht dann fürs "Marketing" das schöne Bild, es gäbe wenige Bugs, nur einen Haufen Kundenwünsche. Das ist aber ein Zerrbild und stellt nicht die Realität dar.

Oder anders gesagt: Das alles zusammen ist eigentlich genau das Gegenteil von "kein Grund, den Schlaf zu verlieren".

Den Schlaf raubt es mir glücklicherweise nicht, aber es ist einfach alles ziemlich nervig, vor allem was davor passiert und wie zeitraubend das alles ist: Cases bleiben wochenlang liegen, und der Support verweist mich ins Anwenderforum, um meinen Vorschlag dort zur Diskussion zu stellen. Das sehe ich, wie ich bereits darlegte, nicht als meine Aufgabe. Anforderungen aufzunehmen, zu bewerten und zu priorisieren ist Sache des Herstellers und nicht die einer unbezahlten Community-Diskussion.

Dass Kunde und Supporter einen Sachverhalt unterschiedlich sehen, ist normal, und wo mit Case-Tools gearbeitet wird, wird auch gemessen, wie Cases laufen. Das ist für sich genommen kein Problem. Es darf nur nicht dazu führen, dass berechtigte Punkte von Kunden kleingeredet werden.

Kann ich alles verstehen. Die Probleme hatte ich auch und der Frust war groß. Auch als Beta-Tester bin ich nicht immer mit Steinbergs Entscheidungen einverstanden oder glücklich über die Prioisierung, wann welches Problem angegangen wird.
Ich habe mich aber lediglich zu dem Mißverständnis bezüglich der Tags äußern wollen. Denn bei den anderen Themen kommen wir schnell an den Punkt, wo mein NDA greift.

In jedem Produkt gibt es die berüchtigten "low hanging fruits", kleine Änderungen mit überschaubarem Aufwand und spürbarem Nutzen für Anwender und Produkt. Die brauchen keinen langen Prozess, sondern jemanden, der die Chance erkennt und sie einplant.

Gerade bei Euch Beta-Testern, wie auch Supportmitarbeitern, die langjährige Erfahrung im Umgang mit diesen Produkten haben und die täglich im Kontakt mit dem Kunden stehen (über offiziellen Support, aber auch Forenarbeit), sollte es Meldewege geben, die ein Review einer Designentscheidung vorsehen, um kleine Dinge ohne großen Aufwand schnell zur Zufriedenheit aller fixen zu können. Wenn man die Chance nicht direkt beim Schopf ergreift, dann schiebt man doch nur eine immer größer werdende Bugwelle vor sich her, die am Ende gar nicht mehr zeitnah abgearbeitet oder überhaupt bewältigt werden kann.

Von außen nehme ich das Gegenteil wahr: Es wird sorgfältig eingeordnet, viel Energie verpufft und danach passiert nichts.

Klassifizierung ersetzt keine Entscheidung. Wenn brauchbare Anregungen von Kunden regelmäßig versanden, dann wäre das auch mal ein Thema für die Teamleitung. Praxiswissen frei Haus ist im Übrigen günstiger als jede Marktforschung.

Selbst in der Autoproduktion ist es inzwischen üblich, dass Designer und Produktionsmitarbeiter miteinander sprechen, um Abläufe zu optimieren.

Dass Du dabei aus NDA-Gründen nicht voll einsteigen kannst, verstehe ich, und ich will Dich zu Internem auch gar nicht ausfragen.

Mein Punkt bleibt: Am Ende hat man als Kunde einfach nur das Gefühl, nicht ernst genommen zu werden und einen schlechten Produktsupport zu bekommen. Für meinen Geschmack dürfte es auch ruhig mehr Bugfixes und Clean-ups als Features geben.

 

[Realist]

Mein Punkt bleibt: Am Ende hat man als Kunde einfach nur das Gefühl, nicht ernst genommen zu werden und einen schlechten Produktsupport zu bekommen. Für meinen Geschmack dürfte es auch ruhig mehr Bugfixes und Clean-ups als Features geben.

Empfinde ich zur Zeit auch so, leider.
Ich muss dazu sagen, dass ich bisher alle meine Probleme oder Problemchen mit Cubase selbst in den Griff bekommen habe und all die Jahre den Support nicht wirklich brauchte.
Das Problem mit der Midi Remote war das erste Mal.

Ich kann ja verstehen, dass Steinberg bzw. deren Mitarbeiter sich in den Foren auch etwas bedeckt halten. Eine falsche Aussage und Du hast die ganze Meute am Hals.
Ein bisschen mehr Tranzparenz wäre aber trotzdem schön.
Also so etwas wie "wir hören euch" oder "wir sind da dran und halten euch auf dem Laufenden".
Dann sollte aber auch ein paar dedizierte Infos kommen. Man muss ja nicht gleich irgendwelche Betriebsgeheimnisse ausplaudern.

Das Prblem mit dem Verweis auf das Forum ist auch nicht ideal.
Zugegeben es gibt dort sehr findige User, die auch helfen, aber solche Threads mit Problemstellungen, die dann auch mehrere User betreffen können dann auch sehr schnell, sehr gross werden.
Ich kann da auch nur wieder von der Midi Remote und den Duplikaten und Zuweisungen sprechen.
Da gibt es Threads die sind seitenlang mit Workarounds und anderen Tipps. Selbst als User steigt man da nicht mehr durch.
Ein Programmierer von Steinberg wird sich da erst recht nicht durchwühlen.

Ich weiß ja, dass Microsoft und Windows nicht so gut angesehen ist, aber ich möchte doch einen Lob für einen Mitarbeiter aussprechen. Und zwar für Pete Brown, der die neue Midi Engine in Windows entwickelt. Ich glaube der Mann schläft nie. Ist auf seinem Discord Channel immer im Austausch mit den Usern. Schreibt auch die Hersteller an, ist in Foren aktiv und kann ihn sogar privat über Discord anschreiben und er antwortet.
BEe ihm hat man das Gefühl, dass man verstanden wird und er redet auch nicht alles schön.

 

[C14 - frag mich]

Ich versuche, es nochmal zu formulieren: Ich habe Dir/Euch gesagt, was es mit den Tags "issue" und "feature-request" auf sich hat, bzw. wann ein Mitarbeiter von Steinberg von einem Bug und wann von einem Featurewunsch spricht.
Ich hatte gehofft, dass diese Erklärung es verständlicher macht, warum ein selbstempfundener Bug von Steinberg als Featurewunsch eingestuft wird.

 

[akl]

Ich versuche, es nochmal zu formulieren: Ich habe Dir/Euch gesagt, was es mit den Tags "issue" und "feature-request" auf sich hat, bzw. wann ein Mitarbeiter von Steinberg von einem Bug und wann von einem Featurewunsch spricht.
Ich hatte gehofft, dass diese Erklärung es verständlicher macht, warum ein selbstempfundener Bug von Steinberg als Featurewunsch eingestuft wird.

Verstanden habe ich Dich beim ersten Mal. Einverstanden bin ich deswegen nicht.

Dass Steinberg intern zwischen Bug und Featurewunsch trennt und wie das getaggt wird, war nie strittig.

Ich habe ausführlich geantwortet: dass die Spezifikation selbst der Fehler sein kann, dass die Einstufung als Feature-Request sehr wohl über die Priorität mitentscheidet, und mir darüber hinaus vor allem Meldewege fehlen, über die eine Designentscheidung noch einmal geprüft wird.

Auf keinen dieser Punkte gehst Du ein. Im Gegenteil: Du wiederholst die Erklärung und machst aus meinem Einwand ein Verständnisproblem. Sorry, aber ich lasse mir auf diese Art kein X für ein U vormachen.

Zum "selbstempfundenen Bug": Was mich als Anwender in der täglichen Arbeit ausbremst, ist nicht "selbstempfunden" (oder erfunden), das ist die Praxis im Umgang mit Steinberg-Produkten, die ich käuflich erworben habe.

Passt aber ins Bild. Anstatt sich zu bemühen, den Kundensupport zu verbessern, wird Wortklauberei betrieben.
Man sollte mal den Blick über den Tellerrand heben und überlegen, was guten Support ausmacht.

 

[Joost]

Ich versuche, es nochmal zu formulieren: Ich habe Dir/Euch gesagt, was es mit den Tags "issue" und "feature-request" auf sich hat, bzw. wann ein Mitarbeiter von Steinberg von einem Bug und wann von einem Featurewunsch spricht.
Ich hatte gehofft, dass diese Erklärung es verständlicher macht, warum ein selbstempfundener Bug von Steinberg als Featurewunsch eingestuft wird.

Für mich ist das Handling von Bugs und Features zumindest klar. Außerdem muss man auch berücksichtigen, daß die Support Mitarbeiter auch unterscheiden können müssen, ob es ein Bug oder Feature ist, was da angefragt wurde. Manchmal leiten sich auch aus der Kommunikation Einträge in der Wissens DB des Supports ab, um weitere Anfragen schneller beantworten zu können - oder das läuft inzwischen über ein LLM...

Wenn in solch einem öffentlichen Support Forum Bugs oder Features eingekippt werden, muss der Inhalt ja auch erstmal durchgearbeitet werden, bevor dieser an die Entwickler geht und dann diese Themen in einen Sprint eingeplant werden und somit auch definiert wird ob und wann (in welchem Release) sie ausgeliefert werden können.Soetwas dauert oft länger, als es sich ein Benutzer wünscht.

Bei einem solch großen Projekt ist das eine Menge Planungsarbeit bevor ein Fix angegangen wird, die Benutzer in den seltensten Fällen verstehen.

 

[C14 - frag mich]

Was das Arbeiten mit Templates angeht: Wenn man die gleiche Aufnahmesituation hat, dann wäre es schön, wenn Cubase und Nuendo den Record-armed-Status der Spuren speichern und wiederherstellen würden, wie es andere DAWs auch tun (Studio One, Fender Studio Pro). Presonus macht das, aber Steinberg nicht.

Ich habe mir das Thema nun mal angeschaut und vielleicht eine sinnvolle Idee.
Wenn man ein Template abspeichert, wird zwar nicht der Status "Record Enable" für die Spuren abgespeichert. Wohl aber, ob eine Spur ausgewählt ist oder nicht.
Du könntest also alle Spuren auswählen, die Du nach dem Laden scharf geschaltet haben möchtest. Entweder hälst Du dann Alt+Shift / Opt+Shift um Q-Link zu aktivieren und klickst dann bei einem Track auf das Feld. Das schaltet dann alle ausgewählten Spuren scharf. Oder Du wählst in den Präferenzen aus, dass ausgewählte Spuren automatisch scharf geschaltet werden sollen. Dann bräuchtest Du nach dem Laden gar nichts weiter tun.

Das hilft natürlich nur unmittelbar nach dem Laden.

Wenn es im weiteren Verlauf des Bearbeitens auch funktionieren soll, könntest Du die Spuren, die Du immer wieder scharfschalten möchtest, im Namen mit einem speziellen Zusatz versehen, z.B. (Arm).
Dann kannst Du ein Preset im Projekt Logical Editor erstellen, dass alle Spuren auswählt, die diese Zeichenfolge enthalten. Im gleichen Preset sollte dann das scharfschalten möglich sein.
Das kannst Du Dir auf ein Tastaturkommando legen oder den Aufruf per Midi Remote einrichten.