Inputs and outputs (descriptions) are accumulated in a variable when reconnecting in custom region

vvvv gamma question
1

7.1-0101

I noticed that descriptions accumulate when reconnecting. This is about the new custom region API. I suspect this behavior is abnormal.

Screenshot
Screenshot1414×798 53.5 KB

CustomRegionNewAPI2025.vl (41.4 KB)

2

I just realised that this is probably not a bug. It’s just a lack of management on the part of the patch.

Screenshot
Screenshot628×1042 24 KB

But at the same time, it is completely unclear how to delete descriptions of inputs and outputs?

3

That’s true. We didn’t put anything into the API that notifies you about a change use of the region (like added or removed BCPs).

We just didn’t see the need for this yet.

Those Acknowledge & Retrieve operations are only called when a link exists to the BCP, which implies it is there. But sure, for sake of house-keeping it might feel nice to know about deleted BCPs still. Do you have an example where it’s necessary already?

4

@gregsn To be honest, I haven’t quite figured out how it all works yet. Maybe that’s why I suspected it was a bug.

I don’t really understand how to work with BCP yet. Could you perhaps provide a very simple example where, for example, data enters the patch via BCP, is then processed, and also exits via BCP? Some kind of example of BCP management.

I would be very grateful, as it would allow me to analyze the issue in more detail.

Right now, I feel like working with BCP is too inaccessible and complicated. But I just don’t understand how.

5

Hm. Well the main point of the new IRegion API is that it supports both

  • input and output pins inside patches designed by the region designer
  • input and output BCPs added by the region user

So. BCPs in general are dictated to you by the user of the region.
Even writing and reading from/to them is dictated by the user. Even the moment and when not to.

grafik
grafik586×487 9.76 KB

All you can do is to make sure that the data gets is retrievable. For that you can work with your favorite dictionary. For example, if you want to design a region that invokes the patch inlay on different threads, you would maybe want to use a concurrent dictionary.

But that really depends on the particular region. Supporting splicers can be more tricky. The Patch Inlay pins are meant to tell you which inlay patch instance is currently executing, when an input BCP is read from or an output BCP is written to by the user. Typically you have many patch inlay instances when you support splicers.

grafik
grafik490×448 5.82 KB

But apart from that you are just responsible to acknowledge that the user wrote some data into a BCP and retrieve it when asked for.

6

@gregsn Am I correct in understanding that, as a node-region designer, I don’t have many options in the context of BCP? For example, I can’t make splicers (a custom region doesn’t even have an ‘input’ like, for example, a foreach region).

  • I want to make an analogue of the Cache region (not because I need to, but just as an example). To do this, I need to know inside the patch that the input data has changed. How can I do this?

  • I want to make it so that BCPs with a specific name become part of the context (something like a scope accessible via the send node).

  • I want to create a region with splicers, for example. Is this possible?

  • Read and count the number of connected BCPs. Get data from them and submit it to some process inside the patch.

I wouldn’t say that this is something that is really needed or necessary, but it just gets my imagination going and I want to test the limits of what is possible. There is a suspicion that simply removing all the logic about BCP from the patch will not change anything. I even made test custom regions, completely removing this part, and it was much easier not to be distracted by it. But still, since it is there, perhaps these mechanics can be applied somehow?

7

Yes, at list on c# side this is possible, however the way it’s done i would not call obvious at all: