It seems that the ‘Bang On Create’ pin only affects the UpEdge output.
the DownEdge bangs on Creation in any case.
It seems that the ‘Bang On Create’ pin only affects the UpEdge output.
the DownEdge bangs on Creation in any case.
hhhm,
it seems that the behaviour has changed inbetween.
but it’s still, ahem, strange…
BangOnCreate.v4p (8.9 kB)
could the strange behaviour described here be related to that?
hey kalle!
i think everything works fine. maybe we only have a pin naming problem here. (Bang On Create)
the problem:
togedge can only operate when it knows the current and the last input value. only that way it can report an upedge or a downedge.
so in the first frame there is a special case: we have no last frame.
so with this option (Bang On Create) we would only want to decide on how the last frame value should be simulated.
the discussion thread:
just bangign both doesn’t make sense at all in my opinion.
what do you think? better idea for naming of the pin?
oh well, not everything is fine.
also when a new slice is created we have the same scenario as on create. so the behaviour here should also be influenced by the “Bang On Create”.
tog edge bug.v4p (12.9 kB)
The logical choice to me seems that this pin should have a dropdownlist to choose the kind of bang.
The other possibility I see, is making 2 separate ‘on create’ inputpins - ‘bang up’ and ‘bang down’ - which would allow to bang the 2 pins at the same time, which is against any logic, but which might be useful to some people for initalizing things.
The first choice is logical, but limiting.
(I started using vvvv 2 weeks ago, so I apologize if this comment is useless)
hm. i wouldn’t put in special modes which are against any logic ;) especially not when we would need to add another cryptic pin.
this node should be so easy:
figure out if there was a change from 0 to 1 or the other way around. it should do no more than that.
the problem is that in rare cases no former value exists which makes a comparison impossible. so we need to spell out which former values would make sense:
former value =
that are all possibilities i can think of.
we need to see which of these possibilities should be implemented.
at the moment the last two are implemented.
and then we need a nice default.
btw. fixed that slice bug i mentioned above for beta>=22.
to keep patches running and to keep things simple i would suggest to keep these two modes and not add more.
however we should discuss about a better name.
how about: “Signal Change On Create”
if false: no signal change -> no bang.
if true: up edge for current value = 1,
down edge for current value = 0
That is a possibility.
Looking at the framedelay node, it has a default value. maybe that would be a more logical choice, making the node ‘simple’, that is, banging if and only if the input changes. The possible behaviours you describe could be constructed with simple logical operations on the same input.
I know this wouldn’t necessarily be compatible with previous versions but I think it would be a good idea to define ONE GENERAL RULE for every vvvv node that needs to know its previous input in order to not have an undefined state.
These are difficult choices. Always adding a default pin might be a possible choice, but whatever the choice may be, it should be consistent in my opinion.
(Talking about the framedelay node, the fact that you can initialize it multiple times also makes it some sort of switch node, and though that can be a handy feature, it’s also blurring this nodes main purpuse a bit)
hi ft!
that thread is getting interesting!
i think you’r making a good point here. however to be able to talk about general rules, we should take more examples into account. and we should then check if the clarity of just one rule will also result in simplicity on a high (patching) level.
but as states in general are somehow related let’s go even more lowlevel before we check examples.
about states in general
we have nodes which are purely functional (have no state and behave like pure functions) and we have nodes which are stateful (store some data for the next frame).
all stateful nodes can be seen as nodes composed outof two methods:
in a way the first frame of a new slice can be seen as creating and evaluating that slice, whereas all other frames just evaluate the slice.
so a stateful node needs to create/initialize states and the one question would be if there is a natural way to do that. natural would probably most of the time equal neutral. however often there is no completely neutral value…
think of a (multi)flipflop, a (multi)toggle, a queue, a S+H, integrate, automata. they all try to keep things easy and natural, even when there is no completely neutral state value (like a 0 in addition or a 1 in multiplication). what is neutral is dependant of the patch around it. so to get things really flexible we would need to put default pins everywhere. but i’m not sure if this is the level we should design node interfaces…
one way to combine flexibility with simplicity would be to have advanced versions with those default pins for its states (flexibility) and to have simple versions (could be modules) which feed the default pins with values best for the common cases (simplicity). however this blows up the node list…
the “previous input” state
now there are nodes like togedge, framedifference, framevelocity and the simple filter nodes (linearfilter, damper …). they all can be thought of working with a framedelayed input internally. i attached an example patch how togedge can be implemented as a module working with a framedelay internally.
like in the more general case also here the state could be initialized with a default value, which could be done by the user if there was a default pin.
in most of those nodes however you would want to use the first input value as the default. (framedifference and framevelocity should output 0 in first frame, filter nodes should start from the first input value). so in the standard case you would need to draw two links instead of one. (one to the input and one to the default)
however in most cases you don’t want to do that. so we again would need a simple node (module) covering just that standard case.
that would blow up the node list. but at the end of the story this is probably worth it in a long term (when we have reworked the node list to make simple nodes more prominent than advanced ones). what do you think?
ps: about the initialize pin in the framedelay. i think you are right. it somehow blurs the main purpose of the node. however it also doesn’t hurt too much. maybe we should just hide it by default.
togedge.v4p (7.2 kB)