LinuxMusicians

Posted: **Fri Sep 03, 2021 1:32 pm**

(2009-2021, and still evolving)

the last few days, i've been focusing on the gui
"a picture says more than a thousand words", they say:

source code (the KODE framework itself, and the plugins):
https://github.com/skei/kode2

i compiled a bunch of test plugins, some ported from jesusonic, some from ladspa, some fro other things, and a few i made myself..

https://u.pcloud.link/publink/show?code ... RP8uQNTWLk
(linux, 64bit, 3.3mb)

i recorded a video too, showing all the plugins, but forgot to connect the audio from bitwig to obs, so it turned out silent :-/
will record a new one soon.. in the meanwhile, here's a little older video, where i compile a few different plugin formats, and finally try the plugin in bitwig..
https://www.youtube.com/watch?v=VLrzyw6_X2w

- tor-helge

Posted: **Sat Sep 04, 2021 7:16 am**

First, congratulations for the release!

Second, even if I am not a lawyer, if you have any questions about licensing feel free to PM me. But in short, from what I've seen from your license.txt file, you could travel the same road as JUCE and:
1) Make it GPLv3+
2) Ask contributors to sign a CLA
3) Sell exceptions to the GPLv3
I personally dislike this approach (and so does the community, see the Audacity case) but it makes your library usable

my favorite approach is to go all-in on the AGPLv3+ and, if you want to make money off it, sell support and run a fundraiser.

Posted: **Sat Sep 04, 2021 11:40 am**

Can the GUI use vectors or only images?

I don't see a license file or headers in the source.

Posted: **Sat Sep 04, 2021 1:26 pm**

Basslint wrote: ↑Sat Sep 04, 2021 7:16 am First, congratulations for the release!

Second, even if I am not a lawyer, if you have any questions about licensing feel free to PM me. But in short, from what I've seen from your license.txt file, you could travel the same road as JUCE and:
1) Make it GPLv3+
2) Ask contributors to sign a CLA
3) Sell exceptions to the GPLv3
I personally dislike this approach (and so does the community, see the Audacity case) but it makes your library usable my favorite approach is to go all-in on the AGPLv3+ and, if you want to make money off it, sell support and run a fundraiser.

hi..
need to think a little more about licensing..
personally, i would prefer mit or bsd, but some things in the framework is based on gpl3 licensed code (vst3 api, etc), so i have to respect that, of course.. i could probably say gpl3, and be done with it, i guess... but, some some thinking and consideration is neeed..

not very interested in the money side of things..

Posted: **Sat Sep 04, 2021 1:28 pm**

d.healey wrote: ↑Sat Sep 04, 2021 11:40 am Can the GUI use vectors or only images?
I don't see a license file or headers in the source.

both vector gfx and bitmaps..
and, need to think a little more about licensing..
gpl3 is the most probable, it seems..

- th

Posted: **Sun Sep 05, 2021 7:07 am**

skei wrote: ↑Sat Sep 04, 2021 1:26 pm hi..
need to think a little more about licensing..
personally, i would prefer mit or bsd, but some things in the framework is based on gpl3 licensed code (vst3 api, etc), so i have to respect that, of course.. i could probably say gpl3, and be done with it, i guess... but, some some thinking and consideration is neeed..
not very interested in the money side of things..

GPLv3 is considered a "viral" license (I don't like the term because virus are usually bad things but there are actually good viruses which help us stay healthy

). This means that as soon as your code interacts with GPLv3 code (and this includes linking), your code must be GPLv3 too. So I guess you don't have much of a choice

Posted: **Sun Sep 05, 2021 1:11 pm**

