Thank you for the clarification. I realized that atoms were compiled, but could possibly leave a string for certain custom function calls such as coefficients or even logic arguments. So, now I know they are quite 'tight'. And I thank you for this info.jksuperstar wrote:Happycritter, atoms are already compiled code, they don't have interpreters or compilers in themselves, so no, there isn't anything to just type in a math equation. I think matlab can export C code, but you'd probably need a special license for that. But I wouldn't worry about that yet...the atoms do have a lot to offer, and you can get most things done there.
What SCOPE SDK does is take your circuit design, of graphically connected atoms, and links those into a device or module. Think of the SDK as a graphic programming language. That's for the DSP end of things. For SDK 5.1, there are also scripts and other ways to run on the host/PC aside from atoms. But they are more or less completely contained within the parent process of SCOPE.
What the new SDK6 and GUI SDK offer is APIs to run your native code in any way you like. They suggest JUCE, but that's not the limit. Graphical programming of DSPs using atoms is still mostly the same.
Really, you can get most objectives accomplished in Modular. The SDK takes it to a lower level, and let's you use all the atoms available to make an optimized device for scope fusion, or a new module for use in modular. Many atoms exist as a modular in Modular. Then there's the dongle/gui sdk approach that allows you to write your own DSP code. It is very much worth while spending time in Modular first, since you will get to understand the system rules, such as how polyphony works, how to deal with feedback paths, and even various data type connections available. These rules more or less apply to the SDK graphical language as well. By the time you get to writing assembler code, you will understand what you can and cannot do.
For some things I have in mind, the circuit approach may prove to be very useful...
Thanks for this very useful information! I look at MATLAB as a wrapper for a C++ engine since the commands are more than 90% the same, only one doesn't have write/bookkeep code for common functions. I will develop in MATLAB for numerous reasons, and then when code is ready, make the necessary adjustments.jhulk wrote:if your going to compile into a .dll you will need the guisdk and compiler of your choice vstudio is recommended for pc then you can use your own class library or one of the others juce vstgui
you can create your c++ algos and then interface them to use sync and async pads for the scope dsp,s and a gui interface for the controls
once you have compiled your .dll file it then can be added to the module list and you can then wire it up using the sdk
you will need the sdk 5.1 is very stable and would recommend asking for that version as sdk6 crashes
ask gary b about the sdk for the xite and the guisdk beta
then go to bcmodular and ask sharc to join the sdk developers forum
there are several developers working on the guisdk as its a new avenue to lots of them and theirs a wiki being created about it only for developers
explaining the atoms list and various how to,s
and the master that is tgstgs also frequents with his vast knowledge
I now have a clearer understanding of what approaches are available for what tasks, and for this I am very grateful.