Ich glaube die Jungs von Presonus haben hier im Forum mitgelesen und die Wünsche, die wir für die Generic Remote hatten, einfach mal für S1 umgesezt.
Dort wird je nach Focuswindow für das jeweilige Plugin die Controllerbelegung umgeschaltet.
Ich hoffe das Steinberg sich davon ne Scheibe abschneiden kann.
Wie ihr sehen könnt schläft die Konkurrenz nicht:
sehr nice!
Wenn man für Automationen einen eigenen Spurtyp hätte (schneiden,insert,send,kopieren…) bzw auf den Midi-spuren den Automatisierten Parameternamen in den Listen hätte, wäre es perfekt…
Dafür!!
Noch etwas…
Da Presonus/Kundrus ne Menge Gutes bei Steinberg/Cubase geklaut hat (man schaue sich nur mal den Kern an, unglaublich was da von Cubase/Nuendo stammt!) - wird es jetzt an der Zeit, dass Steinberg mal bei Studio One klaut!
Nur keine Skrupel, Steinberger: klaut bitte mal den S1-Mixer, Drag/Drop, Ausblenden von Spuren, Copy/Paste/Compare in den Plugins, den OnBoard-Sampler, und die o.g. Controllereinbindung…
(alles andere ist in Cubase definitiv aber besser)
Mit freundl. Gruss
Central
Irgendwie scheint mir Steinberg ein wenig hochnäsig geworden zu sein.
Ein damaliger Entwickler hatte in einem Forum geschrieben, das sie früher nur die super Ideen der User umgesetzt haben und das Produkt (Cubase) deswegen so gut geworden ist.
Heute wird doch kaum mehr auf uns gehört, da hat die Marketingabteilung wohl das letzte Wort.
Ich erinnere hiermit noch einmal an das Drag and Drop von Audio innerhalb Cubase zu einem drittanbieter Plugin.
hm. Denke ich nicht.
Das wird eher daran liegen, dass Steinberg mittlerweile so groß geworden ist.
Es ist sicher nicht einfach, sich als Steinberger Mitarbeiter für ein tolles Feature durchzusetzten, wenn man von anderen Kollegen, Vorgesetzten oder Programmierern blockiert wird. Auch wird es ja eine fixierte Zeit- und Featureplanung geben, welche umgesetzt werden muss. Zumal die Japaner ja nun auch ein hohes anteiliges Mitspracherecht intus haben, dort steht aber ganz sicher Gewinnmaximierung an erster Stelle. Vermute ich mal.
Der Kundrus mit seinen 4 oder 5 (?) Mitarbeitern kann es sich “noch” erlauben, anders vorzugehen. Wenn das dort dann wachsen sollte, wird es auch anders laufen. Die werden zusätzlichen Gewinn dann auch nicht verpönen. Wie jede andere marktwirtschaftlich orientierte Firma auch.
Für mich als Kunde ist diese Entwicklung natürlich bedenklich bis schlimm. Aber es ist noch lange kein Grund ewig andere DAWs zu testen oder immer wieder den Sequenzer zu wechseln, wie es genügend andere User täglichst ja betreiben.
Trotzdem finde ich, dass es in den letzten Jahren bei Steinberg merklich besser geworden ist: so ist die Anteilnahme der Mods in diesem Forum, gerade im Englischen Teil, wirklich gut. Verbessert werden kann und sollte immer, klar. Und dies an jeder Stelle, gerade wenn es im Kundenwunschumsetzungen geht.
Ach ja: ich bin es auch leid, ewig Wunschlisten zu tippen. Ein großer Teil davon wurde aber in der Tat längst umgesetzt, sehr rühmlich.
Aber sowas wie ein neuer frei expandierbarer Mixer (alles in einer Ansicht, alles gruppierbar und ausblendbar usw.), oder ein kleiner simpler Drag/Drop OnBoard-Sampler (was ja nun wirklich Standard geworden ist und alle auf dem Markt befindlichen DAWs dabei haben) kann meines Erachtens doch nun wirklich nicht so schwer sein für Steinberg - zumal der Sampler-Code dort in Hamburg ja eh aufgrund die Halion-Produktlinie in der Schublade liegt.
Wir werden sehen…
Gruss
Cent.
“Im Prinzip” gibt es in Cubase ja längst die Möglichkeit der “Umschaltung der Controllerbelegung je nach aktivem Plugin”.
Cubase nutzt dafür die QuickControls: Je nach aktiver Spur wird die Controller-Belegung “umgeschaltet”, der Controlelr steuert je nach aktiver Spur sogar beliebige Parameter Plugin-Übergreifend…
DIESES “spurbezogene Konzept” ist in meinen Augen genial. Das “Anlernen” beliebiger Parameter wurde in v6 auch extremst vereinfacht, das geht also mittlerweile vergleichbar effizient/schnell/unkompliziert wie die Plugin/Controller-Anlernerei in S1v2…
Der “Arbeitsunterschied” ist, dass Cubase “spurbezogen” ist, die Quick-Cotnrollerei ist eher ausgerichtet auf die “zeitliche Veränderung von (wenigen) Parametern”, während S1 “plugin-bezogen” ist, dessen Controllerei ist eher ausgerichtet auf Echtzeit-Steuerung von Plugins…
ICH würde mir beides wünschen. Ich “spiel” auch gern mal in Cubase rum, ohne mich “entlang einer Zeitachse zu orientieren”. Ich bastle an Sounds in nem Plugin, konzentrier meine Arbeit darauf, sitz vor der Klaviatur und schraub an Synth. UND ich möchte dann, später wenn ich im Kontext des Songs arbeite, ein paar Schrauben auch entlang einer Zeitachse modulieren/automatisieren…
Für letzteres sind die Quick-Controls m.E. genial.
Für ersteres benutze ich Automap g oder aber auch Kore2 - und ganz viel auch die Maus gg, trotz Automap und trotz Kore2. Ganz einfach, weil es irre zeitaufwändig ist Plugins/Controller erstmal zu “mappen”, genauso aber auch sich das “Mapping” seines Controllers wieder in Erinnerung zu rufen(! welche Regler war doch bei Tyrell gleich wieder "Attack-Time von Oszillator1??? ach, egal…-> Maus, Mausrad, fertich)
Gerade wenn man mehrere Plugins zur Verfügung hat und “mal eben” irgendwas, mit irgendeinem Plug ausprobieren/rumschrauben will, da geht das (bei mir) oft schneller mit der Maus, statt mich durch meine Automap-Belegung zu suchen, oder im Kore2 die Plugin-Page zu suchen und dort dann noch den Regler… Filter CutOff-Freq? Wo war die gleich nochmal??? Ach, egal…-> Maus, Mausrad, fertich…
Ich bin ABSOLUT dafür, dass Plugins (und andere “Objekte”/Fenster) eine “Context-GenericRemote” bekommen! Ich fürchte aber, dass ich doch eher immer wieder zur Maus greifen würde, außer ich beschäftige mich mal über einen längeren Zeitraum als “mal eben wo was schrauben” ausschließlich mit einem Plugin.
Diese Mapping-Sache ist immer so ein Ding… immer moch noch eine weitere Schicht zwischen mir und dem zu steuernden “Gerät”. Ich SEHE das Gerät und alle Bedienelemente vor mir (auf dem Bildschirm) und könnte jedes beliebige Bedienelement sofort mit der Maus bedienen! Stattdessen greif ich rechts vom Bidlschirm zum SL25MkII und suche auf welcher Page ich doch gleich wieder ein bestimmtes Bedienelement gemappt habe…
Die “Zwischenschicht”, zwischen mir und dem was ich vor mir sehe, die nervt moch langsam g dieses ganze Gemappe geht mir auf den Senkel wenn ich es dann doch nicht nutze, weil ich “nur eben mal” was einstellen will…
Wenn ich mir vorstelle wie das wäre wenn ich statt nen Regler für das Bedienelement zu suchen, und statt zur Maus zu greifen um den Mauszeiger auf das Bedienelement zu positionieren DIREKT auf den Bildschirm fingern könnte, direkt auf das Bedienelement… ohne “gemappe”, und ohne Mauszeiger… What you see is what you control…
Ich befürworte absolut eine “Context-Generic-Remote”!
Aber mir wäre es wirklich lieber, Steinberg arbeitet eher an der “direkten multitouch-Bedienung” und “Skalierung/Verteilung” der "visuellen Bestandteile der Software! Konkret: Wesentliche Überarbeitung der Fensterverwaltung von Cubase, um z.B. “mal eben” ein Plugin-Window auf einen (evtl. transportablen) (Multi)touch-Screen zu befördern um es “dort” dann DIREKT zu bedienen, oder, bereits am/vor dem (evtl. transportablen) (Multi)touch-Screen sitzend sich ein beliebiges Plugin-Window zu holen…
solche Sachen also wie die “V-Window”-Geschichte von “V-Control”, allerdings nicht proprietär an iOS-Geräte gebunden, sondern generisch, in dem es die multiplen, am PC hängenden (touch-) Bildschirme besser unterstützt, inklusive Multitouch-Unterstützung, und auch, als VNC-Server funktionierend und beliebige VNC-Clients als “zusätzlichen” Bildschirm nutzend und “einfach” eine wesentlich bessere Multi-Monitor-Nutzung durch wesentlich bessere Fensterverwaltung möglich machen… DAS wär’s…
Windows 8, beliebige und beliebig viele Multitouch-Screens (Multitouch-Monitore, iOS-/Android-/Windows-Tablets, andere Rechner, Mac, PC im Netz als VNC-Client deren (touch-)Monitore), da sollte was gehen…
Sehr interessantes Statement, TabSel!
Kurzum bin ich der Meinung, dass es simples Midi-Learn für ALLE überhaupt gegebenen Parameter geben sollte.
Die MultiTouch-Controllerei stehe ich bis heute leider eher skeptisch gegenüber: dies ist natürlich meine Meinung, gerade weil ein Studiokollege viel mit dem iPad “kontrolliert”, und ich so auch mit meine Erfahrungen gemacht habe. Nun, ein Hardware-Kontroller von Yamaha/Steinberg in Richtung expandierbarer Mackie-Control würde mir im täglichen Studioalltag absolut mehr liegen. Denn die Schwierigkeit besteht bei diesen Touchbildschirmen, erst mal genau seine Finger zu positionieren um Regler zu bewegen, Solo/Mute überhaupt zu “treffen”, mehrere Fader gleichzeitig (!) korrekt zu bewegen, uvam. Man hat hierbei auch seine Augen dabei viel zu oft auf dem Touchbildschirm, es gibt ja da nichts, was man da als haptische und blind sofort tastbare Orientierung überhaupt hat (die fettige Fingerschmierei auf den Screens erwähne ich jetzt mal nicht.)
Das ist bei Hardware-Potis/Fadern nun wirklich ganz was anders. Bis heute.
Natürlich gibt es genug Anwender, die dem aber äusserst positiv gegenüber stehen, es ist klar, dass die Touchkontrollierung daher auch seitens Cubase forciert werden muss und auch sollte. Mit dem Cubase iC oder auch der LoopMash-App sind erste Tools ja bereits sehr gut von Steinberg umgesetzt worden.
C.
da stimme ich Dir voll zu.
Es ist immer abhängig vom “Kontext” in dem jemand “an etwas” arbeitet. Ergonomie ist äußerst komplex.
Völlig klar: beim Mixen will und braucht man haptisches Feedback. Der “Lautstärke-Mixer” konzentriert sich nicht auf den Bildschirm, sondern auf auf sein Gehör und will mit geschlossenen Augen Lautstärken anpassen. Da ist ne Touch-Bedienung völlig fehl am Platz. Am Besten wäre da eine Hardware-Konsole mit unendlich Fadern, mit nem Display über dem Fader damit der Mixer auch weiß welche Fader er bewegen muß. Dann muß er aber doch wieder die Augen auf machen lach
Schweineteuer ebenso, aber dafür gibt’s ja Mackies, BCFs und anderes warmes geschnitten Brot etc… da hat man dann acht Fader und könnte acht Kanäle sogar blind mixen, weil man nicht mit dem Dreh-Stuhl die Konsole entlang fahren muß g WENN DOCH NUR die gewünschten 8 Kanäle auch immer zur Verfügung wären und man nicht durch hin- und herblätterei der Faderpage DOCH wieder Augen auf den Screen richten muß um zur gewünschen Kanalgruppe im Cubase-Mixer zu hüpfen… Wenn doch nur der Cubase-Mixer als Bildschirm-Window direkt über der unendlichen Anzahl Fader wäre…
Daher sagte ich ja, ich befürworte ABSOLUT kontext-sensitive generic remote controller unterstützung, nicht nur für plugins, sondern für alle Cubase-Fenster - und sogar einzelne “objekte” in den Fenstern…: Stell Dir vor Du klickst auf nen Button auf Kanal 1, 7, 8, 9, 23, 24, 31 und 47 und ohne weiteres Zutun wären diese 8 Kanäle per Mackie oder BCF Fader 1-8 steuerbar… Augen zu und “mal eben” die Gitarren und deren Hall-Return mixen…
Jemand anders wieder arbeitet ausschließlich mit ein, vielleicht zwei Synths. Na wär das nicht toll er hätte das Hadrware-Pendant vor sich? Oder wenigstens auf Knopfdruck seine BCR oder sein MIDI-Keyboard mit dutzenden Reglern und Knöpfen gemappt? Er weiß ja WIE er es gemappt hat, er arbeitet ja ausschließlich mit wenigen Synths und muß nicht überlegen wo was ist…
Wieder andere lassen Ihre Lead-Sequenz laufen und basteln mit der Maus an Parametern im Plugin um den Sound zu finden der Ihnen paßt. Die könnten sich in Ihrem Drehstuhl zurücklehnen mit nem Tablett im Schoß und schrauben direkt am Plugin-GUI rum… Sound gefunden? Parameterverlauf aufnhemen, damit die Lead lebendiger klingt? Dann einfach schnell noch am Tablett auf nen Button im Plugin-Window klicken, die gewollten Parameter berühren (die dadurch automatisch “projektglobalen” Quick-Controlls zugewiesen sind, aufsetzen vor die BCR Cubase-Play-Marker setzen, Wiedergabe starten die 8 BCR-Regler schrauben…
So, stelle ich mir das irgendwie vor. Es soll ja eins nicht das andere ausschließen, sondern sich ergänzen und integrieren…
Auch wahr, ja!
“kontext-sensitive generic remote controller unterstützung, nicht nur für plugins, sondern für alle Cubase-Fenster - und sogar einzelne “objekte” in den Fenstern…”
Aber wie wäre dies umzusetzen? soll ein Controller immer die aktuellen Fenster bedienen, also dann "automatisch “aufs oberste, weil aktivierte umschalten”? Was, wenn man hintere Fenster mit irgendwelchen Paramtern weiterhin controlliert haben möchte? Und müsste man nicht für alles eh Zuweisungen weit vorab treffen? (ich versuche mich gerade hineinzudenken)
so jetzt wart ihr 2 schneller, aber egal…
Ihr habt alle recht, aber eigenständige Automationsspuren^^
zum schneiden, kopieren, Senden auf alle VST Parameter im gesammten cpr., von Midi auf Automation, ohne sich umständlich was über QC oder GR herumschalten zu müssen und sich sogar verschieden ansichten für jede Spuren machen kann (Pan, Vol, Berglandschaft oder auch nur einen dünnen der bei vielen offenen Autoamtionen für verwirrung sorgen kann…
finde ich am wichtigsten.
Wenn man sowas hätte könnte man sich wenn einen die QC ausgehen mehrere machen, und vor allem Spurübergreifend arbeiten, achja und das ganze als “Spurarchiv” speichern können aber wie TrackPresets…
Multitouch ist sowieso zukunft.
Cubase hat halt seine Fenster…
Dass man die Mixer ansichten wircklich alle gleichzeitig einblenden könnte würde ich auch sehr begrüßen. oder Vl, noch zusätzliche Projectfenster oben drauf…
Das feature worums in den Thread eigentlich geht (focus device plugins) wäre sowieso das non plus.
aber wenn das wirklich umgesetzt werden sollte, und man auf eine derart geile weise automationen aufnähmen könnte, wäre es halt toll wenn man mit Automationen auch so wie Midi bearbeiten könnte (in blöcken). weil jetzt ist es toll wenn man am schluss drüber automatisiert, aber wenn in Musikalischen kontex die Automationen wichtiger sind als noten und man sie getrennt von einander bearbeiten will, ist es einfach umständlich und unübersichtlich… (von den Teilweise umständliche routing / wenn man spurübergreifend arbeiten will und kein Midi am Plugin verfügbar ist/ abgesehen davon “muss” man die CC’s wissen - unbenennen… eigentlich unnötig weil die VST Parameter ja eh schon einen namen haben…
Alternativ würde ich sehr begrüßen die Anzahl der QC erhäblich zu erhöhen, dann ersparrt man sich wenigstens die GC wenn man es als überbrückung zwischen Midi u. Automation verwendet.
lass es, macht Kopfweh lach
habt ihr noch nie einen teil von Automatione der euch wircklich wichtig war, gerne in einen Block drinnen gehabt, kopieren, an mehrere Ziele schicken (send), umwandeln (insert), bzw einfach der verdammt Name von den was man tut automatisch dort steht?
mit den anderen meinte ich.
Das lauter 10 nanometer kleine striche, überhaupt wenn man viele hat, nicht gerade die übersichtlichkeit fördern.
Wenn man sich einen mittelstrich dazu einblenden (für Pan zb.) und umschalten kann auf hügellandschaft (wie midi editor) man schon optisch, auf einen blick ordnung in das chaos bringen kann, (wenn man verschiedene ansichten gleichzeitig verwendet) und einfach angenähmer ist zum anschauen weil man sich nicht in den monoton strichen verliert…
das andere sind halte die Blöcke, die man abgesehen vom Editier komfort, als Zeitlichen anhaltspunkt verwenden kann, abgesehen davon ist es NUR mit Cubase (und jeder anderen DAW auch) NICHT möglich alle Parameter eines Plugins mit einer eigenen Spur zu steuern wenn das VST kein MIDI für den Parameter unterstützt, und auch wenn stehen keine Namen dabei…
hoffe das konnte die Kopfschmerzen wenigstens linder.
EDIT: Hab jetzt erst bemerkt es, ging ja gar nicht um meinen post…
die Lösung wäre ganz einfach, es ist nämlich schon fast alles quasi “da” lach
VST-Expression:
Ermöglicht das Aufnehmen/Einzeichnen von “echten” Kruven, also nicht diese MIDI-CC-Event-Strichelei.
Ziel eines dieser VST-Expression-Daten-Kurven kann sein:
jetzt nur noch
dann
bitte diese VST-Expression-Daten-Kurverei auch als “Lane-Typ” im MIDI-Part/Editor ermöglichen, zusätzlich zum MIDI-CC-/Pitchbend-Lane-Typ. Ich mein, der Editor ist ja schon vorhanden (pro Note, aber nicht pro Part, wobei man ja einen Part mit einer Note von vor bis hinten malen und VST-Expression-Daten für diese Note nutzen könnte… was ja dann das gleiche wäre…)
und wenn Ihr schon dabei seid, dann bitte auch (N)RPN unterstützen)
dann hätten wir Part-bezogene Automationsdaten…
MIDI-CC-Konflikte können wie bei VST-Expression per “Konsolidierung” gelöst werden (allerdings in Echtzeit bitte, nicht offline wie bisher) und Automationskonflikte ebenso per Echtzeit-Konsolidierung, Mixing oder Trimming, wie auch immer, einstellbar…
Könnte man dann auch eine Automation auf mehrere Ziele senden?
Der Thread kommt gerade schön in Wallung, ich finde wir haben schon viele Verbesserungsvorschläge.
Ich wäre auch für eine Erweiterung der VST Expression.
Bitte den AI Knob mit in die Generic Remote einbauen und die vergessenen Parameter (Channel EQ Type etc.) noch in der GR nachpflegen.
Und bitte das “Schreiben der Automation sofort beenden wenn der Wert sich nicht ändert” noch mit ins Automationsmenü aufnehmen.
Bisher wird das Schreiben der Automation erst nach 2sekunden der letzten Wertänderung ausgesetzt.
DAS ist der Grund!!! Oh man KopfKlatsch
Als VST Expression raus kam war mein erster Gedanke: WARUM denn bitte nur MIDI-CC und VST3.5-Parameter??? Ich hab bei der Ankündigung von VST Expression so gehofft dass ich damit pro Note irgendeinen VST Automation Parameter steuern könnte und war erst so enttäuscht… aber durch Deine Frage ist mir das jetzt klar:
Eine MIDI-Spur, damit MIDI-Parts und damit VST-Expression-Daten werden ja immer an ein Device geroutet: Ein VSTi, oder ein MIDI-port. Per Send auch an bis zu vier weitere Devices… Wenn man nun im VST Expression Editor einen bestimmten VST Automation Parameter wählen könnte, ja, wo soll denn der dann hingeroutet werden… Logisch!!!
Also, um Deine Frage zu beantworten: Nein. Und es wird wohl auch nicht kommen, dass man irgendeinen VST Parameter im VST Expression-Editor verwenden kann!!!
Ok, nochmal überlegen: Eine Möglichkeit wäre die von Dir vorgeschlagene: Automationsspuren “abkoppeln” vom Parent-Device, stattdessen als eigenständiger Spurtyp, mit Parts wie bei MIDI- und Audio-Spuren und eigenen Spurparametern wie Konfliktverhalten (Mixing, Trmming), Output (EIN VST-Parameter), mehrere Sends (beliebige andere VST-Parameter etc…)…
Was mir auch noch in der Generic Remote fehlt ist die Möglicheit die Mixerpresets umzuschalten.
Quasi die Funktion die die Mackie Control “Fader Banks” Buttons bieten, mit in die Generic Remote aufnehmen.
Bitte gebt auch eine Möglichkeit die Namen der Generischen Controller unter Fernbedienungsgeräte zu ändern, das erhöht die Übersicht.
Ich habe bisher 4 Generische Controller inkl. einer Mackie Control in den Ferbedienungen.
Sehr wichtig wäre es auch die Mackie Controls selbst als Extender umzuschalten.
Bisher funktioniert das ja automatisch.
Hintergrund:
Man hat ein Problem wenn man zusätzlich einen MCU Controller (IPad mit Lemur MCU Emulation) einbinden will.
Die zusätzliche MCU wird immer als Extender angesehen.
Wenn man nun mehrere Mackie Controls als Master anlegen könnte würde das ganze funktionieren.
Ein weiteren Wunsch hätte ich noch.
Midi Makros pro Spur anlegen zu können (als Erweiterung der QCs).
Diese Funktion hat Ableton Live schon länger.
Das Gute dabei ist, das man dann über einen Controller gleich mehrere andere Controlziele in den Wertebereichen anlegen kann (sogar invertieren).
In diesem Video kann man das sehr schön sehen:
was auch geil wär wenn man die anglernten Quickcontrols, oder was auch immer, den gemappten Automations-Parameter auf einen Display am Controller ausgeben könnte, via sysex oder so, dass die Hardware Hersteller endlich mal anfangen Dispalys auf ihren Controllern zu montieren… und wenn ihr schon dabei seid könntet ihr doch gleich einmal eine Möglichkeit schaffen die Plugin-Menu-Ordner von vst2 plugins und vst3 überhaut zu verwalten ohne dass man sich wie in der Steinzeit vorkommt… 
Das MIDI Manifest…
Dauerhaft sollte man nun von den sehr sich ausruhenden Herstellern zum Thema Midi.
Was gebraucht wird:
what is necessary: