External DLL support

[ffx]

Hello,

wouldn't it be nice to have the ability to include external DLLs for example for including C++ programmed DSP code or resources into SM projects?

Thanks & regards,

ffx

[infuzion]

welcome to the forum FFX
Does it have to be C++? I want to program in Rexx

[Shifrin]

I voted don't care as I personally have no use for such a feature, indeed I dumped C++ for SM! I could see uses for it, but I'd probably stay clear of such things

REXX?! Woah, I've not heard that mentioned since I used to dable with ARexx on my Amiga many years ago

Bring on the Brainf**k interpretor

Shif.

[ffx]

Also it would be cool if there was a processor detector module available, so I could load different optimised DLLs for each cpu type.

[ffx]

Hehe, who vote for no???

[stefan]

If I'd feel it was right for me to vote I would vote no I want SynthMaker to be as self-contained as possible, and hence I want as much as possible to be doable _within_ SM, instead of externally. When I started using it, it was instead if C++, so for all my DSP stuff, I stopped using C++ and started using SM instead.

Why not do your DSP code within SM? I know some things are a bit cumbersome, but it'd be good to know what's hindering you.

Cheers!

[rl]

...
Why not do your DSP code within SM? I know some things are a bit cumbersome, but it'd be good to know what's hindering you.

Cheers!

here is why I would vote for a SDK (even if it had limited possibilities):

- no support for double (sometimes needed)
- currently the codemodule is not suitable for bigger tasks (FFT, iFFT, PSOLA) (or pls. show me how to implement FFT, iFFT with windowing size/function using the current feature set.)
- no subroutines in code module
- limited loop support (no variable loop boundaries (BTW: how about allowing them for non vectorized vars))
- no support for binary files (e.g. to extract special chunks from wavefiles, read midi files,....)
- easier port of existing dsp algorithms
- VST hosting
- sidechaining
- ... general: go beyond the existing possibilities

(enough is never good enough, you know)

[stefan]

I don't see why it wouldn't be better to have native support for those things Ofcourse, it might take a while, so one would have to be able to cope with that, and just because I can you don't have to

What do you mean by sidechaining btw?

[rl]

mixer sidechaining, e.g. for a ducking compressor/limiter: Have a plugin in one "mixer-channel" that "side-chains" to another mixer channel to control a compressor/limiter.

[Tom7777]

I agree with Stefan on this, i think that the code module should just get updated a bit and it should all be done in SM.

[stefan]

mixer sidechaining, e.g. for a ducking compressor/limiter: Have a plugin in one "mixer-channel" that "side-chains" to another mixer channel to control a compressor/limiter.

So instead of routing the two channels to the same effect you'd have two effect instances with a shared memory area?

I know what sidechaining is, I just didn't know what you meant was missing for it

[ffx]

You don't have to use dll support if you don't want...

I also would like to use sm modules in most cases. But sometimes it could be a good feature.

I am writing about the possibility to load dlls and use its resources or code within a SM dll loader module.

There are a huge lot of reasons and also unpredictable reasons, this could be very helpful.

Some more reasons:

- Using SM for structure and gui
- Including a wide range of open source projects
- Complex algorithms like neural networking or fft
- Speed improvements
- Transferring data to other applications or network
etc.

I believe it would Synthmaker be an even more professional audio development application, maybe even a new standard application?

[stefan]

The most valid points I've seen so far, I'll give you that!

[infuzion]

good discussion; I was attracted to SE because I could use it as a skelton for C++.

[doug4350]

I voted (unofficially) for this early on when I jumped on board. I was informed it is possible to have an sdk and would more than likely be possible down the road. I also heard there was concern on function call overhead, but there's ways around that. rl and ffx pretty much hit my reasons, which are to overcome limitations in SM that might otherwise hold me back or be 10x harder in SM than in C. No slam intended, I have all the confidence in SM. This has been demonstrated by the past several releases which have fairly significant new features and not just maintenance.

Maybe this is a blessing in disguise to the dev's. I bet there'd be fewer posts here with an sdk on the streets .

Aloha,
Doug