Anthony Palomba

I would like to use pattr to save pieces of data that are

not tied to any UI object. Specifically strings for VST name and path.

When I create my pattr, and save my data in it, but it sends

the data out the left outlet. But it also sends the data out the

This creates an awkward cyclical dependency. I could ignore the left

outlet and use the output of a preset control to trigger a load, but

this is also very cumbersome if the patcher is in an abstraction.

Is there a more elegant way to do this that I am missing?

I would like to use pattr to save pieces of data that are
not tied to any UI object. Specifically strings for VST name and path.

When I create my pattr, and save my data in it, but it sends
the data out the left outlet. But it also sends the data out the
left outlet when it restores the data. 

This creates an awkward cyclical dependency. I could ignore the left
outlet and use the output of a preset control to trigger a load, but
this is also very cumbersome if the patcher is in an abstraction.

pattr-behavior-request

As has been discussed many times here pattr is deprecated for the kind of uses you describe. That said fastest solution is to put relevant data into textboxes and hide them.

But you should really use coll instead. Or dict, if it suits your puposes and you have max 6

Ahhh I see. By textboxes which object exactly are you referring to.

Ahhh I see. By textboxes which object exactly are you referring to.
Do you mean textedit?


Yes textedit. But, I would definitely go with coll or dict.

I'm not aware of pattr being officially "deprecated" for any particular usage. It's just a question of whether it's the right object for what you're trying to do. I'm not sure I fully understand the exact context in which the OP is using pattr, or what the OP wants or doesn't want to happen, so maybe an annotated example from Anthony would clarify.

If I understand correctly, though, I'm pretty sure you can figure out a way to employ the 'initial' and 'thru' attributes of pattr to get whatever behavior you want. Check out this example. Save it, close it, and reopen it to observe the behavior of the two pattr objects, then experiment to get what you want.

@chistopher, where did I say "official"? Sure, you can make different things work different ways,but the question is waht "makes sense"? IMHO, anyways.

@jamesson, You didn't say "official" (nor did I quote you as having said it), I did. Your use of the passive voice "is deprecated" left unclear who is doing the deprecating, and since in the software world the phrase "is 

" connotes that something has been officially declared obsolete or undesirable by a governing body (e.g., "the 'font' tag has been declared deprecated in HTML4 by the W3C"), I was just trying to clarify that -- to my own knowledge -- the pattr object has not been deprecated by Cycling '74 for the kind of use that Anthony described, namely "to save pieces of data that are not tied to any UI object." (Indeed, that is a pattr object's default behavior until it is explicitly bound to a UI object.)

@jamesson, You didn't say "official" (nor did I quote you as having said it), I did. Your use of the passive voice "is deprecated" left unclear who is doing the deprecating, and since in the software world the phrase "is deprecated" connotes that something has been officially declared obsolete or undesirable by a governing body (e.g., "the 'font' tag has been declared deprecated in HTML4 by the W3C"), I was just trying to clarify that -- to my own knowledge -- the pattr object has not been deprecated by Cycling '74 for the kind of use that Anthony described, namely "to save pieces of data that are not tied to any UI object." (Indeed, that is a pattr object's default behavior until it is explicitly bound to a UI object.)


Thanks for posting an example, the @thru attribute is exactly what I

am looking for. How would I know when I would need to bang out

the new pattr value? Do you know if there is a way that pattrstorage

can notify you when a new preset is triggered?

Thanks for posting an example, the @thru attribute is exactly what I
am looking for. How would I know when I would need to bang out
the new pattr value? Do you know if there is a way that pattrstorage
can notify you when a new preset is triggered? 

I don't really have any idea what the context of your patch is. If you want the value to come out when it's changed, then why do you want to turn off thru? But what I'm 

 you're trying to achieve is to store something in a pattr locally without it sending that value out, but have the value be sent out when you change it remotely via pattrstorage. Is that correct? If so, here are a couple ways you could do that. (But without knowing how your patch is constructed and what behavior you're really trying to get, I don't really know what to recommend to you.)

I don't really have any idea what the context of your patch is. If you want the value to come out when it's changed, then why do you want to turn off thru? But what I'm guessing you're trying to achieve is to store something in a pattr locally without it sending that value out, but have the value be sent out when you change it remotely via pattrstorage. Is that correct? If so, here are a couple ways you could do that. (But without knowing how your patch is constructed and what behavior you're really trying to get, I don't really know what to recommend to you.)


"Do you know if there is a way that pattrstorage

can notify you when a new preset is triggered?"

This can be done by monitoring pattrstorage's output in response to loading presets. I've modified Christopher's previous example to show one way of doing this, and demonstrated using pattrforward to remotely 'bang out' the value of a pattr object that uses the @thru 0 attribute

"Do you know if there is a way that pattrstorage
can notify you when a new preset is triggered?"

This can be done by monitoring pattrstorage's output in response to loading presets. I've modified Christopher's previous example to show one way of doing this, and demonstrated using pattrforward to remotely 'bang out' the value of a pattr object that uses the @thru 0 attribute


pattr behavior request...