M
Mr.Pink
||||||||
Reaper 6.71 unterstützt CLAP.
D
danielrast
Guest
Ich habe heute mal Vital in Bitwig im CLAP Format ausprobiert. Leider ein Fail, da die GUI nicht richtig funktioniert hat. War da etwas überrascht.
Benutzt hier jemand regelmäßig CLAP Plugins? Es wäre ja mal interessant zu hören was stabil läuft und was nicht.
Benutzt hier jemand regelmäßig CLAP Plugins? Es wäre ja mal interessant zu hören was stabil läuft und was nicht.
moss
|||||
Alles von u-he.
hansolo
|
Diverse Plugins von TAL in Reaper.
T
Turing
Thou shalt not loop
Leider wird CLAP von JUCE noch nicht unterstützt.
Da ich selbst mit JUCE entwickle, bedauere ich das auch ganz persönlich, aber ich bin ein Nichts und es gibt viele große und relevante Namen, die auch betroffen sind bzw. die umgekehrt von einer Unterstützung von CLAP in JUCE profitieren würden. Damit hätte man im Handumdrehen sehr viele Hersteller/Produkte mit im Boot.
Es muss aber auch gesagt werden, dass die JUCE-Philosophie bisher darin bestanden hat, nur den Funktionsumfang abzudecken, der von allen Plugin-Standards abgedeckt wird, so dass ein gegebener Softsynth oder Effekt Plugin auf jeder Plattform und unabhängig vom Plugin-Format immer gleich klingt und dasselbe kann.
Das hat in der Vergangenheit schon dazu geführt, dass Neuerungen wie etwa die grundsätzlich in VST3 mögliche Sample-akkurate Automatisierung nicht umgesetzt wurden, weil sie über die Mimimal-Schnittstelle des von allen Formaten unterstützten Funktionsumfangs hinausgeht (und vermutlich ein Re-Design wichtiger interner Schnittstellen erfordern würde).
In ähnlicher Weise würde vermutlich eine CLAP-Unterstützung in JUCE nicht dazu führen, dass mit JUCE realisierte Plugins von den erweiterten Möglichkeiten von CLAP profitieren würden. Sie würde lediglich dazu führen, dass man die entsprechenden Produkte auch als CLAP-Plugins anbieten könnte, so dass sie auf CLAP unterstützenden Hosts nutzbar würden.
Ich wünsche mit sehr, dass JUCE hier einmal vorwärtsgewandter agieren und z.B. alternativ zu den bisherigen Schnittstellen eine "neue" Schnittstelle anbieten würde, die z.B. sample-genaue Automatisierung besser unterstützt - oder eben auch fortschrittliche Features, die erst durch CLAP möglich werden.
Wie ich gesehen habe, gibt es ja auch tatsächlich Bemühungen, CLAP-Support für JUCE bereitzustellen, und dabei auch die innovativen Möglichkeiten nutzbar zu machen. Leider haben es die juce-clap-extensions bisher noch nicht ins offizielle Framework geschafft. Stattdessen hat der CLAP-Support hier weiterhin den Status eines noch nicht umgesetzten Feature Requests.
Das oben erwähnte Vital ist ja auch JUCE-basiert. Wenn das bisher als CLAP Plugin (dann vermutlich über die juce-clap-extensions realisiert?) nicht stabil funktioniert, dann schafft das nicht unbedingt Vertrauen, die Extension jetzt bereits zu nutzen. Andererseits wurden für Surge XT und Dexed mit Hilfe der juce-clap-extensions ensprechende CLAP-Plugins umgesetzt, und dies offenbar erfolgreich.
Was das Überschreiben des Plugin-Zustands bei bisherigen Plugins (wie VST3) durch Automatisierung angeht: Damit hatte ich nie ein Problem.
Ich "vertraue" der DAW sowieso nicht, was die Speicherung des Plugin-Zustands angeht. Man hat doch realistischerweise immer mal wieder Fälle, in denen eine Plugin-Instanz neu geladen werden muss, weil sie gecrasht ist. Und in einem solchen Fall ist es ein Ärgernis, wenn der Plugin-Zustand nur in der DAW existiert hat und nicht innerhalb des Plugins als Patch gesichert wurde. Letzteres mache ich daher aus leidvoller Erfahrung sowieso immer und dann ist es auch egal, dass die DAW bei der Automatisierung alle Knöpfe "verdreht".
Der Vorteil der absoluten Automatisierung ist, dass man genau versteht, welchen Einfluss der Wert des Parameters in der DAW hat - insbesondere wenn sich die Slider in der GUI dann auch in derselben nachvollziehbaren Weise bewegen. (Bei einer relativen, reversiblen Automatisierung durch temporäre Parameter-"Offsets" ist das durch eine zusätzliche Visualisierung natürlich auch zu erreichen, man kriegt es aber nicht sozusagen "geschenkt" wie bei bisherigen Plugins mit der Gleichsetzung von Automatisierungs-Sollwert und Parameter-Wert im Plugin.)
Da ich selbst mit JUCE entwickle, bedauere ich das auch ganz persönlich, aber ich bin ein Nichts und es gibt viele große und relevante Namen, die auch betroffen sind bzw. die umgekehrt von einer Unterstützung von CLAP in JUCE profitieren würden. Damit hätte man im Handumdrehen sehr viele Hersteller/Produkte mit im Boot.
Es muss aber auch gesagt werden, dass die JUCE-Philosophie bisher darin bestanden hat, nur den Funktionsumfang abzudecken, der von allen Plugin-Standards abgedeckt wird, so dass ein gegebener Softsynth oder Effekt Plugin auf jeder Plattform und unabhängig vom Plugin-Format immer gleich klingt und dasselbe kann.
Das hat in der Vergangenheit schon dazu geführt, dass Neuerungen wie etwa die grundsätzlich in VST3 mögliche Sample-akkurate Automatisierung nicht umgesetzt wurden, weil sie über die Mimimal-Schnittstelle des von allen Formaten unterstützten Funktionsumfangs hinausgeht (und vermutlich ein Re-Design wichtiger interner Schnittstellen erfordern würde).
In ähnlicher Weise würde vermutlich eine CLAP-Unterstützung in JUCE nicht dazu führen, dass mit JUCE realisierte Plugins von den erweiterten Möglichkeiten von CLAP profitieren würden. Sie würde lediglich dazu führen, dass man die entsprechenden Produkte auch als CLAP-Plugins anbieten könnte, so dass sie auf CLAP unterstützenden Hosts nutzbar würden.
Ich wünsche mit sehr, dass JUCE hier einmal vorwärtsgewandter agieren und z.B. alternativ zu den bisherigen Schnittstellen eine "neue" Schnittstelle anbieten würde, die z.B. sample-genaue Automatisierung besser unterstützt - oder eben auch fortschrittliche Features, die erst durch CLAP möglich werden.
Wie ich gesehen habe, gibt es ja auch tatsächlich Bemühungen, CLAP-Support für JUCE bereitzustellen, und dabei auch die innovativen Möglichkeiten nutzbar zu machen. Leider haben es die juce-clap-extensions bisher noch nicht ins offizielle Framework geschafft. Stattdessen hat der CLAP-Support hier weiterhin den Status eines noch nicht umgesetzten Feature Requests.
Das oben erwähnte Vital ist ja auch JUCE-basiert. Wenn das bisher als CLAP Plugin (dann vermutlich über die juce-clap-extensions realisiert?) nicht stabil funktioniert, dann schafft das nicht unbedingt Vertrauen, die Extension jetzt bereits zu nutzen. Andererseits wurden für Surge XT und Dexed mit Hilfe der juce-clap-extensions ensprechende CLAP-Plugins umgesetzt, und dies offenbar erfolgreich.
Was das Überschreiben des Plugin-Zustands bei bisherigen Plugins (wie VST3) durch Automatisierung angeht: Damit hatte ich nie ein Problem.
Ich "vertraue" der DAW sowieso nicht, was die Speicherung des Plugin-Zustands angeht. Man hat doch realistischerweise immer mal wieder Fälle, in denen eine Plugin-Instanz neu geladen werden muss, weil sie gecrasht ist. Und in einem solchen Fall ist es ein Ärgernis, wenn der Plugin-Zustand nur in der DAW existiert hat und nicht innerhalb des Plugins als Patch gesichert wurde. Letzteres mache ich daher aus leidvoller Erfahrung sowieso immer und dann ist es auch egal, dass die DAW bei der Automatisierung alle Knöpfe "verdreht".
Der Vorteil der absoluten Automatisierung ist, dass man genau versteht, welchen Einfluss der Wert des Parameters in der DAW hat - insbesondere wenn sich die Slider in der GUI dann auch in derselben nachvollziehbaren Weise bewegen. (Bei einer relativen, reversiblen Automatisierung durch temporäre Parameter-"Offsets" ist das durch eine zusätzliche Visualisierung natürlich auch zu erreichen, man kriegt es aber nicht sozusagen "geschenkt" wie bei bisherigen Plugins mit der Gleichsetzung von Automatisierungs-Sollwert und Parameter-Wert im Plugin.)
Zuletzt bearbeitet:
News
-
News SequencerTalk 226 - Synthesizer Transporte & Aufstellung & News - heute 20:30 live- Gestartet von Moogulator
- Antworten: 1
-
News 26.11.24 SequencerTalk 225 über Akkorde, Organisation und Tape ohne Tape
- Gestartet von Moogulator
- Antworten: 1