DanT's Bright Idea?

Ah thanks, that’s the term I needed, search found this thread Force single module instance

2 Likes

Glad to help.

As pgatt mentioned, my PurrSoftware Meander module is implemented as a singleton due to its use of global variables since it was once a Windows app. Andrew guided me a couple of years ago on how to make a singleton and the technique works very well but it is not trivial even though it is fairly straight forward. One complication is that you have to handle the situation of the user actually trying to add a 2nd instance. You either have to do nothing and confuse the user, or display some type of disabled module that tells the user what the deal is. This last is what Meander does.

1 Like

Ah, glad you found the thread. I had forgotten that was around.

1 Like

I would think an easier and less confusing option would be to just make multiple instances work. If your knobs follow the actual setting in rack, and only change it when a knob moves, then multiple instances would always have the same value.

This doesn’t work with how I have coded the module, I am directly setting the Rack value from the parameter + CV value, multiple instances overwrite the value on each process step.

The master instance is easy enough to implement, so I’ve done that, currently only the master instance gets ports & knobs. Once I’ve done the full panel design, I will add a label that indicates why the non-master instances do not do anything.

I’ve got a quick Windows build here for anyone that wants to give it a bug bash. (I may have a Mac build later if I find the time…) Release bright-idea-v1.0 · Miff-Real/DanTModules-Manual · GitHub

I think I need to add a feature to deactivate the module when the module browser is open, because its quite annoying not being able to see when adding modules to a patch. Is there any knowledge on detecting the module browser?

There should be more than enough room to add a parameter for the flashlight, should that be added to the API.

1 Like

You might look in my Meander.cpp file on my GitHub repository as I handle this. Look in the MeanderWidget constructor where I mention what I did to get the panel to display in the browser when there is no module instance due to being a singleton.

Actually, I misinterpreted what you were asking, I think. My comment had nothing to do with Room Brightness, etc.

I added the GitHub workflow from Automated building and releasing Plugins on Github with Github Actions to my repo and it seems to work, so I have made a new test build for Windows, Linux & MacOS (although the Linux build was made with ubuntu-latest which I’ve read can cause issues)

1 Like

After a little digging in the API and Stoermelder PackOne, I think this may work: APP->scene->browser->isVisible()

1 Like

Hi,

thanks for the newly added Bright Idea module.
When loading an instance into the patch, the module takes over the current settings of the parameters.

But when clicking the ‘active’ button from the default ‘on’ state to ‘off’, and then back to ‘on’, all parameters are set to a max setting.

Is this intended? I would prefer if maximising the value’s didn’t happen.

It was intended, but I am working on a new version that will have some additional context menu options to let you configure how the module works. (The new version will probably not be available until some time Saturday because it’s nearly beer o’clock where I am).

  • Override Rack off by default - Controls the values when the module is added to the patch, activated, or when the module is un-bypassed. When this is off, the module will set it’s parameter values to match the current Rack settings, ignoring any changes to the parameters that may have been made while the module was not active. When this is on the current module parameter values will be used, ignoring any changes to the Rack settings that may have been made while the module was not active or bypassed.

  • Deactivation Defaults on by default - Controls the values when the module is deactivated or bypassed. When this is on the Rack default settings will be restored when the module becomes inactive. When off the values of the parameters will not change. Rack default settings are: float cableOpacity = 0.5; float cableTension = 1.0; float rackBrightness = 1.0; float haloBrightness = 0.25; as seen here Rack/src/settings.cpp at b3b7b652c1e4832e169afc8578747a33929c0caf · VCVRack/Rack · GitHub

  • Module Browser Deactivation on by default - This option will temporarily deactivate the module while the module browser is open. Note, this is independent of the Active Toggle button & CV.

And you can see that the module has my traditional CV Param Mode & CV Input Slew options as well.

Obviously these new menu options add a lot of extra use cases for saving & loading patches, both in VCV and the VST, especially where you may change the Rack settings between save and load. So far I have really only tested using the module directly in a patch, so any additional testing reports would be gratefully received.

4 Likes

Excellent!

Enjoy your beertime :slight_smile:

VCV Youtube videos are about to get more fun. Very cool ideas. I love the recent mods too. Cheers!

Well it took me awhile to figure out the dynamic text for the module state, but I finally just finished the update.

Here are the new builds (note: the Linux build is still done on ubuntu-latest so might not work, I haven’t tested it) Release bright-idea-v1.1 · Miff-Real/DanTModules-Manual · GitHub

