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".

[RobinSchmidt]

for some reason, the preset loader doesn't respect this [colorscheme] setting. must be a bug - i will look into it...

fixed. also, in ToolChain, you can now interactively edit the colorscheme settings (using the "Setup" button)

[RobinSchmidt]

...i think, tomorrow, i'll attempt the upgrade to juce 5. if that works smoothly, the next step is to get all the preset- and sample-directory stuff for mac right

[elanhickler]

yayyyyyyyyyy!!!!

[elanhickler]

did you upgrade yet? should i pull latest from repository?

[RobinSchmidt]

yes, i updated the juce version on tuesday

[elanhickler]

can't build, some weird errors form juce library. How did you get your project to build?

Severity Code Description Project Line File Suppression State Error C3805 'type': unexpected token, expected either '}' or a ',' (compiling source file ....\JuceLibraryCode\include_se_framework.cpp) Spiral Generator_SharedCode 288 d:_programming\rs-met\libraries\juce\modules\juce_gui_extra\misc\juce_PushNotifications.h

Error C2065 'large': undeclared identifier (compiling source file ....\JuceLibraryCode\include_se_framework.cpp) Spiral Generator_SharedCode 292 d:_programming\rs-met\libraries\juce\modules\juce_gui_extra\misc\juce_PushNotifications.h

Error C2062 type 'char' unexpected (compiling source file ....\JuceLibraryCode\include_se_framework.cpp) Spiral Generator_SharedCode 288 d:_programming\rs-met\libraries\juce\modules\juce_gui_extra\misc\juce_PushNotifications.h

[RobinSchmidt]

i never hit this with ToolChain. no idea why. i have just tried to build SpiralGenerator and hit this error there, too. it seems in juce_PushNotifications.h there's an enum (line 285):

        enum BadgeIconType
        {
            none,
            small,
            large
        };

and there seems to be a macro-definition for small in rpcnr.h (no idea where this file is included or is located or what it is good for). hmmm...

edit: the include file rpcnr.h sits in C:\Program Files (x86)\Windows Kits\8.1\Include\shared

[RobinSchmidt]

so, i guess this macro-definition causes the keyword char to appear in an enum (after the preprocessor stage has passed) and that causes an error. i don't know, why i don't hit this

[elanhickler]

What if it's that I need to create my jucer project from scratch? I would do that, but the problem is that my shared framework stops working, bajillion errors.

[RobinSchmidt]

What if it's that I need to create my jucer project from scratch?

why should you have to do that? i didn't do that either.

[RobinSchmidt]

i see that you are using a couple of juce library modules in SpiralGenerator which i don't use in ToolChain (juce_audio_utils, juce_cryptography, juce_opengl, juce_video). maybe one of these modules includes that weird rpcndr.h file and i don't get any errors because i don't include that?

oh the joys of maintaining and migrating build-systems! you get weird, inscrutable errors and can only shoot in the dark :-(

[RobinSchmidt]

...nope - that's not it. i removed those modules, the error remains. ...but maybe it's a good idea to remove those modules anyway, when they are not needed for that project.

[elanhickler]

indeed 👍

[RobinSchmidt]

oh - i just see juce_audio_utils is actually needed for the standalone build

[RobinSchmidt]

ok, pull an update of my library and try again. i hacked juce (added an #undef small) which seems to fix the weird error. you'll still get some other errors but these are apparently related to some setup-stuff in your jucer file. you can remove the crypto and video modules, too. edit: and i guess opengl as well

[elanhickler]

oooooooooooooook what about prettyscope? opengl. oh you're just saying remove them... not necessarily that they are causing errors.

[RobinSchmidt]

well, there you need opengl, of course!

[elanhickler]

can you also fix this white text on white background, agghhh!!!

[RobinSchmidt]

iiihh! is this new?

[elanhickler]

of course, it's when you started trying dark theme for your plugins

[elanhickler]

Robin, do you have in place modulation repainting methods for modulation indicators that I can override?

[RobinSchmidt]

do you mean the color overlay when a slider has modulation connections? (because that other kind of modulation indication does not exist (yet)). if so, then you can just override ModulatableSlider::paint

[elanhickler]

I mean animated modulation indication, realtime update.

Oh, and modulation range would be nice too (repaint when modulation range updates to show user the min/max of the range)

[elanhickler]

Are you planning on adding modulation callback for animation soon? 😃

[RobinSchmidt]

well, i wanted to look into spline-drawing for scope-oversampling next. what's your priority list?

[elanhickler]

Priority: Whatever is easier/faster. I can do an update to all my oscilloscope music plugins if you add modulation indicator to your default sliders. That will be a huge and appreciated addition. Seriously it would make a night-and-day difference to the user experience.

[RobinSchmidt]

i think, scope interpolation is easier. it's just some straightforward math. ...ok - for a more refined version, maybe also some not-so-straightforward stuff - but a first version may not need that. the modulation animation is a software engineering/design problem and i'm not yet sure, what's the best way to approach it (but i have an idea)...but it could be fiddly

[elanhickler]

What are the main design problems? CPU usage? Class relationships?

[RobinSchmidt]

yes. both. probably also multithreading. i guess i'll introduce some sort of RepaintManager class that regularly calls the repaint callback on some number of registered repaintees (the widgets)....but better call the repaint callbacks only when actually necessary (the (modulated) value actually changed)...so maybe i need a subclass ModulationRepaintManager that somehow also keeps track of what modulation is going on...just some first ideas...

[elanhickler]

Ok, work on what you are most inspired to work on. Work on Liberty if you want to create a powerful prototyping environment. Work on the oscilloscope if you want a better visual. Work on modulation animation if you want to bring your framework to the next level.

Edit: Also, I'm thinking of open-sourcing PrettyScope. I can't do much with it, don't know how to work with the code. If you want, you could try to get PrettyScope to be easy to add to any project. I couldn't figure it out, some stupid include/undefined/redefined errors.

[elanhickler]

I actually do really need modulation indication by November 1st. That gives you 7 weeks and 2 days!

[RobinSchmidt]

ok, let me finish the spline drawing for the scopes and then i'll look into this

[elanhickler]

question: can you make phase scope drawing a separate process as you look into modulation indication? It's kinda a similar thing, right? Having multiple phase scopes displaying in a project can start to stop the DAW UI from updating. I dunno if this is related actually

[RobinSchmidt]

i guess, you mean a separate thread, not process, right? because i think it would be weird for an audio plugin to spawn processes. i just checked the threading model of my scope. all the real drawing work is actually done in the audio thread. in the gui-thread, i just draw the ready-made juce::Image (which was prepared in the audio thread) to the screen which shouldn't be that expensive. ...unless the resampling is expensive (but that should apply only, when the "Scale" parameter is something other than 1 (in this case, i draw onto a lower-resolution image internally (making my drawing code less expensive) and let juce upsample it)

the modulation indication, as i currently have laid it out in my mind, would also draw in the gui thread. in my mixsonic mini-daw, i actually did something like that - i delegated the drawing to its own thread because indeed the gui became unresponsive when moving around the clips (each of which has to draw a waveform display). i guess i could dig out that code. ...i was a bit messy but sorta worked. i actually want to integrate that code into my codebase anyway

[elanhickler]

So how is your idea different that just... say... every 1/30 of a second, get all modulated parameter settings, call repaint? I could probably figure out how to implement that myself right now.

[RobinSchmidt]

well....yeah...you can inherit your widget from juce::Timer and repaint every 1/30 seconds.....but i think that would be wasteful if there's nothing to actually redraw. i think the system should figure out, if redrawing is needed and redraw only then

[RobinSchmidt]

i think, that would be a very dirty solution. it may work, though

[elanhickler]

So then a simple if statement to start timer if connections exist, stop timer if no connections exist.

[RobinSchmidt]

i'm currently setting up a RepaintManager class. i think, it is better to have one central object that derives from Timer and that calls repaint on a number of registered "repaintee" objects - so we don't need to bloat each and every of our widget classes by adding yet another baseclass. probably much leaner design, memory footprint wise and also probably less code to write

[RobinSchmidt]

...although...looking at the Timer class - it actually looks quite lean....maybe my design idea is needlessly complicated...hmmm

[RobinSchmidt]

do you intend to let the update rate be changed by the user at runtime? ....bcs i think, that would be enough justification for my design (we would have a central place to set the update rate). if that is not necessarry (i.e. the update rate can be hardcoded at compile time), i could probably indeed just add juce::Timer as baseclass to ModulatableSlider and do it like you suggested

[elanhickler]

hmmmmm.... I'm thinking either 30fps or 60fps or sync timer to monitor refresh rate (using that global switch in juce) Edit: So yes, decide at compile time.

[elanhickler]

I see you added a modulatable slider animated class, which inherits timer. Why? Don't we want a global timer that starts if modulation connections > 0 and stops if not? Then upon timer trigger, repaint.

[RobinSchmidt]

i don't know...i was starting to implement your design idea....do you think, i should instead follow my (more complicated) idea instead?

[RobinSchmidt]

do you think, i should follow the ideas, i outlined with the RepaintManager? (i actually already created a stub for such a class)....yeahhh....maybe that's a better idea. maybe some other client code already wants to use the Timer baseclass for something else and it just seems to be an overall cleaner design

[elanhickler]

Yes. I need to repaint constantly more than just modulatable sliders, repaint manager could work.

[RobinSchmidt]

yes - i'll go that route with the repaint manager. has also the advantage that we can just de/register at the manager whenever the mod-connection status changes. the widget itself doesn't need to keep track of that and the manager will iterate only through those widgets for repainting that actually need repaint (similar to the smoothing manager)