Generate the code for further dsp challenge?

[llze]

Hello..

i wonder if its possible to generate the code for further tweakin in c++ to reach dsp level with a finished plugin in sonicbirth..like you can do it in synth edit or synth maker..

thx mark

[eigentone]

If I understand you correctly, No.

In many cases, you have a better alternative - SonicBirth's source code is available:

http://sourceforge.net/projects/sonicbirth/

The project is not entirely C++ - there is (of course) C and Objective-C. Objective-C is not difficult to learn if you already know C. Creating your own circuits is quite simple - there are only a few things you will have to declare (other than writing the DSP), and they are just the obvious things like name, description, i/o configuration.

So, it will not generate C++ code for you, but it is a great environment to test your algorithms (which you have written in C++).

J

[dscro]

Yes, it's great for that. Because you can test your math in minutes and then save yourself hours of coding that might lead to nothing useful. When you get something that sounds good in SB then you can write it from scratch in C++ as an AU or VST using appropriate SDK from Apple or Steinberg.

[eigentone]

Yes, it's great for that. Because you can test your math in minutes and then save yourself hours of coding that might lead to nothing useful. When you get something that sounds good in SB then you can write it from scratch in C++ as an AU or VST using appropriate SDK from Apple or Steinberg.

I have been meaning to improve this in the SB project (as in, for C++/C developers), so it should eventually be even easier.

J

[dscro]

That would be fantastic! If we could actually somehow use the code from SB in a more direct way in a native coded AU to save time rewriting everything from scratch. Or, if SB could actually generate completely free-standing AUs and VSTs without the need for working with the specific SDKs . . that would be even better, even if it meant later going into the code in places to optimize routines etc.

[eigentone]

Hi dscro,

Using elements within other projects would be very easy (I haven't tried it, but from my knowledge of the project... it would take very very little code).

Much of the code is highly optimized, but a lot of it is designed for the SB environment (which will not be optimal for other projects).

Just remember, SB is under GPL.

wrt SDKs, the SB project is not an ideal way to 'remove' the AU/VST interfaces... though maybe you are referring to the SonicBirth framework.

Cheers,

J

[dscro]

Yeah. What I was really thinking is that down the road it would be terrific if an exported-to-AU SB plug could run on another users machine without the need to install the SB framework.

But moreover,
When I've written a few very basic Au plugs after working through Apple's Audio unit tutorial, there are all of the steps of designing the parameters interface, and of course defining the parameters themselves, initializing them, creating a sub class of AU effect base class . . etc. Then, just a handful of lines of actual DSP processing of the sample buffer in all the code. Those lines are the simple part for me. It's all the other details in the coding that take me so much time. Obviously, SB somehow takes care of all that now. Could it still do that and yet export a plug that doesn't need its framework to run?

[eigentone]

Yeah. What I was really thinking is that down the road it would be terrific if an exported-to-AU SB plug could run on another users machine without the need to install the SB framework.

I haven't done any coding for SB in regards to getting the plugins to run without the framework - it isn't presently priority for me. From what I do know, coding this would be a very large undertaking. Sure, it could be done *fairly* quickly, if it were done the wrong way. If it were done the right way, I'd say it would require much restructuring of the current code base. SB is written using primarily 3 programming languages - all them message/load/run a bit differently. The reason it would have to be done *right* is that whoever programs this aspect should assume that other SB created plugins would exist at runtime, and they may not necessarily be using the same version. Since there can be binary differences, one plugin instance's executable code could interfere with another instance - as in, a plugin could make a call, and it could be handled by the other plugin's executable. In this case, the call could cause the plugin to behave unexpectedly as the binary (of the framework) can change slightly from release to release. There are, of course, other caveats. An implementation could be hacked together pretty quickly, but to do it right... would take a long time.

But moreover,
When I've written a few very basic Au plugs after working through Apple's Audio unit tutorial, there are all of the steps of designing the parameters interface, and of course defining the parameters themselves, initializing them, creating a sub class of AU effect base class . . etc. Then, just a handful of lines of actual DSP processing of the sample buffer in all the code. Those lines are the simple part for me. It's all the other details in the coding that take me so much time. Obviously, SB somehow takes care of all that now. Could it still do that and yet export a plug that doesn't need its framework to run?

Yeah - you can create library of useful functions/classes/templates and not rewrite so much every time you want to create an AU. Just build a source code library as you work and reuse it in each project. Of course, you can just render things differently using the same plugin - i.e. create a generic filter AU interface and conditionally render (or build) using different algos. Also, I won't write a UI if I don't need it - and if the test/proof of concept AU requires a UI, I'll generally use Cocoa, which is very easy to build UIs with. With Cocoa, you are limited to a few hosts (Logic, GB, AU Lab.... NOT DP, Live...). Maybe all that is obvious to you by now though.


J