edit: I just noticed in that screenshot that the slider lights are funky on both WAVULIKE and VCV RANDOM, I guess that’s a bug?

Hi Dan,

i just had a quick look at the module.
Thanks for adding “deactivation defaults”.

Still the button “bypass on/off” doesn’t work as one would expect,
for example:

If i have my custom value’s set for the screen in Rack itself, and i adjust the settings in your module (while deactivation defaults in enabled).

And then click the bypass button to OFF, i would expect the settings of the module to take over (this happens and is ok).

And when clicking the bypass button to ON i would expect the settings which were default in Rack itself to take over (this does not happen).

That would be a bypass,
but right now the bypass button works as a reset.

Maybe i missed something? Or what i describe is technically not possible?
Eitherway thanks for the module :slight_smile:

Sorry I am not quite following, and it seems to me you are describing the module backwards (clicking the button to deactivate the module, what you describe as OFF, would mean the module values are NOT applied, when deactivated the button is unlit)

There are 3 context menu options that control how the module acts when it’s state changes, and these 3 options interact with each other, so, I’ll try to describe all the different combinations of use you might need:

  • you have a patch without Bright-Idea

    • The Rack settings apply, you can change them from the View menu, the values are saved into the settings.json file, they are not saved in the patch file
    • If you load any patch that does not include an active Bright-Idea module, the Rack settings will remain the same
  • you add the Bright-Idea module to the patch

    • the module is active by default but the option Override Rack is OFF by default, so when you add the module to the patch, the module will set it’s parameters to the Rack settings, then take control of the settings
    • you can no longer change the values from the View menu because the module is controlling them, you can change them directly on the module using the knobs, or via CV
    • the module parameters and its state (active or deactivated) will be saved in the patch file, so if you load any patch with an active Bright-Idea module, it will immediately change the values
  • you deactivate the module by clicking the Active Toggle button (or toggle the button with a CV trigger)

    • By default, the Deactivation Defaults option is ON, this means when you click the button and the module becomes deactivated (the button is unlit), the Rack default settings will be applied. The module will no longer control the settings, if you want to change the settings you can do so via the View menu, you can still change the knobs on the module but this will not affect the values.
    • This is also true if you right-click and bypass the module, but note that this is independent of the Active Toggle button, if the module is deactivated when you bypass the module, it will remain deactivated when you un-bypass the module
  • you activate the module by clicking the Active Toggle button (or toggle the button with a CV trigger)

    • By default, the Override Rack option is OFF, this means that when you reactivate the module, it will set it’s parameters to the current Rack settings, which will be the default settings if you have not turned OFF the Deactivation Defaults option, or not modified the values via the View menu while the module was deactivated. So effectively you will see no change.
    • If the Override Rack option is turned ON, this means that the values of the module parameters will be set as the Rack settings. I think this is the situation you are confused by, if you want the module to save it’s values and apply them when it is reactivated, you need to enable this option.
  • you open the module browser

    • The Module Browser Deactivation option is ON by default, which means that the module will be deactivated when the module browser is open. However, if you have also turned OFF the Deactivation Defaults option, when the module is deactivated, the values will not be changed from what the module parameters are at the instant of deactivation (you might be modulating the parameters with CV). So potentially, if the Room Brightness was low, it would remain low in the module browser.

Hopefully you can see from this explanation that the 3 options control how the module works, and what the combination you need is.

It is possible that the behaviour you desire is for the Module Browser Deactivation option to be independent of the Deactivation Defaults option, so that when the module browser is open, the Room Brightness is always max.

This would be possible to code, but would add another context menu option, and clearly the usage is already leaning towards the complex side, so let see what the public consensus is before I add that.

Another alternative would be to make the Override Rack option ON by default, the consequence of which would be that the module would immediately change the Rack settings to default when it is added to any patch, I thought this would be unexpected and not desired by most users.

Or another alternative, I could make the Override Rack option ON by default, but, make the module deactivated by default when it is added to a patch. But again, this may be confusing to the user, adding a module that doesn’t do anything until you activate it.

Possibly I could also change the dynamic text on the module when it is deactivated, to make that clearer?

1 Like

Thanks Dan,

Maybe i was overthinking it, I will go ahead and use the module according to twhat you described above.

And for now avoid using the enable/disable button, as that button is currently throwing me of. Until i get more custom with how you implemented it :slight_smile:

I changed the implementation of the dynamic text so that it shows clearly when the module is deactivated, but I haven’t created a new build yet, will do that once I know there are not more changes needed.

Hopefully this video will give you some insight

1 Like
1 Like