External DLL support

infuzion · 13 Mar 2006

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

Shifrin · 13 Mar 2006

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 · 14 Mar 2006

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 · 14 Mar 2006

Hehe, who vote for no???

stefan · 14 Mar 2006

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 · 14 Mar 2006

stefan wrote: ... 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 · 14 Mar 2006

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 · 14 Mar 2006

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 · 14 Mar 2006

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 · 14 Mar 2006

rl wrote: 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 · 14 Mar 2006

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 · 14 Mar 2006

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

infuzion · 14 Mar 2006

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

doug4350 · 14 Mar 2006

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

MyCo · 15 Mar 2006

I voted for "yes", but my C++ is so bad that I couldn't use it But I could translate the SDK to Delphi, so I'm shure that I would use Delphi DLLs. But a big disadvantage is, that if you publish your osm in the board, or your VST in general, you also have to include other DLLs. And if there are several DLLs flying around in the board, there will be big projects with a large number of DLLs. May be there will be commercial DLLs (like you know it from VST plugins), then you have to buy these DLLs, before you can use a free Plugin...

TheAudiophileDutchman · 15 Mar 2006

BUMP

How to implement an efficient realtime convolution algorithm within SM? For sample-based VSTi's, convolution is become fairly standard these days....

See also: Convolution

stefan · 15 Mar 2006

TheAudiophileDutchman wrote: BUMP

How to implement an efficient realtime convolution algorithm within SM? For sample-based VSTi's, convolution is become fairly standard these days....

See also: Convolution

Some kind of stream FFT/iFFT will probably be added further down the road, which basically is what you need for convolution.

TheAudiophileDutchman · 15 Mar 2006

Wow, that's great stuff, Stefan!

TomC · 10 Oct 2007

stefan wrote: Some kind of stream FFT/iFFT will probably be added further down the road, which basically is what you need for convolution.

Any news concerning this?

Tom

Acrobat · 10 Oct 2007

stefan wrote: 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.

I agree with Stefan. Also for me SM must grow on its own... and perhaps using external resources like SE could bring also lots of compatibility issues and crashes, or at least the software behaviour and performance will be less "controllable" by the developers, in my opinion..

matti · 11 Oct 2007

ffx wrote: Some more reasons:

- Using SM for structure and gui

- Speed improvements

Yes! The gui is great! But unfortunately some dsp things are really slow in SM compared to inline assembler inside C++. With the exact same code SM is 4x slower Could be cool to bypass the slowness this way.