I went ahead and added factory presets to emulate Frolic, Glee, and Lark. Look for those names in parentheses after the attractor name:
This is all in pre-release 9:
Unless there is a bug or serious problem found soon, pre-release 9 will be what I submit to VCV Rack.
Trying to run Zoo attractors in order from the CHAOS knob, I can get past Chen-Lee. After loading the first two attractors, Chen-Lee fails going into overflow.
Chen-Lee runs properly if Zoo is initialized before selecting the attractor.
Hadley & Sakarya use CHAOS setting B, the rest use A when loading from the CHAOS knob.
I confirmed this is a bug. I’m really glad you found this! I will have a fix soon.
This was an intentional editorial choice on my part. I feel like the B mode is more interesting than the A mode in this attractor, so I prefer it as the default. However, if people find it distracting to see B after loading it, I’m open to the idea of making A the consistent default mode for Zoo factory presets.
Here is the updated pre-release that fixes the bug @scook found:
I needed to make this tiny code change, otherwise after loading “Aizawa (Glee)”, other attractors get messed up parameters.
WRT inconsistent chaos setting
Ignoring for a moment the terms may be swapped, having the examples as they are and documenting it may be a good help tip,
nice
I submitted the pre-release 10 code to VCV Rack for approval. Assuming everything goes well, it will officially become Sapphire version 2.6.001. The VCV update will probably occur next week, based on observing their recent integration cycle.
It sounds like it should be the default option for new patches, but old patches should leave it off. yes?
I like that idea. Keep existing behavior in existing patches, but allow new instances to have improved capabilities.
Yes. Unfortunately the only way I know to do that is to put something in old patches so you can know. I always put in a parameter called “schema” . Some people put in special json.
Given Zoo has yet to be released can the “old patches” be updated to work like “new patches” so it all works the same for the initial release? If I can help with this let me know.
If I add this new polyphony option, it will not require any special work to fix old patches. The option will only be present in the json in the proposed new plugin. If the new plugin does not see the option when it loads an older patch, it will default to turning polyphony off, to preserve behavior.
The new plugin will always save the option to the json, to automatically upgrade old patches to explicitly disable the option.
When creating a new instance of Zoo, the polyphonic CV option will be enabled by default, and saved that way. There will be a menu option to turn the feature off if you don’t like it, but it will be turned on by default.
So everything should just work.
Not true. The absence of a parameter in the json can be just as informative. In the code, initialize the parameter to your desired modern value. Then in the dataFromJson, if the parameter does not exist, revert back to the old behavior. So newly inserted modules get the modern default. New patches get the parameter in the json and get the modern value. And old patches without the json parameter revert back to old behavior. Works great for me.
yes. But if you use the regular params, like many ppl do, then you can’t do that.
If you are processing your own JSON, which it sounds like you are.
You lost me there. The dataFromJson is executed after the standard parameter load is complete, yes? So if a json value is missing (I was loosely calling it a parameter), your code can then override any number of parameter and internal variable settings to revert back to old behavior.
I thought that if a parameter is missing the deserialization code just creates it with a default value? But if I’m wrong about it, that’s fine. wouldn’t be the first time!
hmm–Module::paramsFromJson and ParamQuantity::fromJson (like all of the default implementations) use the Jansson json_object_get which returns NULL if it can’t find a value key in the JSON snippet for the parameter, in which case the relevant ParamQuantity->setImmediateValue is never called (see here and here); same if a paramId is never reached when traversing the params array (though Andrew guarantees a paramId for every array position, you could still run short). So I think [?] the parameter default is just set by the defaultValue defined here.
But in any case I think @DaveVenom is talking about dataFromJson which is virtual {}; the only default implemented behavior relating to this is that if there’s a data key in the module JSON, dataFromJson gets auto-called at the end of Module::fromJson (here). So if I’m tracking (which I may not be!) anyone using dataFromJson is already rolling their own processor (at least beyond the Jansson fundamentals).
Technically, deserialization just doesn’t set a value if the parameter is missing, so it will have the default value given by the config… call in the constructor. Effectively the same thing as if it had to code to look up the paramInfo and set it to the default value given there, but that would be completely unnecessary code.
paramsFromJson called before dataFromJson is virtual, so modules can override it and do anything they want. I’ve never found a need to do that.
Omitting certain parameters in a factory preset is quite useful - then the preset changes only what’s necessary.
