From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Nu Audio Science ·
Im starting to get to grips with the component module differences
I was actually wondering if an SDK is planned for components or if the code component was enough ?
Would compiled components be anymore streamlined than code components ?
My partner at NAS (KLF@KVR) does the coding and i do the prototyping (So far SE) GUIs samples presets and MIDIfiles , We have decided to crossover to SM for prototyping but i haven't convinced him entirely yet that SM will replace C++ for finished plugs (He's in love with JUCE), I thought i better supply some backgrounds in reference to the above question.
Oh i should mention Dhaupt has created a lot of unreleased modules for us to get SE prototypes working in the past.
jorge ·
Nu Audio Science wrote: I was actually wondering if an SDK is planned for components or if the code component was enough ?
An SDK is not only planned but we have an initial internal one although I dont think we'll be releasing it soon. With an SDK you need a function call each time you want to call the SDK's module, with one sample at a time processing you would need 1 function call per sample which is just too slow. SDKs are ok for applications that process frames rather than samples. If you were creating a Poly component for SM using an SDK you'd just be passing to SM the high-level code that you normally type inside a code component, not much point in doing that.
Nu Audio Science wrote: Would compiled components be anymore streamlined than code components ?
The code compiled by SM is more efficient than code compiled by C++ as it is dedicated to SSE sound processing. For example, with SM you dont have any function calls, when you do a comparison you get a mask without any conversion to float etc. Basically the SM high level language is very close to actually writting assembler although in a much more user friendly way. Also like I said before, if you wrote an SDK module with C++ you'd need one function call per sample which would make it very inefficient. Another advantage of SM is that the code is re-linked every time you press a switch or change a selection.
Nu Audio Science ·
So you are saying that SM is better or should i say more efficient than C++ , Right im gonna point KLF to this thread (See if we cant drag him away from JUCE) 🙂
jorge ·
Nu Audio Science wrote: So you are saying that SM is better or should i say more efficient than C++ , Right im gonna point KLF to this thread (See if we cant drag him away from JUCE) 🙂
I wouldnt say that SM is better than C++ as it is not so complete and not as user friendly as you cant use conditional statements. The reason you cant use conditional statements is for efficiency. What I'd say is that SM is quite a lot more efficient than C++ even when using intrinsic SSE functions.
Nu Audio Science ·
So whats the chances of different code components C++ maybe Java and so on ?
Probably a really stupid question but then im not the coder here at NAS 🙂
jorge ·
Nu Audio Science wrote: So whats the chances of different code components C++ maybe Java and so on ?
When you're coding for SSE you cant really have conditional statements like you have in C++ and Java as you're processing 4 floats simultaneously. For processing sound, we have efficiency as a priority so C++/Java wont be likely, better to have a faster-than-c++ SM high-level language. For other things like Midi, Drawing etc it would be good to have C++/Java, it might happen but not in the near future.
Nu Audio Science ·
Cheers Jorge
JAVA would be cool for GUI stuff, KLF is a wizard with that stuff
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker