Laat je niet tegenhouden omdat de vorm van een functiecall je niet aanstaat of object georiënteerd programmeren niet meteen klikt, ook als je het dan even niet leuk vind. Die keuzes zijn niet zomaar gemaakt en door mensen met vele, vele jaren meer kennis en ervaring dan jij.
Of er moest even snel een beslissing genomen worden en de minst erge optie was degene die je zag
Ook programmeertalen lijden aan voortschrijdend inzicht.
Zodra je daar daadwerkelijk vlieguren in maakt word schakelen op ten duur een eitje. Je zit dan ook niet aan een taal vast. Die frictie hoort er bij, zoveel is lelijk en onlogisch aan C++ (en elke programmeertaal) als je nog niet gevorderd bent.
Ik vind C++ inderdaad niet echt de netste taal. C# ziet er stukken beter uit, maar heeft ook veel minder bagage in vergelijking, alleen gaat niemand dat in een kernel stoppen.
Ik ga verder met C++ leren, of ik die taal nu mooi of lelijk vind. En wel om reden dat die taal in audio software een centrale rol blijkt te spelen. Ik wil bij mijn software avondturen weten wat er onder motorkap gebeurt en dan kom je bijna altijd weer uit op C++ (of C). Dus is het nu zaak om door te pakken.
Ik heb de rest niet helemaal gevolgd want we zitten volgens mij in totaal al op een hele ris pagina's, dus het is wellicht overbodig.
De volgende basis-aannames zijn bekend. Digitale audio is een stroom van bitjes. De taak is om die bitjes - linksom of rechtsom - naar een DAC te krijgen zodat je een voltage krijgt. Dat kun je dan naar je speaker sturen zodat er iets gaat trillen zodat je iets kunt horen.
Je kunt een zaagtand-oscillator bouwen door iets te maken wat van -32,768 to +32,767 telt (en dan weer terug bij af begint). Als je 44100 keer per seconde een getal naar de DAC stuurt heb je dan een zaagtandgolf. Iets naar de DAC sturen is niks anders als op tijd er voor zorgen dat er een bepaalde waarde in het geheugen staat wat de DAC moet uitlezen.
Dit is letterlijk hoe je op een Commodore 64 muziek maakt. Schrijf dingen naar een geheugenlocatie, en de SID pikt dit op en doet de rest. Doe dit op de juiste tijd, en het resultaat klinkt ook nog eens muzikaal.
Het is net een fabriek die elke dag een vrachtwagen aan widgets moet maken. Het maakt niks uit of de werknemers 1 uurtje bezig zijn en de rest van de dag niks doen, of dat ze pas om 5 voor 12 's nachts klaar zijn met het werk; om 00:00 staat de vrachtwagen er en die moet vol zijn. Zo niet, dan krijg je stukken stilte in de audio (het geheugen van de DAC wordt na aflevering op 0 gezet) of digitaal geschreeuw (het geheugen van de DAC was nog vol met de oude inhoud en die wordt nu weer uitgelezen; denk aan een korte sample die je loopt).
Helaas is het allemaal niet zo simpel, want je bent niet alleen.
Tijdens het maken van je zaagtand moet een computer nog een ris andere dingen doen. Je mag niet zomaar naar willekeurige stukken geheugen schrijven; om er voor te zorgen dat alles netjes gaat krijg je een stel functies aangeboden die dat voor je faciliteren. Ook die functies geven van alles van software-laag naar software-laag door, dus wie weet wat ze op de achtergrond doen. Da's ook interessant, maar dan mag je dus dingen doen zoals [drivers leren schrijven](https://www.youtube.com/watch?v=juGNPLdjLH4). Ook weer een hele andere tak van sport, en ook weer iets waar een hoop werk al voor je gedaan kan zijn.
In de tussentijd wil je ook nog even kijken of er misschien iemand aan de virtuele knoppen draait; en als die de frequentie van de zaagtand aanpast wil je natuurlijk wel een ander setje bitjes naar je DAC sturen.
Het grote verschil met een scripttaal zoals Python is dat Python start en weer stopt en in de tussentijd allerhande dingen gedaan heeft. LISP heeft dit letterlijk in de naam zitten - LISt Processing.
Bij een applicatie (en of dat nu een plugin of een spel of iets anders is) ben je continu aan de gang; er wordt een loop opgestart en in die loop doe je werk. Je controleert - zit er iemand aan de user interface knoppen te draaien? Moet ik nu wat naar de DAC sturen? Mag ik nu een aantal nanoseconden spenderen aan het uitrekenen van het volgende blokje golfvorm?
Iets als JUCE neemt je dat soort dingen uit handen, en dat betekent dat je dan eerst even al je energie kan steken in leren hoe DSP werkt.
Alles tegelijk proberen te leren is een goede manier om niks te leren
Maar serieus, wat ook meespeelt is dat @ProgHead ook aangeeft dat oplossingen die door anderen met een zekere ontwerpfilosofie zijn bedacht hem vaak weinig kunnen bekoren. Of iets zelf bouwen echt een goed idee is, dat is vooral aan hem om te beoordelen, maar een frisse kijk op het onderwerp van audio en het genereren en bewerken daarvan, en daar iets voor creëren, dat levert voor hem althans wellicht iets op dat hij niet zo gemakkelijk of helemaal niet zal vinden met bestaande tools. Ook iets dat niet zo groot en niet heel complex is kan in de juiste vorm een aha-moment opleveren dat inzicht geeft in de materie waar je mee bezig bent. Ergens proef ik uit de posts van @ProgHead dat het hem vooral daarom te doen is.