Basslint wrote: ↑Sun Sep 05, 2021 7:07 amGPLv3 is considered a "viral" license (I don't like the term because virus are usually bad things but there are actually good viruses which help us stay healthy ). This means that as soon as your code interacts with GPLv3 code (and this includes linking), your code must be GPLv3 too. So I guess you don't have much of a choice

yeah, i know..

one of the main points for the plugin framework, from the start, has been to keep everything very modularized, and easy to replace or ignore.. kind of like lego.. you put together the pieces you need, and skip the rest.. no external code/libs are being compiled or linked in without you manually #incude'ing it.. and, the framework kan be used for other things than plugins, and for various formats and different underlying backends, all with varying licenses and restrictions, so it easily becomes a mess.. i can't find one license that fits everything, so that's why i started thinking about dual/multi-licensing..

the vst3 part, for example.. i'm not using a single file from the steinberg sdk.. i simplified and stripped it down completely, and built my own kode_vst3.h header to replace it.. but, it's derived from the steinberg sdk, i got all the struct info and constants, etc from there, so it has to be gpl3 (unless it touches some of the same issues as the google vs oracle case - is a pure api copyright-able?).. the vst3 sdk itself is dual-licensed, either gpl3, or proprietary (if you have signed an agreement with steinberg)..

so, maybe, to avoid as much licensing trouble as possible.. i might say that all my code is mit/bsd, and if you use only that, no problem.. do what you want.. but if you drag in anything with a gpl license, or anything derived from gpl, you have to respect that for your own creations too.. xcb is mit, cairo is lgpl/mpl, lv2 is isc.. apart from that, i don't think there's any other external stuff being used..

i've been thinking about wrapping all GPL code in something like

Code: Select all

#ifdef #USE_GPL
  #include "gpl_licensed_code.h"
#else
  #error needs to be GPL
#endif

or something, so that you have to manually add a -DUSE_GPL to compiler without errors..

- tor-helge

licensing issues suck..

Posted: **Mon Sep 06, 2021 7:48 am**

skei wrote: ↑Sun Sep 05, 2021 1:11 pm i can't find one license that fits everything, so that's why i started thinking about dual/multi-licensing..

Well, GPLv3 would certainly fit everything as it's compatible with all major licenses still in use (except [L]GPLv2 without the "any later version clause", ironically!

), and it's used by major frameworks like JUCE and VST3 so I suppose it's not a problem for FLOSS users.

Posted: **Mon Sep 06, 2021 12:14 pm**

Basslint wrote: ↑Mon Sep 06, 2021 7:48 am Well, GPLv3 would certainly fit everything as it's compatible with all major licenses still in use (except [L]GPLv2 without the "any later version clause", ironically! ), and it's used by major frameworks like JUCE and VST3 so I suppose it's not a problem for FLOSS users.

i'm not too happy about that viral/cancerous part of gpl, and would ideally release everything i do as mit or something, but since i have ported some other gpl code/plugins, and have to make the source code available - gpl(3) it is..

juce and vst3 wouldn't "succeed" if they hadn't had a proprietary option..
(but "success" is not really what i'm after)

- tor-helge

Posted: **Tue Sep 07, 2021 3:01 pm**

did some more gui work:

vst3 in ardour, using cairo (on top of xlib/xcb)
so far, i have avoided giving any considerations to the looks or design.. the widget painting, and the events/functionality is separated, so it's very, very easy to make a variant of a widget that just looks a bit different, or have some additional features..

- tor-helge

Posted: **Tue Sep 07, 2021 11:14 pm**

finally got around to record a video, with sound this time..
(but unfortunately a bit low volume)..

i went through the plugins, one by one, and tested them, so that you can get at least an impression of what the plugins do..
and, you can say that this is the current state of the KODE framework repository.. from the gui stuff at the end of the video, you might get some hints of what kind of plugins i hope to do soon..

https://www.youtube.com/watch?v=EYU3HA0HRuc

- tor-helge

Posted: **Sun Sep 12, 2021 8:27 pm**

time to start working on a 'proper' plugin.. a continuation/upgrade of my old fx_cutter plugin.. first version will probably just be the old plugin with some of the missing features: host sync and some crossfading to get rid of some clicks, and then i'll start adding features.. will keep you updated when i have something you can test..

but, what i am really thinking about, is:
it would be very nice to have a working lv2 version too.. at the moment, i have a basic lv2 plugin (i think.. i haven't really tested it much), but i haven't been able to get a gui up and running.. i don't think i really understand the extension stuff.. i will try to dive deeper into it soon, but if anybody could give some hints about it, especially how the gui thing works with lv2, i could make lv2 versions of all other plugins too.. so, what do i have to add to the manifest/ttl? what about that extensions data? when will the host call into the plugin, etc? reading the official specs haven't helped much yet.. :-/

and one another thing, i think i saw something about an "embedded manifest" extensions or something? anybody could give some hints about that? right now, i export a function in the .so, that saves out the .ttl files.. then i have an external tool/script that loads the .so, and calls this function.. but if there were some way to tell the host that it could call this function (or another similar one) directly, it would be nicer, and would fit my plugin framework a lot better....

- tor-helge

Posted: **Thu Sep 23, 2021 6:06 pm**

sa_botage is evolving..
https://www.youtube.com/watch?v=ZDWw2jb3CYc

Posted: **Thu Sep 23, 2021 6:09 pm**

Looks interesting, and sounds great! Eager to try it.

Posted: **Thu Sep 23, 2021 6:21 pm**

LAM wrote: ↑Thu Sep 23, 2021 6:09 pm Looks interesting, and sounds great! Eager to try it.

the source code is already available (link in first post), so, if you're adventurous, you can already try to build it..

but i will work on it for a couple of days now, add some features, fix a few things, and then post a binary..

LinuxMusicians

KODE (plugin development framework)

KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)

Re: KODE (plugin development framework)