Nieuwe plugin-standaard "CLAP"

uhe-clap-header-1100x290.jpg


Bitwig en U-He hebben een nieuwe plugin-standaard geintroduceerd genaamd "CLAP".

Het lijkt me best indrukwekkend:




Advantages of CLAP for Musicians

Developed in collaboration with experts from diverse fields in the music software industry, CLAP is a cutting-edge plug-in standard, designed for modern computers, software, and paradigms. CLAP caters to novel DAW concepts, and opens up new horizons for what a plug-in can do or be.


Here are some immediately useful advantages of CLAP:


Better Performance From Modern CPUs

Developed with modern CPUs in mind, CLAP takes multi-thread management to a new level, with a clear and efficient allocation of roles between plug-in and host. Specifically, CLAP allows collaborative multicore support between plug-in and host through a so-called “thread-pool”, also allowing hosts to manage CPU-threading for plug-ins that provide their own multicore support. Preliminary tests show significant performance gains compared with current solutions.


Better and Faster Organization

CLAP hosts can read plug-in metadata and help organize your plug-ins. As CLAP hosts can retrieve information from plug-ins without having to wait for them to initialize, plug-in scans can be much faster.


Furthermore, we’re currently finalizing an extension which lets plug-ins tell the host which files they need (e.g. samples or wavetables), and the host can consolidate those in the project file. That means you'll never lose a sample while transferring a project between systems!


Better Modulation

The CLAP standard promotes new ways to create music with automation, modulation, and expressions. Here are a few examples:


CLAP supports per-note automation and modulation (in accordance with the recent MIDI 2.0 specifications).
Going one step further, CLAP’s parameter modulation concept allows for temporary parameter offsets. Parameter modulation is non-destructive, so as soon as the modulation has finished, the target parameter will return to its original state.
CLAP makes it possible for polyphonic plug-ins to have their per-voice parameters modulated for individual notes (“MPE on steroids”).

With this new standard we aim to inspire host developers to add exciting new features to their products. Initial implementations by Bitwig, u-he and the Surge project demonstrate just a few of the possibilities.
 
Last edited by a moderator:
Hoi Forum,

Wat een mooie discussie voeren jullie rondom CLAP.
Ik ben zelf meer developer dan muzikant dus ik wil graag mijn two cents geven.
Allereerst zie ik hier veel muzikanten (logisch) waarbij sommige de meerwaarde
van 'alweer een plugin format' niet zien, omdat er maar weinig nieuws onder de zon is.
Ja, daar is CLAP dan ook niet om begonnen.
(Ik switch nu naar developer). Wij als developers worden al jaren tegengewerkt door Steinberg.
We hadden VST2.4 en dat is niets meer dan een API/beschrijving hoe je een Host en een Plugin
laat samenwerken. Het is dus een beschrijving. Geen Code, geen 'framework'.
Iedereen was happy, totdat Steinberg zeer actief VST 2.4 begon tegen te werken.
Opeens moesten developers een license hebben of tekenen, waarbij van alles werd ge-eist.
Dit terwijl eerder de beschrijving opnbaar was. De laatste jaren is het zelfs zo dat open source
software die op Github staat (ik heb er ook een paar) die VST2.4 implementeerd actief door
Steinberg benaderd worden (me too) om dat te verwijderen. Dat is bij developers zeer slecht gevallen.
Veel van hen konden niet meer ontwikkelen omdat ze geen license hadden en ook niet meer kregen van Steinberg.
'We' worden gedwongen VST3 te omaramen, maar daar zijn veel zaken die in VST2.4 werkten gewoon
verwijderd (ik noem de MIDI CC/PRG etc functionaliteit, waardoor heel veel MIDI 'Arpeggio/Sequence'
gewoon weg niet lopen onder VST3) en als je hierbij navraag doet bij Steinberg reageren ze niet of nauwelijks.
Kortom, zij dicteren een standaard en staan niet open voor wensen van ontwikkelaars. Sterker nog 'als het
maar met Cubase werkt'.
Developers hebben al lang gezien: een API/beschrijving moet publiek zijn, in plaats van in handen van 1 partij.
Vergelijk het met HTML5, vroeger was Microsoft vaak bezig met eigen HTML extensies, zonder zich aan te trekken van de rest.
Dat liep uiteindelijk helemaal de soep in.
De developers hebben al veel pogingen gedaan om een nieuw open format te verzinnen,
om maar van Steinbergs nukken af te zijn.
(iedere maand staat er op KvR weer een nieuw poging, maar het bloed iedere keer dood, want zo simpel is het niet.)
(Er is een open source format LV2, maar dat wordt maar moeizaam omarmt...).

CLAP zou nu dit Open Format kunnen worden, sterker nog, het is er nu dus.
De makers (en dat is niet Bitwig of U-he) zijn er lang mee bezig geweest, maar juist de omarming van een
belangrijke Host-fabrikant (en ook plugin fabrikant) ontbrak. Bitwig en U-he hebben nu dit momentum gegeven.
Ik hoop dat Reaper snel zal volgen.
Om het voor muzikanten interessant maken zijn er in CLAP nu al wat extensies op genomen, maar voor muzikanten zou
hopelijk het belang van een Open API ook duidelijk moeten zijn/worden: Alle standaarden in de computerindustrie moeten gewoon
Open zijn.

Nog wat misverstanden uit de weg helpen:
- De API is taal-onafhankelijk. Dus het kan in C, C++, Delphi, whatever you want. Er is een ABI gebaseerd op C en dat maakt het geschikt
voor iedere programmeertaal. (Je hoeft NIETS met C te doen, veel developers gebruiken C++) [ Steinberg heeft een eigen, vreselijkj ingewikkeldead een eigen
- Het is geen tool waarme je zowel VST, AU, etcetera kunt genereren. Die tools bestaan wel (Juce en Iplug2), men heeft voor JUCE nu een extensie
naar CLAP gemaakt: Dus als je de tool Juce gebruikt en je code in C++, dan kan JUCE nu meteen een CLAP genereren.

Er is nog veel meer te vertellen, maar voor nu lijkt het me genoeg.
Ik ben er superblij mee, na de vakantie maar weer eens wat dingetjes maken...
 
@ Eduur

Hartelijk dank voor deze duidelijke uitleg. SynthEdit had naar ik begreep ook al problemen met Steinberg gehad omdat Steinberg het gebruik van VST2 na de introductie van VST3 onmogelijk probeert te maken.

Nog even over API en ABI, om de VST API te vervangen zou je toch een andere API moeten hebben, of volstaat een ABI ook?
 
een ABI is een nogal technisch begrip:
Het betekent dat er een eenduidige wijze is hoe functies vanuit de Plugin naar de Host kunnen worden aangeroepen.
een C ABI betekent dan dat de functies makkelijk vanuit C werken. Maar omdat C nogal een simpel protocol hiervoor gebruikt
is het ook eenvoudig dit te vervangen door bv. Delphi.
De Steinberg ABI is echter in C++ geschreven en dat is voor andere programmeertalen echt moeilijk precies zo te doen.
De VST2.4 spec was gewoon een C ABI en dus prettig voor ontwikkelaars (en prettig betekent vaak: Minder Bugs).

Oef, na deze moeilijke woorden: Clap heeft (uiteraard) een andere API dan VST, anders
was het een copy en dan zit Steinberg je meteen op de hielen.

Verschillende APIs (Application Programmers Interface) betekent voor developers iedere keer
een andere manier hoe met het betreffende protocol om te gaan. Dat is bijna geen doen, want Developers
willen zich concentreren om mooie plugins te maken, dus vooral DSP werk.
Het switchen van de ene naar de andere API kost gemiddeld zo'n maand werk.
Daarom zijn er frameworks zoals JUCE en Iplug2 (en ik heb zelf ook wat gebroddeld),
waarmee je (zoals dat mooi heet:) APIs weg abstraheerd. Oef, dat betekent eigenlijk
dat JUCE weer een andere API aanlevert, maar dat, als je je daar aan houdt, je wel meteen
met wat tools de diverse plugin soorten kunt opleveren.
Veel developers gebruiken zoiets, maar sommigen hebben al zoveel legacy data geschreven,
dat ze hier geen gebruik van kunnen maken en voor ieder protocol weer aan de slag mogen.

Antwoord op je vraag: Om VST API te vervangen moet je 'gewoon' een andere maken, liefst eentje die flexibel is
naar de toekomst (MIDI 2.0) en liefst een waar iedereen aan kan bijdragen, ipv. een opperhoofd met bijbedoeling.
Welke ABI die API gebruikt is minder relevant, maar 'hoe platter hoe beter' (dat zegt je waarschijnlijk niks,
maar de C ABI is zo plat als een dubbeltje, de Steinberg ABI 'niet'). Lees maar even hier hoe blij developers zijn:

en een quote van een developer aldaar:

"I really like that this is a C API and not a C++ API.
Writing bindings is going to be much easier.
I'll probably look into this more when/if Reaper gets support for it."

[Ik wacht ook op Reaper..., dan is de beer echt los ]

Synthedit is een heel ander verhaal... Wat een prachtige tool was/is dat: Hiermee konden
ook minder geoefende developers mooie interfaces en mooie DSPs maken.
Maar synthedit had last van de remmende voorsprong: Alles was gebaseerd op 32 bits.
En er zijn heel veel mensen die voor SynthEdit gratis uitbreidingen maakten. Al die code zat verweven
in het Synthedit model. Maar toen gingen we 64 bit. Voor developers geen echt probleem: Vaak betekent het het
gewoon omzetten van een optie, opnieuw bouwen en hup, je hebt een 64 bits plugin.
Maar met synthedit gaat dat niet: Er waren al vele 'hulpstukken' aangeleverd door externe partijen.
Die moet je dus ook opnieuw bouwen, maar helaas, vele developers waren al weg en bezig met andere dingen.
Daarom is het niet mogelijk 64 bits te krijgen.
VST3 draait geloof ik alleen 64 bits (terecht hoor) dus kan Synthedit nooit naar VST3. Maar ook met CLAP zal hier
geen stap gezet kunnen worden. Jammer.... Ik ben een nogal conservatief muziekmaker en ik gebruik echt veel Synthedit
plugins (verbaast me vaak!), Arminator 2 vind ik echt de beste CS80 emulator....
 
moah Synthedit.... wat ik me herinner van Synthedit zijn de klaagzangen van die maker (naam vergeten) in de nieuwsgroepen over dat ie nooit geld zag van wat ie gemaakt had "voor de community" en over piracy en zelfde soort constructies probeerde in te voeren als Steinberg nu doet, betreft het gebruiken van synthedit voor de gewone mensch.
dat was een reden voor veel devs om direct in c++ (of whatever taaltje) plugins te gaan maken, en ineens waren die ook veel stabieler en sneller :).

