Plugins en C++

[ProgHead]

Volgende project. Een sprong in het diepe:

Creating Synthesizer Plug-Ins with C++ and JUCE

Audio programming is an exciting intersection between software development, digital signal processing (DSP), and creativity. It's enjoyable and rewarding once you've learned the basics, but how do you get started?In this book, we introduce you to this exciting world with a step-by-step guide to...

www.google.nl

Ik zie wel hoever ik kom. In elk geval wil ik een globaal idee krijgen hoe een plugin in C++ eruit ziet, en wat daarbij komt kijken. Dat moet te doen zijn. Het boek heb ik al, en ga ik vanaf vandaag bestuderen.

 

[Disharmonic]

 

[ProgHead]

Ja - maar inmiddels ben ik er al wel weer in vastgelopen, want Juce werkt niet goed samen met Code::Blocks, en Code:Blocks "bildt" bestanden vanuit Juce niet (geeft errors). Althans onder Linux. Een oplossing daarvoor heb ik op internet niet gevonden. Bovendien heb je met Juce ook weer gedoe met licenties. Niettemin lees ik het boek wel uit, want er staan een boel weetjes in over hoe de zaken horen te werken.

 

[Disharmonic]

Zo'n boek over hoe het hoort te werken had het personeel van Tsjernobyl ook liggen.

Ik lees dat Code::Blocks alleen een IDE is? Daar heb je dan nog een compiler bij nodig?

 

[ProgHead]

Code::Blocks zou het wel moeten kunnen:

Maar bij progjes met een GUI krijg je een error dat er dependencies ontbreken die echter wel op mijn computer zijn geïnstalleerd. En de tips die ik op internet vond om dat probleem dan weer op te lossen werkten niet. Wat eventueel wel zou kunnen werken is om Make (of Cmake) te gebruiken, maar dat is weer een studie op zich... Ik wil mij nu tot twee (of drie) plugin formats beperken: LV2 en CLAP (en eventueel nog een format voor plugin gebruik binnen de browser). Daarmee wordt dan veel gedoe vermeden, en heb ik Juce ook niet meer nodig.

 

[GuidoR]

Zo'n boek over hoe het hoort te werken had het personeel van Tsjernobyl ook liggen.

Ik lees dat Code::Blocks alleen een IDE is? Daar heb je dan nog een compiler bij nodig?

IDE (integrated development environment) is met compiler. Anders is het gewoon een editor. Ik heb verder geen ervaring met deze IDE, wij gebruiken gewoon een editor (VSCode of wat je maar wil) met een cmake project dat onze GCC (cross-compile) environment opzet.
Wellicht een idee om daar eens in te duiken? Dat je zelf je build environment opzet? Is wel leerzaam.

 

[ProgHead]

Ik heb ook een boek over Cmake in de kast staan, maar nog niet gelezen. Maar begrijp ik je goed dat Make of Cmake in principe overbodig zouden moeten zijn als Code::Blocks wel goed zou werken?

 

[GuidoR]

Onderwater zal er in de IDE waarschijnlijk iets van cmake en uiteindelijk de compiler wel aangeroepen worden ja (vaak configureerbaar welke). Dat is het idee van een IDE: alles wat je nodig hebt om te bouwen in één handig pakket.

Ik vind het zelf alleen niet zo handig, vaak is de documentatie van de losse tools beter dan die van de configuratie van een IDE.

 

[Almeros]

Heb je al ervaring met programmeren ProgHead? Aan je naam te zien misschien wel .

Maar anders zou ik klein beginnen. Maak een ui loze volume control plugin (zonder JUCE). Vanuit daar kun je dan doorbouwen. Anders kom je zoveel hobbels tegen dat je misschien ontmoedigd raakt...?

 

[ProgHead]

Ik heb geprogrammeerd met FAUST, ChucK, Csound, Sonic Pi en Python. En heel vroeger met BASIC en Assembler. Ik probeer nu voorzichtig ook wat thuis te raken in C++ om beter te begrijpen wat er bij plugins onder de motorkap gebeurt.

 

[Disharmonic]

IDE (integrated development environment) is met compiler. Anders is het gewoon een editor.

Ja, dat is wel logisch. Maar @ProgHead heeft wel 'ns vaker problemen gehad om dingen aan de praat te krijgen, je krijgt het gevoel dat je het nooit echt zeker weet als Linux in het spel is.

 

[ProgHead]

Op internet vond ik inderdaad dat Code::Blocks op Linux minder goed ondersteund wordt dan meer standaard IDE's op Windows.

Maar de voornaamste hobbel voor het begrijpen van plugins geschreven in C++ is de object-oriented stijl van C++. Ik wil als ik een regel code lees begrijpen wat er gebeurt, en ik kan mij daar voor OOP maar lastig een beeld van vormen.

 

[GuidoR]

OOP is idd een beetje lastig in eerste instantie. Ik denk dat de basis van OOP (objecten, classes, inheritance, interfaces, etc) begrijpen de eerste hobbel is om te nemen. Ik vind persoonlijk C++ niet de beste taal om dat in te leren omdat C++ zich uitstekend leent voor onoverzichtelijkheid, maar dit is persoonlijk. Het is voor het schrijven van plugins wel erg geschikt.

edit:
Mijn ervaring met Linux is overigens dat het echt perfect is voor ontwikkelaars. Je kan alles aanpassen, en alles (aan packages) is te krijgen.

 

[ProgHead]

OOP is idd een beetje lastig in eerste instantie. Ik denk dat de basis van OOP (objecten, classes, inheritance, interfaces, etc) begrijpen de eerste hobbel is om te nemen. Ik vind persoonlijk C++ niet de beste taal om dat in te leren omdat C++ zich uitstekend leent voor onoverzichtelijkheid, maar dit is persoonlijk. Het is voor het schrijven van plugins wel erg geschikt.

Vandaag ontvang ik als het goed is een dikke pil over de programmeertaal Ruby wat ook object-oriented is maar mij makkelijker te begrijpen lijkt.

edit:
Mijn ervaring met Linux is overigens dat het echt perfect is voor ontwikkelaars. Je kan alles aanpassen, en alles (aan packages) is te krijgen.

Linux is (als je meer wil dan wat tekstverwerken, internetten en e-mailen) leuk voor gevorderden, wat ik (nog) niet ben. Vandaar dat ik vaak vast loop. Aan de andere kant houd ik er wel van om dingen te leren, dus ik blijft wel op Linux.

 

[MstrFX]

Deze gast blijft alles in assembly doen heb ik begrepen gotharman.dk

Van de webste: "
To make everything work as fast and effective as possible, no Gotharman machines are programmed behind any "OS". Everything is performed directly by the processor of the instrument, and everything is programmed in assembly language, which is up to 30 times more effective than the C++ language, which most people program in, and it is programmed specifically for the instrument hardware. The latency is 450 times shorter, than on Linux based machines."

 

[GuidoR]

Tja, voor snelheid blijft assembly onovertroffen. Alleen als je ineens een andere MCU of processor moet gebruiken (want obsolete) dan hang je.

 

[ProgHead]

Waar ik inmiddels wel achter ben is dat ook wat de programmeertalen betreft alles zijn voor- en nadelen heeft. En daarbij is alles op dat gebied ook nog eens voortdurend in beweging. Ik moet gewoon de knoop doorhakken waar ik mee ga werken.

Voor Linux plugins is LV2 mooi genoeg. Maar wat dan voor Windows en Mac? Daarvoor twijfel ik nog tussen webapplicaties en CLAP plugins...

 

[Nap]

Zonder VST3 of AU support zit je wel heel erg in een niche dan. Op een paar nerds en Bitwig adepten na gebruikt bijna niemand (als in de ik-wil-gewoon-installeren-en-gebruiken consument) LV2 of Clap.

 

[ProgHead]

Ben over de helft met het boek van Hollemans, en overgestapt op Geany als IDE voor C++. Verder veel video tutorials over C++ gekeken. Langzaam aan begin ik er iets van te begrijpen.

 

[ProgHead]

Heb het boek van Hollemans uit. Het is goed geschreven, maar C++ zelf is uiterst taaie kost. Dus het viel me niet mee, en ik heb ook lang niet alles begrepen. Maar wat de bedoeling was is me wel gelukt: ik heb nu een aardige indruk van hoe een plugin in C++ eruit ziet.