From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
I remembered my suggestion to split up SM's VST DLL into separate parts depending on functions (to help with size, speed, & crossing over into Mac & Linux) when I saw this Flash-studio & Flash's new experimental C++ DLL linking. If SM switched over to Flash, which has many more tools for development, then all SM devs have to do is figuring out how audio works on other platforms. I'm not sure if Flash has sample-accurate timing, but perhaps another dev (which would be easy to find) can focus on both the run-time & editor GUI, & SM devs can focus on the audio & MIDI parts.
Only cavat is this quote:
Ideally suited for computation-intensive use cases, such as audio/video transcoding, data manipulation, XML parsing, cryptographic functions or physics simulation, performance can be considerably faster than ActionScript 3.0 and anywhere from 2-10x slower than native C/C++ code.
I'm assuming that is for GUI-intensive actions, not playing audio when the VST is hidden. & perhaps it will not be that slow for SM, & once Alchemy leaves beta it will be faster.
Lua seems dead, so Flash-SM 2.0 perhaps?
stefan ·
That C++ compiler, as you probably understood, compiles to Flash, so it's not about linking platform specific compiled C++ into Flash. And the performance for DSP tasks is quite horrible compared to in natively compiled C++ (or SM for that matter).
Flash has its uses, that's for sure, but it's not within performance critical applications. Not yet anyway. I'm already keeping an eye on this project though, it's highly interesting and usable for lots of things 🙂
infuzion ·
stefan wrote: And the performance for DSP tasks is quite horrible compared to in natively compiled C++ (or SM for that matter).
After about 4 months of research, I'll have to agree, somewhat. Using flash as a centre point of a VSTi would be a bad idea, since Flash has more timing issues for "frame-rate" than SM does for MIDI timing, due to how Flash schedules tasks to CPU per frame:
http://gskinner.com/talks/quick/#29 #30, #31, #32, #33
http://www.craftymind.com/2008/04/18/up ... -and-avm2/
So for VSTs, I'd think I it would not be a good idea to have a wrapper around a Flash .SWF to make a VST out of Flash, such as the one for Java. But I still think a GUI-less VST could use Flash as a front-end, such as the one that exists already. This could be SM's ticket to OSX compatibility (even if it is export-only).
Also, I could see SM's audio engine (scheduling voices, etc) be translated into a Flash/Flex/Air library plugin, such as the SM-X for Firefox years ago:
via Alchemy
C=64 .sid in Flash: http://www.unitzeroone.com/blog/2009/02 ... -flash-10/
http://www.unitzeroone.com/blog/2009/05 ... compilers/