distrho/dpf

DISTRHO Plugin Framework

DPF - DISTRHO Plugin Framework

DPF is designed to make development of new plugins an easy and enjoyable task.
It allows developers to create plugins with custom UIs using a simple C++ API.
The framework facilitates exporting various different plugin formats from the same code-base.

DPF can build for LADSPA, DSSI, LV2, VST2, VST3 and CLAP formats.
A JACK/Standalone mode is also available, allowing you to quickly test plugins.

Plugin DSP and UI communication is done via key-value string pairs.
You send messages from the UI to the DSP side, which is automatically saved in the host when required.
(You can also store state internally if needed, but this breaks DSSI compatibility).

Getting time information from the host is possible.
It uses the same format as the JACK Transport API, making porting some code easier.

Provided features and implementation status for specific plugin formats can be seen in FEATURES.md.

Licensing

DPF is released under ISC, which basically means you can do whatever you want as long as you credit the original authors.
Some plugin formats may have additional restrictions, see LICENSING.md for details.

Help and documentation

Bug reports happen on the DPF github project.

Online documentation is available at https://distrho.github.io/DPF/.

Online help and discussion about DPF happens in the kx.studio chat, DPF room.

List of plugins made with DPF:

See this wiki page for a list of plugins made with DPF.

Plugin examples are also available in the example/ folder inside this repo.

dpf's Issues

Latest version of DPF repeatedly resizes on MacOS REAPER.

This bug was reported on my plugin:

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

I tried to reproduce using Distrho Mini-Series 3 Band EQ. I checked out Mini-Series, built it for MacOS, loaded it in REAPER, and did not observe the bug. Then I noticed that Mini-Series is using an older DPF. I updated the dpf submodule to the latest, rebuilt Mini-Series, and then the 3 Band EQ did reproduce the bug; this seems to indicate that the bug has been introduced in a recent version of DPF.

Remove dependence on `SetFile` in OSX VST builds

Idea taken from here:

https://github.com/overdrivenpotato/rust-vst2/blob/master/osx_vst_bundler.sh

👍

Isn't this the only remaining step to cross compile without needing a physical OSX machine?

License & documentation do not draw attention to (L)GPL'd source files

The main LICENSE file contains an ISC style license, giving the impression that the framework is suitable for creating non-copyleft plugins. However, the following files contain a GNU GPL or LGPL notice:

distrho/src/dssi/dssi.h (LGPL v2.1+)
distrho/src/dssi/seq_event-compat.h (LGPL v2.1+)
distrho/src/ladspa/ladspa.h (LGPL v2.1+)
distrho/src/lv2/lv2-midifunctions.h (LGPL v2+)
distrho/src/lv2/lv2-miditype.h (LGPL v2+)
distrho/src/lv2/atom-helpers.h (GPL v2+)
distrho/src/vestige/aeffectx.h (GPL v2+)
distrho/src/DistrhoPluginCarla.cpp (LGPL – version not specified)🟉
distrho/src/DistrhoPluginJack.cpp (LGPL – version not specified)🟉

As the files marked 🟉 are credited to @falkTX I'd be willing to assume that he intends the ISC license of this project to take precedence. However, the others are not. Therefore, the combined work would fall under the GPLv2 (preferably “or later”), unless all the other authors have granted exceptions for this project. If that is the case, it needs to be clearly mentioned in the source to avoid any confusion.

In addition, two files mention including JUCE code. I don't know what license applies to it because it is not stated:

distrho/extra/LeakDetector.hpp
distrho/extra/ScopedPointer.hpp

I should add that the plugin examples include a comment stating “For commercial plugins this should return some short copyright information”, which reinforces the idea that non-free code can use the framework.

I discovered this because I remembered that the VeSTige header is GPL'd. I was prepared to remove it and use the official SDK to build (even though its license sucks) but it occurred to me to grep the source tree, just in case. Not everyone is going to do that, so this situation is inviting a (probably unintended) GPL violation. Indeed, as things stand the framework is already in violation. Even if the intention was for the individual files to be ISC licensed while letting the GPL apply to the whole, and not adding a notice to that effect was an unfortunate oversight, copies of the relevant GPL and LGPL text would need to be included for compliance.

Document state API

Currently there is no documentation about states beyond a incomplete documentation of the calls.

Lots of warnings in NanoVG on G++ 6.1.1

I'm getting this:

