Hello .
I'm developing a multi-effects patch with only two knobs and two switches for control. I'm using select and spigot to navigate and tweak through the different parameters

I'm seeking guidance on how to ensure that parameter values are updated only when the knobs are adjusted.

Whenever I switch effects, the values/numbers from the previous effect transition to the new one, causing unintended fluctuations. I've attempted to work with float and change objects, but I've encountered repetitive operations that haven't effectively addressed the problem.

Thank you

@ytt Not knowing what the unintended fluctuations might be, my first thought is that you tag the data and send it as lists.
i.e. switch1 value switch2 value knob1 value knob2 value.....

You can add the tags to the data using [list prepend]
i.e. [list prepend switch1]
or dollars in a message
i.e.[knob2 $1(

Then you can obtain the parameters for the effect, filtering using [route]

Ahh..... the unintended fluctuations.......
You want to send the last parameters received back to a switch or knob when you change one of the switches (the switch that controls which effect you will edit)...... and you can do that with a [set( message to the other controls.
A [set( message will set a value in the control. but the control (gui) will not send it. It allows you to then change the gui value from that starting position.

Probably the easiest way to store and recall settings for the switches and knobs will be using [text]
David.

it gets in the weeds - basically you got a problem if your knob isn't a digital encoder which sends things like +1 or -1 to move numbers - typically these also have a push button.

if your knob is a potentiometer/slider/knob/pot like on an electric guitar - these only give discrete values and will Jump like on the left.

if you use one of those like I am on the right - and I apologize for it seeming messy, I'm cleaning up little problems - but the knob is still a potentiometer, so even tho I changed it into something that compares if its going higher or lower it ends up at weird places - so to do it right these needs to be an encoder type of knob - (which I'm simulating by just hitting the 1 and -1, a little surprised acting like an encoder isn't in [knob] yet.)knob-problems-pot-vs-encoder.pd

@ytt Another....... pfff.zip
You need to ignore the first message from encoders when you change to another effect...... send the previous settings for that effect back to them, and then start accepting messages again...
....... I think.
I am sure it can be simplified....... it is just a quick sketch to check the principle.
David.

Thanks a lot for your feedback.
That's exactly what I'm looking for.
The goal is to install this patch on the electro-smith daisy pod. Unfortunately, not all pd elements are supported, specifically ones related to lists and Exp.
Is there a different approach to achieve the same outcome?

The tricky part is that the knob/potentiometer keeps sending its current value. If I could make it act more like pd's slider or number box, I think it might work.

My understanding of pd is pretty basic, so I really appreciate your help.

Unsupported_vanilla_objects:
https://github.com/CorvusPrudens/hvcc/blob/develop/docs/10.unsupported_vanilla_objects.md

Oh ok yeah I clocked that. I mean with enough creativity you can do anything with PD - for example that was some masterclass work with lists to save and recall two states.

You are better off changing your idea and working within what you can make the daisy pod do or see what others can make it do because it's too obscure to ask here. In plugdata you can turn on compile mode and that gives you a better idea of whats going to work and not. Think about it like - there is one push encoder and two pots. And also just give yourself some patience and space because you are learning two different things at once.

The heavy compiler was basically complete for vanilla pd but for objects at like 0.43 or something. We're at 0.54. Nobody really knows without getting in there and just seeing if it will compile a patch or not to see about what it can and can't do except the hero who picked up that abandoned project and is working to maintain it now.

Check out the daisy discord, they hired the sound simulator guy and there's a lot of question asking and answering https://discord.com/invite/ByHBnMtQTR

@ytt Perhaps this? It lacks the fault of the [expr] version which can leave you not being able to reach min or max rotation without altering the other value but it means the knob does nothing until you reach its old value. Error in the pic ([i] and [change] are reversed) but fixed in the file.
knob.pd

Edit: The [i ] -> [change] might be less then ideal and may not work at all depending on the output of your knob, if it outputs a float between 0 and 1 then this will not work as patched. Few different ways to fix this issue, depends on what exactly pd recieves from the knob and what your needs are.

@oid that's a good comprimise & I checked - it can compile with the heavy compiler onto the daisy pod ( [expr] is not in heavy ), - have it latch until it reaches the old value. If only the knobs on the daisy pod were digital encoders instead of potentiometers ..
really hit a wall right away when I got a daisy pod .. say I have an idea I want to put on it - -- it's got four sliders, the daisy pod basically has two sliders & an encoder ... :/ .. I have a couple other "things you can put your PD patch on" and having the layout of the hardware UI already decided makes it feel weird to put a new idea on - at least for me.

@fishcrystals You just need to spend more time in vanilla and rely less on externals, most of the more recent objects are just shorthands and the logic of using current vanilla applies directly to older versions. Vanilla is surprisingly complete, it is just low level and requires you to develop the lower level skills. Your [expr] can be replaced with a [moses] and a [t f f].

Thanks a lot @fishcrystals
That's exactly what I was looking for and it works perfectly.
It's great that I can choose to recall the values only when the knob reaches its initial position or have them update immediately as soon as I adjust the knob, just have to remove the top portion of your patch.
It's quite enjoyable to come up with creative solutions to overcome the limitations of the pods.
Hopefully, midi functionality will be quickly integrated into the pd2dsy.

@oid Nice, this inspired me to try and scale this up to many additional "layers" of parameters (8 right now).

The latching feature is really something I wanted to implement soon as well, so this came in quite handy.

I'm also using Daisy btw. testing on the Field. What I'm currently doing is scaling the 0-1 float to 512 integers instead. Larger might be possible, but I found that it's harder to hit the latching value as precision of the received value goes down and you may over-shoot.

Other than that this setup works reasonably well. I've tweaked it a little bit so that each latching parameter can be represented with a single abstraction taking an id to initialize.

@ytt Midi is available in the integration with plugdata.

Try the latest nightly builds to test the upcoming 0.8.0 release!

@dreamer said:

Larger might be possible, but I found that it's harder to hit the latching value as precision of the received value goes down and you may over-shoot.

You can just test if the number is larger or smaller than instead of equal to, a bit more complex and could be too much for the daisy but who knows, I know nothing about it.
knob2.pd

Edit: Suppose that bang should be triggered by the right float atom, forgot to switch that over, bang was mainly for easy reset while testing.

Edit: Actually it is not much heavier than the previous version, just a test which happens once to see if the number is larger or smaller then the previous and the route stuff. Have the right float atom go to the right inlet of the [f ], bang the [f ] and the reset bang once when this parameter is selected.

And a simpler version, could be made more efficient on the reset side but I am not sure it is worth it. Not sure what I was thinking recreating moses with the swap/pack/route.
knob3.pd

Edit: went ahead and fixed the reset stuff, could still be made more efficient yet with a once between the bang of the [t f f b] and the [f ] but that is probably a meaningless improvement over the simpler [change]?

Edit (again): But I suppose there is no reason to test floats after the test has passed so sticking a spigot before moses would be a worthwhile improvement. Updated.

@oid Cool, I'll see if I can work that in and see if that helps with the latch.

Theoretically greater/smaller should indeed work better, so will try soon!