There are two big issues that come up. First, when the inspector is in a different rack, and connected by busses, it is hard to avoid 'jitter' in the controls, where two different values chase each other around the loop.
Secondly, it's easy for data from one source to mistakenly get sent to another source.
All my inspectors so far have had timers. So when the channel gets changed, data from the inspector to the old channel is blocked. Then we wait. Then we let data from the new channel in. It's been clumsy slow and complicated, but it has worked. But real 2-way communication has still not been possible. I could allow changing values either from individual channels, or from the inspector but never both, or I would end up with jitter.
But thanks to gurulogic, I have a better way to wire this:
This is now a solution for my inspector problem. Data is sent to and from the inspector, with the first item in the array being the source channel number. The script checks the channel of incoming inspector data to make sure it matches before changing anything, and when it does, it is 'injecting' inspector data into this nice tight 1-block local loop. I have managed to scale this up to many more parameters without issue, and there are no timers, so it changes as quickly as possible.Third example (example2waymap(alt)) is another approach where I circumnavigate the buses latency issue by having the plugin parameters kept in a local loop and sending the remote parameters data to manipulate the local loop directly.
It does seem to be important to close the loop completely for all parameters, even if they only need to go one direction, or else stray values can end up in the loop (not sure how this happens....)
Don't know if anyone else might need this, but here it is, just in case:
http://www.sensomusic.com/forums/upload ... orTest.wkp
