Params that can hold negative values are not initialized properly

[h2g2guy]

Describe the bug I'm creating an oscillator that uses a param with range -100% to 100%. When I switch to an Init Program on the Prologue, and switch to my custom oscillator, it sounds like the parameter is set to -100% (i.e. a call was made to OSC_PARAM with a value argument of 0). However, when you go into the "edit mode" on the prologue, it displays a value of 0% (which means the argument to OSC_PARAM should have been 100). Changing the value in the edit menu resumes correct and expected behavior.

To Reproduce

1. Create a simple oscillator program that uses a param range of -100% to 100%. Design this program such that the sound will be audibly different with values of -100% and 0%.
2. After uploading the oscillator to the device, open an init program. Verify in the menu (without changing the value) that the parameter is set to 0%.
3. Play some notes with the oscillator. Note the sound generated.
4. Change the parameter's value to 1%, then back to 0%.
5. Play some notes with the oscillator. Note the change in the sound generated.

Expected behavior I would expect the sound heard in steps 3 and 5 to be the same. Instead, when you play notes in step 3, it sounds like the param is set to a value of -100%.

Desktop (please complete the following information):

• OS: [Ubuntu in WSL]
• Device: [prologue ver 2.00]

Additional context This seems related to issue #35 . It's my expectation that calls to OSC_PARAM should be made upon initialization of the oscillator, in order to set up the oscillator if it is a part of a preset. However, we ought to be able to set default values, and even if we can't, there should never be a situation where the value the user is shown is different from the last value sent to the custom OSC_PARAM.

[h2g2guy]

@etienne-korg , I hate to ping devs directly, but I've not received feedback on this for several months. I'm prepping for release of an oscillator in the next few weeks, and if this bug is not resolved, I will need to release with an workaround that will be unpleasant from both the dev and user perspectives (and I'll need to explain to my users that this issue is an issue with the synth, not with my oscillator).

I can confirm that this bug still exists in prologue version 2.10, using the very latest version of the SDK (I pulled master before building).

If there's anything I can do to help drive this bug to a root-cause and a resolution, please let me know. I'm happy to supply a sample oscillator and a repro video, if that would be helpful.

[dukesrg]

I can confirm thet bug too. Current workaround is to limit bipolar parameter to -99 and add 100 in the parameter handler if zero value is received.

[dukesrg]

Some additional details on bipolar values:

• minilogue XD initializes params internally by raw 0 value (i.e. -100%), displaying first time 0%. On the second selection of the same parameter, the lower bound value (which is stated in the manifest) is displayed, but parameter value is unchanged. On program recall all parameters are restored and displayed fine.
• NTS-1 initializes to the lower bound value - both internally and displayed value.

@etienne-korg I really hope drumlogue won't have such issues and all logues firmware will be aligned.