Det har sagts att bästa sättet att bli bekant med ett instrument, är att lära sig spela det. Det näst bästa, är ett samtal med någon som har lärt sig att spela det.

Man behöver inte kunna göra plugins själv, för att kunna använda dom; precis som man inte blir bättre bilförare genom att bli bilmekaniker. Men det kan öka förståelsen för hur plugins fungerar, vad som kan vara fel om något strular, och man kan få en betydligt bättre "karta" över det universum av plugins som finns, och ständigt förändras.

Ett ljud/musikprogram har en viss funtionalitet. Men flera program är gjorda så att man kan införa ny funktionalitet i programmet; man kan 'plugga in' en extern digital modul som utökar programmets funktionalitet med vissa egenskaper. En sån extern digital modul kallas i allmänhet för 'Plug in' eller plugin. Själva inpluggandet i värdprogrammet kan ske lite olika, beroende på typen av plugin.

Plugins tillverkas - som alla datorprogram och rutiner - genom att programmera dem, i ett datorprogram avsett att skapa datorprogram och liknande digitala rutiner; ett s.k. IDE program.

Microsoft Visual Studio är ett vanligt program vid framställning av plugins

Arbetet att programmera påminner principiellt om att skriva koden till en hemsida - för de som har provat lite sådant. Man startar IDE-programmet, öppnar ett blankt arbetsunderlag, och skriver in kommandon och instruktioner i ett givet programspråk, kommandon och instruktioner som kommer sammanställas till pluginens funktionalitet.

Programmeringsspråket C++ var det första språket för att göra plugins och är det mest grundläggande än idag. Datorkommandon och kod i lågnivå-språk (som C++) ser märkliga ut för ett ovant öga, men har en extremt logisk – om än komplex – struktur:

union LongDoubleNum
{
long double dx; //12 bytes variable
long lx[3]; // 3 * 4 bytes variable
}ldn;

int main()
{
fn.fx = -118.6253433; //variable assignment declaration statement
//show size of float
cout << "\nsize of float = " << dec << sizeof(fn.fx) << endl;
cout << setprecision(10) << fn.fx << " = 0x" << hex << fn.lx << endl;

dn.dx = 112.6255678; //assign value to a variable
//show size of double
cout << "\nsize of double = " << dec << sizeof(dn.dx) << endl;
cout << dn.dx <<" = 0x" << hex << dn.lx << endl;

ldn.dx = -12.61256125; //assign value to a variable
//show size of long double
cout << "\nsize of long double = " << dec << sizeof(ldn.dx) << endl;
cout << setprecision(10) << ldn.dx << " = 0x" << hex << ldn.lx[2] << ldn.lx[1] << ldn.lx[0] << endl;
return 0;
}

För att ett värdprogram ska kunna läsa en framställd plugin, och kommunikationen mellan värdprogram och plugin ska fungera, så måste pluginen programmeras precis enligt de tekniska specifikationer som värdprogrammet kräver. Det kräver att programmeraren känner till ett värdprograms tekniska specifikationer för plugins, och följer dom specifikationerna när h*n skriver kommandon och instruktioner.

För att programmeraren ska känna till de tekniska specifikationerna, ger tillverkare av ljudprogram ut utvecklingspaket – s.k. Software Development Kit (SDK) – som innehåller mjukvarubibliotek fyllda med funktioner och kommunikationsmetoder (klasser) som programmeraren kan anropa ifrån IDE-programmet. Dessa SDK kan ofta laddas ner från tillverkarens hemsida, gratis eller till en mindre kostnad och levereras oftast i programspråket C++.

När man skrivit in alla kommandon och instruktioner som ger en plugin sin funktion och eventuellt utseende, så sammanställer (kompilerar) IDE-programmet alla dessa instruktioner - inklusive SDK biblioteket och ett antal fler små detaljer - till ett program eller fil som kan sparas på hårddisken. Denna fil kan antingen vara ett rent program (självgenomlöpande), eller vara en digital rutin eller tjänst. En plugin är ett tillägg till ett värdprogram. Detta program eller fil kan installeras på datorn eller placeras i den mapp som värdprogrammet läser av för att söka efter plugins. På så sätt (och andra sätt) kan en plugin skapas.

