.NET VST plugins maken

Maikel, jij brengt me op een idee zeg.
Ik had niet gedacht aan een DX plugin. Dat is ook een optie.
Maar ik moet wel ff uitzoeken hoe dat precies zit.
Want ik heb tot nu toe alleen de "normale" dingen uit DirectX gebruikt.
3d, music en Input enzo... Ik heb nog geen idee hoe een DX plugin werkt.

Verder iedereen bedankt voor de input en nogmaals: performance is geen issue.
Managed code zal nooit zo snel zijn als Win32 applicaties. Daar gaat het hier ook niet over.

En even ter info: C# heeft werkelijk niets met C en C++ te maken. Behalve de taalverschillen maken ze gebruik van totaal verschillende onderliggende structuren en methodes.
 
Origineel geplaatst door Nolet
Wow...hier snap ik echt geen donder van....knap hoor, dat anderen dat wel doen

*meneer die een 6- had voor wiskunde A (na 2 jaar bijles) gaat weer naar Lingo kijken*

Dat valt allemaal wel mee hoor ik doe de hele dag niks anders dus op gegeven moment snap je het wel....

AlonsoMos: ik heb in het verleden ooit een VST plugin geschreven in C++ mbv MS VC6.0,
en op basis van de Steinberg SDK. De signaalbewerkingsstappen heb ik geen moeite
mee; dat gehannes met MFC vind ik wel lastiger.

Volgens mij heb ik nog wel ergens frameworkjes in C++ liggen voor buffering, framing, FFT,
inverse FFT, en overlap add. Dat zou een aardig uitgangspunt zijn denk ik (en redelijk
onafhankelijk van het feit of je nu een VST of DX plugin schrijft).
 
Origineel geplaatst door DJB
Dat valt allemaal wel mee hoor ik doe de hele dag niks anders dus op gegeven moment snap je het wel....

AlonsoMos: ik heb in het verleden ooit een VST plugin geschreven in C++ mbv MS VC6.0,
en op basis van de Steinberg SDK. De signaalbewerkingsstappen heb ik geen moeite
mee; dat gehannes met MFC vind ik wel lastiger.

Volgens mij heb ik nog wel ergens frameworkjes in C++ liggen voor buffering, framing, FFT,
inverse FFT, en overlap add. Dat zou een aardig uitgangspunt zijn denk ik (en redelijk
onafhankelijk van het feit of je nu een VST of DX plugin schrijft).

Voor de luie mens is er dan altijd nog Synthedit, waar je heel eenvoudig je signaalgedeelte in C++ kan schrijven via zelfgeschreven modules en het GUI gedeelte doe je gewoon met klik en sleepwerk...
 
Verder iedereen bedankt voor de input en nogmaals: performance is geen issue.
Managed code zal nooit zo snel zijn als Win32 applicaties. Daar gaat het hier ook niet over.

juist wel, tenzij je een 3000+ GHz supercomputer wil gebruiken om een simpele 303-emulator te gebruiken... (bij wijze van spreken)
 
Misschien moeten we maar eens wat objectiever naar Java/C# e.d. gaan kijken wat de performance betreft. Even de conclusie van de bovenste hieronder genoemde links:

Conclusions: Why is "Java is Slow" so Popular?
Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).

Nevertheless, the idea that "java is slow" is widely believed. Why this is so is perhaps the most interesting aspect of this article.

Let's look at several possible reasons:

* Java circa 1995 was slow. The first incarnations of java did not java a JIT compiler, and hence were bytecode interpreted (like Python for example). JIT compilers appeared in JVMs from Microsoft, Symantec, and in Sun's java1.2.

This explanation is implausible. Most "computer folk" are able to rattle off the exact speed in GHz of the latest processors, and they track this information as it changes each month (and have done so for years). Yet this explanation asks us to believe that they are not able to remember that a single and rather important language speed change occurred in 1996.

* Java can be slow still. For example, programs written with the thread-safe Vector class are necessarily slower (on a single processor at least) than those written with the equivalent thread-unsafe ArrayList class.

This explanation is equally unsatisfying, because C++ and other languages have similar "abstraction penalties". For example, The Kernighan and Pike book The Practice of Programming has a table with the following entries, describing the performance of several implementations of a text processing program:
Version 400 MHz PII
C 0.30 sec
C++/STL/deque 11.2 sec
C++/STL/list 1.5 sec

