Nested Bpatcher
Sep 25 2018 | 11:27 am
Can anyone suggest a good solution? Its a little difficult to explain but ill do my best.
I have multiple copies of the same Bpatcher nested inside a global Bpatcher, however the problem I am experiencing is, when I tweak a parameter dial on one of the multiple Bpatcher copies, these tweaks are mirrored through to the other copies (children). I am guessing that this is happening because the paths are crossing over from using the same send / receive messages without patch chords.
Is there a way to stop the Bpatcher communicating with its copies?
Hope thats not too confusing.
- Sep 25 2018 | 11:38 amThis shouldn't be happening. can you post an example?
- Sep 25 2018 | 12:22 pmHi, I have made a simple example to highlight the problem, however the real thing is much more complex.
- Sep 25 2018 | 12:44 pmMichael. Look at your send and receive objects. Do you know about #0 ?
- Sep 25 2018 | 10:17 pmWhats wrong with the send and receive objects? No i don't know about #0?
- Sep 25 2018 | 10:37 pmNot to get too Socratic here but... What makes you think that one receive should NOT listen to the send in the other patcher?Send and Receive are like walkie talkies. If you have 3 walkie talkies on the same frequency, one person talks and two people hear them. This is how your patch is functioning. You're sending your dial values on channel "dial" and both receives are on the same channel "dial" you need to get them off each other's frequency.#0 is a special symbol you can attach to the beginning of a symbol to make that symbol unique to the patcher it's in. So if you use [Send #0.dial] and [Receive #0.dial] You'll get one send channel for one bpatcher and another for the other bpatcher.try pasting this into your patch
- Sep 26 2018 | 10:05 amThanks for the feedback, i really appreciate the help.The s/r messages crossing over is exactly what i suspected was the cause of the problem. When i originally started writing my patch i didn't anticipate the need for a bpatcher so the s/r messages were not an issue, but my work has evolved a lot since then.Th #0 is a really nice and easy solution which will not require much amendment to get it working.Thanks again.
- Sep 26 2018 | 10:09 amIt's happened to me a thousand times. Glad to help
- Sep 26 2018 | 10:59 amunlike normal named s/r, #0 makes things patcher-exclusive.if you really need to use s/r within the same patcher is another question.
