Would like to experiment with modulation indication / animation

[elanhickler]

Is there a notification for modulation update that the graphics can use so that repaint can be called for given widget? Or maybe repaint is not called per-widget...

ok you have this:

but that's only for modulation assignment, not modulation value. You should probably rename that function to "ModulationAssignmentChange" or "ConnecitonChange".

I am working on a knob widget and in its paint function I have this:

so all I need to do is fill out that modulatedValue somehow, and the repaint needs to be called when modulation value updates. Then I can draw a second line indicator for "actual value".

[elanhickler]

heehee it's working!!!!!!!!... well, only when I move the knob, repaint is called.

omgaaad!! all I need is that repaint notification for modulation value updates!

[RobinSchmidt]

the "modulatedValue" is actually updated per-sample - you certainly don't want to get per sample-notifications and call repaint per sample. do you want an animated gui that always shows the modulated value along with the slider center value?

i think, for the mod-system, it could make sense to send out notifications, when the mod-depth changes such that a slider can somehow indicate that depth (as mod-range), but an animation for the current modulated value is a different story. i'd probably try something based on juce::Timer to regularly poll the current value and repaint ...i'd probably make a class RepaintManager or something that can set a repaint interval (maybe as frame-rate) and where sliders (or, more generally, juce::Components) can register themselves to get called at regular intervals (and then register when there are connections and deregister when there are none). the RepaintManager would call repaint regularly on all its repaintees (of class juce::Component)...as a first idea

btw. - you did not say anything to my last question here: https://github.com/RobinSchmidt/RS-MET/issues/135#issuecomment-350587473

[elanhickler]

Yeah, maybe I should stick to mod depth change painting, because animation is going to be expensive.

You're talking about the invoice? Yes, send the invoice.

[elanhickler]

Actually I really like the idea of animation, it is just more informative and easier to grasp.

[RobinSchmidt]

yes, it's certainly a nice to have. actually, it would be best to have both

[RobinSchmidt]

looking at the inheritance diagram of this: https://juce.com/doc/classAnimatedAppComponent it seems i'm on the right track with juce::Timer. but it's probably wasteful to let each widget be its own timer, so registering at a global Timer-derived RepaintManager is probably better

[RobinSchmidt]

btw - i also used juce::Timer for triggering the repaint in my PhaseScopeDisplay

[RobinSchmidt]

btw. - i'm currently adapting echolab for chainer and experimenting with other gui-colors (black/dark plots and widgets). black plots look much better, i think:

[elanhickler]

Yeah looks good. Are you using standalone app? Do you know how to make it use windows default?

[RobinSchmidt]

