MIDI lag issue or Interface lag problem
Hello,
I am trying to create a interface for my hardware synth. I have done this in the past with NRPN for a DSI MophoX4. That patch still works pretty well for me. I bought a new synth, the DSI Pro 2 and wanted to create a patch to control it and store the patches in Ableton.
First off.
MBP 2012 15" 2.3GHz Intel Core i7
16GB RAM
SSD HD
NVIDIA GeForce GT 650M Graphics Card
10.13.3
Ableton Live 10.0.1
Max 8.0.0
My problem is that there is a lag when I turn a parameter on the synth Ableton picks it up and the interface updates but there is a lag. Meaning if I turn the pot on the synth from 0-127, the Max patch counts up slowly from 0-127. The attached video shows what I am talking about. From Ableton, if I turn the same parameter to change it on the synth I can go as fast as I want and it responds.
This is a larger patch. There is a good bit of parameters to control. The code is really simple and is just duplicated for each parameter for the parameter number to edit. The patch is attached.
Now, if I isolate the patch to one element, any parameter, everything is fine. I had a test patch of just the basic code to get it working, then duplicated for each parameter. So it appears to be once the patch is larger with more elements that is slows down. I am unsure as to why this is happening. I tried changing the Queue throttle to 1. That didn't help. I tried disconnecting the MIDI CC from the MIDI stream so it only goes through the patch elements. That didn't help. I tried disconnecting the output of the NRPN commands. Didn't help. So it appears to be an amount of UI elements that is the problem is my guess.
Any help on suggestions on what I am doing wrong would be appreciated. Is there a better way to handle this many elements? Is my machine just not capable of handling this? I don't think this would be a problem.
Thank you.
The main little patcher 127+NRPN is what does all the work. I have a bunch of these so I can just copy them and assign the parameter number I need for that parameter. If I delete a bunch of these the interface response is as I would expect. Obviously this is not a solution.
I used the same thing in other smaller patchers without a problem. This is the largest patch I have tried with this technique.
What is the best way to handle this much midi routing to individual parameters? Obviously the way I coded this is not the most efficient.
Thank you.
Also the patch You posted is not the most optimal way.
patcher 127+NRPN is missing...
Sorry. I guess copy compressed on a frozen device doesn't capture the bpatcher information?
Here is the .AMXD file.
Should I only use one set of the CNTRL IN objects and use send a recieve inside of the 127+NRPN object?
What would be the most optimal way to handle this midi routing?
I am sorry but I can't really help You.
I don't use Live at all, and so have no interest in debugging live devices.
but I see that You use js for simple midi routing.
I would never do so.
I would check the routing and gating of incoming 4 midi CCs (99, 62,0,29)
to this enourmus nuber of destinations ...
Rather using forwarding or something else, than having each parameter
listen to 4 CCs and outputing 4 CCs all the time ...
OK. Well , thanks for the response.
To anybody that may read this and experiences a problem along these lines, the problem was the js 127+ Receive location in the patcher. I needed to move it after the gate before the outlet. Where I put it, it was processing this code for each device. Simple fix.
I am trying to keep the synth in NRPN for higher parameter resolution. I think this would require all 4 CC messages to each parameter to work correctly.
