Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@etheory
Copy link

@etheory etheory commented Feb 25, 2025

With reference to: https://iplug2.discourse.group/t/automatic-hz-khz-change-during-frequency-parameter-changes/984/3 add a new function called: InitFrequencyAutoRange that provides a frequency parameter that automatically changes formatting between Hz and kHz.

Uses the function:

  auto freqFormatter = [](double val, WDL_String& str, IParam* parent)
  {
    const double onethousand = parent->FromNormalized(parent->ToNormalized(1000.));
    const bool gte1k = val >= onethousand || val >= 1000.;
    const char* units = gte1k? "kHz" : "Hz";
    if (gte1k) val *= 0.001;
    const int displayPrecision = parent->GetDisplayPrecision();
    str.SetFormatted(MAX_PARAM_DISPLAY_LEN, "%.*f %s", displayPrecision, val, units);
  };

In order to both provide formatting, and also respect either the precomputed precision, or a call to:
SetDisplayPrecision

All feedback welcome.

InitDouble(name, defaultVal, minVal, maxVal, step, "", flags, group, ShapeExp(), kUnitCustom);
auto freqFormatter = [](double val, WDL_String& str, IParam* parent)
{
const double onethousand = parent->FromNormalized(parent->ToNormalized(1000.));
Copy link
Author

@etheory etheory Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has to be added due to the imprecision of normalization causing an entry of 1000. using a PromptUserInput call as with IVKnobControl. If you don't go through the normalization and back again you an type 1000. and not get 1.00 kHz in the output due to imprecision.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this. I don't want to be picky, but shouldn't there be a solution for the text input '1.2k' as well?

Copy link
Author

@etheory etheory Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be inconsistent with every existing control but its certainly possible. At the moment all existing controls only accept numbers as inputs and not text. That would be a separate PR. It also has nothing to do with this PR. I was going to also add that cause I also agree it should be supported, but it wouldn't be here, it'd be in the prompt class.

Copy link
Author

@etheory etheory Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TBProAudio here is a partially working implementation of what you asked: #1204 - it needs a bit more work and feedback, but it's definitely heading in the right direction.

If you use it in conjunction with: SetPromptShowsParamLabel(true); it's already quite compelling. But there are a few key missing things that I note on the PR to make it more complete. But it's very doable.

@TBProAudio
Copy link
Contributor

Thanks. Yes, works as intended.

@etheory
Copy link
Author

etheory commented Mar 4, 2025

There are a few things that need updating, I will try and get to updating this PR this weekend and do another more mature revision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants