New DLL feature - Library Resource Thread

[Tronic]

I do not understand why there is not directly manage the stream.
Not be enough to run the module DLL function,
for the cycle automatically, as well as for the Primitive Code and Assembly?
The difference is based on the concept frame, as happens in reality when programming in C.

[tester]

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.

While I read you with pleasure - without understanding.

On above example - the source code is available. http://www.fftw.org/download.html

Build (no matter what) with what from what? And then how the next what?

I guess for folks like me, with no experience on such stuff - some step-by-step guide with example would be helpful. The only thing I (vaguely) understand right now, is - that these external libs have then internal "nodes" to which somehow I can connect something and from which I can get something, and all within some sort of format.

[Tronic]

But is it just me?
it seems that the audio return from the DLL is in advance of the source.
is processed before anything else?
however, the system works like this:
- Create a frame with the size of the audio buffer.
- Shall be taken and passed his memory pointer to the stream,
- Writes the data in memory with an assembly write.
- Frame is reread with the trigger taken from Primitive Frame.

when the data back to its Module DLL,
- Frame is re-created with a different pointer.
- You pass its pointer to the stream and re-read it in blue.

it was better to do it without the cumbersome round ruby?
you might not have an API master clock from to use directly in your code?
Would not it be nice to have the option of using callback from DLL.

For now it seems very nice, but extremely complicated, take something with it.
Would not it be better to have some kind of SDK or API to use inside the DLL?