no, its the plugin (and i don't have a standalone version ...might actually be cool to have for easy testing without an additional host...hmm...). but i think, for standalone-apps to have native look-and-feel, you should have a look at: https://juce.com/doc/classTopLevelWindow#a749fbd5e688ed8c9af3d0d99b21e18c8

[elanhickler]

I know, I already did that. Didn't work, that's the issue.

Just add standalone to your build process in your jucer, just a matter of clicking a check box. And let me know if you figure out how to make it use windows default.

Edit: Also, upgrade your jucer to latest projucer before you do that. It's a lot easier to deal with a VS project with multiple build types (standalone / vst / etc.).

[RobinSchmidt]

where is it? i can't find it in the projucer. only the various plugin formats: ...or do i have to change the project type?

[elanhickler]

I guess you have to upgrade your jucer.

[elanhickler]

The only issue I had with upgaded jucer VS projects is it complaining that ProjectInfo is redefined, no idea how it manages to get redfined.... so I just rename to ProjectInfo2, nothing is affected by this rename....why.................

[RobinSchmidt]

wouldn't i have to upgrade my juce-version then, too?

[elanhickler]

NOPE

[elanhickler]

I mean, upgrade your projucer, but leave your juce library code as is.

[elanhickler]

I think I can just send you the Projucer.exe so you don't have to create a juce repository and go througha ll those steps: http://www.elanhickler.com/transfer/Soundemote/Projucer.exe

[RobinSchmidt]

uuuhh...yes - the new version requires a login everytime you start it. annoying. do you use the self-compiled version with this gpl-flag? ...or what kind of licensing option do you use for juce?

edit: your exe seems to be identical to the original in the juce download package

[elanhickler]

i pay for a license... it is weird that it asks for login every time, it should save your info. I guess it doesn't?

edit: wait, it didn't ask me for login last time I opened it.

Edit: Anyway, you need to upgrade at some point. Still have that retina issue on PrettyScope.

[RobinSchmidt]

no - it doesn't save the login info here. i guess, if i start using it on a regular basis, i'll compile it for myself

[elanhickler]

o my god.

animated modulation indication is AWESOME!!!!!!!

It shows you exactly what's going on in the case of chaotic feedback routing especially, this is going to be so informative. I had no idea what kind of modulation curves were happening. Audio-rate feedback/chaotic modulation can result in perceptually slow value changes!! This is eye opening!

[RobinSchmidt]

are you already doing it using my idea with the RepaintManager?

[elanhickler]

noooooooo, i;m just observing modulation by frantically moving the knob so it updates continuously. I think I'll have to wait for you to implement your idea, I don't know how to do it myself.

[RobinSchmidt]

i guess, making a standalone "plugin" have a native look requires to edit the juce library classes. i guess here:

class StandaloneFilterApp  : public JUCEApplication
{
public:
    void initialise (const String&) override
    {
        mainWindow->setUsingNativeTitleBar (true);  
    }

...ohh...yes - it works

[RobinSchmidt]

however - i have no idea, how to do it without editing juce classes. maybe we can from the editor component somehow get a pointer to the top-level window and call setUsingNativeTitleBar on the returned pointer (might require a dynamic_cast to TopLevelWindow...)

[RobinSchmidt]

...ohhh - and the "Options" button is lost. not good. it's needed

[elanhickler]

wtf.......... ugh.

we should try this again once we upgrade juce library.

[RobinSchmidt]

here: https://juce.com/doc/classComponent#a64415a8c5911f94475b5c624598adfa8 then cast that pointer to TopLevelWindow and if the dynamic_cast returns a non-nullptr, call setUsingNativeTitleBar ...probably

[RobinSchmidt]

...but as said - without the options button, it's probably not a good idea to use the native window

[RobinSchmidt]

we should try this again once we upgrade juce library.

indeed. it seems to make more sense to me to use the same version of jucer as the library. when i want to keep up with my plan to release chainer on christmas, i'll probably have to upgrade before and then use the "with-splashscreen" licensing option (my old commercial juce license only applies to juce pre 3.0)...or otherwise license my library under gpl or something (i actually want to use a more liberal, non-viral open-source license along with commercial licensing - we'll see).

[RobinSchmidt]

i actually want to use a more liberal, non-viral open-source license along with commercial licensing

what i want, if someone uses my library for free in an open-source product, is that all the other code is also open-source (well, obviously, otherwise it wouldn't qualify as an open source product), but not necessarily all gpl (can be mit, bsd, custom, public domain, whatever)

[elanhickler]

Are you planning on having draggable components so we can reorder effects?

also... not good:

I would change the paint methods or color scheme myself, but breakpoint modulator is not my code so it would be difficult.

[RobinSchmidt]

you mean, like in chainer, you could grab a slot and drag it to another slot to change slot-order? yeaahhh...that would be really nice to have. not trivial to implement, though - but eventually i really want that feature

[RobinSchmidt]

what do you mean by "not good"?

[elanhickler]

I need the previous color scheme on my plugins

[elanhickler]

I'm going to start replacing all your paint methods soon, so you won't have to worry about this in the future.

[RobinSchmidt]

really? you like the white plot-backgrounds more? there is some function to change the color-scheme, i'll have to dig it out..

btw - i wonder, if i should change my module-headline font, too. the big version of my pixel-font looks rather ugly (the small versions for the widgets and axis annotations are actually ok, imho)

[elanhickler]

The breakpoint window can be black, sure, but not all the sliders and buttons

[RobinSchmidt]

I'm going to start replacing all your paint methods soon, so you won't have to worry about this in the future.

for this to work with library-provided sub-editors (such as my breakpoint editor), i really need to delegate the painting to a "strategy" object (like we did with the parameter mapper) because you can't change the slider-class that is used in my breakpoint-editor

https://sourcemaking.com/design_patterns/strategy

[RobinSchmidt]

because - you can, of course, override "paint" in a subclass derived from my slider class, say, and use your slider subclass in your editors. but you can't tell my breakpoint editor to use your subclass for its sliders. that's why we need the strategy pattern for gui customization

[RobinSchmidt]

or i could templatize my editors on the widget classes to use. haha! nope! that's a fucking bad idea!

[elanhickler]

I don't need to tell breakpoint editor to use my subclass for its sliders. I would redesign the breakpoint editor from scratch.

[RobinSchmidt]

oh - ok - but that's a rather big task. i actually want to refactor all my plot-node-dragging editors at some point...factor out some common NodeEditor class to capture and re-use what they have in common. maybe with callbacks like "nodeDraggedTo(int index, int newX, int newY)". breakpoint-editor, equalizer-editor, etc could then be subclasses of that and just override these nodeDragged callbacks. all the mouse-event handling would be factored out, avoiding a lot of code-duplication

[elanhickler]

why would that be a big task? I don;t know when I'd tackle the task of creating my own breakpoint widget, but I can certainly create a new editor, put the breakpoint widget, and then put in whatever sliders I want around the breakpoint widget. Easy. (not something I can do right now)

[RobinSchmidt]

well, i mean the breakpoint-widget itself is a quite big and complicated class - not putting some sliders around it

[elanhickler]

i never said I wanted to re-design the actual breakpoint widget, just the breakpoint module editor in the near future.

[RobinSchmidt]

ah - ok - misunderstanding

[RobinSchmidt]

call setWidgetAppearance(ColourScheme::DARK_ON_BRIGHT); somewhere in the constructor of your editor. ... but for some reason, the preset loader doesn't respect this setting. must be a bug - i will look into it...

[RobinSchmidt]

i'm not yet sure, if i'll keep using black widgets by default, though