Thanks for considering our feedback. The more right clicks the merrier. Seriously, I think it’s fine. It was a great rec by @aetrion-music - it helps old patches from breaking and if someone wants to use it, you can enable and even use that going forward as default.
1 Like
glad to hear that, thanks 
i’m actually currently working on it right now, and i think i’ve managed to implement a solution to force instances in previously saved patches to default to “remap on generate” to keep the old behavior, and making new instances default to the new behavior.
i honestly don’t even know yet if i want this to be the default behavior going forward, but at the very least, i absolutely can see a path forward that doesn’t involve breaking any patches, so good news all around, i guess.
thanks again to both of you 
2 Likes
okie dokie, i’ve pushed up a new update for the nightly build with the new “remap on generate” toggle in the right click menu, which i’ve decided would be easier to just keep defaulting to “true” so it shouldn’t break existing patches, and new instances will still keep the old default, but the option to toggle it off is there in the menu.
i’ve done a little preliminary test in my local environment, but i’m admittedly a little limited in my ability to fully test this on an actual old patch using the current release version, so i had to kind of ‘fake’ an ‘old’ patch to try it with. everything seemed to work as i’ve intended, but i would definitely prefer to hear from someone else who can give it a try in their own actual existing patches, to ensure it’s not actually breaking anything.
If you are concerned about an explosion of context menu options, you could collect an entire set of them and place them under a “Backward compatibility” sub-menu. That would be easily ignored by most, yet still give all the options needed.
yeah honestly i’ve already started thinking about doing basically that. just consolidating the menu options a bit. it’s not terrible right now or anything.
anyway i can pretty easily just move the sequence, slips, and mod range options all into a single “range” submenu, same with the handful of options related specifically to the mod sequence. that would already probably be enough to make me feel a bit better about things. 
The menus get really hard to use when they get big/cascaded (and people often forget it’s there). I’ve started putting menu buttons on the module. These can even be backed by a switchparam, in which case they become mappable for midi/other modules.
1 Like
For sure. As I continue to refine my module development I strive to have all the functionality visible and accessible from the front panel. As a strong proponent of developing interfaces for large patches, especially when emulating hardware, it is critical to allow modules like PatchMaster and others to be able to map to the parameters. And as much as I like documentation, I know most people do not read it, and so often times context menu options are overlooked.
But often times modules are refined in a way that would alter the sound of old patches. Context menus are a great solution for giving access to historical behavior while still allowing the module to evolve, especially if old patches default to the old behavior.
Then there are features that are esoteric and rarely used. Cluttering up the faceplate might make the module more difficult to use for the majority. But these situations are much more a gray area. Who am I to know what the majority of people will do? So yeah, I struggle with making the call sometimes. Like everything in life, there is no perfect solution that fits all scenarios.
I for one never bothered having a long list of right click menu options as long as the most important stuff is on the faceplate.
A very popular solution for hardware is to have a SHIFT or ALT button and then have other buttons do different things based on the state of that (either holding it down or having it as a switch). SurgeXT modules are already doing that in a way with their modulation controls.
Not being able to select two things at the same time is the main drawback when using a mouse but could also be implemented the same way we use SHIFT+Click in other desktop applications to multi select stuff.
We have some modules using a long press, which is probably fine as well as long as the functionality is indicated by proper labeling on the panel.
Last but not least, we have expanders in VCV that add the possibility to expose lesser used features to an additional front panel.
I don’t know if this could be helpful; but there is a way to parse the plugin version when loading modules, I found that a while ago when doing research for a PR; I didn’t implement it; but VCV’s Random plugin does a simple version of that, it could be expanded upon:
2 Likes
looks useful, thanks for the tip
1 Like
You can always write an “edition” or “features” string to your patch json. If it’s missing, you know it’s a patch made before you added it. Or, more directly, write flags for specific behaviors, rather than a version check. You can pack multiple flags into an integer. This is easier to understand in your code later, because it is logically connected to the behavior, whereas a version is just a point in time where things changed.
1 Like
The standard way to deal with this is to save off a schema id with the patch. Like “this is a version 2 patch”. When you see that
thanks for all the tips and suggestions, everyone.
as of now, i’m just going with leaving the old behavior as the default, and simply having this new menu option to use the new behavior. (“remap on generate” was the best i could come up with, basically describing the old behavior, so it will default to ‘true’/‘on’ for new instances AND old)
i’ve just done a tiny bit of menu item consolidation, basically just moving the ‘mod sequence’ specific options into a submenu. nothing major but it makes me feel a bit better.
anyway, it’s all up in the repo under the nightly build now. unless i or anyone else discovers that i’ve broken something (which i’m certainly prone to do), i’ll probably go ahead and submit a new update to the library sometime within the next week or so.
5 Likes
just submitted v2.5.6 to the library. (link points to current build in my repo)
- fixed polyphony in
nososcillator (which also fixed a CTD reported by a user) - added option to
slipscontext menu to choose when output values are remapped to specified ranges - added ‘manual’ links to all modules
- various other minor tweaks/cleanups
as of a few minutes ago, i’m actually pretty sure there is still at least one minor “issue” with this new version of slips, but it’s not something that will automatically break old patches, so i’m not too concerned about it right now. but just know that, when loading old patches with the new version, if you uncheck the new “remap on generate” option, you may get weird/unexpected results, because the module has no idea what the old patch’s actual normalized (0-1) values were, since with the old “remap on generate” behavior, values are stored in their remapped forms, and not in a normalized form. (i hope this makes sense)
it’s definitely something i hope to come up with a solution for at some point, but since it doesn’t inherently break old patches, and everything else seems to work as expected, i’m going ahead with the update (primarily because i want to make sure the released version of nos will no longer cause the CTD reported earlier in this thread). i will certainly continue looking for a solution.
i hope this is acceptable to people. i just didn’t want to leave nos in its current broken state even longer than i already have.
1 Like
@alefnull did check Nos 2.5.6 - its ok, no CTD. (BTW what is CDT abbreviation ? lol)
crash to desktop
2 Likes
Central Daylight Time 
1 Like
2 Likes
plugin has been updated in the library to v2.5.6.
- nos polyphony fixed
- nos CTD fixed
- added toggle menu option for slips to change when sequence values are mapped to their desired output range (default ‘on generate’, or toggled off to remap just before output, not requiring a new sequence to be generated to achieve the desired output range)
- also did some minor general cleanup and maintenance across the whole plugin
i’ve also been continuing to tinker with a side project plugin that i started before stepping away from Rack development the first time. i don’t know if it will ever see the light of day, but it’s at least keeping me interested and excited enough to keep working on Rack stuff.
hopefully i can eventually also finally figure out how to fix the problems that still remain with NullPath, as well.
1 Like
I’m wondering what version number is higher 2.5.54 or 2.5.6 ?