How to (consistently) set one function object from another?
For an abstraction I'm building, I'd like to build an envelope using [function] outside of the abstraction, but then be able to pass it to a [function] object inside, which will then be read through with another process (walking through the range with an [accum] in this case).
At the moment I'm using the 'listdump' message, since that gives me a list that's structured in a way that I can re-parse internally, but this breaks whether curve is enabled or not. When curve is enabled (as it is in my main use case), I get something that I can [zl iter 3], but not when it's in linear mode.
Is there something silly that I'm overlooking here or is there not an easy way to just put the contents of one function in another?
Here's a nice trick, and its great because you can put the [pattr f1] in the abstraction too using @bindto instead of a cable. (Sometimes pattr outputs data in an object-specific syntax that the object itself doesn't necessarily output. The nice thing is you can pass that same message into another pattr and it re-translates it.)
Hmm, I hadn't even used it that way. That is indeed a cool trick, though it does require awareness on the outside too (e.g. if I'm going to setup some pattr objects, I could just make sure that I have curve enabled too). Ideally it would be something you could bang or dump/listdump without needing to care about the contents of the function for it to work.
All you need to know is the varname of the source...?
This works as well, but again, becomes a bit fragile if I want to have two of them or copy/paste etc...
Obvious this is something I can manage, but it's just as easy to make sure curve is always enabled. So it's really just hoping to be able to essentially duplicate the contents without needing to name or set anything in a special way.
Gangbusters!
Ah right, I was scratching my head for a while trying to figure out the issue, but the above mode doesn't work if there is curve involved. Annoying curve needs to have a point set, then the index of that point has it's curve set separately, which can just be done by iter-ing like in my initial example. I didn't know about the getmode message though, so that will help is figuring out whether to iter2 or iter3 further down the line.
"but again, becomes a bit fragile if I want to have two of them or copy/paste etc..." I really don't understand. You can dynamically change the pattr binding(s) if you want independence. (e.g. you can bind only while you're "copy/pasting" if that's what you want).
As in, I have to be aware of the scripting name of the objects to use it (or if it has a name at all), which removes the simplicity of just instantiating a function and using it with the rest of the patch below this.
sorry, I deleted my post by mistake, while adding stuff to that linked example which used only
linear mode.
here is what I meant
if you want straight dump without any pattr stuff
varname doesn't seem like a high bar, plus it allows greater patcher layout independence and less cabling. But here's another solution hilariously similar to Source Audio's that I just coded up...
The non-pattr solutions need "getsustain" too, to be complete.
maybe include getoutputmode to ensure same behaviour of copied function ?
Are there any other attributes important for same behaviour of copied function missing ?
Awesome, these are all fantastic. I'll be able to cobble something together with this stuff