kode (plugin toolkit)

Programming applications for making music on Linux.

Moderators: MattKingUSA, khz

User avatar
skei
Established Member
Posts: 337
Joined: Sun May 18, 2014 4:24 pm
Has thanked: 8 times
Been thanked: 57 times
Contact:

kode (plugin toolkit)

Post by skei »

hi!

just a quick post to let you know that i recently set up a github repository for 'kode', my c++ library/toolkit/framework.. it's mainly meant for creating plugins (ladspa, lv2, vst2, vst3), but also useful for anything else.. it's still quite early (v0.0.0), there's a bunch of stuff missing, and things that needs to be fixed, but it's growing and evolving quickly.. take a look at it, and i will happily answer any questions you might have.. i mainly develop it for myself, but if anybody else is interested in it, i will take that into account, and listen to ideas, suggestions, feature requests and stuff like that..

https://github.com/skei/kode

- tor-helge
User avatar
skei
Established Member
Posts: 337
Joined: Sun May 18, 2014 4:24 pm
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: kode (plugin toolkit)

Post by skei »

i added dssi support, plus midi in for the formats that supports it.. and also, in addition to the 25 or so already existing example plugins/ports, there's a simple synth in there, to test the (polyphonic) voice manager class, .. also, tweaked the vst2 part, so it can be compiled with the vestige header, or even completely 'naked' (no vst sdk or vestige header needed)..
next out is editor/gui.. (almost there)..
- tor-helge
Lyberta
Established Member
Posts: 681
Joined: Sat Nov 01, 2014 8:15 pm
Location: The Internet
Been thanked: 1 time

Re: kode (plugin toolkit)

Post by Lyberta »

I've looked at a few files and... wow, what a mess. volatile instead of std::atomic? memcpy instead of std::copy? No support for non-POD types in your KODE_Array class, no thread safety in KODE_Queue_Buffer, no exception safety, reinventing standard library, etc.
User avatar
skei
Established Member
Posts: 337
Joined: Sun May 18, 2014 4:24 pm
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: kode (plugin toolkit)

Post by skei »

that's the kind of reactions i had expected :-)
but no worries.. if you don't like it, just ignore it.. i mainly made the library for my own use, and i think it works pretty well for that.. and i thought i should make the code available, in case anybody else might find it useful for anything..
User avatar
sadko4u
Established Member
Posts: 986
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 359 times

Re: kode (plugin toolkit)

Post by sadko4u »

Lyberta wrote:I've looked at a few files and... wow, what a mess. volatile instead of std::atomic? memcpy instead of std::copy? No support for non-POD types in your KODE_Array class, no thread safety in KODE_Queue_Buffer, no exception safety, reinventing standard library, etc.
^ Don't listen this guy, just do your job ^

I've done some quick review. Splitting small data into classes is not good idea, the overall performance when utilizing huge amount of such classes will be poor. Consider looking this video: https://www.youtube.com/watch?v=rX0ItVEVjHc

According to my observations, bulk operations are much more effective. In other words, you can have a complex class that represents complex numbers and provides some methods to manipulate complex numbers. Working with such class is easy for programmer but very greedy to CPU. And, by the other side, it's not scalable. You need to call some method (for example, multiplication) for each complex number instance. Having array of raw complex numbers just allows us to call one function that will process this array (we eliminate call overhead) and allows to perform additional optimizations like applying SIMD mathematics which gives additional performance boost.
LSP (Linux Studio Plugins) Developer and Maintainer.
User avatar
skei
Established Member
Posts: 337
Joined: Sun May 18, 2014 4:24 pm
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: kode (plugin toolkit)

Post by skei »

thanks for the youtube link..
i think i might have already seen that one, but it won't hurt watching it again!

i haven't focused too much on optimizations yet, except letting gcc do whatever it does when adding an '-O3' argument.. :-) .. but since the entire library/toolkit is headers-only, there's also automatically a form of lto/wpo optimization going on, 'for free'.. which seems to work quite well..

1. make it work
2. make it right
3. make it fast
i'm currently at step 1.3 or something..

from earlier versions of the library, i already have code for a quite fancy (resizable) gui and tons of widget types, mpe/note-expressions, host sync/timing, midi out, plugin hosting, etc, etc.. and will re-introduce all of that in small steps, but i want the 'base' to be as stable as i can, for all the different plugin formats, before i start piling additional features on top of it.. and then, after (or during) that, i will do some testing and profiling and thinking about low-level optimizations..

a lot of the classes, especially in the /core directory, is not really used anywhere.. some of it is me collecting notes and testing/preparing implementations, etc, but deciding to postpone it until later.. there's always a ton of other, more interesting things to do..

- tor-helge
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: kode (plugin toolkit)

Post by fundamental »

After a quick look at the project I'd say it's trying to be too many things at once and it does reinvent the wheel more than need be. I would recommend writing down in the readme what the goals are and clearly define what is outside the scope of the project. By spreading yourself too thin, then it makes it hard to test and hard to improve the overall code. For instance, why would there be a neural network implementation inside a plugin toolkit.

Per Lyberta's points, I would recommend std::atomic if it's built to be a C++ lib, I would either add standard C++isms or declare containers as POD-only in a comment, and I would generally add some top level note motivating why certain things are offered by the library. Some of the containers are built to be AOT defined with a maximum capacity, so that is a differentiator.

Additionally you may want to provide some motivation for why this new library should exist over existing options (e.g. DPF). It's fine if the answer is "Just for fun", though it would be helpful for that to be mentioned in a top level readme.
ZynAddSubFX maintainer
User avatar
SpotlightKid
Established Member
Posts: 250
Joined: Sun Jul 02, 2017 1:24 pm
Has thanked: 48 times
Been thanked: 54 times

Re: kode (plugin toolkit)

Post by SpotlightKid »

Bravo, some constructive criticism at last!
User avatar
skei
Established Member
Posts: 337
Joined: Sun May 18, 2014 4:24 pm
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: kode (plugin toolkit)

Post by skei »

thanks for the comments, and especially the constructive criticism..

i hate writing documentation and specs (like all coders?), but i'm currently trying to put together an introduction thing, that hopefully will explain a little about the toolkit, the what's, why's and how's.. so, give me a few days, and it might all be a little clearer..

but in the meanwhile:

i understand that it might look like an unorganized, amateurish mess, but there's actually quite a bit of reasoning behind most of the 'weirdness'.. the toolkit is meant to be used in some very specific situations, with some quite specific constraints and requirements.. also, i am more of a low-level/assember/hacker type of coder, and after 35 years of programming in multiple languages and for various architectures, i have picked up quite a few bits of knowledge, ideas, and tricks, and probably some pretty bad habits and opinions too.. i have plugins made with earlier versions of the library, working flawlessly here for almost 10 years or so now, in a bunch of different hosts..

it seems to work pretty well.. a simple vst2 plugin compiles in a second or two, and result in a binary file about 40-50k.. and with a gui using xcb/cairo graphics, it's around 200k.. (i know that this doesn't interest many people, but i hate bloat, of any kind, cpu, ram or hd space).. ladspa, dssi, and lv2 is around the same size, but vst3 is a bit bigger because of the com/interface stuff.. the header-only design, and simplistic/naive code works really well for compilation, letting gcc do some real wonders and optimization magic.. a 16-voice synth, with multiple antialiased oscillators, waveguide/resonators, and filters per voice, sample-accurate modulation, extensive modulation matrix, and mpe support takes _very_ little cpu here on my low/mid-spec pc.. and i haven't really started with the _real_ optimizations yet (except some tests with cache-alignment, and code/data locality)..

the toolkit is not meant to replace or compete with neither iplug, juce or dpf, or anytihng else.. it's another option.. more choices is good, eh? :-)

here's a bunch of old vides and images that show some of the features in older versions of the toolkit, that i will bring back to this new version soon:

a synth:

http://www.youtube.com/watch?v=mHkavADdvFQ

modular/timeline stuff:

http://www.youtube.com/watch?v=wSvu2oGoYlg

hierarchial gui:

http://www.youtube.com/watch?v=DDteKLfEPVo

some older images (some plugins, and some jesusonic scripts that i have later ported to 'real' plugins):

Image

Image

Image

Image

Image

- tor-helge
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: kode (plugin toolkit)

Post by CrocoDuck »

fundamental wrote:For instance, why would there be a neural network implementation inside a plugin toolkit.
I am really not that much of an expert about this but what I think is... why not?

For instance, the simplest kind of adaptive FIR filter is indeed a neural network with linear kernel. So, this would enable adaptive filtering quite nicely. Also, use of neural networks is growing in the field of linear and nonlinear system identification, and I see this technology being useful for building measurement/profiling plugins. I think there is gonna be more and more of a role for neural networks in audio in the future, and we are seeing some examples indeed:

https://github.com/lucianodato/speech-denoiser

Now, audio coding is a hard realtime thingie (is that the correct technical term?) so, we need good realtime safe implementations at the very least for forward propagation... so I guess it makes sense to have a realtime friendly neural nets implementation in a plugin toolkit, as maybe those used in other toolkits put the emphasis of numerical accuracy and stability rather than speed. This is exactly why these guys had to write their own run-time neural network code in C:

https://people.xiph.org/~jm/demo/rnnoise/

Just my 2 cents.
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: kode (plugin toolkit)

Post by fundamental »

skei wrote:i hate writing documentation and specs (like all coders?), but i'm currently trying to put together an introduction thing, that hopefully will explain a little about the toolkit, the what's, why's and how's.. so, give me a few days, and it might all be a little clearer..
Then I'd stick with something akin to a blog post introducing the library and talking vaguely about some of the highlights. IMO a lot of the code can be somewhat self documenting with the inclusion of example plugins if the broader context is described/discussed in enough detail.
i hate bloat, of any kind
If so, do you think it's worth it to support LADSPA and DSSI at this stage?
Both are by and large on their way out (DSSI moreso than LADSPA).
the toolkit is not meant to replace or compete with neither iplug, juce or dpf, or anytihng else.. it's another option..
Sure thing. Based upon what you've written your elevator pitch is mostly "kode is a header-centric C++ library for creating audio plugins which focuses on lightweight, fast to compile, fast to run apps. It has been slowly built up over the years and has been used in a number of cross-platform plugins including: LIST HERE"

more choices is good, eh? :-)
My opinion is that more choices are good if there are there are community resources to support the different options, the options have some notable areas where they do not overlap, and the needed information to users of the options is available to know which option to look into. If there are multiple options that are essentially equivalent, without the needed contributors, and without a clear distinction for users to make a choice, then you end up with lackluster software and confused users. That does not seem to be the case here whatsoever, but I figured I'd throw out that general opinion.
CrocoDuck wrote:why not?
If something is used by only a very small number of users of a library, then the code adds a maintenance burden without significant benefits. The added scope creep of adding features which are used in fringe cases can result in bloated libraries which will end up unpolished and eventually unmaintained. For something very domain specific the code should either be in a library where it is a more primary focus or it should be tied to the specific application instead of the library itself.

On top of all of that it makes the library look unfocused and that can make people less likely to use it as it has more complexity than they need even if they aren't directly referencing the code in question. If the goal of the library is to be lightweight, then something like this seems beyond secondary to that goal and should be delegated to a specific example rather than the library core. That's my opinion anyway.
ZynAddSubFX maintainer
User avatar
skei
Established Member
Posts: 337
Joined: Sun May 18, 2014 4:24 pm
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: kode (plugin toolkit)

Post by skei »

again, thanks for all comments and opinions..
now that the christmas/new-year holiday/celebrations are over, i will get back to you all, and answer your questions soon..
but i quickly mashed together a sketch with some information, to maybe get some more comments and opinions and questions before i do any real 'public announcements'.. (and it might answer some of your questions already)..
i am preparing a page for the toolkit on my website, with documentation and examples and info.. but there's tons of other code-related things i'd rather want to do, so it's hard to find motivation.. one day i need to 'kick myself in the ass' and just jump into it, and get it done.. :-/

kode toolkit
v0.0.0
https://github.com/skei/kode
kode is (will be) a header-centric c++ toolkit for creating cross platform audio plugins and applications, supporting multiple plugin formats and gui apis.. it focuses on lightweight, fast to compile, fast to run apps and plugins, and un-bloated, cpu-efficient binaries.. to simplify and motivate rapid exploration and experimentation, it also contains a large number of utility classes and helper functionality (audio/dsp, debugging, gfx, math, etc).. it has been slowly built up over the years, and has been used in a number of plugins including: <TODO: LIST HERE>
some of the features:
  • architecture: linux, 64bit
  • plugin formats: dssi, ladspa, lv2, vst2, vst3, and standalone executables
  • gui: xcb, cairo (vst2 only at the moment)
  • lv2: internal .ttl generator
  • vst2: can be compiled with steinberg sdk, the vestige header, or none at all
