@sam recommended some parameters for a potential Config Menu. If there’s will for it in the community, I can put this together with the help of @laborcamp.
PARAMINCV 1 - 4PARAM and IN calibration would be good too.
My PARAM knob goes from 0 to 16340 (and not 16383 as it should).
The one hesitation/issue I have with calibration is that it can be a really hard thing to do the UI for. It usually requires 2 values to be specified, and it’s not always that easy to communicate where those values come from.
Also, will it be computationally cheap enough to use the calibration data? My gut says yes, as OPs are never run that often (computationally speaking).
Other ideas:
It’s already slated for IN.SCALE and PARAM.SCALE, and it’s not many instructions to do. As you mention, it can’t get called all that often. Trivial IMO.
will add to the top post.
How about:
Maybe… but having a configuration option just avoid a single key press at power on might set a bad precedent for how many things end up in the menu. You might struggle to complain about other similarly trivial items if this ends up in there.
I expect than @tehn will veto any number of things, so I’ll just aggregate everything in the top post for now.
There is a trade-off with the config menu and setting basic user expectations. The menu permits flexibility when a design decision would otherwise be rigid. I see things being bumped into the config menu as catering to the community, but there is a lot to be said in favour of just making good decisions where they need to be rigid.
I can go either way, personally.
I see your point - in fact that was my first thought about Startup Metro on/off. But then I could not think of another example that would not be as specific but still obvious. Until I engaged in a discussion about if the variable monitor should be on or off at startup. Why not saving a single key press on every startup as long as it aims to some very defined features.
Also the variable monitor has no OP and can not be toggled from an initial I script.
Yeah, and I think it makes sense. It’s a hardware interface feature as opposed to a teletype core feature. I think @tehn has a good vision for where to draw the boundary, and was right to cut those aspects of the feature out.
Yeah, I also think it makes sense - my point was that as a hardware interface feature it should be configurable via the config menu while features that have OP’s should be configured via an I script.
basically just an offset? or scaling as well?
would prefer a default on-time, as suggested elsewhere. this doesn’t seem like it needs config.
let me talk to the manufacturer first to assess if this is actually an issue. i think the screensaver would effectively solve the possible issue.
that’s a pretty subtle user preference i’d say. resuming the last state (as it does now) seems entirely intuitive.
no. this goes in the I script.
i’d prefer this to be on at startup, with a simple hotkey toggle-off. config seems overkill.
now this is one is tricky. i’d almost prefer some sort of RESET op that does this, and it can be included in I script if someone found it necessary.
looks like i basically slashed off all the items: but calibration is not a bad idea if people are having issues with their DACs and ADCs staying consistent.
Offset + scale, unless there’s a reason not to.
If that’s the case, then calibration can just be a dedicated mode that is accessed with a keystroke or something.
I can make this happen. Can I take your suggestion as an approval?
So… thinking about calibration a bit more. Assuming all the calculations are done at runtime and no pre-calculation is done (e.g. pre-calculating N values). Maybe it would be better for CV out calibration to be an OP… in an ideal world calibration is done to some universally agreed upon standard (i.e. 1V/oct), but in practise it’s to particular set of VCOs (or VCFs).
Assuming you’ve got the values worked out in advance and kept somewhere safe, you could then add a bunch of CV.CAL calls to your I script setting up each of your oscillators.
Just a thought.
I’m a bit in 2 minds about which is better. I know in reality I just won’t be bothered to make a list of values for each of my oscillators (and the values would be different for each CV output used). But I might be bothered to do it once for each of the outputs to get them as near to 1V/oct as I can be bothered.
(Also I would really like my PARAM knob to hit the full range…)
CV.CAL could also write to flash and these could be recalled at startup.
Definitely saved in flash, which means recalibration when new firmware is loaded unless we change the flash layout and flashing procedure.
Also, if it were done as ops, we’d need:
CV.CAL.MINCV.CAL.MAXIN and PARAM counterpartsAs calibration is done in 2 steps.
I can roll this op into the PARAM.SCALE / IN.SCALE patch as it’s part of the same calculation, but it begs the question:
CV.SCALE to prescale CV?