create a constant chop with channels: a,b,c and values: 0, 50, 100
append a filter CHOP (width 1 sec)
delete channel(name): b
all good
add channel(name) b again
channel b ramps from 100 to 50
delete channel(name): b again
channel c ramps from 50 to 100
…
this situtation happens a lot when filtering blobtracking channels, i.e. some (middle) channel disappears and then all the channels with higher channel numbers get re-filtered
BUG? Workaround?
Is it possible for you to create Constant CHOP with stand-in channels for the ones you will be filtering, and using a Replace CHOP to replace those stand-ins when the real channels come into existence?
not really, as then the filter will ramp from the default values to the ones which are in the tracking channels once they come into existance. Besides that, the blobtracker might increase the blob IDs to a pretty high number, so in order to cover all the possible blob IDs, i need to possible handle hundrets of channels. Any other ideas?
So it’s not a bug? if not, why does the first deletion of channel b not trigger any ramping up in channel c, but the second deletion does?
The bug here is actually the behavior the first time you delete ‘b’, since it should be acting as if it’s old value was 50 and it’s input is now 100. This is because this CHOP works based on channel index, not channel names (most CHOPs work like this unless they have parameters to do otherwise).
Let me think about this more to try to find a solution for you.
did you find a solution to this one ?
I think the way you have to do this with existing tools is have a table that maps the channel index to the blob ID. You also have another table that lists unused channel indices.
So when a new blob appears you look into your unused channel index table and assign it a channel index. When a blob disappears clear the reference from the channel->ID table and add the channel to the unused index table.
Use a Evaluate DAT/DAT To CHOP or Expression CHOP to take the channel->ID table entries and create a CHOP with blob x/y values in the correct channel index to be used as the input to the Filter CHOP.
This is very similar to the persistent ID thing I sent to support, and i believe that it will also suffer from the same issue described in the mail.
Besides, if I understood your suggestion correctly, when a blob disappears I also need to keep track of it’s last xy, otherwise the filter will go to 0,0. But even if I do, when i reuse the channel index at a later point, the filter will then ramp from the stored values (from the last blob) to the new value
Seems like you need another input to the Filter CHOP that allows you to reset the channel’s filter history. That would solve the 2nd part right?