Multibuffer 'foo' is defined more than once with different buffer lists
I have a few RNBO abstractions which use a construct like:
[multibuffer argsbuf @buffers #1]
Which allows me to reference 'argsbuf' from codebox (which doesn't otherwise allow access to variable-named buffers, AFAIC), while also allowing the possibility of re-using the same abstraction .rnbopat file with different buffer references.
This seems to work ok generally, but in one of the more nested uses of this error and can't compile the code.
Codegen Error undefined
Multibuffer 'argsbuf' is defined more than once with differents buffer lists.I also believe this error to be inaccurate, as I've audited all instances of multibuffer and they have the same buffer list (#1, which is always being resolved to the same buffer name/reference).
I've tried re-creating this error using the same abstractions in various implementations and can't seem to do it, so I feel a bit lost understanding what's going on.
Does anyone have some ideas or guidance about what I could try? Thank you.
There was a cruft instance of one of the abstractions which didn't have the provided buffer name as an argument.
This seems like it basically results in the same limitation in that all instances of the abstractions with this multibuffer name -- hardcoded so that it can be referenced in codebox -- are stuck referencing the same thing. And presumably they follow the same buffer index assignment as well, so there's effectively no independence at all anyway.
try the local: prefix in your abstractions RE: https://rnbo.cycling74.com/learn/rnbo-abstractions-and-rnbopat-files#localize-buffers-and-sendreceive
Thank you Alex. Completely forgot that local: isn't just for send/receive.
Hi Alex, is it accurate to say that in a parent [A] with [buffer local:foo] that I cannot expect to be able to pass a reference via @args local:foo into child abstraction [B]? It doesn't seem to report an error, but it also doesn't seem to access the referenced buffer.
In Max you could, for instance, pass #0foo into an abstraction as an argument, which is why I thought this might work.
