Brian Kirkbride

I’m wondering if there is a way to store state in a [gen] patch that can be changed from outside (like [param]) but also by the Gen code itself?

in my case I’m tracking a positional index and want external control but also internal advancement of the position.

Many thanks in advance for help with this!

I’m wondering if there is a way to store state in a [gen] patch that can be changed from outside (like [param]) but also by the Gen code its

changing-params-within-gen

You probably need to have a place holder outside of gen that updates the position value and sends it in from a different inlet. In jitter it would be a matrix, in max a float...

@MICHELEZ I was hoping to avoid any outside of Gen logic for this, but you are absolutely right that it could be extracted to a float/inlet setup.

I’m curious if there are Gen only options for this sort of thing?

if you post your patch it's easier to advise...

...but you can store it in a named variable if using codebox(and have a param update that variable), similarly you can use any of the dataspace ops like 'history', 'data', 'buffer' (except you'll be using 'data'/'buffer' to store one single value)...

i'm pretty sure this is possible, though. (you're basically tweaking a 'model-view-controller' paradigm to be more flexible; just need to think which is the view, which is the controller, how flexible you can create those without corrupting information to protect the integrity of data arriving at the model) - wherever you store the value, it shouldn't be the same as where the position advances and the position advance needs to only update from external control when the stored value changes, otherwise, it keeps internal control... hope that makes sense.

i'm pretty sure this is possible, though. (you're basically tweaking a 'model-view-controller' paradigm to be more flexible; just need to think which is the view, which is the controller, how flexible you can create those without corrupting information to protect the integrity of data arriving at the model)  - wherever you store the value, it shouldn't be the same as where the position advances and the position advance needs to only update from external control when the stored value changes, otherwise, it keeps internal control... hope that makes sense.

Sure, here is a patch that is strictly [gen] but can't update it's own Param "pos". There are comments in the [codebox] detailing the code that must be commented out because Params cannot be assigned new values:

and here's a version that handles the position "pos" using a [counter] attached to an extra inlet on the [gen]

My understanding is that Params are for communication with the 'outside world' so to speak, so you can't assign them values except for the initial declared value. Things would get confused if Max and [gen~] were trying to assign a value to a Param at the same time. Is there a specific reason you are avoiding a variable like this

My understanding is that Params are for communication with the 'outside world' so to speak, so you can't assign them values except for the initial declared value. Things would get confused if Max and [gen~] were trying to assign a value to a Param at the same time. Is there a specific reason you are avoiding a variable like this
myVar = (pos + 1) % 16;

As Raja said, you can use the history operator. You can address these from within and without the gen~ world. In your first patch instead of declaring pos as a Param, declare it as a History.

here you go, i was thinking something like this, it might've been overkill, in which case, you'd do exactly as Evan wrote above(which is what i was thinking as a basis) and simply declare it as a History or write the param to a History object in order to use and change it internally, but here's a patch where i instruct it to change using the param 

 if the param has changed, otherwise, keep incrementing internally only:

Sorry to strip out all your other stuff, it helps isolate the problem better, but now you can probably just add it back in right underneath(just make sure the last line "pos_hist = pos;" still comes at the end of all code, because you only want the history to update after each time the entire code is evaluated)....Hope it helps :)

here you go, i was thinking something like this, it might've been overkill, in which case, you'd do exactly as Evan wrote above(which is what i was thinking as a basis) and simply declare it as a History or write the param to a History object in order to use and change it internally, but here's a patch where i instruct it to change using the param only if the param has changed, otherwise, keep incrementing internally only:

@RAJA Thanks for the [history] / [buffer] suggestion. And many thanks for the explanatory patch. In my use case, external logic would likely set pos to 0 occasionally, so detecting a change would prevent that. And since [param] always has the last value set (can't be cleared or set to an "ignore me" value like -1), the [param] sets [history] logic would always occur. I think. But [history] alone will do what I need.

@EVAN Thank you for pointing out that [history] allowed for external updates via messages just like [param]. I had somehow missed that the docs say "The first argument is an optional name for the history operator, 

which allows it to also be set externally (in the same way as the param operator)

@RAJA Thanks for the [history] / [buffer] suggestion. And many thanks for the explanatory patch. In my use case, external logic would likely set pos to 0 occasionally, so detecting a change would prevent that. And since [param] always has the last value set (can't be cleared or set to an "ignore me" value like -1), the [param] sets [history] logic would always occur. I think. But [history] alone will do what I need.

@EVAN Thank you for pointing out that [history] allowed for external updates via messages just like [param]. I had somehow missed that the docs say "The first argument is an optional name for the history operator, which allows it to also be set externally (in the same way as the param operator)"

Changing params within gen