Numera finns flera mångsidiga sätt att programmera plugins, även att översätta en plugin till flera olika standards (kallas att ”porta” en plugin). Det finns även program gjorda för att programmera plugins enligt arbetsmodellen WYSIWYG – t.ex. Synthmaker, Pluggo Max/Msp, Sonicbirth, Usine, Synthedit, Maize m.fl. I dessa program behöver inte användaren använda sig av ren programmering, men måste infoga sig i det ramverk som programmet avgränsar.

Lite bakgrund ...

När Windows introducerades, i synnerhet Windows95 (1994), så ansåg många att det nya operativsystemet utövade en diktatorisk och samtidigt oräntabel kontroll över kommunikationen mellan datorns olika in- och utenheter, som mus, tangentbord, minne, grafik- och ljudkort m.m. Många ansåg att föregångaren DOS var bättre och stabilare miljö, i synnerhet för användningar som satte press på datorns prestanda, eftersom DOS medgav direkt-kontakt mellan datorns olika komponenter. Det var många som ansåg att ljudinspelningsprogram inte alls var bra i Windows95 utan fungerat mycket bättre i den tidigare DOS-baserade miljön.

Microsoft framställde då en separat rutinmiljö på insidan av Windows95 som skulle ge betydligt mer direkt kontroll mellan datorns olika enheter, men endast då program kördes i denna rutinmiljö eller anropade delar av rutinmiljön. Den rutinmiljön kallades för DirectX och finns kvar i Windows än idag. DirectX används mest för datorspel och multimedia och konkurrerar främst med OpenGL. Drivrutiner som ”DirectShow” och ”DirectSound” kanske någon sett i Windows då och då? Dessa är en del av DirectX arkitekturen i Windows.

Genom att använda DirectX-rutinerna så förbättrades prestandan mellan olika enheter, och därför gjordes de kommande ljudprogrammen så att de åberopade och använde DirectX miljön. När även ljudinspelning blev mer möjlig, tack vare den ökande datorkraften, så gjorde några få tillverkare tillägg (plugins) som kunde köras inuti sina ljudprogram. Dessa tillägg kallades för DirectX-plugins. Det rörde sig ofta om enkla små tillägg med odramatiska gränssnitt.

Steinberg Spectralizer. En enhancer plugin skriven för DirectX.

Flera tillverkare av musik- och ljudprogram tyckte inte att detta räckte, utan att det fanns ännu mer kraft att dra ur Windows-systemet än Microsofts rutiner erbjöd.

Tyska tillverkaren Steinberg var redan aktiva med att tillverka hårdvara och tillhörande drivrutiner för att underlätta för datorers inspelning av främst MIDI. Deras MROS och MIDEX t.ex. är relativt kända, liksom ASIO. Steinberg framställde en egen rutin-standard för deras egna program i Windows. Denna rutin-standard skulle avsevärt förbättra prestandan i Windows hantering av ljud-data jämfört med det tidigare DirectX. Steinberg kallade sin rutin-standard för ”Virtual Studio Technology” (VST) och introducerade denna 1996.

Steinberg VST logo

VST var en mycket stor nyhet, och framställdes även för att utöka Steinbergs program Wavelab och Cubase med ytterligare verktyg; verktyg tillverkade av andra än Steinberg själva. En stor förändring i detta var att Steinberg erbjöd gemene man att själva tillverka tillägg (plugins) som man antingen kunde använda själv, sprida som gratis resurser, eller sälja för pengar.

Steinbergs sätt att göra det på, var att ge ut ett gratis mjukvarubibliotek (SDK) i C++ som programmerare kunde importera i sitt arbetsprogram och använda för att anropa- och förstå funktionaliteten som kallades VST.

Gjorde man några enkla rader instruktioner i C++ tillsammades med SDK-klasserna, och kompilerade detta till en DLL-fil som sedan lades i mappen ”VSTplugins” i Windows, så läste Wavelab eller Cubase pluginen vid uppstart av programmet, och den dök då upp i menyn för ljud-effekter.

Funktion och utseende är olika saker

Gör man t.ex. en simpel volymkontroll-plugin i C++, kompilerar den och öppnar den i Wavelab, så ser den ut såhär:

