Dragonfly Hall Reverb

[rghvdberg]

...
re-spaced boxes and stuff
reworked knobs
re-order tabs

to me it looks very easy on the eyes

Outstanding work. I enjoy the coolness of the skeuomorphic GUI but I must admit that the flat design is fine and practical.

Btw, should I now build from your repo or Michael's ?

Best,

dp

Michael's !

Yeah I'm a sucker for skeuomorphic design.
But I found out you challenge / limit yourself a lot.

I'm 99 percent finished now.
But I made an error in judgement. I implemented the tabs as buttons. This turned out to be a PITA because buttons in DPF are supposed to have parameters and they are supposed to be represented on the dsp side too.
Also , I'm drawing all labels with NanoVG, but out of the box you can't draw on top of buttons. I knew that, but forgot. : facepalm:
I'm gonna rip that out and write a little code to make the tabs clickable.

Things learned so far:
Draw text in DPF using NanoVG (from MVerb)
Import a font (from dpf example Info plugin)
Catch mouse events ( from zam-plugins ZamSynth)
Using swatches for colours in Inkscape
Using grid in Inkscape; strangely enough Inkscape defaults to an empty grid. You'll have to configure one for each drawing.

Cheers, Rob

[Michael Willis]

I'm 99 percent finished now.

Are we going to support both interfaces from the same build, or manage them as separate branches, or something else I haven't thought of yet?

[rghvdberg]

I'd vote for just the flat UI.
Easier to maintain. And let's be honest, easier to use.

I think it's possible to have both interfaces and load them dynamically. Would require substantial rewrite of UI code.

[Michael Willis]

I'd vote for just the flat UI.
Easier to maintain. And let's be honest, easier to use.

Ok, fair enough, although I liked the look of the metalic one slightly more, and you might have been on to something with that Rainbow Dash one...

But yeah, I like seeing the numeric parameters directly below the corresponding dials, and I might be able to eventually hack some magic to allow keying in the numbers.

[rghvdberg]

The underlying code for mouse and such is pugl.
So maybe we can look in there for keyboard events.
Maybe it's in DPF already, dunno.

I was given a cool feature request.
Lock parameters : if you load a new preset, the locked parameters don't change.
I think that's very useful and should be implemented.
( think reverb bus, where you want to set the dry signal to 0 %)

I was thinking of making the labels clickable. When clicked, change colour / set font to bold, to indicate it's locked.
Or maybe draw a box around the controls.
We'll have to rewrite the loadprogram function of course.
And give each parameter a 'locked' property.

[davephillips]

...should I now build from your repo or Michael's ?

Michael's !

Thanks, Rob. I did a fresh pull and build today from Michael's repo. I've only run the stanbdalone so far, but it seems flakier than before. I got a little more information from the crash this time:

Code: Select all

assertion failure: "font >= 0" in file src/NanoVG.cpp, line 829
*** Error in `./DragonflyReverb': corrupted double-linked list: 0x0000000000d4dd70 ***

Btw, I ran the Makefile "as is", it built the fancier UI. How can I get it to build the flat graphics instead of the skeuomorphic ? (I agree that the flat design should be the default).

Best,

dp

[rghvdberg]

just did a push to my gitfork and did a pr
but there seem to be some problems

https://github.com/michaelwillis/dragon ... erb/pull/4

[rghvdberg]

for useful crash reports
from the base directory :

Code: Select all

make clean
make DEBUG=true
gdb bin/Dragonfly

press [R] to run the plugin
make it crash !
type

Code: Select all

thread apply all bt

paste output to pastebin.com or the like
open issue on github with link the pasted output

[rghvdberg]

one small thing, before any small mistake is done.
the "lock" of parameters should be done only on the UI side.
handling such state on the DSP and UI side would be prone to race conditions.

I don't fully understand but we'll cross that bridge when we have to
first we need to fix that nasty crash
and get the graph in

[davephillips]

for useful crash reports...

All done. Issue opened in MW's github repo.

Best,

dp

[Michael Willis]

Sorry I haven't been responsive for a few days. Hopefully some time this week I'll make some time to merge in Rob's latest GUI changes and then look at the crash; I'm still fairly convinced that it is a thread concurrency problem.

[rghvdberg]

Take your time, no worries.

[Michael Willis]

Ok, I merged from https://github.com/rghvdberg/dragonfly-reverb back into my repo, fixed the merge conflict, made some minor changes to get it to build on MacOS, and made an attempt at fixing the bug that would crash the VST version.

I think the crash happened when the GUI thread would set parameters at the same time that the DSP code was working on processing audio samples. I haven't really dug into the internals of freeverb3, but if setting parameters ever does something like changing a buffer size or otherwise manipulating pointers, it could certainly crash the plugin if it did so while the DSP thread was active.

My change alters the setParameterValue method such that it stores the new parameter value in an array called newParams. Every time the DSP code gets invoked, it checks to see if any parameters changed. If so it calls the corresponding methods in the freeverb3 objects to update them, and then processes the audio. That way only a single thread ever manipulates the freeverb3 objects.

I submitted a pull request back to rghvdberg so that he can update his repo with my changes. Anybody else is welcome to look at it here:
https://github.com/rghvdberg/dragonfly- ... ll/2/files

[GMaq]

Hi,

Great project and fascinating to see the collaboration evolve..

2 questions:

(1) Would it be OK to include it in the next AV Linux 2018 release (and Ninjas too if @rghvdberg is reading)

(2) I can't build the latest merge... when I git clone there are no subfolders inside the dpf folder so compilation fails. Is this my bad or something missing in the latest merge?

*EDIT
Never mind... 'git submodule init' then 'git submodule update' did the trick, might want to put that in the README's

[rghvdberg]

I'd be honoured

Still some bits and bobs to add on this reverb.
If my latest pr is merged I'll need some testers to confirm the font issues are fixed.
Then it's time to finally put in the response graphics , I think.

Ninjas needs testers too, some audio files crash the plugin but I've been unable to reproduce on other systems.