orange_glass

I have a device that automatically maps 8 nobs to 8 corresponding nobs on an instrument rack, the control method is live.remote~ . The target instrument rack often changes and is determined by a number and arrows in the controller device. I did use live.object but there was too much latency I found.

So now I have switched to live.remote~ it is much more responsive however as my patch changes targets of the 8 nobs the audio gets interrupted and makes a horrid crunching noise. Each nob and corresponding live.remote~ is in a bpatcher. I'm figuring the system just can't handle 8 live.remote~'s receiving new id messages in rapid succession. I have tried both defer and deferlow before the right inlet.

My only other idea is to use a delay mechanism that staggers the mapping process. Any other ideas?

I have a device that automatically maps 8 nobs to 8 corresponding nobs on an instrument rack, the control method is live.remote~ .  The target instrument rack often changes and is determined by a number and arrows in the controller device.  I did use live.object but there was too much latency I found.

So now I have switched to live.remote~ it is much more responsive however as my patch changes targets of the 8 nobs the audio gets interrupted and makes a horrid crunching noise.  Each nob and corresponding live.remote~ is in a bpatcher.  I'm figuring the system just can't handle 8 live.remote~'s receiving new id messages in rapid succession.  I have tried both defer and deferlow before the right inlet.  

My only other idea is to use a delay mechanism that staggers the mapping process.  Any other ideas?

live-remote-rapid-remapping-interrupts-audio

Wow just realised that as my bpatchers received the list of IDs of the target instrument rack, it ran them through a deferlow, then it used another defer after a prepend id. I've found removing the 1st deferlow it's fixed it. Not even sure why I put it there in the 1st place!

I think it may have fixed something else in this device's past.

Wow just realised that as my bpatchers received the list of IDs of the target instrument rack, it ran them through a deferlow, then it used another defer after a prepend id.  I've found removing the 1st deferlow it's fixed it.  Not even sure why I put it there in the 1st place!

I think it may have fixed something else in this device's past.


If you can post the patch maybe i could help you

live.remote~ - rapid remapping interrupts audio