Another evidently well known problem in C++ is the overhead of returning an object from a function (several unnecessary object create/copy/destruct cycles are involved).

* Java program startup is slow. As a java program starts, it unzips the java libraries and compiles parts of itself, so an interactive program can be sluggish for the first couple seconds of use.

This approaches being a reasonable explanation for the speed myth. But while it might explain user's impressions, it does not explain why many programmers (who can easily understand the idea of an interpreted program being compiled) share the belief.

Two of the most interesting observations regarding this issue are that:

1. there is a similar "garbage collection is slow" myth that persists despite decades of evidence to the contrary, and
2. that in web flame wars, people are happy to discuss their speed impressions for many pages without ever referring to actual data.

Together these suggest that it is possible that no amount of data will alter peoples' beliefs, and that in actuality these "speed beliefs" probably have little to do with java, garbage collection, or the otherwise stated subject. Our answer probably lies somewhere in sociology or psychology. Programmers, despite their professed appreciation of logical thought, are not immune to a kind of mythology, though these particular "myths" are arbitrary and relatively harmless.

Performance of Java versus C++

Binaries Vs Byte-Codes
 
Origineel geplaatst door Almeros
Misschien moeten we maar eens wat objectiever naar Java/C# e.d. gaan kijken wat de performance betreft. Even de conclusie van de bovenste hieronder genoemde links:



Performance of Java versus C++

Binaries Vs Byte-Codes

Toch vreemd dat de meeste audio engines dan nog steeds in C++ of Assembler gemaakt worden. Zal toch wel een specifieke reden achter zitten denk ik.
 
Origineel geplaatst door Acidfever
Toch vreemd dat de meeste audio engines dan nog steeds in C++ of Assembler gemaakt worden. Zal toch wel een specifieke reden achter zitten denk ik.
Macht der gewoonte, ben ik bang. Waarom zou je iets op een andere manier gaan doen? Je kon het al in C en snel ook (zowel het programmeren zelf als de executie), dus waarom zou je dan een nieuwe taal gaan leren en daarin uitvinden hoe het snel kan?

Ter illustratie: precies dezelfde semi-religieuze discussies vind je terug bij de technische rekenaars (ingenieurs, wetenschappers, e.d.), maar dan als "Fortran vs. de beschaving". Fortran is werkelijk een vreselijke taal, maar zo'n beetje het enige dat ingeburgerd was toen er veel (en relatief goedkoop) rekenkracht beschikbaar kwam voor de onderzoekswereld -we spreken ergens halverwege de jaren 70.

Het gevolg is dat nog steeds hele generaties onderzoekers van alle rangen en standen zweren bij Fortran omdat het beter zou performen voor rekenkundige taken. Op een single-processor machine of message passing algorithm situatie is dat sowieso onzin, want meestal is de (optimizing) backend gelijk en wordt alleen een frontend (Fortran, C, C++) gebruikt en voor de multi-processor machines (Cray en the likes) bestaan er varianten van C die net als de nieuwere Fortran-talen data-parallele statements kennen.

Maar het zit er dus zo hard in dat men werkelijk massaal bereid is verschrikkelijk veel tijd aan softwareontwikkeling te spenderen, want het ontwikkelt nu eenmaal minder snel in Fortran dan in een fatsoenlijke taal als Java, op grond van feiten die al minstens 1 decennium niet meer aan de orde zijn.

Een taal als Java is trouwens dan wel een "best of both worlds" vw. die native interfaces. Ik stel me zo voor dat Arturia alles in Java doet behalve de stukken waar er echt met raw floats gespeeld moet worden.
 
Macht der gewoonte, ben ik bang

ik denk dat het daar niets mee te maken heeft, want java en C# programmeren echt wel wat lekkerder dan C of C++.
Dus behalve om snelheidsredenen gaat niemand vrijwillig in die ouwe talen programmeren :)

Maar nu deze topic toch weer wat aandacht krijgt stel ik mijn vraag nogmaals:
Heeft iemand al een VST plugin in C# (of een andere .NET-taal) gemaakt?
 
maarre, wat is er eigenlijk mis met de oude vertrouwde synthedit??

het schijnt dat je daar eigenlijk best nog wel goede plugjes mee kan maken.

je hebt meteen alle "bouwstenen" al bij de hand.

k zal wel weer een domme vraag stellen maar waarom moeilijk doen als het ook makkelijk kan?
 
