Features: Makes sdk more standard

[hickscorp]

This PR is an attempt to make the Korg Logue SDK more modern.

It allows projects to reference include files globally so the SDK can be installed in a standard location (Eg /usr/local or ~/.local/opt) and include paths can be properly specified (Eg using #include <logue/whatever.h> vs the old "local" includes #include "whatever.h").

Reciprocally, all examples are also updated and show good practice as per how to import things.

This PR's goal is to prepare the SDK for modern and standard distribution packaging (deb, rpm etc).

Note that I chose to have all include files placed inside a logue folder - so global includes reference it in user projects - but it could be changed easily to anything else - keep in mind that having it clearly contain something vendor-specific is much better to avoid name collisions in the future (which I had in my case, as all .h files were not namespaced in a folder). Also, having inc/utils, inc/dsp should not be done anymore, again because of name collisions. Instead, a user who want to use anything in the utils folder can now refer to it directly (Eg #include <logue/utils/float_whatever.h>). This is also reflected in the example projects.

[hickscorp]

Any chance we could get this merged? The vanilla really doesn't feel very professional - having to include it in each project (vs what my PR does - eg have it at one place of your system and being able to reference it from all user projects).

These are pretty standard conventions applied here...

[hickscorp]

Bump? Anyone? Dead projecy?

[xiashj24]

Making logue-sdk compatible with package managers is a great idea!
Unfortunately we do not have enough resources to revamp logue-sdk for the og products (nutekt-digital, minilogue-xd, etc.)
But we definitely want to bring this to new generation products (NTS-1 mk2 and NTS-3).
We will take some time to review your PR and figure out what to do. Thanks!

[hickscorp]

This is 5 years old @xiashj24 ... Not sure I'll be of any help.
The principles I used to refactor the SDK are industry standard. If you look at the original changes you might be able to get the thing to look professional. Having to *copy" the SDK in every project is pretty bad - SDKs (in particular written in C) can usually be singletons in a system.

Good luck!