patch.GetKnobValue jumping around

Getting Started
1

I’m using Daisy patch. I’m using:

speed = patch.GetKnobValue(static_cast<DaisyPatch::Ctrl>(0)) * 4.0f + 0.1f;

To read the value of a control knob. I notice the value seems to fluctuate a lot. At max is seems to span from 2.5 to 4.1 or so. Which seems like a pretty big span. How do i deal with this. Is there a way to get these values to settle?

I’m new to hardware programming. This problem has to be have been solved. Is there a standard way to handle this?

2

Do all the knobs behave this way?
Maybe it’s a dirty potentiometer? Try turning it back and forth many times, to see if this changes the behavior?

1 Like
3

Here is what I’m using at the moment.

float speed;
const float SMOOTHING_ALPHA = 0.05f;
const float DEADZONE = 0.2f;

...

float newSpeed = patch->GetKnobValue(DaisyPatch::CTRL_1) * 4.0f + 0.1f;
if (fabs(newSpeed - speed) > DEADZONE) {
    speed = (SMOOTHING_ALPHA * newSpeed) + ((1.0f - SMOOTHING_ALPHA) * speed);
}

This works better but has issues. With the control at min, I’m displaying the value * 100 on the oled. It shows 30 for a moment, then jumps to a random value, between 50 and 150, then goes back to 30. Small improvement but needs work.

I’m considering making a class to do this work but I’m not sure if I’m using the right approach.

4

I’m still wondering why it jumps around so much. Ive been tinkering with Daisy for years, and don’t recall it being that bad.

Have you verified the same behavior using the example Patch programs?

5

That’s good to know, this is the first time I’ve used Daisy so I’m not sure what to expect.

I built and tested all of the patch apps in the DaisyExamples. They all seem to work. A couple apps display a bar that represents the value of a control. I don’t remember those jumping around.

I’ll compare the examples to the code I have and if there is any significant differences…

6

Question: Do I need to initialize the controls in some way?

Currently I’m doing this:

patch->Init();
patch->StartAdc();
patch->StartAudio(AudioCallbackWrapper);
7

I tested CTRL_2 with the same code as above, and its total stable! Not sure whats’s going on but CTRL_1 seems to have a problem.

Not sure what’s going on with the first pot? Could there be some noise leaking into that first pot?

8

I’m an idiot! I had something plugged into the jack above CTRL_1, oops!

Never occurred to me, I figured I’d have to handle CV input in code! looks like the CV input is routed through the pot. Seems like CV input affects the control value even when the pot is turned all the way down, so the pot doesn’t act as an attenuator. When the pot is all the way up it never gets above the max knob value, so it doesn’t seem like the CV is added to the pot value.

I should take a look at the schematic…

1 Like
9

Yes, the CV input is added to the pot value.