Den ser ut såhär, på grund av denna plugin inte innehåller några instruktioner för hur den ska se ut. När man programmerar en plugin så bestämmer man inte enbart hur den ska fungera, utan man kan även programmera in ett visuellt användargränssnitt (GUI) för pluginen, som kan se ut nästan hur man än vill.

Om man inte programmerar in ett utseende, så alstrar värdprogrammet (Wavelab i detta fall) ett standard-utseende för pluginen automatiskt. Detta standardutseende visar upp endast de parametrar som användaren kan påverka i pluginen – i detta fall Volym. Nedanstående plugin är densamma som ovan, fast med ett inprogrammerat utseende tillagt:

Här är samma volymkontroll som ovan igen, med ett annat grafiskt gränssnitt inprogrammerat:

... men motorn under huven är densamma för alla tre plugins ovan. Det här är något man kan tänka på när man ska välja plugin: en smäcker yta har ingenting med processen under motorhuven att göra. Det är bara en påklistrad yta. (Detta betyder dock inte att en volymkontroll-plugin alltid har exakt samma funktionalitet under motorhuven).

Standardutseendet, som ges till en plugin utan inprogrammerat gränssnitt, skiljer sig i olika DAW. Men alla tillhandahåller samma parametrar.

En plugin utan inprogrammerat gränssnitt visas såhär ^ i värdprogrammet Apple Logic.

I flera DAW-program kan man välja att se pluginen utan sitt förprogrammerade utseende. Då visas endast de parametrar som användaren kan förändra. I DAW-programmet Reaper visas pluginen SoftTube FET såhär:

Men genom att trycka på knappen ”UI”, som syns uppe till höger i ramen, så kopplas det programmerade gränssnittet bort, och Reaper visar då endast de parametrar som användaren kan förändra - de parametrar som i gränssnittet ovan visas som rattar. Men funktionaliteten är exakt densamma:

Skillnad på instrument och ljudverktyg

VST har utökats med en variant, som deklarerar pluginen som ”Instrument”, till skillnad från ljudmanipulerande plugin. Den varianten kallas VSTi, och deklarerar mjukvarusyntar och sampleplayers m.m. – verktyg som alstrar ljud snarare än manipulerar ljud. Även det tidigare DirectX-systemet har uppgraderats med samma variant, kallas DXi och klassificerar pluginen som ”instrument”.

Denna klassificering medför bland annat att renodlade ljudprogram - som t.ex. Steinberg Wavelab - inte visar upp VSTi plugins i sin pluginlista, utan bara VST klassificerade plugins. Men olika DAW- och ljudprogram följer denna variant lite olika noga. Därför kan vissa program sortera ut VSTi/DXi till en egen kategori som kallas Instrument, medan vissa DAW-program inte sorterar ut instrument-plugins på samma sätt, eller inte alls.

Ytterligare en skiftande faktor är att programmeraren själv väljer om en plugin ska presentera sig själv som VST eller VSTi för värdprogrammet. Vissa programmerare som gör VST-Instrument, glömmer att ange dem som av VSTi typ, och dessa sorteras då (oftast) in bland ljudmanipulerande plugins som Equalizers, kompressorer m.m.

Efter sin introduktion har VST-standarden vidareutvecklats och renoverats till nyare versioner - VST 1.5, VST2, 2.4, VST3 och nu senast VST3.5. Även den äldre DirectX-standarden har uppdaterats kontinuerligt, men det utvecklas väldigt få ljud-plugins för DirectX idag. Sony är en tillverkare av mediaprogram som fortfarande håller kvar vid DirectX rutinerna relativt stadigt.

Digitala oförutsägbarheter och kreativitet

Men om man gjorde en enkel volymkontroll, så innebar det inte att den lät helt genomskinligt. En simpel volymkontroll i VST-standarden färgar ljudet aningen:

Så hur gjorde man för att skapa en volymkontroll som var kliniskt ren i ljudet och inte färgade? Tja, den instruktionen ingick inte i SDK-paketet, och gick inte att utläsa. Om man gjorde en enkel instruktion, så fick man inte ut exakt den funktion man ville. Så programmerare som ville skapa renare kontroller fick söka okända vägar, genom ren improvisation eller magkänsla. Man fick bygga om koden med nya funktioner som inte ingick i VSTs standardbibliotek, men ändå på ett sätt som var kompatibelt med VST-biblioteket.

Så att skapa plugins handlade inte bara om att lära sig C++ och använda utomstående C++-klasser i SDKn, utan om att ge sig in i en väldigt programmeringsteknisk värld utan karta. Att skapa plugins är med andra ord inte för alla.

Avancerade plugins och analoga förebilder

För att sen skapa mer avancerade plugin-verktyg, t.ex. en equalizer, så skriver man in instruktioner i programmet som skickar digitala ljudsignalen genom samma process som signalen underkastas i en analog elektrisk equalizer. Man imiterar alltså den analoga teknikens förebild, fast nu i ett nytt tekniskt ramverk: digitalt. Man skapar kod som dirigerar signalen genom olika förlopp, processer som i sin tur måste förmås manipulera signalen på önskat sätt.

En analog equalizer fungerar genom att skapa en intern rundgång inom ett givet frekvensområde, så att volymen för detta frekvensområde förstärks i förhållande till omkringliggande frekvenser. Genom att fasvända denna process så åstadkommer man en gradvis fasmässig utsläckning av utvalt frekvensområde, varpå den utvalda frekvensen reduceras i volym i förhållande till omkringliggande frekvenser. Detta förfarande kan direkt tillämpas på digital väg, genom att helt enkelt använda C++ kod till att skapa funktioner och rutter som orsakar intern rundgång för ett utvalt frekvensområde osv. Man måste alltså både skapa rutiner som dirigerar signalen genom olika stadier, och sen även skapa de funktioner som varje stadium ska utöva.

Så den digitala världen är – i de allra flesta avseenden – en ren emulering av den analoga förebild som föregick den. Samma sak gör man när man skapar kompressorer, gates, reverb osv. Den digitala tekniken har i mindre utsträckning öppnat upp förrän för lösningar som bygger vidare på den analoga förebilden och i mindre utsträckningen även skapa lösningar som är annorlunda än den digitala förebilden. Men att börja se lösningar som kastar av sig den analoga förebilden helt och hållet, det ligger ännu framtiden.

Många pluginformat

Inte långt efter att Steinberg introducerat VST, så gjorde konkurrerande tillverkare av ljud/musik-program samma eller liknande sak: introducerade sin egen standard och gav ut SDK. Plugin-standarden AudioSuite för Mac följde 1997 och RTAS för Protools 1999 osv. Idag finns ca 20 mer eller mindre vanliga standards för plugins, etablerade av olika tillverkare. De flesta av dessa har genomgått en evolution lik VSTs utveckling ovan. Men kompatibilitet och marknadsmässiga fördelar gör att ljudprogram som tillverkas av ett företag i flera fall kan använda flera plugin-standards, inte bara sitt egna.

De mest kända plug-in formaten idag är:

• AAX – Avid Audio Extensions, av Digidesign. Tillgängligt på Mac och Windows. Ett nytt format som ersätter Avids tidigare TDM format. Kan användas både som Native och med DSP-kort. Läses av Avid Protools.

• AU – Audio Units, av Apple. Tillgängligt på Mac. Läses av Apple Logic.

• DX – DirectX, av Microsoft. Tillgängligt på Windows. Läses av Cockos Reaper, Sony Soundforge, Steinberg Wavelab.

• Rea – Reaper/Jesusonic, av Cockos. Tillgängligt på Mac och Windows. Läses av Cockos Reaper.

• RTAS – Real Time Audio Suite, av Digidesign. Tillgängligt på Mac och Windows. Läses av Avid Protools, Digidesign Protools och Motu Digital Performer.

• TDM – Digidesign. Tillgängligt på Mac och Windows. Läses av Avid Protools, Motu Digital Performer och Apple Logic. TDM plugins behöver specifika kretskort installerade i datorn, som utför processningen och sparar på datorns egna processorkraft.

• VST – Virtual Studio Technology, av Steinberg. Tillämpligt på Mac och Windows. Läses av FruityLoops, Steinberg Cubase, Motu Digital Performer, Sony Soundforge, Steinberg Nuendo, Steinberg Wavelab, Cockos Reaper, Cakewalk Sonar m.fl.