@bliepbliep: dat is geen domme vraag hoor :)
het is puur om te kijken of het kan. Noem het maar interesse.
En ik vind het altijd leuk om verder te kijken dan de "bouwstenen" die je krijgt van een bestaand pakket.
 
Voor wat de ontwikkel omgeving betreft nog een kleine aanvullende tip. Ik ontwikkel VST's in C++ met de DevC++ omgeving en die is gratis, simple en werkt prima. Mijnheer Gates is al rijk genoeg naar mijn mening. ;)

Ik zou het trouwens leuk vinden als we meer software ontwikkel discussies op dit forum zouden hebben.
 
Nog even over de performance..

Ik zou zeggen: lees deze thread over 5 jaar nog maar eens terug.
Waarschijnlijk zul je een beetje gniffelen bij het lezen van de opmerkingen over de traagheid van java en c#.

10 jaar geleden dachten de meeste mensen ook dat je alles in assembler moest schrijven om die laatste paar cpu cycles uit de software te persen.

Geen enkele serieuze ontwikkelaar zal er nu ooit nog voor kiezen om een uitgebreide applicatie in assembler te gaan schrijven. Op een gegeven moment gaat de onderhoudbaarheid een grotere rol spelen dan dat kleine beetje performanceverschil.

Ok, de allerbeste assembler programmeurs kunnen waarschijnlijk betere software uitpoepen dan de slechtste javaprogrammeurs, maar over het algemeen komt de overhead die komt kijken bij het gebruik van een low-level taal de kwaliteit van de software niet ten goede.

Als zelfs mijn oude telefoon met gemak java applicaties draait, dan zal extra last voor mijn 3.4ghz pc wel meevallen.

Toch denk ik dat vooral door de bestaande SDK's, voorbeeldcode en documentatie C++ de beste keus is als je een plugin wilt maken, maar die keuze heeft wat mij betreft weinig met performance te maken.
 
Origineel geplaatst door AlonsoMos
Bedankt voor jullie antwoorden maar mijn vraag blijft: kan ik in .NET (C#) een VST plugin maken?

Het gaat me niet om performance. Ik wil gewoon kijken of het kan.
Ik heb geen ambitie om een nieuwe synth te schrijven :)

Probeer het gewoon zou ik zeggen ;)
 
Synthedit maakt geen gebruik van de instructiesets van de CPU, daarom is het wat minder efficient.
Er is iig kortgeleden een 3rd party Filter module uitgekomen en een OSC module die wel gebruik maakt ervan,
en er was een duidelijke performance winst volgens de developer.
Waarschijnlijk komen er dan nog wel meer modules uit ermee.

Volgensmij komt er ook een SSE included synthedit versie.... maar dat weet ik zo niet zeker.

locatie filter & OSC :

yahoo SE usergroup > Files > Modules > RJ_Modules > rj_filter2_sse.zip
yahoo SE usergroup > Files > Modules > RJ_Modules > la_quad2.zip



De standaard set van modules in SE niet erg groot, en is het verstandig op zoek te gaan naar 3rd party modules.
Of de modules zelf te maken mbv de SDK en een C++ compiler.

links naar modules :

http://www.dehaupt.com/SynthEdit/semodules.htm
http://www.rubidiumhexafluorosilicate.com/synthedit/
http://www.audiosyn.com/home/seprefabs/
http://www.crashforce.demon.co.uk/cmrdigital/SEmodules/index.html
http://www.puntoexe.info/SLSEModules/
http://home.comcast.net/~deztex/modules.html (---- SOURCE CODE INCLUDED !
http://www.chriskerry.f9.co.uk/
http://www.evmsynths.com/modules.htm (--- geen modules op dit moment blijkbaar..stond altijd wat :S (updates misschien)
http://www.dadev.com./
http://synthedit.xs4all.nl/cms/index.php?name=Downloads

http://www.panicnow.net/~emusic/ (--- deze developer kan met FFT overweg, zie zijn wavedraw systeem.



Synthedit Versie 1.1 zal een Sysex module bevatten, zodat het mogelijk wordt om in SE een controller te maken om sysex codes naar de hardware synth te sturen.
...je eigen Sysex controller VST :D

Huidige versie : 1.011
http://www.synthedit.com/downloads_beta_main.htm

:W
 
Laatst gewijzigd:
Back
Top