g++ src/NanoVG.cpp -Wall -Wextra -pipe -MD -MP -fPIC -DPIC -DNDEBUG -O2 -mtune=generic -msse -msse2 -fdata-sections -ffunction-sections -fvisibility=hidden -std=c++11 -fvisibility-inlines-hidden -I/usr/include/libdrm -I. -Isrc -c -o src/NanoVG.cpp.o
In file included from src/nanovg/nanovg.c:25:0,
from src/NanoVG.cpp:976:
src/nanovg/stb_image.h: In function ‘unsigned char* stbi__convert_format(unsigned char_, int, int, unsigned int, unsigned int)’:
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:877:10: note: in expansion of macro ‘CASE’
CASE(1,2) dest[0]=src[0], dest[1]=255; break;
^~~~
src/nanovg/stb_image.h:877:49: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(1,2) dest[0]=src[0], dest[1]=255; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:878:10: note: in expansion of macro ‘CASE’
CASE(1,3) dest[0]=dest[1]=dest[2]=src[0]; break;
^~~~
src/nanovg/stb_image.h:878:52: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(1,3) dest[0]=dest[1]=dest[2]=src[0]; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:879:10: note: in expansion of macro ‘CASE’
CASE(1,4) dest[0]=dest[1]=dest[2]=src[0], dest[3]=255; break;
^~~~
src/nanovg/stb_image.h:879:65: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(1,4) dest[0]=dest[1]=dest[2]=src[0], dest[3]=255; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:880:10: note: in expansion of macro ‘CASE’
CASE(2,1) dest[0]=src[0]; break;
^~~~
src/nanovg/stb_image.h:880:36: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(2,1) dest[0]=src[0]; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:881:10: note: in expansion of macro ‘CASE’
CASE(2,3) dest[0]=dest[1]=dest[2]=src[0]; break;
^~~~
src/nanovg/stb_image.h:881:52: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(2,3) dest[0]=dest[1]=dest[2]=src[0]; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:882:10: note: in expansion of macro ‘CASE’
CASE(2,4) dest[0]=dest[1]=dest[2]=src[0], dest[3]=src[1]; break;
^~~~
src/nanovg/stb_image.h:882:68: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(2,4) dest[0]=dest[1]=dest[2]=src[0], dest[3]=src[1]; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:883:10: note: in expansion of macro ‘CASE’
CASE(3,4) dest[0]=src[0],dest[1]=src[1],dest[2]=src[2],dest[3]=255; break;
^~~~
src/nanovg/stb_image.h:883:78: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(3,4) dest[0]=src[0],dest[1]=src[1],dest[2]=src[2],dest[3]=255; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:884:10: note: in expansion of macro ‘CASE’
CASE(3,1) dest[0]=stbi__compute_y(src[0],src[1],src[2]); break;
^~~~
src/nanovg/stb_image.h:884:67: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(3,1) dest[0]=stbi__compute_y(src[0],src[1],src[2]); break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:885:10: note: in expansion of macro ‘CASE’
CASE(3,2) dest[0]=stbi__compute_y(src[0],src[1],src[2]), dest[1] = 255; break;
^~~~
src/nanovg/stb_image.h:885:82: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(3,2) dest[0]=stbi__compute_y(src[0],src[1],src[2]), dest[1] = 255; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:886:10: note: in expansion of macro ‘CASE’
CASE(4,1) dest[0]=stbi__compute_y(src[0],src[1],src[2]); break;
^~~~
src/nanovg/stb_image.h:886:67: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(4,1) dest[0]=stbi__compute_y(src[0],src[1],src[2]); break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:887:10: note: in expansion of macro ‘CASE’
CASE(4,2) dest[0]=stbi__compute_y(src[0],src[1],src[2]), dest[1] = src[3]; break;
^~~~
src/nanovg/stb_image.h:887:85: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
SE(4,2) dest[0]=stbi__compute_y(src[0],src[1],src[2]), dest[1] = src[3]; break;
^~~~~
src/nanovg/stb_image.h:873:44: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
#define CASE(a,b) case COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
^
src/nanovg/stb_image.h:888:10: note: in expansion of macro ‘CASE’
CASE(4,3) dest[0]=src[0],dest[1]=src[1],dest[2]=src[2]; break;
^~~~
src/nanovg/stb_image.h:888:66: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(4,3) dest[0]=src[0],dest[1]=src[1],dest[2]=src[2]; break;
^~~~~
src/nanovg/stb_image.h: In function ‘int stbi__extend_receive(stbi__jpeg_, int)’:
src/nanovg/stb_image.h:1156:21: warning: left shift of negative value [-Wshift-negative-value]
return (-1 << n) + k + 1;
^
In file included from src/nanovg/nanovg.c:25:0,
from src/NanoVG.cpp:976:
src/nanovg/stb_image.h: In function ‘int stbi__create_png_image_raw(stbi__png_, stbi_uc_, stbi__uint32, int, stbi__uint32, stbi__uint32)’:
src/nanovg/stb_image.h:2504:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2506:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_none) cur[k] = raw[k]; break;
^~~~
src/nanovg/stb_image.h:2506:57: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(STBI__F_none) cur[k] = raw[k]; break;
^~~~~
src/nanovg/stb_image.h:2504:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2507:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_sub) cur[k] = STBI__BYTECAST(raw[k] + cur[k-img_n]); break;
^~~~
src/nanovg/stb_image.h:2507:88: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
SE(STBI__F_sub) cur[k] = STBI__BYTECAST(raw[k] + cur[k-img_n]); break;
^~~~~
src/nanovg/stb_image.h:2504:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2508:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_up) cur[k] = STBI__BYTECAST(raw[k] + prior[k]); break;
^~~~
src/nanovg/stb_image.h:2508:84: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(STBI__F_up) cur[k] = STBI__BYTECAST(raw[k] + prior[k]); break;
^~~~~
src/nanovg/stb_image.h:2504:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2509:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_avg) cur[k] = STBI__BYTECAST(raw[k] + ((prior[k] + cur[k-img_n])>>1)); break;
^~~~
src/nanovg/stb_image.h:2509:106: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
cur[k] = STBI__BYTECAST(raw[k] + ((prior[k] + cur[k-img_n])>>1)); break;
^~~~~
src/nanovg/stb_image.h:2504:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2510:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_paeth) cur[k] = STBI__BYTECAST(raw[k] + stbi__paeth(cur[k-img_n],prior[k],prior[k-img_n])); break;
^~~~
src/nanovg/stb_image.h:2510:125: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
I__BYTECAST(raw[k] + stbi__paeth(cur[k-img_n],prior[k],prior[k-img_n])); break;
^~~~~
src/nanovg/stb_image.h:2504:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2511:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_avg_first) cur[k] = STBI__BYTECAST(raw[k] + (cur[k-img_n] >> 1)); break;
^~~~
src/nanovg/stb_image.h:2511:95: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
__F_avg_first) cur[k] = STBI__BYTECAST(raw[k] + (cur[k-img_n] >> 1)); break;
^~~~~
src/nanovg/stb_image.h:2504:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2512:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_paeth_first) cur[k] = STBI__BYTECAST(raw[k] + stbi__paeth(cur[k-img_n],0,0)); break;
^~~~
src/nanovg/stb_image.h:2512:105: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
first) cur[k] = STBI__BYTECAST(raw[k] + stbi__paeth(cur[k-img_n],0,0)); break;
^~~~~
src/nanovg/stb_image.h:2520:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2522:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_none) cur[k] = raw[k]; break;
^~~~
src/nanovg/stb_image.h:2522:57: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(STBI__F_none) cur[k] = raw[k]; break;
^~~~~
src/nanovg/stb_image.h:2520:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2523:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_sub) cur[k] = STBI__BYTECAST(raw[k] + cur[k-out_n]); break;
^~~~
src/nanovg/stb_image.h:2523:88: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
SE(STBI__F_sub) cur[k] = STBI__BYTECAST(raw[k] + cur[k-out_n]); break;
^~~~~
src/nanovg/stb_image.h:2520:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2524:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_up) cur[k] = STBI__BYTECAST(raw[k] + prior[k]); break;
^~~~
src/nanovg/stb_image.h:2524:84: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
CASE(STBI__F_up) cur[k] = STBI__BYTECAST(raw[k] + prior[k]); break;
^~~~~
src/nanovg/stb_image.h:2520:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2525:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_avg) cur[k] = STBI__BYTECAST(raw[k] + ((prior[k] + cur[k-out_n])>>1)); break;
^~~~
src/nanovg/stb_image.h:2525:106: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
cur[k] = STBI__BYTECAST(raw[k] + ((prior[k] + cur[k-out_n])>>1)); break;
^~~~~
src/nanovg/stb_image.h:2520:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2526:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_paeth) cur[k] = STBI__BYTECAST(raw[k] + stbi__paeth(cur[k-out_n],prior[k],prior[k-out_n])); break;
^~~~
src/nanovg/stb_image.h:2526:125: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
I__BYTECAST(raw[k] + stbi__paeth(cur[k-out_n],prior[k],prior[k-out_n])); break;
^~~~~
src/nanovg/stb_image.h:2520:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2527:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_avg_first) cur[k] = STBI__BYTECAST(raw[k] + (cur[k-out_n] >> 1)); break;
^~~~
src/nanovg/stb_image.h:2527:95: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
__F_avg_first) cur[k] = STBI__BYTECAST(raw[k] + (cur[k-out_n] >> 1)); break;
^~~~~
src/nanovg/stb_image.h:2520:20: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for (k=0; k < img_n; ++k)
^
src/nanovg/stb_image.h:2528:13: note: in expansion of macro ‘CASE’
CASE(STBI__F_paeth_first) cur[k] = STBI__BYTECAST(raw[k] + stbi__paeth(cur[k-out_n],0,0)); break;
^~~~
src/nanovg/stb_image.h:2528:105: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
first) cur[k] = STBI__BYTECAST(raw[k] + stbi__paeth(cur[k-out_n],0,0)); break;
^~~~~