Ik krijg wel een beetje de indruk dat Steinberg een beetje tot de kop van jut is verworden in "het wereldje" en dat het stoer en hip(ster) is om anti te zijn.

ik ben eerlijk in deze, het boeit me maar weinig. of ik mijn geniale muziek nu maak met een vst32 vst2 vst3 of een sample. ik weet wel dat ik al een beetje hekel begin te krijgen aan dat geclap.
 
Oude 32-bit versies van SynthEdit zijn gratis te downloaden van de SynthEdit site, ik heb er nu eentje draaien op een oud laptopje met Windows XP. Heel leuk speelgoed, dus van mij hoor je geen geklaag. Voor nieuwere versies van SynthEdit moet je inderdaad betalen, en dat is de maker zijn goed recht.
 
@Nap ja dingen als JSFX, Faust, SOUL (defunct) en nu Soundstacks zijn eigenlijk zulke manieren een soort "script" te hebben dat geinterpreteerd of "just in time" gecompiled tot een machine specifiek executable. Maar wil je uitgebreide DSP doen zullen developers altijd zo dicht mogelijk tegen het metaal aan willen zitten, en dan kom je dus toch uit bij C/C++/Rust/etc. en moet je voor elk OS en architectuur specifiek compilen.

Daarover gesproken de developer achter Yabridge (manier om met wine windows plugins op linux te draaien) heeft een plugin framework gechreven in Rust dat ook CLAP ondersteund. GitHub - robbert-vdh/nih-plug: Rust VST3 and CLAP plugin framework and plugins - because everything is better when you do it yourself
Als daar ooit ook eens LV2 in komt dan lijkt me dat wel een leuke manier om met Rust te spelen :)
 
Uli B. werkt aan een nieuwe DAW. Als die er eenmaal is, het maakt alle andere DAWs en standaarden voor plugins op slag obsolete. *D
Ja, da's waar, ik las pas geleden dat ie pas rond 2030 uitkomt, schijnt door een tekort aan chips te komen. :D
Maar ff zonder gekheid, ik ben er reuze benieuwd naar maar het duurt wel weer eeuwen, je leest er ook verder helemaal niets van of zo.
 
@krautrock1958 : Weet niet of dit ook op het forum was, dit is van afgelopen maart. Dus kennelijk zijn ze er wel mee bezig. Geen aankondiging van een release-datum ofzo.

 
Wordt dat free software (freeware)? Met gratis VST emulaties van iconische synths? Waarom zouden ze dat als bedrijf doen?
 
Als die DAW alleen door Behringer hardware controlers is aan te sturen zal het geen grote impact hebben, maar als je er een wlilekeurig MIDI keyboardje op kunt aansluiten wordt dat anders. Vooral die gratis VST emulaties van iconische synths spreken mij aan. Goeie gratis VST emulaties van iconische synths zijn immers zeldzaam.
 
Tenzijn die pauper-freeware-daw van behringer CLAP gaat ondersteunen heeft dit echt he-le-maal niks met dit topic te maken.
 
Interessant - een nieuwe categorie software: de "pauper-freeware-daw". Zouden LMMS, Rosegarden en SunFox ook pauper-freeware-daw's zijn vraag ik me dan af. En ben ik zelf dan wellicht ook een pauper. Of is een DAW alleen een echte "pauper-freeware-daw" als er Behringer op staat, ongeacht hoe dat programma er uiteindelijk uit komt te zien? :?
 
Back
Top