DSP Robotics Support

No need to reinvent the wheel, ever again.

Sheesh .. thats one cynical streak MegaHurtz has. Hehe

I wasn't implying with this thread that we should all go find DLL's to pillage and plunder. I was more curious if some time could be saved looking for a library to meet our particular needs. I'm not looking to create an uninspired vst. I just want to create a couple vst's that work the way I think. I have 4 years into 2 vst's but they have issue's due to Synthmakers shortcomings ... so I hope the DLL thing changes that.

I have wanted some midi note sorting and midi chord storage functions that Synthmaker could not handle. (Million+ Modules were kicking the cpu's but.) Would it be better to use Ruby or a DLL for this kind of thing? Do I learn Ruby or C?
Also can we make internal mp3 playback happen with a dll? Another question would be how fast can we expect data to move through a wrapped, sandboxed dll? Can we send an audio stream through the DLL or no?

Build-it wrote:Can we send an audio stream through the DLL or no?

Yes, but only in chunks (frames) - so latency will likely be an issue more than raw processing power.

In speed terms, there's no reason that 'frames' should be particularly slow - I think maybe they are a little misunderstood. A Ruby frame is a very small object - just a pointer to a memory address where the buffer (as raw floats) is held. Ruby's relative slowness only kicks in if you process a frame within Ruby - it then has to turn the raw binary data into Ruby Float objects so that you can use them within your code. Doing that conversion (and back again!) for hundreds or thousands of objects is really what kills Ruby for audio processing.

However, when you pass a Ruby frame to a .dll component, you are not doing any conversion or copying - all that happens is that the pointer and data size are passed to the .dll - just a few bytes. Once inside the .dll you can access that memory directly any way you like - and you are always manipulating the data "in place", there's no need to copy it anywhere unless your DSP algorithm requires it. The rest is down to the quality of the .dll programming and the effectiveness of the compiler used to make the .dll.

The limitation is that you need to pass chunks of data - not "one sample at a time" processing as we see with the DSP code and ASM primitives. That's pretty much to be expected - "one sample at a time" is an illusion created by the FS "compiler" to make DSP programming easier; in reality, processing is done "per buffer" as with any other kind of VST.
Calling a .dll for every single sample would be very inefficient anyway - buffers aren't just there to prevent audio glitches, they also enable much more efficient code to be used, and far less thread switching for the CPU.

But that means that there'll be an extra buffer of latency on the .dll processed signal. I don''t know without testing, but possibly this will be cumulative if you chain .dll objects in series, too - so I suspect it will be better to write big .dlls that do a lot rather than many small "primitive" style one; though that assumption could well be wrong.

Incidentally, using the buffer method is probably an advantage if we want to use audio libraries. I would imagine that it's usual to assume that any audio is buffered when writing general-purpose libraries for dealing with streams(i.e. just hand them the memory pointer) - that would be the default method of dealing with them in most app's.

In other words - will it be possible to use free dll's like (if I remember correctly)

http://www.fftw.org/

for external FFT processing at higher resolution, and then get data, splitted into smaller paralel arrays?

tester wrote:In other words - will it be possible to use free dll's like

As far as I can tell; "Use", yes, but embedding them into a module/schematic no.

To do it, you would have to make a "custom" .dll that matches the FS specification. Then use that as an interface to call the 'library' .dll.
The "custom" .dll can be stored into the schematic/export file, so the end user doesn't need that .dll on their system. However, the 'library' cannot be stored into the schematic - the export would only work if the end-user has the same 'libraries' installed on their PC.

I don't wan't to put external dll's into my schematics; it is a rediculous idea for me. External dll's should be external, so that they can be upgraded (by their devs?) without interference on my side (as long as they are compatible with previous templates).

In fact - it would be interesting to have the ability to use modulatized FSM schematics, so that you upgrade only "partials" and not whole "single-schematic" projects.

Though - I still have no idea how to connect such dll to my part.

so the big question is for what it makes sense to create dll`s , i would think about drawing data intensive stuff, everything which uses big arrays of data like drawing audiowaves, manipulating picture data... in general all the non audio thread intenive stuff

maybe there would be also better ways to get midi data out of mono data? (like midi sync to host)

Nubeat7 wrote:midi data out of mono data? (like midi sync to host)

Good idea! All the PPQ sync stuff so far is having to convert to Ruby objects, so they take far too much CPU for a "little utility module" - that would be a really good candidate for conversion.

Yes, but can only work with PDC setted accordly with your buffer audio.

trogluddite wrote:

tester wrote:In other words - will it be possible to use free dll's like

As far as I can tell; "Use", yes, but embedding them into a module/schematic no.

To do it, you would have to make a "custom" .dll that matches the FS specification. Then use that as an interface to call the 'library' .dll.
The "custom" .dll can be stored into the schematic/export file, so the end user doesn't need that .dll on their system. However, the 'library' cannot be stored into the schematic - the export would only work if the end-user has the same 'libraries' installed on their PC.

For achieving what Build-it wants you would need the source code of the library, build it as stati (not dynamic) library. That will produce .lib file, not a .dll file. Then when making your custom dll for FS link to the static library, which will effectively embed the library into the final .dll, at least the part needed for your code to run. SO of course there´s some work to be done, but nothing too extreme.