And it ends with this:

Generate ttl data for './ftz_nes_pulse_dsp.so', basename: 'ftz_nes_pulse_dsp'
/home/fatony/Stuff/C++/fTzNESSynth/dpf/utils/generate-ttl.sh: line 28: 16915 Segmentation fault $GEN ./$FILE
Makefile:24: recipe for target 'gen' failed

Cleanup and rearrange makefiles

Made some improvements in Carla to autodetect compile target and other things.
Time to see how the makefiles can be made simpler.

Will be a pain updating all of them (on the individual plugin projects), so see if something can be done about templating this.

DSSI build said not to have an UI (in Carla and Qtractor)

Carla and Qtractor tell me the DSSI build of d_meters from the plugin-examples doesn't have an UI, but it does have one if I open it in Renoise. Same thing with d_states and Wolf Shaper.

Nekobi, MVerb, and the few zam-plugins that I've tried don't have this issue.

Not sure what's going on here. It seems like only the plugins that use resource files are labeled as having an UI?? Am I missing something obvious? :p

External/embedded UI takes lots of CPU in suil's x11_in_gtk2

If I run Zyn with the NTK UI in jalv.gtk, I get huge CPU usage (htop says 80% for jalv). That's in part due to this function:

https://github.com/drobilla/suil/blob/master/src/x11_in_gtk2.c#L58

