DSP Robotics Support

I guess some of these become relevant now that we have DLL control. Maybe we could make this a Library Resource Thread for where to find stuff for the new DLL feature. Open-source is great because it is free but selling it is another thing. The Bass library costs allot. I wonder if there are any free libraries that allow you to sell what you make?

BASS is an audio library for use in software on several platforms. Its purpose is to provide developers with powerful and efficient sample, stream (MP3, MP2, MP1, OGG, WAV, AIFF, custom generated, and more via OS codecs and add-ons), MOD music (XM, IT, S3M, MOD, MTM, UMX), MO3 music (MP3/OGG compressed MODs), and recording functions. All in a compact DLL that won't bloat your distribution.
http://www.un4seen.com/

Also check out the section on midi here http://www.un4seen.com/doc/#bassmidi/bassmidi.html

Licensing is expensive though.

============================================================================================

Also maybe Allegro https://www.allegro.cc/about its open-source.

============================================================================================
jdksmidi
This library was originally a collection of utility functions for MIDI written in C back in 1986 for the Atari ST computer. Since then it has evolved into a fairly powerful C++ MIDI Library including:

* MIDI parsing
* MIDI Show Control message creation and handling
* Standard MIDI File type 0 and type 1 reading and writing
* Timestamped MIDI message and System Exclusive encapsulation
* Efficient MIDI Track objects for sequencing
* MIDI Track objects for editing MIDI events
* MIDI message process chains
* Containers for multiple MIDI Tracks with iterators
* MIDI Sequencer core for sequencing and triggering GUI events
* MIDI Driver abstractions for I/O and sequencing
* MIDI Driver implementation for Win32 for I/O and sequencing
* Tempo calculations
* MIDI Matrix to count note on's and off's and hold pedals to avoid stuck notes and all-notes-off problems when merging midi streams
* SMPTE management and calculations
* MIDI Utilities useful functions

Supported Operating Systems
win32,
win64,
Mac OS X,
Linux,
UcLinux,
other Unix style systems,
other embedded systems, 16 bit, 32 bit, 64 bit.

https://github.com/jdkoftinoff/jdksmidi

==========================================================================================
OpenMIDIProject
http://openmidiproject.sourceforge.jp/index_en.html

will these even work? the way im understanding the dll thing is it is for custom built dll's, it says in the manual that the dll's functions has to contain certain code to work!

"Now that we've looked at the component let's turn our attentions to the dll. As you've seen, the DLL
component calls a particular function in your dll. This function must have a very specific declaration
which goes as follows:
extern "C" __declspec(dllexport) void myFunction( int nParams, int* pIn, int* pOut )"

so then you need do your own dll's? useless to the likes of me! but it would be nice to see what stuff others can achive with this

Regards

I don't know if they will work Jay. I think we will have to do some futzing around in C. The good thing is that there is tons of source-code lying around so maybe we can fumble around in C just enough to get the parts we want.

So is it now possible, to not only copy the good willed demo's of others to flood the market with uninspired crap.
But to also repackage plugins of others
That would be ram dumps and worlds of hurt for some.

MegaHurtz - your comments are "brilliant" as usual.

Im sory, im just the guy for a brutal antithesis.
It gives me wood

MegaHurtz wrote:So is it now possible, to not only copy the good willed demo's of others to flood the market with uninspired crap.
But to also repackage plugins of others

Looks like ttey have made a pretty good effort to address that worry.
The .dllls must be custom written to match a very particular FS function call signature, you can't directly import or wrap any old .dll that you take a fancy to.
No doubt you could call into other .dlls by creating a wrapper - but "child" .dlls cannot be wrapped into the schematic in the same way. As I read it, once wrapped, the primitive's "custom" dll is put in a little sandbox from where it can't share global memory space.
Maybe it's hackable by someone who really knows their chops (what isn't?) - but it's a huge effort for a casual re-skinner, and potentially more secure for developers than was previously possible with an SM/FS export.

Nothing isn't hackable indeed
Then everybody's happy right. Reminds me of a conversation I had trying to struggle with asm, dll in dll stuff.
No time and bitter x-over to do the graphics.. Tsjeez

Of course, we've got to write something worth hacking first before we can find out for sure!

I denounce your logic! My next project is shure to cause global thermo nuclear warfare.