Nou..
Ik ben al een tijdje op zoek naar een plugin die een
deel van het frequentiebereik kan inverten om een beetje een scrambled politie signaal te emuleren. Ik zeg niet dat je die moet gaan maken maar aan de hand daarvan heb ik mezelf ongeveer dezelfde vragen gesteld die jij ook hebt, dus ik brand wel ff los in deze thread.
De tijd ontbreekt me momenteel helaas om zelf een heel VST framework in elkaar te draaien, maar ik kende de .NET en Java wrappers niet dus misschien wordt het hiermee wel een stuk gemakkelijker. Ook is er trouwens een VST->Pd wrapper zodat je het als een Pd patch zou kunnen schrijven, maar ik weet niet hoe stabiel dat is (versienummer ligt nog schrikbarend dicht bij de 0.0).
Een andere optie is
Synthmaker wat ik nu aan het uitchecken ben. Ik weet niet of Synthedit dit ook kan, maar Synthmaker heeft twee taaltjes waarin je zelf modules kan schrijven; je kan dan gewoon de bytes van het signaal manipuleren. Er is een C/java-achtig taaltje en een assembler-achtig taaltje. Voorzover ik Synthmaker heb uitgeprobeerd met hun bijgeleverd example synth, die redelijk complex is, lijkt het CPU-gebruik van een Synthmaker-gegenereerde VST plugin heel aardig te zijn!
Maar goed, ik zit eigenlijk dus ook te broeden om zelf iets te maken, want zo'n frequentie inverter zou een heel geinig effect kunnen zijn. Synthmaker heeft helaas zelf geen kant-en-klare FFT module dus dat wordt helemaal zelf programmeren, wat misschien niet lukt met de ingebouwde taaltjes.
Het effect dat ik wil komt waarschijnlijk op de volgende stappen neer:
1. Het inkomend signaal in tijddomein (samples) met een Fast Fourier Transform (FFT) omzetten naar frequentiedomein (levert een array van de sterkte van de verschillende frequentiecomponenten)
2. Op basis van een frequentiepaar (bijvoorbeeld freq1 en freq2) het bijbehorende deel van dit array swappen (bijv. array[16] t/m array[31])
3. Met IFFT (wat eigenlijk hetzelfde als FFT is) dit array weer omzetten naar een signaal, en dat uitvoeren.
Los van of je dit ook wil, zal het waarschijnlijk in dezelfde hoek zitten wat je gaat maken.
Overwegingen:
- Performance van het rekenwerk: Het echte rekenwerk bestaat voornamelijk uit een paar vermenigvuldigingen en sin/cos voor de FFT. De trigonometrische functies kunnen natuurlijk bij het opstarten in een lookup table worden gezet, dus dit kan heel snel. Vermenigvuldigen en array indexen is in alle mogelijke talen (C#, Java, etc.) gewoon heel snel.
- C#/.NET/Java: Wat wel jammer is voor de performance, is dat alle ingevoerde data eerst moet worden gekopieerd naar de managed heap. Na het berekenen moet je het ook weer exporteren ("marshalen"). Dat komt er, vermoed/vrees ik, op neer dat het signaal twee keer tussen het geheugen heen en weer wordt gekopieerd. (In C# misschien slechts een keer als je met een unsafe blok geheugen kan werken, nog niet uitgezocht). Wat dat betreft zal een managed oplossing dus altijd meer CPU kosten dan wanneer je puur native code gebruikt. C++, of een VST generator die native code genereert, heeft hier geen last van en is dus potentieel beter qua CPU-gebruik.
- Omdat een VST toch meestal puur wiskundig bezig is, wat in vrijwel alle talen dezelfde syntax heeft, is het mogelijk beter om gelijk native te beginnen in C++. Hoewel dit verschil bij normale sampling rates/1 audio-stream waarschijnlijk wel uit te houden is gok ik. Maar tenslotte moet je toch EEN framework gaan leren, en de investering in C++ is dan wel future-proof, bijvoorbeeld als je iets wil gaan maken wat 8 96kHz audiostreams in en uit aankan. Dan gaat het kopieren van native->managed->native vrees ik toch wel aantikken.
- In C# kun je met het 'unchecked' keyword de array bounds checking tijdelijk uitschakelen. Java heeft dit volgens mij niet? Als je veel met arrays werkt (wat zo zal zijn) kan dit een performance hit opleveren, wat Java volgens mij minder geschikt maakt want Java heeft geen mogelijkheid om deze checks uit te zetten (let me know als ik dit verkeerd heb!).
- Streaming: Ik weet niet hoe VST's hun bytes in- en uitvoeren. De FFT bijvoorbeeld werkt alleen op een array van bijvoorbeeld 256 samples tegelijk. Een bewerking met FFT is dus niet helemaal 'realtime' streaming te doen maar alleen in blokken. Dit zal ook voor andere bewerkingen gelden.
- Al met al is natuurlijk het lowlevel input/output werk heel vervelend, wat weer een goed argument is om met een omgeving als SynthMaker te werken. Misschien moet je hier extra maatregelen voor treffen, wat stom en vervelend werk is. Hopelijk handelen de bestaande frameworks dat allemaal goed af maar ik weet niet in welke mate.
- Sterk voordeel van een C#/Java/C++ oplossing is dat je de broncode helemaal in eigen hand hebt, en dat de SynthEdit/SynthMaker mensen je investering niet kunnen vernietigen door bijvoorbeeld geen nieuwe versies meer te maken, of grote bedragen te vragen voor upgrades.
Nou, alle inzichten hierover zijn welkom. Als je aan de slag gaat met coden ben ik wel ge-interesseerd in de voortgang
Ik heb weinig DSP-ervaring maar wel veel programmeerervaring dus misschien kan ik een handje helpen.
groets
MOSFET
