search

AlexHarker / FrameLib

A library for arbitrary-rate arbitrary-size frame processing
BSD 3-Clause "New" or "Revised" License
74 stars 9 forks source link

Context patcher - Embedded bpatcher edge case #73

Closed AlexHarker closed 2 years ago

AlexHarker commented 3 years ago

There is hypothetical edge case in the context patcher detection when:

This is probably very unlikely to happen, but it would be nice if there were a fix. The issue is that empty embedded bpatchers look identical to embedded bpatchers that are loading and it doesn't seem possible to reliably test which case is present. As we need to correctly traverse embedded bpatchers the edge case is currently preferable to non-traversal in these cases.

AlexHarker commented 2 years ago

Consider a post loading check, now that contexts can be dynamic.

AlexHarker commented 2 years ago

In reality the situation above is probably not a big concern/likely to be possible.

If the patch has no name it has not loaded from disk (this is set even as the patch is loading if from disk). A patch that has not loaded from disk cannot have objects in it at load time. Thus, this would also require that the GUI object is creating a patch from scratch, and adding objects to it in a situation where it later intends to set the association. If the association is set before objects are added things will work correctly. If the association is not set then it's not clear why the patch is hosted (it wouldn't traverse without the loading time code), but traversal will at least be safe.

A more pressing real-world case is that if a bpatcher loads a patch not whilst the bpatcher is being created this is non-detectable and will not traverse. This also appears to have no obvious fix, other than a later check (which is possible). If this check is implemented it will ensure all context are correct, although the implications for connections etc. are a bit unclear. It starts to look like the non-load test (which should be limited so as not to detect loading objects making it faster and 100% reliable) is unavoidable.

AlexHarker commented 2 years ago

Fixed by be11fd4e8a81c4664a3d1f8af0d2365a5665eb8e