I just installed 4153 on one of my less-used systems to do some testing. Starting the new version failed with an error message “JSON parse error … syntax error, unexpected token Identifier”.
The offending line looks like this
"masterInputGain": Infinity,
Replacing Infinity with 1 made Cantabile boot without a problem - looks like an older version wrote something that the latest version doesn’t understand…
Not a big issue if one knows how to patch a settings file, but definitely a funky upward compatibility surprise…
I guess it’s mostly because my setups are among the more complicated ones - I guess I touch pretty much every aspect of Cantabile somewhere in my setups, so if something is broken, I should come across it (knowingly or un-knowingly) at some point.
But TBH I prefer making music with Cantabile (and running into its ideosyncrasies and nastinesses en route) than focusing on testing…
TBH, I’m not sure what build it was - but according to “log-previous” the last started version was 4151. Might have been one of the work-in-progress versions I used to experiment with binding expressions, when things went crazy when I tried to reproduce the translation curves in binding expressions. I distinctly recall input gain displaying “+oo” at some point during that experimentation. Maybe that value was saved as “Infinity”?
And yes, it did start without the error message. Note: the offending line wasn’t in a song, but in settings.json. Unfortunately, no older “settings.lastgood” available - all overwritten by now…
My guess is something went awry when you were experimenting with the binding expressions and the gain actually got set to +Infinity.
The problem is standard JSON doesn’t support serializing NaN or Infinity. Since it’s my own JSON stringifier and parser I could add support for it, but not sure I should.
Yeah it’s a peculiarity of JSON and JsonKit because:
On writing, it uses double.ToString(“R”) to format the output value. If it’s +/-Infinity or NaN then the output is actually invalid JSON.
On reading, it needs to tokenize a sequence of characters valid for a double literal, but it doesn’t handle the Infinity and NaN cases, because they’re not valid JSON anyway.
Either side could be considered a bug, just need to decide which:
Write technically invalid JSON that Cantabile can actually handle x: Infinity
Write valid JSON, but not reload a value correctly. x: null or x: 0
Write the Infinity/NaN values as string literals x: "Infinity" which would be valid JSON, but then you lose that the value is number if you’re trying to parse with something else and don’t have special logic for it.
Hmm, since the Infinity value occuring is only due to some malfunctioning expression, there is very little value in maintaining this aberrant value across sessions - actually more potential for things to go wrong.
If you can’t catch that aberration at the source, it would probably best to “heal” that when saving the settings, and correct it to some value that Cantabile can deal with meaningfully when loading the settings.
Null would make more sense from an “inner logic” point of view (an invalid value replaced by a null value).
A pragmatic way to deal with this would be to replace the aberrant value with a useful one when saving. In case of the Input Gain, that value would probably be 1 (since 0 would effectively mute input gain) - but that would require actually knowing the semantics of the values when serializing - substitution of invalid data would need to be specific to the content - not realistic…
What happens when Cantabile encounters a null value when reading settings.json? If in that case, Cantabile actively keeps a default value for anything not read from settings, then this might mean that Input Gain would automatically be set to 1 - the most useful solution. So - assuming Cantabile initializes all setup parameters to default before it reads settings - setting any “invalid” values to null would automatically initialize them to something useful - the best solution IMO.
