Thank you for the Walk-through documentation, it’s very helpful. My patch is getting a little crowded and was hoping to put some of my beam.tags in subpatchers, but so far no success. Everything works in a crowded patch with one beam.output and all sorts of beam.tags connnected, but the moment i encapsulate some of them, it loses functionality. What steps are required to work with beam objects inside subpatchers or abstractions? (I suspect it has to do with beam.solo, though no luck so far!)
Subpatchers and abstraction are currently partially supported. You can put objects inside a subpatcher, but the inlets and outlets of the subpatch don’t pass Beam signals. However, there are a few options to still make subpatchers useful - especially if the goal is to organize your patch. Here are some ideas:
Use multiple [beam.output] objects
A patcher can have multiple [beam.output] objects. You can also run multiple patchers simultaneously, each containing one or more [beam.output] objects. All signals coming into the [beam.output] objects get summed in the same way as connecting multiple patchcoords to one object. So what you could do is create a subpatcher with its own [beam.output] object. This would give the exact same result as using one [beam.output], but with the benefit of better organization. Here’s a screenshot of what that looks like:
[beam.solo] is related - we use it in our help patchers to ensure that only one [beam.output] has its @active attribute set to 1. Otherwise, all open help patchers would be active which would make it difficult to see what’s going on. In your case, I don’t think [beam.solo] is necessary.
Use [beam.send] and [beam.receive]
If for some reason it makes more sense to use one [beam.output] (e.g. you use a [beam.op] to have a final ‘blackout’ control), you can also use [beam.send] and [beam.receive] to get signals out of a subpatcher. Here’s what that could look like:
And just for completeness, although I would recommend one of the other solutions: you can also use [beam.snapshot] to turn the signal into a Max dictionary and pass it through inlets and outlets. A [beam.sig] object can then turn it back into a Beam signal and pass it to [beam.output]. I don’t think you’d need this in your situation, but it can be useful sometimes.
I hope one of these ideas work for you. If not - and somehow subpatchers are still not working - let us know, since we might be dealing with a bug in that case.
