Is it possible to use Bomes to ‘thin’ midi data on the fly?
As it says above; looks like the VCI/Traktor problems that people are having are due to the Windows midi stack not being able to cope with the amount of controller data being sent through to it by the controller.
With that in mind I’m looking for a solution to this problem and if we can’t beef up the stack maybe we can reduce the data going to it from the controller.
Yup its possible to thin out the data with Bomes, but the midi has to go though the stack before it gets to Bomes anyway - so its not really solving anything
Give it a go though Never know unless you try !
Id go about it by using global variables to track the messages then send only say 3 in 4 messages
I figured that it would all run through the stack but it’s only since recent versions of Traktor that there’s been any problem and apps like midi-ox continue to run happily without hanging, so presumably Traktor copes worse with high amounts of data than other apps.
At the end of the day it’s a stab in the dark but if it works we could finally be coming to the end of the road for this issue.
If you use midi ox and move a rotary or slider slowly, you will see its data value increase slowly. If you move it rapidly, you will see that midi ox skips some values and only catches the relevant ones, which means the VCI is thinning out the data already.
I don’t think this is a stack overflow causes by too much data. My hunch is that its a thread hang caused by traktor waiting for some message to come back that never does.
The controller messages for the jogwheels for a start (I just need them sensitive enough to cue to a track, I don’t scratch or anything), then see how it goes from there.
No messages “come back” with midi - theres no 2 way communication when it comes to sending or receiving messages, messages are simply sent or received - there isn’t any error correction or anything that like that makes sure that a message has indeed got though that would require this kind of two way communication.
Very very little data is actually sent to the VCI and the vast majority of that data could not be thinned at all - maybe if it had line level leds or a phase meters on the device this would be different but it doesn’t.
There may not be any dialog when it comes to midi, but what about the usb driver ? I think its here that the issue lies, as it only affects windows xp / vista and not Mac OS.
As for thinning out the jog wheels, thats a good suggestion.. Unfortunately, that tiny midi map that I posted to crash traktor:-
That’s one of the bigger reasons Stanton uses the DaRouter software. We do a lot of MIDI filtering, including the strange initialization spam from Traktor on startup. We also have logic in our presets that thins out the MIDI feedback output of Traktor so that doubled up messages are ignored.
Thats what i think is the most likely the problem - sadly there isn’t a whole lot we can do about this besides rebuilding the driver from scratch and building drivers is sadly out of my realms of knowledge.
What id be doing is get a very detailed list of all the hardware and drivers that people with the problem are having and make comparisons to see if there is something that the systems that are having the problems have in common.
Oh well, let us know what support say when they contact you back.
Nemonic; are there any presets for filtering and/or knowledge about Traktors midi out you can share with us? The init spam one would be good for a start.
He is talking about the spam of midi messages that Traktor spits out when it starts up - the VCI-100 isn’t crashing when you start Traktor so i doubt this is the issue.
Given that this is a possible ‘buffer overflow’ type of problem that fills up over time would it not be a good idea to try to get rid of any extraneous midi out messages?