RobinSchmidt
Soundemote TODO List 2017-12-28
in order of priority
Bugs
- [x] PRIORITY: Breakpoint modulator level/time/shape sliders are broken #150
- [x] Standalone PrettyScope runs into crashes / nullptr, this is only happening in JUCE 5.
- [x] GUI needs update on preset change: #113
- [ ] AsyncCallInvoker memory leak #158
- [x] Removing modulation connection causes crash #157
- [x] Closing plugin causes crash #156
Features
- [ ] upsampling filter for prettyscope
- [ ] Greg from OrangeTreeSamples needs that frequency locking tuner phase drift problem fixed
- [ ] modulation repainting / notification system
- [x] macro parameters
- [ ] get constrainer to work for FMD (due January 25) #154
OMG! this is ancient code that i never wanted to show anyone ...well, not yet at least. it's in class ModulatorCurveEditor
oh my god - that code needs clean up!
ok, nice. i'll do a meta (or macro or whatever) mapper soon anyway (1-2 weeks). but if you have time pressure to have that feature immediately and jim is much faster, i'll have to back off a little. i'm looking forward to your release of torus generator, by the way.
....do videos! that's what gets people interested. soundcloud doesn't really cut (imho), ...well at least, i like watching your youtube-videos, but the soundcloud demos give me nothing
well - yes, i've seen these 4-hour preset design and programming videos and watched half an hour of it. but they are really boring. you need videos that present the best patches - with prettyscope visualizations. these are goooood and interesting :-)
but yes - this is good: https://www.youtube.com/watch?v=igU0vjzBdbI i did not see this yet. .. yes - i think, prettyscope videos with factory presets are very good promotion
those long videos are done live! I do live videos, live stuff will attract subscribers. My live videos will get better too.
Jim is having trouble getting the modulation curve editor to repaint based on a parameter changing. How do you make it repaint based on a parameter to change? We need to update the cursor position.
you can register at any parameter as ParameterObserver. you need to inherit from ParameterObserver, call registerParameterObserver(this) on the parameter(s) that you want to observe (somewhere in the constructor perhaps) and then override parameterChanged. and de-register in the destructor to avoid dangling pointers
Jim is having trouble getting the modulation curve editor to repaint based on a parameter changing
note that calling repaint from a parameter change callback may be dangerous. better to call repaintOnMessageThread(). it's a rather new function of DescribedComponent which is a baseclass of pretty much any gui object. the thing is that parameters may change from the audio-thread in case of automation and it is not allowed in juce to call repaint on any other thread than the message thread. i was hitting jassert when trying to do so
but you're having to update the GUI when something changes like level/shape/time, so... I was going to look at how you did that.
Standalone PrettyScope runs into crashes / nullptr, this is only happening in JUCE 5.
well you are calling the constructor of OpenGLCanvas withh 3 nullptrs in OpenGLOscilloscope.cpp, line 17:
Component * createMainContentComponent() { return new OpenGLCanvas(nullptr, nullptr, nullptr); }
i added few checks agains nullptr (in 3 places) which fixes the crash - but apparently, with a nullptr, it won't work. you may want to look into why you pass a nullptr in the first place and change that
but you're having to update the GUI when something changes like level/shape/time, so... I was going to look at how you did that.
yes - that's precisely the main purpose of the repaintOnMessageThread function. before discovering how to do that, i had some convoluted mechanism based on subclassing RWidget from juce::AsyncUpdater (and triggering an async update on parameter callbacks and repainting on receiving the handleAsyncUpdate callback). that sucked. much better now, i think.
GUI needs update on preset change
i'm getting lots of compiler errors when trying to build MushroomGenerator of the type:
error C2065: 'midiFrequencyMasterPtr': undeclared identifier (compiling source file ......\Source\JerobeamMushroomPlugin
PrettyScopeEditor.cpp line 373 is where the 3 nullptrs get filled out.
Main.cpp like 69 creates a component with createMainContentComponent()
line 17 OpenGLOscillscope.cpp:
no idea how to solve this, don't know how it all works...
maybe in MainWindow class / constructor I need to create some instances of PrettyScopeEditor/Module/AudioBuffer ? do I need to somehow copy PrettyScopeEditor for MainWindow?
line 15 of PrettyScopeEditor.cpp is where prettyScopeModule ptr is assigned an object
no idea how to solve this, don't know how it all works
i didn't write this code - i guess, jim did it then? or lorcan? my first shot at it would be to have a PrettyScope object (or pointer to it) as member of this "MainWindow" class, initialize it before calling createMainContentCoponent and pass a pointer to that object to createMainContentCoponent - instead of passing a nullptr.
but wait - why actually isn't there a "createPluginFilter" function being called at startup - as is the case with other plugins?
hmmmmmm wait, you know i had to define JUCE_USE_CUSTOM_PLUGIN_STANDALONE_APP=1
but I didn't have to define that for my other plugins, maybe that's the issue... I shouldn't have to define that
shouln't it be initialized as a "StandalonePlugin" (i love that term, btw.) like all other juce standalone "plugins"
i had to define JUCE_USE_CUSTOM_PLUGIN_STANDALONE_APP=1
ah - ok - yes, maybe look into that then
btw, check out my first FMD test: https://hearthis.at/soundemote/fmdtest1/
not using the macro controller yet, this is just from my experimentation.
seriously, have you ever heard a digital filter sound like that? this is just the tip of the iceberg.
btw, check out my first FMD test: https://hearthis.at/soundemote/fmdtest1/ not using the macro controller yet, this is just from my experimentation.
very cool! ...working on the node-editor now (which will be used for the meta/macro/whatever mapper)
seriously, have you ever heard a digital filter sound like that? this is just the tip of the iceberg.
no - but i did not really look very much into that either and i'm also not very familiar with analog filters. however - sounds good indeed.
The principle of how FMD works is so simple. What happens when you modulate the PHASE of a sinewave of 0 hz with a sawtooth? What do you get out? A sawtooth! Because obviously you're just modulating a DC signal... actually that's as far as I understand. Then you need FM, filtering, multiple oscillators, yeah I don't get it haha. Edit: Eventually I might understand it.
basically the point is to send signal "through" oscillators, the oscillators can recreate the original signal but distorted in various ways or lock on to features (fundamentals / beats) of the input signal. You can get stuff that really sounds like distortion without clippers, but definitely a unique sound compared to clipping.
like this: https://hearthis.at/soundemote/jerobeammushroom-analog-style-filtering/
send signal "through" oscillators
like using the input signal as phase ...or phase-offset?
use input signal as phase and frequency modulator, and if you have more components in the signal chain you could try sending some input signal or oscillator signal to modulate those. It's just a big fun frankenstein of modulation that creates endless variation.
crash :(
no idea why or how, will have to wait until it happens a bunch of times
:-O i have never encountered this. 0xFFFFFFFFFF....? the only pointer that gets derefenced there is the this-pointer. how can a this-pointer possibly be uninitialized? very weird indeed.
damn! 3 new bugs? looks like a longer debugging session is due again. as for making the constrainer work: as said, i'm out of ideas with that and think we need to turn to the juce forum. should i do this for you or do you want to do that yourself?
yeah, i can't continue with all these bugs, because now I don't know if I'm doing something wrong. working on trying to find the commit that causes the close crash
if all these problems are new since i introduced the meta-mapping system, look at sliders calling Parameter::setValue. this is illegal now for meta-controlled parameters (see other thread - at least when they actually have a custom mapping - i'm not yet sure how to handle menus and buttons. i guess, a mapping function makes no sense there - yet they also work with meta-controlled parameters)
phew! at least not all my bad! ;-) ...or well, we'll see. but watch out for this setValue/setNormalizedValue problem anyway. it's a change that i had to make that may break client code that calls Parameter::setValue
maybe i should start to somehow document client-code-breaking changes....but actually the framework was meant for personal use ...hmmmm
no don't worry about that. I'm trying to let your framework be for personal use, I'm trying to move away from depending on your framework. With FMD I'm actually overriding all your paint methods. I will only be using your modulation system with FMD.
.....well, I need to not be overriding your stuff and I need to create my own classes from scratch, but I need your mod system and macro system for now.
im using your child module system... i can replace that by just instantiating parameters with myparams eventually.
I isolated the crash completely!... well... this:
BasicOscillatorEditor.cpp
uhh nevermind, you should start documenting your changes that would break my code.
If I override certain functions, recreate those functions with your code with a copy and paste, and you change said code, my code no longer works, your code remains working, and I waste hours of time dealing with it.
We need a solution.
I think you should help me somehow transition from using your framework.
No idea how, because I don't know how to create my own slider, my own set/get functions and still use your smoothing system or modulation system. Seems like that's not even possible.
Maybe it's better if you just accept that your frame is no longer just for personal use and do what you were going to do: provide paint methods for your sliders, for starters.
I don't know what to do.
When I try to move away from your framework you do something that breaks my code
When I try to stick with your framework you don't have obvious features I need to make a decent gui...
it seems you didn't fix the slider display name issue. I need to be able to set if the plugin is bipolar or not, but you have it hardcoded to "LINEAR_BIPOLAR", if the slider is using linear_bipolar, then it's bipolar. But we have several other bipolar scalings. It should not be based on bipolar.
Ok.
I need to edit your code and do pull requests. It's the only solution here. Then you need to make sure you do those pull requests as soon as possible.
provide paint methods for your sliders, for starters.
i have added a setPainter method to RSlider. you are supposed to pass a pointer to an object of a subclass of RSliderPainter. in your subclass, you will have to implement the paint function. in RSlider's paint, i check the pointer against nullptr, and if it's not a nullptr, i delegate the painting to the object - otherwise i paint directly. pretty simple infrastructure, but should be very flexible. you can do as many subclasses of RSliderPainter as you want and do whatever you want there - use bitmap-strips, svg vector-graphics, custom algorithms, etc. if it works, we can do the same for buttons and menus and also whole editors (if you need custom backgrounds, for example) and implement functions for the editors to set the painters for all embedded widgets
it seems you didn't fix the slider display name issue
what issue was that? there actually is no separate "display name". the slider's name is what is displayed. the underlying parameter, however, may (or may not) have a different name (and it's the parameter's name, which is used in the state-xml)
ok, you also need to have a setting of whether the slider should be vertical or horizontal... and type of drag scaling. Knobs need a totally different drag scaling, knobs drag scaling should not be based on size like sliders, and it needs to be vertical instead of horizontal.
hmm...yes....i see. i wonder what's the best way to handle this. maybe a "type" member that can have values for horizontal, vertical and knob