"Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain)

[zestoi]

Oh, and gave the PC a night to mull it over, and my channel fader works now Yeah, I know that I called it fader - going through the lua later to add A_ before everything! - Then copy & paste and find & replace to map to deck B.

cool. the standard that i've been following is to append the deck/sample deck/fx unit to the end, so like "volume_fader_a" etc

also i've been thinking that coming up with a more standard naming convention between controllers makes a lot of sense, since then most of most mappings will just work on any controller. if it has a volume fader then that part of the mapping will work, if it doesn't then just that bit of functionality won't.

so i'm going to go thru all the devices i have so far in devices/* and rename all the controls to match as close to the devices/traktor.lua file as possible

won't always make sense ofc - but will do for any standard dj type control.

grid controllers are already 100% standardised. the pads get named like "2,3" which means the pad at row 2, column 3.

i'm open to changing the names in the traktor.lua file too tho first if u think we can come up with better names, tho i'd have to go thru all the existing code that uses them. i still think that appending the deck name etc makes the most sense tho probably.

[escapemcp]

FYI: Just trying to get my lua for all functions on my controller, but your learn.exe doesn't seem to support double figures for interface (mine is on 10). I type in 10 in the "choose a device:" section, and it just closes the app. Same with 11 & 12. Ok for 1-9

[escapemcp]

FYI: Just trying to get my lua for all functions on my controller, but your learn.exe doesn't seem to support double figures for interface (mine is on 10). I type in 10 in the "choose a device:" section, and it just closes the app. Same with 11 & 12. Ok for 1-9

Oops... my bad... had mm open in another window! Ignore this! (no delete post on forum!)

[zestoi]

FYI: Just trying to get my lua for all functions on my controller, but your learn.exe doesn't seem to support double figures for interface (mine is on 10). I type in 10 in the "choose a device:" section, and it just closes the app. Same with 11 & 12. Ok for 1-9

pretty odd, can u run it from a command prompt just to check it's not spewing out any error message before it dies? works here ok:

$ ./learn.exe 
1: LoopBe Internal MIDI
2: MM to Traktor
3: Traktor to MM
4: MidiFighter1 Input
5: MidiFighter1 Output
6: MidiFighter2 Input
7: MidiFighter2 Output
8: MidiFighter3 Input
9: MidiFighter3 Output
10: MM to Ableton
11: Ableton to MM
12: DJM_101

choose a device: 12
enter the device type (will create devices/TYPE.lua): tmptmp
writing to [devices/tmptmp.lua]
Enter the number of grid controller rows (0 for none): 0

Press/activate a control and enter the name followed by enter (q to quit)
channel=1 type=cc value=65
channel=1 type=cc value=66
channel=1 type=note value=34
channel=1 type=note value=33

i'll have a look at the code

[zestoi]

Oops... my bad... had mm open in another window! Ignore this! (no delete post on forum!)

ah cool tho it really should output a message rather than just dying like that - and wait for a keypress before quitting.

if u edit a post i noticed a delete option there the other day - new

edit: just editted the code to display an error if it hits that issue. cheers for that - i'm sure others will hit the same issue too.

[escapemcp]

pretty odd, can u run it from a command prompt just to check it's not spewing out any error message before it dies? works here ok:

i'll have a look at the code

Naah, don't bother - check my 2nd message... i had the midiport already open as I had mm running!

[escapemcp]

Naah, don't bother - check my 2nd message... i had the midiport already open as I had mm running!

Whoops... maybe I should check your 2nd message also!!!

Anyways, thought I had already posted this, but seem not to have. So

1) 14 bit midi in MM? Trying to learn.exe my pitch fader, but every movement learn thinks that a different control is being activated - I guess that the MSB (or is it LSB) keeps changing for the 14 bit control, and MM keeps thinking that it is a different control.
BTW/FYI: not 100% on this, but I think 14 bit midi sends out a 'start' message, and then loads of 14 bit controls that aren't really signed - the midi protocol just knows that it is just that 14-bit control that is being altered. It doesn't need to know the control's hex number, as until something else moves, it just keeps spewing out 14-bit values. If something else gets moved/pressed, the flow is interupted. Move the 14-bit slider again, and it re-sends the 'start' signal, and then the 14-bit stream starts again. The 14 bits use the hex number that is normally used to identify the control, and as such, I think learn is seeing them as loads of different controls moving. Make sense? - I can send you a midiox/learn/mm output stream for you to see this when I get home.
2) Seem to be running quite a lag (latency).. any tips for improving this??
3) Can you do flashing led's - I saw something about them on the launchpad, but that has flashing led's in the firmware.

Many thanks!

escapemcp

[escapemcp]

edit: just editted the code to display an error if it hits that issue. cheers for that - i'm sure others will hit the same issue too.

Yeah, just me being dumb.. I *may* be the first, but hopefully not last!

[zestoi]

Whoops... maybe I should check your 2nd message also!!!

Anyways, thought I had already posted this, but seem not to have. So

1) 14 bit midi in MM? Trying to learn.exe my pitch fader, but every movement learn thinks that a different control is being activated - I guess that the MSB (or is it LSB) keeps changing for the 14 bit control, and MM keeps thinking that it is a different control.

i need to implement this. a dump or something from a pitch fader moving would be handy - tho my nanokey does have pitch bend buttons that i presume should match what your pitch fader is sending out?

BTW/FYI: not 100% on this, but I think 14 bit midi sends out a 'start' message, and then loads of 14 bit controls that aren't really signed - the midi protocol just knows that it is just that 14-bit control that is being altered. It doesn't need to know the control's hex number, as until something else moves, it just keeps spewing out 14-bit values. If something else gets moved/pressed, the flow is interupted. Move the 14-bit slider again, and it re-sends the 'start' signal, and then the 14-bit stream starts again. The 14 bits use the hex number that is normally used to identify the control, and as such, I think learn is seeing them as loads of different controls moving. Make sense? - I can send you a midiox/learn/mm output stream for you to see this when I get home.

awesome info thanks i hadn't spent much time looking into it so far. i read some code for decoding a pitch bend message, but don't really even remember that

a midiox output stream would be really useful. i think it's better to rely on standard tools for stuff like this - rather than dump.exe etc.

2) Seem to be running quite a lag (latency).. any tips for improving this??

it doesn't seem to be on my laptop but i've always been expecting it to rear it's ugly head. there's quite a few areas i can look at and tbh was always expecting to have to optimise it more. what i should probably do is set up some experiment where i somehow use some external app to log+timestamp a midi message from a controller, pass it thru midimasher and back to (the same?) app and log/timestamp again and see how long midimasher is spending processing it.

what type of functions/midi controls are u seeing the most latency in etc? or it is worse when traktor is playing a deck and spewing out all the beatphase/output levels etc?

3) Can you do flashing led's - I saw something about them on the launchpad, but that has flashing led's in the firmware.

it is in the firmware but i sync it to the beatphase in traktor. the launchpad has a double buffering system and u can flip between the buffers just with a simple CC.

it could be changed slightly so u could register any device/event/onval/offval and so a central single function would send those d/e/v sets each time they needed to flash. the launchpad would only need to register one set for the whole device, but for other devices u could register each button/led.

back to the latency issue... i noticed a bug earlier today in the device pass thru code, but when u use set_device_route() midi data is pretty much just coming into midimasher and being sent out right away. the only processing mm will do is decode the raw midi into an event name to see if there's any other action registered for it. i'll start there and see how long that processing takes and then expand to more complicated test cases.

i do know that if i use pipe() to send an lpd8 pad to the cue button in traktor i can drum away on that pad and it doesn't feel laggy at all.

also currently it all runs in a single thread (apart from RtMidi listening to the midi ports) and i'm hoping to keep it like that - else it might be a bit of a nightmare with different threads trying to access lua. there's plenty of things to try tho anyway - i just need to isolate where any lagginess is.

ofc the more complex the lua code becomes the more chance of the latency increasing is, but most of the actual callback functions that get registered are quite simple, and most logic is only run at setup time.

[zestoi]

edit: these stats are wrong... the timer lib i was using wasn't working. guess i was too tired and/or stupid to realise at the time that it would be impossible for the processing code to take less than 1 micro second... ah well... a follow up post with a correct set of stats is on the next page of this thread...

2) Seem to be running quite a lag (latency).. any tips for improving this??

i just realised one dumb thing... it runs in a tight loop, checking each open midi port to see if there's any messages to process, processing them all then checking the next one and then sleeps for 1 millisec before rechecking them all. that's a bit stupid... i just reduced that sleep to 1 microsec and there's no difference in cpu usage, so i'll leave it at that. that could well have made a difference ofc.

also as a quick test on a standard capture()+send() type function i changed the core of the midi processing loop to this:

...deleted incorrect stats...

edit: another thing i've been thinking for a while that mm needs anyway is the ability to send out a message a certain amount of time in the future which will fix 2 issues... 1) i can then remove all the sleeps() from the slicer and other code which atm stop anything else from being processed and 2) i can then implement auto-repeats