coming soon:
  • resizable, scalable gui (vectorial/bitmaps)
  • mpe, note expressions
  • 32bit (in theory it's already 32-bit ready, but not tested)
  • windows support (mainly needed for gui, nogui should work almost as-is)
  • plugin hosting (ladspa/dssi more or less done)
comparison:
(work in progress)

Code: Select all


                kode  juce  dpf   iplug

linux           +     +     +     -
windows         -     +     +     +
mac             -     +     +     +

dssi            +     -     +     -
exe             +     +     +     .
ladspa          +     -     +     -
lv2             +     -     +     -
vst2            +     +     +     +
vst3            +     +     -     +

simplicity      +     -     .     .
flexibility     +     +     .     .
efficiency      +     .     .     .
features        .     +     .     +
bloat           +     -     .     .
dependencies    +     -     +     -
license         .     .     +     .

(+ = yes/good, - = no/bad, . = unknown)

juce:  no ladspa/dssi/lv2, big and bloated, telemetry, awkward license
dpf:   no vst3, no midi out, gui/plugin communication using strings
iplug: no linux, no ladspa/dssi/lv2, wdl (window-centric abstractions), mutexes/locks everywhere
here's a working, minimal, do-nothing plugin.. :-)

Code: Select all

#include "core/kode.h"
#include "core/kode_main.h"
#include "plugin/kode_plugin.h"
#include "plugin/kode_instance.h"

class myInstance
: public KODE_Instance {
  public:
    myInstance(KODE_BasePlugin* APlugin, void* AHost)
    : KODE_Instance(APlugin,AHost) {}
    virtual ~myInstance() {}
};

class myPlugin
: public KODE_Plugin {
  public:
    myPlugin() : KODE_Plugin() {}
    virtual ~myPlugin() {}
    KODE_BaseInstance* createPluginInstance(void* AHost) final {
      return new myInstance(this,AHost);
    }
};

KODE_MAIN(myPlugin)
- tor-helge
User avatar
SpotlightKid
Established Member
Posts: 250
Joined: Sun Jul 02, 2017 1:24 pm
Has thanked: 48 times
Been thanked: 54 times

Re: kode (plugin toolkit)

Post by SpotlightKid »

DPF plug-ins actually can produce MIDI output now.
User avatar
skei
Established Member
Posts: 337
Joined: Sun May 18, 2014 4:24 pm
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: kode (plugin toolkit)

Post by skei »

SpotlightKid wrote:DPF plug-ins actually can produce MIDI output now.
nice!
i will need to update the info/comparisons before posting it anywhere else..

- tor-helge
User avatar
skei
Established Member
Posts: 337
Joined: Sun May 18, 2014 4:24 pm
Has thanked: 8 times
Been thanked: 57 times
Contact:

Re: kode (plugin toolkit)

Post by skei »

a small update, in case anybody is interested:

* added an initial description on the github page.
* all (30 or so) example plugins, all plugin formats, compile without warnings, using simple 'build all plugins' scripts. (maybe i should collect them, and post a 'ported plugin pack' of some kind?)
* added a ton of audio related things.. antialiased oscillators, filters, processing, oversampling, analysis, etc..
* gui is on its way back, currently exe and vst2 only (vst3 and lv2 in progress), but the most important widgets (knob, slider, etc) to get started with a plugin editor is in place now..
* docs, etc, is still completely missing.. i started some drafts, but it's a bit messy.. need to find some motivation to really focus on it.. :-/

i'm not 100% sure about what direction i should take from here.. two main choices.. i can either continue to work on the toolkit itself, or i can get back to where i left off (before i started this 'rewrite entire toolkit from scratch' thing).. i was working on a hybrid synth, with elements of subtractive, phase modulation and waveguide/resonator stuff.. the sounds i managed to create with the prototype was _very_ promising, and i got tons of new ideas during the last months/year.. maybe it would be nice to show what the toolkit is capable of..

we'll see..
Post Reply