Finns även mindre förekommande format, som t.ex. LV2, LADSPA, DSSI, Venue, ReWire m.fl. I omlopp finns även finns container-program eller hjälpmedel (s.k. Wrappers) som gör att man kan använda t.ex. en VST-plugin i ett program som inte läser VST-standarden.

Skillnaden mellan de olika pluginformaten är inte överlag stora, och prestandan är utan problem jämförbar. Det är alltså inte nämnbart bättre ur prestanda-synpunkt att hålla sig till en DAW som kan läsa ett format i förhållande till ett annat.

En skillnad kan vara tillgången till olika verktyg. Formatet VST är det äldsta och mest använda formatet vid plugin-framställning, där det finns i särklass flest olika plugins. I dagsläget innehåller sajten KVR Audios stora databas ca 5300 tillgängliga plugins i VST format, ca 2000 i Audio Units format och ca 1200 i RTAS format etc.

Använder man en DAW som inte läser VST formatet så har man alltså inte tillgång till den största floran av verktyg. Men detta ställer i dagsläget inte till några direkta hinder, eftersom i princip alla former av verktyg finns tillgängliga i nästan alla plugin-format.

Många mindre utvecklare gör plugins som de tillhandahåller gratis, medan ett mindre antal gör plugins som säljs kommersiellt. Det kanske mest kända tillverkaren av plugins är israeliska Waves Audio (www.waves.com), och det kanske största kända forumet för samarbete och kunskapsutbyte inom plug-in tillverkning är KVR Audio (www.kvraudio.com). Där hänger även många kända plugin-tillverkare.

DSP

Plugins belastar datorns processor i real-tid. Därför lanserades idén att man kunde använda separata processorer som enbart hanterade beräkningarna som beordras av plugins, men lämnar övriga systembelastningen åt datorns centrala processor.

Sådana separata processorer placerades på egna kretskort som kapslades in en rack-enhet (eller liknande chassi) och kopplades ihop med datorn via Firewire eller USB. Vissa tillverkare av såna kretskort erbjöd rena kretskort (utan extern chassi) med processorer på som man kunde sätta in i datorns ISA eller PCI platser.

DSP-kretsen Powercore, av T.C. Electronics, används som rackmonterad enhet ansluten via FireWire.

Såna här processkretsar – med eller utan chassi - kom kort och gott att kallas DSP (Digital Signal Processor) eller DSP-kort/DSP-enhet/DSP-accelerator. En DSP-krets har traditionellt givit i runda slängar 75% av processkraften av en normal modern dator, och det kostar ofta 75% av vad en modern dator gör. Men det säljs även DSP med flerdubbla processkretsar i, som mångdubblar processkraften. På så sätt kan man erhålla processkraft som motsvarar flera mycket starka datorer, i en och samma dator.

Några tillverkare är särskilt kända för att erbjuda – eller har erbjudit – sådana kort. Waves, Avid, T.C. Electronics, Universal Audio, SSL m.fl. Dessa tillverkare erbjuder dock inte att man använder vilken plugin man än vill tillsammans med deras DSP-kort. Med dessa kort kan man bara använda vissa förbestämda plugins. Det är ofta plugins som tillverkaren själv säljer, plus eventuellt några få ifrån andra stora tillverkare.

DSP-krets som PCIe-kort: UAD-1 av Universal Audio

Några tillverkare – speciellt Universal Audio, T.C. Electronics, Avid och Steinberg - är även kända för att göra enheter som erbjuder både ljudkort och DSP i samma enhet.

Steinberg MR816CSX utför både rollen som ljudkort och DSP.

Avids plattform Protools är sen länge känd för att erbjuda två olika sorters plugins. En sort som körs i real-tid och inte kan användas med DSP, och kallas RTAS. Den andra sorten är en som inte kan användas utan en DSP, och kallas TDM eller AAX.

Tack vare att plugins nu kunde köras på två olika sätt: med eller utan DSP, så tillkom ett nytt namn i pluginfloran: Native. En plugin som kördes via DSP kallades helt enkelt för DSP plugin, och en plugin som använder datorns egna centralprocessor kallas för Native (sve: ”inhemsk, ursprunglig”).