that’s true, but if you have manually added some modules from a plugin in the library (by clicking “add”, not “subscribe”) and you then drop a development version of that plugin into your plugin folder, any new modules in the dev version won’t show up automatically until you click “subscribe” on the entire plugin.
at least, that is the situation i have found myself in multiple times recently.
This may deserve its own topic rather than hijacking this topic, but do not all plugins and modules set such a flag and check it in process()? Meander does, but it looks like I only added that when I implemented multi-instanced Meander a couple of months ago. I can’t remember how I decided to do this, but I may have seen others doing it.
I ask, because this issue sure seems similar to the issue I have been chasing for a month or so where my patches would crash but no plugin implicated. I have not had such a crash since I eliminated the delayed startup master reset module logic.
Edit: I should say that I effectively add such a flag and check, but it it not set in init() but rather in the module constructor.
I’ll try it out for sure. What are some things I can do to get more debug info, since -d isn’t helping much?
Super useful, thanks! While it is technically possible to call a method before the constructor finishes, surely am I right in thinking that in Rack it’s safe to assume process() isn’t called until after the constructor finishes (otherwise Params wouldn’t exist/be configured yet etc)?!
If so, adding init() to the Peaks constructor seems like an elegant solution? I’ve made that change, pushed it (latest build should also have the change for those wanting to test). It works for me (but then I can’t reproduce the crash anyway). I’ll create a linux VM too just in case that helps.
As far as I know, process() doesn’t start getting called by the engine until all Modules in the patch have been constructed and the modules fromJson() has been called to retrieve the module settings . The ModuleWidgets on the other hand may not necessarily have been constructed at the point where processing starts.
Well, people will always find something to complain about. I think it depends on the intention of the feature which I don’t find fully baked. Does it mean:
So in that model, when you add 3 modules of a plugin it means that the other ones are put on your blacklist, which will be in your settings file as meaning “I don’t want to see those”, and new modules arriving are auto-added until you might remove those manually, and then they’re put on your blacklist too.
Yeah, and my proposal would fix that scenario, because modules are not automatically blacklisted, they’re automatically whitelisted.
Oof… that sounds… interesting.
Indeed. In headless mode of course the ModuleWidget will never be constructed.
I think that this is why the widget json methods were deprecated in favour of the module json methods
This fixed the crashes I was seeing.
The original Peaks code is so old (pre-v1, maybe 0.5 even) that some of this might have worked at some point, but was dependent on the underlying implementation and timing of Rack.
Sadly, same old error:
[8.673 info src/app/Browser.cpp:89 chooseModel] Creating module Audible Instruments Percussive Synth
[8.679 info src/app/Browser.cpp:93 chooseModel] Creating module widget Audible Instruments Percussive Synth
make: *** [Makefile:107: run] Segmentation fault
I’m trying to get GDB up and running but this whole thing is definitely above my skill level a little bit. I’ll let you know if I find anything.
Turns out I’m just a moron and wasn’t running the right branch. I switched to v2-peaks and everything runs fine. Your fix did it! Thanks so much man!
Ha I was about to suggest that. Great well I’ll let people rinse it for a bit longer to see if any issues shake out, then submit a PR to Andrew
Not sure what I’m doing wrong- I have deleted all Audible Instruments from my plugins folder (Windows machine) and all references to Audible from my settings.json file, but Peaks still doesn’t show up after adding the 2.1 vcvplugin file to my plugins. What am I missing? I also noticed when I look at the plugins.json file it still refers to version 2.0 >Confused<
Figured it out, thanks. ‘Not’ intuitive, for me haha
Just an update - I spoke to Andrew about merging this back to VCV proper. His response is he’d need to completely review the code from scratch which would take many hours and probably find many issues (that could instead be spent improving VCV), which is fair enough I guess. Also that Peaks was one of the less interesting Mutable modules (I have to agree there!). So this will just have to remain an unofficial port I’m afraid.
Peaks is actually the one Mutable module I can’t live without in hardware, although to a large extent that comes down to the Dead Man’s Catch firmware.
Speaking of which, as this will now remain an unofficial port, any chance of adding DMC at some point please?
To be honest I have only a little time and more interesting things to work on at the moment - the UI part is done though so happy for someone to take a punt at it. 
Also to clarify less interesting, I mainly mean it doesn’t have modulation inputs and for me personally that is the most interesting draw of modular.
I’ve been getting better and better at understanding Rack programming, and I may try my hand at a branche version of your Peaks port with modulation inputs and two sets of physical controls. So far, I’ve struggled a lot more on the DSP side of programming in Rack than the UI/“traditional programming” part, so I definitely think I could figure this out, depending on how advanced the port code is.
I just gave this VCV plugin a try. I’m curious about the hardware version because of a podcast interview with James Blake, where he says he uses it live for syncing Eurorack with his drummer. He mentioned that it tracks well when they slow down the tempo of a song.
I wanted to try this out. I set up an LFO as my clock, and connected its FM input to a very slow descending saw LFO. This gives me a nice, steady decrease in tempo on the clock LFO.
In this version at least, Peaks follows the decreasing tempo well, but it introduces a double gate whenever the incoming tap trigger arrives when the output gate is high.
Can anyone confirm if this behaviour is also present in the hardware version? It would seem difficult to use it as a clock if it emits double triggers like this.
