Statistics: Posted by gurulogic — 30 Jan 2015, 07:45
]]>
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
Statistics: Posted by sephult — 30 Jan 2015, 03:55
]]>
Statistics: Posted by gurulogic — 30 Jan 2015, 00:52
]]>
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
Statistics: Posted by sephult — 29 Jan 2015, 16:28
]]>
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..
Statistics: Posted by gurulogic — 29 Jan 2015, 07:09
]]>
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
Statistics: Posted by sephult — 28 Jan 2015, 13:16
]]>
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)
Statistics: Posted by gurulogic — 28 Jan 2015, 09:49
]]>
Are you on the latest version of HH?
Statistics: Posted by shawnb — 27 Jan 2015, 20:14
]]>
]]>
]]>
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
Statistics: Posted by sephult — 26 Jan 2015, 03:20
]]>
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?
Statistics: Posted by gurulogic — 26 Jan 2015, 01:45
]]>
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,
Statistics: Posted by shawnb — 25 Jan 2015, 23:44
]]>
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..?
Statistics: Posted by gurulogic — 25 Jan 2015, 23:20
]]>