One user has reported repeated crashes with Peaks (I think on Windows) - I can’t reproduce this, so I was wondering if anyone else had this issue. I’ve just pushed some more changes and a build to address possible uninitialisations, but I am skeptical that this will change anything. @officialdjglitch - you could give this a try?
Yeah, it seems like a crazy way to do it with whitelists, if that is how it works, as people will be endlessly confused as to why new modules aren’t showing up. Pretty sure that design is a mistake and should have been done with blacklists instead.
I don’t like the way it works, but i cant see blacklists being any better. If someone subscribes to 1 module, they’re likely to complain if another module just randomly (apparently) turns up one day, and they have to go to the library and unsubscribe from it.
I think there’s no ideal way to implement it.
yes, but maybe if there was some way in the UI to make it more obvious why this is happening?
2 Likes
btw, this may be another USA culture things, but where I work we don’t use terms where white means good and black means bad. I think we call these “allow lists” and “forbid lists” or something like that.
8 Likes
My post was to point out that you don’t need a subscription to have any of a plugin’s modules appear in the browser, be it a library released plugin or a development build of a plugin that has yet to be released at all to the library.
I can make Peaks crash pretty consistently on Ubuntu 22.04 when the module is added to Rack.
Since it doesn’t crash always, my assumption is that the problem is in the initialization sequence and related to timing. The module’s init() function is called from the dataFromJson() method and perhaps process might run before that method has had a chance to complete. For testing, I put a sync flag in to return from process until the init() function is called and the crash goes away.
Backtrace:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f40e9d50824 in peaks::MultistageEnvelope::Process(unsigned char const*, short*, unsigned long) () from /home/cschol/src/Rack-2.0-Home/plugins/AudibleInstruments/plugin.so
[Current thread is 1 (Thread 0x7f40d157e640 (LWP 2237565))]
(gdb) bt
#0 0x00007f40e9d50824 in peaks::MultistageEnvelope::Process(unsigned char const*, short*, unsigned long) () from /home/cschol/src/Rack-2.0-Home/plugins/AudibleInstruments/plugin.so
#1 0x00007f40e9c90134 in Peaks::process(rack::engine::Module::ProcessArgs const&) () from /home/cschol/src/Rack-2.0-Home/plugins/AudibleInstruments/plugin.so
#2 0x00007f40f21e59e2 in rack::engine::Module::doProcess(rack::engine::Module::ProcessArgs const&) () from ./libRack.so
#3 0x00007f40f21df929 in rack::engine::Engine::stepBlock(int) () from ./libRack.so
#4 0x00007f40f21224a0 in rack::audio::Device::processBuffer(float const*, int, float*, int, int) () from ./libRack.so
#5 0x00007f40f2100523 in rack::RtAudioDevice::rtAudioCallback(void*, void*, unsigned int, double, unsigned int, void*) () from ./libRack.so
#6 0x00007f40f25b6ab5 in RtApiJack::callbackEvent(unsigned long) () from ./libRack.so
#7 0x00007f40f25b6de1 in ?? () from ./libRack.so
#8 0x00007f40f186db0f in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#9 0x00007f40f186d7d8 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#10 0x00007f40f188a910 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#11 0x00007f40f1b85b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#12 0x00007f40f1c17a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
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.
1 Like
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:
- I only EVER want to see these 3 modules in this plugin, no matter how many more arrive in the future. That’s the current model. Or…
- For NOW I only want to see these 3 modules in this plugin, and as more arrive in the future I will go and remove them or not, on a case by case basis, just as I have done now. That’s what I’m proposing would be the better model.
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
1 Like
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.
1 Like
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<