As an integral part of my setup, I have program changes sent upon pattern change from a hardware sequencer (Elektron Octatrack) to my computer via a USB MIDI interface (MOTU Micro Express) where a preset manager in HH is triggered by the incoming program change to recall a specific program change message to be sent back out through the USB MIDI interface and to trigger pattern changes on connected hardware sequencers (Elektron Analog Rytm and Analog Four)
Due to the round trip latency of this process, if the MIDI program change message from HH arrives at the external hardware a fair amount (in MS) later than it would if sent directly from hardware device to hardware device, and if received too late the device receiving the program change will not change pattern for one full cycle of the set sequence length.
Through careful patching, with numerous other factors in my setup to consider I had it working fairly reliably with HH running on my laptop computer.
Now I have migrated to a much more powerful desktop setup with the same MIDI interface and OS (windows 7) but for some reason it seems as if round trip MIDI latency with the new computer has increased to the point where the program changes on the receiving hardware are not ever received in time, despite the fact that I have found a way to remove one bloc of latency from the process, as well as I have tried with a much lower bloc size. This tells me that for some reason the USB bus on this computer must have added latency compared to the USB on my laptop but I have no idea if there is any way to combat this issue?
Anyone have any suggestions? I'm thinking Windows tweaks that might increase priority of a USB bus or..?
USB MIDI latency tweak?
Not all USB ports are created equal...
On Windows, there are often MANY USB ports, and if you're having latency issues it's a good idea to (1) stay away from hubs, & (2) use the lowest # USB port on your motherboard; use a USB port directly connected to your mobo. You're looking for the most direct path from a USB port to the Southbridge chip on your mobo.
My understanding at this point is to stay away from USB 3.0 for audio, the drivers still aren't there yet for some inexplicable reason and some of the USB 3.0 chipsets are far better than others.
Some additional info here on vguitarforums:
http://www.vguitarforums.com/smf/index. ... 8#msg89368
http://www.vguitarforums.com/smf/index. ... 6#msg50206
Hope this helps,
On Windows, there are often MANY USB ports, and if you're having latency issues it's a good idea to (1) stay away from hubs, & (2) use the lowest # USB port on your motherboard; use a USB port directly connected to your mobo. You're looking for the most direct path from a USB port to the Southbridge chip on your mobo.
My understanding at this point is to stay away from USB 3.0 for audio, the drivers still aren't there yet for some inexplicable reason and some of the USB 3.0 chipsets are far better than others.
Some additional info here on vguitarforums:
http://www.vguitarforums.com/smf/index. ... 8#msg89368
http://www.vguitarforums.com/smf/index. ... 6#msg50206
Hope this helps,
Address the process rather than the outcome. Then, the outcome becomes more likely. - Fripp
Thanks, I tried your suggestion, no difference. I suppose I should try measuring the round trip MIDI latency of the desktop vs the laptop just to be sure that it isn't some other factor..
Another thought is I have not bothered installing the USB 3 drivers in the new computer as I do not use any USB 3 devices, maybe this could somehow have something to do with it? Also I am running my PCI Express X1 audio interface in the PCI Express X16 slot, I wonder if this could be making the PCI to USB controller run at a slower speed?
Another thought is I have not bothered installing the USB 3 drivers in the new computer as I do not use any USB 3 devices, maybe this could somehow have something to do with it? Also I am running my PCI Express X1 audio interface in the PCI Express X16 slot, I wonder if this could be making the PCI to USB controller run at a slower speed?
Hi Guru!
So how are you checking your latency?
1. I would suggest doing a comparative test, use Tobias LoopMidi and send your MIDI out and then back into Usine to see the delay. Then use your USB interface and do a loopback test with a MIDI cable and do a comparative patch to determine the latency.
I would be interested to see how much the real delay is related to the USB driver/Controller or if for some reason it is going on in Usine and the Kernel. Yes there will a difference in latency as LoopMidi will have it's own, but would be curious to see how much a difference the hardware gives, rather than an internal. Just an experiment but might yield some numbers.
Just a suggestion but that might be a step you could take to get some metrics you could base your tweaks on or understand better.
-Windows Power Options - Advanced, Turn off USB suspended. Sometimes this will cause latency and cause drivers to misbehave.
Also make sure you have performances maximize (which on a desktop they should be).
I am looking into seeing what I can find regarding driver priorities, make sure you have all your device drivers installed and updated, also make sure you are not using Windows default drivers. (Probably already checked that).
Can you give more information regarding your setup and devices?
-S
So how are you checking your latency?
1. I would suggest doing a comparative test, use Tobias LoopMidi and send your MIDI out and then back into Usine to see the delay. Then use your USB interface and do a loopback test with a MIDI cable and do a comparative patch to determine the latency.
I would be interested to see how much the real delay is related to the USB driver/Controller or if for some reason it is going on in Usine and the Kernel. Yes there will a difference in latency as LoopMidi will have it's own, but would be curious to see how much a difference the hardware gives, rather than an internal. Just an experiment but might yield some numbers.
Just a suggestion but that might be a step you could take to get some metrics you could base your tweaks on or understand better.
-Windows Power Options - Advanced, Turn off USB suspended. Sometimes this will cause latency and cause drivers to misbehave.
Also make sure you have performances maximize (which on a desktop they should be).
I am looking into seeing what I can find regarding driver priorities, make sure you have all your device drivers installed and updated, also make sure you are not using Windows default drivers. (Probably already checked that).
Can you give more information regarding your setup and devices?
-S
"Every act of creation is first an act of destruction." -Picasso
Thanks for the input. I will try a loopback latency test with both computers and if there is a noticeable difference I will post back with some more setup info.
Also, can anyone confirm for me what I suspect, that the "Send MIDI to Usine" module acts like a bus and adds one bloc of latency? Also perhaps the "MIDI In" module when used in a Device out patch?
"Send MIDI to Usine" had a bug in it that caused MIDI latency that was fixed in the very latest version of HH.
Are you on the latest version of HH?
Are you on the latest version of HH?
Address the process rather than the outcome. Then, the outcome becomes more likely. - Fripp
Yea latest version.. Seems I have something else going on though. Round trip MIDI latency tests as 14-15MS on both computers with the Micro Express via Hollyhock . Somewhat better with the RME Multiface MIDI. Ahh, lesson here is I should really check this stuff thoroughly before jumping to conclusions.. Back to pulling my hair out. Maybe by the time I figure it out the soon to be released VST integration of the Elektron AR and A4 will solve all my problems..
Just for giggles, here's a way that seems to work fairly well for measuring time between two events (create button has to be hit a second time to reset timer)
Just for giggles, here's a way that seems to work fairly well for measuring time between two events (create button has to be hit a second time to reset timer)
So you are using a Motu?
I have been using the MIDI Express XT USB for almost a decade now, as well as the RME multiface....such a good combination.
So the RME Multiface is a Proprietary Firewire to PCI card so I would expect it to be faster. and hmm you have the same midi latency between computers.
So your original setup/symptoms. You were performing Program changes at specific times? Question is how are you doing or performing this?
-S
I have been using the MIDI Express XT USB for almost a decade now, as well as the RME multiface....such a good combination.
So the RME Multiface is a Proprietary Firewire to PCI card so I would expect it to be faster. and hmm you have the same midi latency between computers.
So your original setup/symptoms. You were performing Program changes at specific times? Question is how are you doing or performing this?
-S
"Every act of creation is first an act of destruction." -Picasso
Hmm ok, I'm now on the right track, thanks for putting the thought in my head sephult.
I made a nifty little tool for measuring delay of a message at various points through a rack, findings are that there is indeed one bloc of latency between the send midi to usine module and the midi in module within a patch, also there is a delay of one bloc between the midi out from a patch and the midi in of an output midi device.
The big discovery is that it is taking a preset manager 95-110MS to recall one listbox which is used to generate a new Program Change message to send to a midi output. The preset manager target in this sub patch is set to current patch, and as I noted, the "Listbox" is the only thing that should be stored in a preset which I have ensured is the very frst thing in this patch to receive an action when a midi program is received. The highlighted modules at the bottom are my measuring tool and are not relevant to this specific patch. The question now is how can I trigger an unique per preset Program Change message without this huge lag and why did it work better on my laptop? (haven't yet bothered setting up this same test on the laptop) I'm wondering if perhaps moving HH install folder from one computer to another caused a problem maybe?
Sending the incoming MIDI direct via bus to an output works fine, but obviously I can not dynamically remap messages this way. I am envisioning a way I could set up a global PC remap per project where specific PC values are premapped and sent directly out but in my head this seems a huge headache and potential for conflict as the idea of each project / workspace is that it is split into 16 banks that can be interchanged with other projects /workspaces and needs to have the mappings intact for each bank..
I made a nifty little tool for measuring delay of a message at various points through a rack, findings are that there is indeed one bloc of latency between the send midi to usine module and the midi in module within a patch, also there is a delay of one bloc between the midi out from a patch and the midi in of an output midi device.
The big discovery is that it is taking a preset manager 95-110MS to recall one listbox which is used to generate a new Program Change message to send to a midi output. The preset manager target in this sub patch is set to current patch, and as I noted, the "Listbox" is the only thing that should be stored in a preset which I have ensured is the very frst thing in this patch to receive an action when a midi program is received. The highlighted modules at the bottom are my measuring tool and are not relevant to this specific patch. The question now is how can I trigger an unique per preset Program Change message without this huge lag and why did it work better on my laptop? (haven't yet bothered setting up this same test on the laptop) I'm wondering if perhaps moving HH install folder from one computer to another caused a problem maybe?
Sending the incoming MIDI direct via bus to an output works fine, but obviously I can not dynamically remap messages this way. I am envisioning a way I could set up a global PC remap per project where specific PC values are premapped and sent directly out but in my head this seems a huge headache and potential for conflict as the idea of each project / workspace is that it is split into 16 banks that can be interchanged with other projects /workspaces and needs to have the mappings intact for each bank..
As far as your setup are you activating/deactivating with the Grid as well?
I have run into some "missed" first messages because of a few things that are on the hairy edge, I believe Preset Manager recall was one of these. At the time I had to recall things earlier than the sequence, without enabling/disabling....however yes it's completely project dependent. Your initial post about, things not happening till the next cycle...I ran into that a lot.
If I recall the Preset manager too can be driven by just changing the NUM input, be interested if there was any quicker response in doing so. Doubt that is the case...but when stuff like this becomes a problem you never know
Have you changed your trigger for the Create MIDI? Maybe triggering off of the Listbox instead of the recalling Preset manager?
Also curious about your differences in setups between the two computers. Do you have the same graphics settings, and other in main settings? Make me wonder now if the listbox refresh graphically happens first if it is dependent on graphics or just the data triggers. We all know that the audio thread is separate, but makes me curious about the preset recall thread and data dependencies. Just a curiousity.
It is interesting (and also frustrating) finding out these kind of things. I would suggest moving your trigger to the Listbox change first, checking. Secondly I would look into changing the Preset Recall from the NUM and seeing if there is any difference. This might indicate a module difference and/or could point to the input select as causing the delay. (Im not 100% sure how much or what you checked with your tool, but a suggestion).
Also have you played around with the Bloc size settings and measured any differences in these? Be curious if the delay is still the same or if it improves much. Maybe that could be a clue.
Hope some of this talk helps Guru, like I said I know it's frustrating but you look like you are on the right track. Very cool!
I'd be interested in the measuring tool, you should package up and put in the add-ons. I think a lot of people could benefit from more tools, help us all work together to identify issues and improve upon.
Regardless, these frustrations at the end of the day just teach us a lot more, you will get there.
-S
I have run into some "missed" first messages because of a few things that are on the hairy edge, I believe Preset Manager recall was one of these. At the time I had to recall things earlier than the sequence, without enabling/disabling....however yes it's completely project dependent. Your initial post about, things not happening till the next cycle...I ran into that a lot.
If I recall the Preset manager too can be driven by just changing the NUM input, be interested if there was any quicker response in doing so. Doubt that is the case...but when stuff like this becomes a problem you never know
Have you changed your trigger for the Create MIDI? Maybe triggering off of the Listbox instead of the recalling Preset manager?
Also curious about your differences in setups between the two computers. Do you have the same graphics settings, and other in main settings? Make me wonder now if the listbox refresh graphically happens first if it is dependent on graphics or just the data triggers. We all know that the audio thread is separate, but makes me curious about the preset recall thread and data dependencies. Just a curiousity.
It is interesting (and also frustrating) finding out these kind of things. I would suggest moving your trigger to the Listbox change first, checking. Secondly I would look into changing the Preset Recall from the NUM and seeing if there is any difference. This might indicate a module difference and/or could point to the input select as causing the delay. (Im not 100% sure how much or what you checked with your tool, but a suggestion).
Also have you played around with the Bloc size settings and measured any differences in these? Be curious if the delay is still the same or if it improves much. Maybe that could be a clue.
Hope some of this talk helps Guru, like I said I know it's frustrating but you look like you are on the right track. Very cool!
I'd be interested in the measuring tool, you should package up and put in the add-ons. I think a lot of people could benefit from more tools, help us all work together to identify issues and improve upon.
Regardless, these frustrations at the end of the day just teach us a lot more, you will get there.
-S
"Every act of creation is first an act of destruction." -Picasso
Nailed it! If I use the num inlet, delay is 6ms to recall the preset. It's not the dispatch, it's the recall inlets that are slow. The use of the dispatch to trigger the recall inlets is something I did change sometime in the last while, it is just a bit hard to keep track of because I have only been picking away at this project here and there when I have time so it's easy to lose track of, but I can see that I maybe didn't check the response time of the external gear after making this change as my focus has been getting the right presets to load in a slightly complex usage scenario. Essentially I am emulating the grid mode of v5 with 16 "grid lines" that are remotely enabled and disabled per bank (each containing 16 patterns) of the Octatrack and must recall the appropriate preset when the patch is first enabled which is why use of the recall inlets are a must as it's impossible to recall a preset that is already loaded via the num inlet.. hmm, at least now I know what direction to look in solving this. Thanks for the suggestions so far! And yes, I have a bunch of useful bits and pieces I would sometime like to upload and share
Awesome guru!
Glad to hear you are getting there.
So couldn't you use a fast script dispatch to numeric? I am a little confused why you say you must use the recall instead of the NUM?
I actually think I've done this before or could script it up for you. If you would like me to do so I could probably do this with a fastscript.
Hmm. Actually why not use a selector instead of the dispatcher and use the numeric 1,2,3,4,5...etc...as constants and push those to the NUM input?
-S
Glad to hear you are getting there.
So couldn't you use a fast script dispatch to numeric? I am a little confused why you say you must use the recall instead of the NUM?
I actually think I've done this before or could script it up for you. If you would like me to do so I could probably do this with a fastscript.
Hmm. Actually why not use a selector instead of the dispatcher and use the numeric 1,2,3,4,5...etc...as constants and push those to the NUM input?
-S
"Every act of creation is first an act of destruction." -Picasso
Num input needs to change value to load a preset, right? If the last selected preset in a patch is say preset 0, then that patch is deactivated and when reactivated again, preset 0 may need to be re-loaded in order to send updated MIDI data to connected gear, but it does not work, unless triggered via the recall inlets which can recall the same preset repeatedly. Otherwise, the num input works fine for selecting presets within a patch that has not been deactivated. 0-15 no prob, reloading a currently loaded preset is the problem.
Or am I maybe looking at this the wrong way?
Or am I maybe looking at this the wrong way?
Who is online
Users browsing this forum: No registered users and 22 guests