Am I completely and totally misunderstanding the purpose of [clip], or is this a bug?

I fail to understand how an output value of -1500 has been clipped to the boundaries of 0 and 300. -1500 is going in, yes, but my understanding of [clip] was that it should never come out with these parameters.

The more reasonable conclusion is that the object simply doesn't work?

hjh

I recreated the object and it works now.

But... the text in the object box is correct. Why would the object not have been created correctly? I assume object creation is deterministic? But, it wasn't, just now.

hjh

@ddw_music Was there ever anything accidentally connected to the middle inlet that you deleted just before this started happening, something that might have set the lower boundary to <= -1500? Something like that just happened to me and it was confusing for a minute.

@jameslo Yes, also a list will overwrite the values of the boundaries, as the contents of the list will be distributed like it is with some other objects. So it is important to make sure that only a single float is arriving at [clip]. Potentially with [f] or [t f].

@ingox Oooh, my money's on your explanation....

@jameslo "Was there ever anything accidentally connected to the middle inlet that you deleted just before this started happening...?"

I didn't think so, but there must have been. Replaying it in my mind, that's a distinct possibility though my memory isn't 100% clear.

That's a prospect that is easy for me to forget about. In SuperCollider, if I write something.clip(0, 300), there is absolutely no chance of anything clobbering those parameters. If I want the boundaries to be variable, then I have to write a variable expression. I understand why it's not the same in dataflows and I'm not complaining about it -- but it did confuse me in this case.

Thanks for the possible/likely explanations.

hjh

@ddw_music To set variables via inlet is certainly a feature of dataflow/Pd.

This:

is probably also supposed to be a feature, but is at least confusing or counter-intuitive. Especially as it doesn't work for all objects the same...

@ingox “To set variables via inlet is certainly a feature of dataflow/Pd.”

I guess, the inherent conflict is: the text in the box can't change, because you need it to be saved as is to restore the proper initial condition when reloading the patch -- but this also means there's no way to inspect an object's current state. So the real state is invisible, and must be invisible. (The same is true of local variables in SC, unless you post them periodically.)

It might be nice if you could mouse-hover over an object and see a tooltip with the current actual parameter values (up to a reasonable amount of text, of course).

hjh