My understanding is that DPF external/embedded UIs set the LV2 UI widget ID to 0. So, this condition is always false:

if (children[i] == (Window)socket->instance->ui_widget) {

It causes suil to constantly queue resizes requests:

https://github.com/drobilla/suil/blob/9a93d3c3b9ffe7ff7fe2602d0523d4f80655e8aa/src/x11_in_gtk2.c#L234

If I comment out that g_idle_add call, CPU usage is low.

Anyway, I don't know what I'm supposed to do to fix this, or if this is even a DPF bug at all. Any clues?

(well, I guess avoiding external UI would be the best thing to do 😛)

AU plugin support

Hi, AU plugin support would be great to have someday. I know it's not going to happen in near future, but one can always hope..

System hang when using any DPF-based plugin with Helm synth on Ardour 5

I try to process Helm synth output with ZamTube and 3BandEq on Ardour 5.12. In both cases ROSA Linux R10 hangs. Also I have KDE Plasma 5 specific configuration to keep plugins windows on top.

Allow setting custom widget z-order

Right now, widgets are drawn in the order in which they are created. However, I think it would be useful if we could specify a custom z-order for widgets at runtime.

My approach for this would be to add a setOrder method to the Widget class. Setting the z-order of a widget would cause the parent window to sort the widgets before displaying them.

(I guess the subwidgets vector in WidgetPrivateData should be sorted too, but I have yet to understand why this vector is needed. See my comment in #75)

Should I send a pull request for this, or would you rather not have this feature in DGL?

strncpy warnings with GCC 8

WIth GCC 8 I get the following warning on compilation:

In function 'void DISTRHO::strncpy(char*, const char*, size_t)',
    inlined from 'intptr_t DISTRHO::PluginVst::vst_dispatcher(int32_t, int32_t, intptr_t, void*, float)' at ../../dpf/distrho/src/DistrhoPluginVST.cpp:465:43:
../../dpf/distrho/src/DistrhoPluginVST.cpp:79:17: warning: 'char* strncpy(char*, const char*, size_t)' output may be truncated copying 23 bytes from a string of length 32 [-Wstringop-truncation]
     std::strncpy(dst, src, size-1);
     ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~

Since the custom DISTRHO::strncpy function inserts a null char at size-1 in any case, can't we just use std::memcpy instead of std::strncpy to get rid of the warning?

Set VST parameter hints where useful

Need clarification on NanoWidget constructor with NanoWidget* argument

Namely, that one:

DPF/dgl/src/NanoVG.cpp

Line 945 in 4a4f95f

NanoWidget::NanoWidget(NanoWidget* groupWidget)

It allows reusing an existing NanoVG context, which makes sense to me (I don't see the point in using multiple contexts?)

I've added an example to the gl-examples that shows its behavior: https://github.com/pdesaulniers/gl-examples/blob/master/examples/nanovg3.cpp

In the code, I set the absolute location of three rectangles to (100, 100), (200, 200) and (300, 300).

Right now, all the rectangles are getting drawn in the top left corner of the window. The position of the NanoRectangles is effectively ignored:

However, if I instantiate the rectangles with the NanoWidget(Widget* groupWidget, int flags) constructor instead, they appear at the expected location:

Is this the expected behavior?

Add a utility script for converting fonts to cpp/hpp files

That would be useful :)

ImageSlider should snap to initial value upon shift-click

Implement MIDI output

I plan on making a general-purpose LFO tool someday. I'd need to be able to send MIDI CCs.

licence conflict

Hi falkx,
Licence of DPF/dgl/src/resources/blender_icons.svg (inside the file itself) mention that :"This content is under CC Attribution-NonCommercial ShareAlike licence 3.0 as long as it's used for Blender 3D GUI. Any other uses are not allowed." but the file "LICENSE-blender_icons.svg.txt" says it's GPL2.

Certainly a boring licensing stuff but I thought you might want to know about this.

OSX build of LV2: manifest.ttl has incorrect plugin name

On OSX builds, the manifest.ttl files needed to be updated as they point to the .dylib as ".dylib.dylib" which do not exist.

Export presets for VST

Because VST spec is shitty, we need to save/cache the current state for all presets in memory.
The current behaviour in DPF was just so I could skip having to do this.
Losing presets is a bit painful too, need to see how much work it is to expose them properly.
Or maybe just expose them in a kinda wrong way, the spec is broken and nobody follows it anyway.. hmm

MACOS_OLD build broken due to C++11 ism

Can we add a workaround for this issue please?

i686-apple-darwin10-g++ ZamCompX2Plugin.cpp.o ZamCompX2Artwork.cpp.o ZamCompX2UI.cpp.o ../../dpf/distrho/DistrhoPluginMain.cpp ../../dpf/distrho/DistrhoUIMain.cpp ../../dpf/libdgl.a -Wall -Wextra -pipe -fPIC -DPIC -DNDEBUG -O2 -ffast-math -mtune=generic -msse -msse2 -fdata-sections -ffunction-sections -fvisibility=hidden -DHAVE_DGL -I/opt/local/include -fvisibility-inlines-hidden -fvisibility-inlines-hidden  -I. -I.. -I../../dpf/distrho -I../../dpf/dgl -I/opt/local/include   -fdata-sections -ffunction-sections -Wl,-dead_strip -Wl,-dead_strip_dylibs  /opt/local/lib/libfftw3f.a /opt/local/lib/libsamplerate.a   -lpthread -framework OpenGL -framework Cocoa -dynamiclib -DDISTRHO_PLUGIN_TARGET_VST -o ../../bin/ZamCompX2-vst.dylib
In file included from ../../dpf/distrho/DistrhoPluginMain.cpp:29:
../../dpf/distrho/src/DistrhoPluginVST.cpp:99: error: expected ';' before 'noexcept'
../../dpf/distrho/src/DistrhoPluginVST.cpp:105: error: expected `;' before '~' token
../../dpf/distrho/src/DistrhoPluginVST.cpp:105: error: expected ';' before 'noexcept'
../../dpf/distrho/src/DistrhoPluginVST.cpp:1478: error: expected `;' at end of input
../../dpf/distrho/src/DistrhoPluginVST.cpp:1478: error: expected `}' at end of input
../../dpf/distrho/src/DistrhoPluginVST.cpp:1478: error: expected unqualified-id at end of input
../../dpf/distrho/src/DistrhoPluginVST.cpp:1478: error: expected `}' at end of input

OSX build broken

Can you please rename the nanovg "final" variable because it breaks OSX build.
Thanks,

Keyboard events don't pass through to parent window

Could be pugl? Could be Window.cpp?

Fixing examples

• Still have URI https://github.com/DISTRHO/plugin-examples
• copy&paste errors, like midi through mentioning latency

Add an official project generator script / project skeleton

As we've previously discussed.

DPF plugins use similar project structures and Makefiles, so there should probably be an official way of starting a new DPF project.

For those who already want something like that, this project is pretty neat: https://github.com/SpotlightKid/cookiecutter-dpf-effect

DSSI memory leak

So I've run Rosegarden with my plugins in DSSI format under GDB. When I closed the app I saw this in a terminal:

*** Leaked objects detected: 4 instance(s) of class 'PluginExporter'
*** Leaked objects detected: 4 instance(s) of class 'Plugin'

So I assume the DPF doesn't properly clean after itself.

VST parameters back to default after reloading project when plugin uses states

Here's a way to reproduce the issue:

1. Load the VST version of ZamHeadX2, ZamSynth, ZamVerb or ZaMultiComp in Carla
2. Tweak the plugin's parameters
3. Save the project
4. Load the project

The parameters are now back at their default values.

This also happens in Renoise and Bitwig 1.3.15, but not in Ardour.

If "Use Chunks" is not ticked in the plugin's settings in Carla, the parameters are saved / loaded correctly, but the state is lost.

What's happening? :)

Suggestion: Convenience function to sync audio frames with midi frames

Have a look at this nested for loop. All it does is syncing midi events to the right audio frame.

I suggest a function that returns a zipped list of audio and midi frames/events for the current buffer, already in sync. This would be a convenient way to get sample accurate midi handling.

https://github.com/osamc-lv2-workshop/simplesynth/blob/master/plugins/SimpleSynth/PluginSimpleSynth.cpp#L141

Running lv2-ttl-generator on ZynAddSubFX.so produces random pset:value in prests.ttl

Trying to create reproducible builds in ZynAddSubFX, I've stumbled upon a strange bug. During the build process lv2-ttl-generator is run on each of ZynAddSubFX's plugin's and when run on ZynAddSubFX.so itself the value of "lv2:port [ lv2:symbol "osc_port" ; pset:value 14366.000000 ; ] ." in presets.ttl produces a seemingly random pset:value. Can you point me in the direction of where this value is derived? I suspect that this is most probably a ZynAddSubFX issue but the source forge bug page doesn't seem to have much movement.

OSX build failure

using GCC 4.2 with apple patched toolchain:

../../dpf/distrho/src/DistrhoPluginLV2.cpp: In member function 'void DISTRHO::PluginLv2::lv2_run(uint32_t)':
../../dpf/distrho/src/DistrhoPluginLV2.cpp:381: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
/usr/lib/apple/SDKs/MacOSX10.5.sdk/usr/include/architecture/i386/math.h:405: note: candidate 1: double fmod(double, double)
/usr/lib/apple/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/cmath:255: note: candidate 2: float std::fmod(float, float)
../../dpf/distrho/src/DistrhoPluginLV2.cpp:557: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
/usr/lib/apple/SDKs/MacOSX10.5.sdk/usr/include/architecture/i386/math.h:405: note: candidate 1: double fmod(double, double)
/usr/lib/apple/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/cmath:255: note: candidate 2: float std::fmod(float, float)

Add support for enum parameters

I'm referring to parameters which have a different label for every value.

They seem to be supported by all four plugin formats, except I haven't found an example for DSSI.

Import standalone window fixes from Carla

Regarding window being a dialog.
Should be set in case it has transient.
otherwise just set type as normal.

Implement sendNote on JACK and VST formats

For sending notes to the plugin from the UI.

Relevant method:

DPF/distrho/src/DistrhoUILV2.cpp

Line 259 in 68b3ca4

void sendNote(const uint8_t /*channel*/, const uint8_t /*note*/, const uint8_t /*velocity*/)

DPF/distrho/src/DistrhoUIDSSI.cpp

Line 183 in f8cd00f

void sendNote(const uint8_t channel, const uint8_t note, const uint8_t velocity)

DPF/distrho/src/DistrhoPluginVST.cpp

Line 281 in 70cec6a

void sendNote(const uint8_t channel, const uint8_t note, const uint8_t velocity)

Seems like it's implemented for DSSI already. However, I tried it in Renoise and the plugin wouldn't receive the notes.

Jack format doesn't seem to have this method in place.

It seems like I got it working for VST2. Should I send a pull request? (I think you also mentioned using atoms or something like that...)

External UI stays around when closed from the host side

Issue

• The process that the external UI spawns is never killed if the UI is closed via host

Reproduce

• Open Qtractor
• Add ZynAddSubFx plugin
• toggle Plugin Settings->Edit -> opens 1. external UI
• toggle Plugin Settings->Edit -> nothing (should close 1. external UI)
• toggle Plugin Settings->Edit -> opens 2. external UI
• toggle Plugin Settings->Edit -> nothing (should close 2. external UI)

Result

• 2 external UIs stay around, although both should have been closed

Problem

• ExternalWindows::terminateAndWaitforProcess seems not to be called from lv2ui:hide

UI not rendering (black window) on laptop, works on desktop

I've compiled the plugin-examples and the UI with text labels (Info plugin) doesn't show anything but a black window on my laptop
Kubuntu 17.04 intel onboard gfx card

On the desktop pc (nvidia gfx card) everything works fine.
Mint 18 (== Ubuntu 16.04)

rename vestige header

Prevent issues from over-zealous steinberg killing opensource projects lately.

Add support for trigger parameters

See #28
Need to finish it and make it part of next release

Different plugin are recognised as same by Carla

So I'm using Carla to test LV2 plugins but when I compile more than one in one go, the carla lists 2 plugins but when loaded they have the same name and sound. I think this is the case where DistrhoPluginInfo macros get exported into object files shared by plugins.

(LV2) stateChanged callback not always received when showing UI

...and if it is received, it takes a bit of time, compared to the VST and DSSI builds.

This issue can be seen by running Wolf Shaper or ZamSynth, in Carla or Ardour.

This issue doesn't seem to affect everyone. I assume there is some race condition somewhere.

puglIgnoreKeyRepeat Isn't Configurable

I'm not sure if this functionality needs to be fully configurable or not, but for my own usage it was helpful to ignore repeated keys by inserting this function call near:
https://github.com/DISTRHO/DPF/blob/master/dgl/src/Window.cpp#L199

Simplify Windows build

I was not able to build DPF on Windows due to the fact that there's only makefiles. I had to work around several MinGW issues:

• Making a symbolic link to gcc so that "cc" can be recognized (not sure why this was necessary)
• My MinGW has a glext.h from 2002, which obviously breaks the build since that's way too old
• ...and I didn't really go any further because I don't know how to fix that issue.

Perhaps there should be a Visual Studio project/solution? Or better documentation on how to set up MinGW and build it on Windows?

(I must be doing something wrong setting up and building with MinGW, I hope someone can point me in the right direction.)

release

It would be great to have a release for dpf, so that it can be properly packaged by downstream distributions. This way plugins using it can depend on it dynamicly.

This would allow me to ship zam-plugins for Arch Linux for example.

Building with embedded, external UI seems broken in latest DPF

If I update DPF in zynaddsubfx and try to build it with the NTK UI, I get these errors:

In file included from /tmp/zynaddsubfx/DPF/distrho/DistrhoUIMain.cpp:17:
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoUI.cpp: In member function ‘void DISTRHO::UI::setGeometryConstraints(uint, uint, bool, bool)’:
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoUI.cpp:74:5: error: ‘getParentWindow’ was not declared in this scope
     getParentWindow().setGeometryConstraints(minWidth, minHeight, keepAspectRatio);
     ^~~~~~~~~~~~~~~
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoUI.cpp:74:5: note: suggested alternative: ‘getNextWindowId’
     getParentWindow().setGeometryConstraints(minWidth, minHeight, keepAspectRatio);
     ^~~~~~~~~~~~~~~
     getNextWindowId

Then, in the LV2 build:

In file included from /tmp/zynaddsubfx/DPF/distrho/DistrhoUIMain.cpp:26:
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoUILV2.cpp: In member function ‘void DISTRHO::UiLv2::setSize(uint, uint)’:
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoUILV2.cpp:295:40: error: no matching function for call to ‘DISTRHO::UIExporter::setWindowSize(const uint&, const uint&)’
         fUI.setWindowSize(width, height);
                                        ^
In file included from /tmp/zynaddsubfx/DPF/distrho/src/DistrhoUI.cpp:17,
                 from /tmp/zynaddsubfx/DPF/distrho/DistrhoUIMain.cpp:17:
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoUIInternal.hpp:463:10: note: candidate: ‘void DISTRHO::UIExporter::setWindowSize(uint, uint, bool)’
     void setWindowSize(const uint, const uint, const bool) {}

And in the VST build:

In file included from /tmp/zynaddsubfx/DPF/distrho/DistrhoPluginMain.cpp:29:
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoPluginVST.cpp: In member function ‘void DISTRHO::UIVst::setSize(uint, uint)’:
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoPluginVST.cpp:331:40: error: no matching function for call to ‘DISTRHO::UIExporter::setWindowSize(const uint&, const uint&)’
         fUI.setWindowSize(width, height);
                                        ^
In file included from /tmp/zynaddsubfx/DPF/distrho/src/DistrhoPluginVST.cpp:25,
                 from /tmp/zynaddsubfx/DPF/distrho/DistrhoPluginMain.cpp:29:
/tmp/zynaddsubfx/DPF/distrho/src/DistrhoUIInternal.hpp:463:10: note: candidate: ‘void DISTRHO::UIExporter::setWindowSize(uint, uint, bool)’
     void setWindowSize(const uint, const uint, const bool) {}

onSpecial callback never receives events under x11

X11 backend drops all special events ctrl/shift/etc in dispatchKey

Group widgets seem broken

As we've mentioned the other day.

I'm not sure what's going on here, but it seems like the widgets aren't getting positioned correctly.

EDIT: The demo-subwidgets in the gl-examples just shows a black screen for me.

incorrect null termination

DPF/distrho/src/DistrhoPluginVST.cpp

Line 75 in fe371d4

std::memcpy(dst, src, std::min(std::strlen(src), size-1));

should be std::min (std::strlen(src) + 1, size - 1)

to terminate short strings correctly in case "dest" is not zero-filled.

Add support for effEditKeyDown and effEditKeyUp

Some VST hosts do not reliably relay keyboard events to the plugin, with one notable example being FL Studio. From researching this issue it appears that some (deprecated) VST opcodes are used to send the messages instead. I would ask that effEditKeyDown (59) and effEditKeyUp (60) are added to support keyboard events under these hosts.

Information is scattered around the net about these particular opcodes (one example for reference https://forum.juce.com/t/vst-plugin-still-not-getting-keystrokes/6582/14 ). So, it should be possible to add this without too much of a headache.

Build warnings with G++ 7

In file included from src/pugl/pugl_x11.c:46:0,
                 from src/Window.cpp:36:
src/pugl/../sofd/libsofd.c: In function ‘int x_fib_handle_events(Display*, XEvent*)’:
src/pugl/../sofd/libsofd.c:2126:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
    if (!strcmp (XGetAtomName (dpy, event->xclient.message_type), "WM_PROTOCOLS")) {
    ^~
src/pugl/../sofd/libsofd.c:2129:3: note: here
   case ConfigureNotify:
   ^~~~
src/pugl/../sofd/libsofd.c: In function ‘int x_fib_cfg_buttons(int, int)’:
src/pugl/../sofd/libsofd.c:2315:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
    if (v == 1) {
    ^~
src/pugl/../sofd/libsofd.c:2322:3: note: here
   default:
   ^~~~~~~
In file included from src/Window.cpp:36:0:
src/pugl/pugl_x11.c: In function ‘PuglStatus puglProcessEvents(PuglView*)’:
src/pugl/pugl_x11.c:545:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
    }
    ^
src/pugl/pugl_x11.c:547:3: note: here
   case ButtonRelease:
   ^~~~

Optimize the widget rendering by NanoVG

Hello. As I attempt porting my standalone effect as DPF plugin, I took the route of implementing a standard set of components with custom drawing as NanoVG widgets.

As soon as I add a dynamic component in my UI, my rendering gets a performance hit which makes it quite unsatisfying. I am calling the component's repaint method at 30 fps rate, and get a 25% usage of CPU (a 5-6x CPU usage in comparison with effect processing itself).
As I discover, the CPU usage total comes not so much from the dynamic widget itself but from the sum of all widget drawing, as a repaint of one widget asks to repaint the whole set every time.

As most of UI is static, I've made an attempt at doing rendering caching per-widget, with GL framebuffer objects (also part of nanovg_gl_utils). This feature is openGL 3, and can be available in older openGL as extension.
My branch has so far a non-working attempt with the GLEW library.
(I must admit, I'm not at all competent at openGL usage and would be very grateful for some help on this)

• DPF branch for rendering cache
• Source of project (plugin branch)
• Source of project (fbo branch)

Provide a preprocessor macro for standlone JACK mode

So in plugin mode the host takes care of CCs and program changes but in standalone mode there is no such thing. So having a macro will make it possible to conditionally compile code for manual MIDI data processing.