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

**decon** · 12-01-2011, 04:33 PM

Had 3 days left on my Korg nanopad guarantee. I'll be reporting back as soon as I receive a fixed one. I really hope that Korg decides to throw a a nanopad 2 my way instead of repairing the old one.

**zestoi** · 12-01-2011, 05:06 PM

Originally Posted by decon

Had 3 days left on my Korg nanopad guarantee. I'll be reporting back as soon as I receive a fixed one. I really hope that Korg decides to throw a a nanopad 2 my way instead of repairing the old one.

cool

i thought i already had a devices/nanopad.lua file but i don't seem to. would be very quick to create using learn.exe and having one available ofc.

a nanopad2 as replacement would be nice... tho i've heard the pads are better on the mk1?

**zestoi** · 12-01-2011, 08:47 PM

the next version won't be using any sleep's in the main processing loop, i've changed it to use interrupts which seems much better.

also i have a working timer lib now to analyse how long processing takes for different events. so good/bad/ugly here's some stats (in micro seconds, not milli seconds, so in 1,000,000th of a second units)...

this is me moving a pot on my lpd8, all midimasher is doing is reading in the midi, decoding it and checking to see if any user code is registered and not finding any:

Code:

  [timer     ] 20.5311 useconds
  [timer     ] 19.5979 useconds
  [timer     ] 26.5972 useconds
  [timer     ] 21.4644 useconds
  [timer     ] 19.5979 useconds

this is with a capture() call followed by an empty lua function. so it goes into the lua to call it, but it doesn't actually do anything:

Code:

  [timer     ] 49.9281 useconds
  [timer     ] 44.3286 useconds
  [timer     ] 50.8612 useconds
  [timer     ] 52.2611 useconds
  [timer     ] 61.1268 useconds

in this function it captures the event and then sends out a single event to a loopbe port, so it has to additionally go back to the core code, convert the event to a midi message and send it out:

Code:

  [timer     ] 99.3894 useconds
  [timer     ] 146.051 useconds
  [timer     ] 147.918 useconds
  [timer     ] 115.254 useconds
  [timer     ] 100.789 useconds

the same as above but sending out two messages to a loopbe port:

Code:

  [timer     ] 140.452 useconds
  [timer     ] 143.718 useconds
  [timer     ] 269.705 useconds
  [timer     ] 140.918 useconds
  [timer     ] 140.918 useconds

a similar function that calls send_midi_raw() so not needing to convert the event back into raw midi seems to take on average 20us less time.

this last one is a more complicated function in lua that has logic to work out what midi needs to be send to traktor to setup an effects unit which in this case results in sending 3 messages to traktor to change panel mode, select an effect and turn the unit on for deck 'a':

Code:

  [timer     ] 329.898 useconds
  [timer     ] 518.878 useconds
  [timer     ] 587.471 useconds
  [timer     ] 524.944 useconds
  [timer     ] 520.745 useconds

so simpler code that just reads in one midi message, does some simple logic and then sends out one or two messages should take about 1/10th of a millisecond looking at that, which i think for most things should be ok, but can still be optimised quite a bit in the core code.

one issue could well be with moving a fader quickly tho that sends out a whole bunch of messages and 128 sets of 100 micro seconds isn't looking so awesome as then the total time would be more like 1/10th of a second which would be noticeable i reckon... ? i'm wondering if in that case aggregating events together somehow would make sense. not sure... thoughts/ideas?

and just for the record (and so i/anyone can try these examples later) here's the config i used. run via "mm.exe -i -t"

Code:

open_midi_device("lpd8", "lpd8", "LPD8", "LPD8")
open_midi_device("loopbe", "generic", "", "LoopBe Internal MIDI")
open_midi_device("traktor", "traktor", "Traktor to MM", "MM to Traktor");

capture("lpd8", "3,0", ALL, 0, function(d,e,v,p)
    traktor.fx_control{ unit = 1, mode = "single", fx = "Gater", active = 1 }
end)

capture("lpd8", "3,1", ALL, 0, function(d,e,v,p)
end)

capture("lpd8", "3,2", ALL, 0, function(d,e,v,p)
    send("loopbe", "CC004", ON)
end)

capture("lpd8", "3,3", ALL, 0, function(d,e,v,p)
    send("loopbe", "CC004", ON)
    send("loopbe", "CC004", OFF)
end)

pipe("lpd8", "fader2", 0, "traktor", "volume_fader_a")

edit: the issue of total time taken to process all 128 midi messages from 0 to 127 for a fader movement, even when slamming it, might not be as much of a big deal as i thought as it will take a finite time to move it anyway, so just depends how much it is lagging behind the current midi message.

**zestoi** · 12-01-2011, 09:28 PM

anyone have any info/thoughts on midi latency?

i just read this article on the blog from 2008: http://www.djtechtools.com/2008/07/0...ew-with-a-pro/

in that post the authour of bomes says that bomes adds:

below 200 microseconds (or below 0.2ms)

so midimasher probably isn't doing so badly already. considering that from those stats i posted a lua function containing some simple logic which results in sending out 2 midi messages from a single input message should take about 0.2ms.

**escapemcp** · 12-02-2011, 10:37 AM

Sorry, have been offline for last few days. With the latency thing, I think I noticed it when pressing play/cue. Will check tonight. I think that the volumes also felt laggy (couldn't be certain, but they just didn't seem to be as tight when using MM).

About the faders: On my midi controller, it does not send out 127 values when slamming (or even quickly moving) faders. This is because the hardware in the controller is only taking a reading of the fader every, say 1ms, so slamming the fader, which may take, say, 20ms, will only send out 20 values (1 for each ms). I would expect this to be the same on all controllers - I cannot see a need to update the controller position more often than 1ms, or it would just flood the midi bus.

I think that the 200us figure is a good one to go by. That way people will not notice if mm is running or not. Normally a good mac/PC has about 5ms latency, so mm would be adding only 4% extra time to the signal, which is perfectly acceptable. Those 500us times that are being edged toward are ok, but if you could get them running faster, then that would be good. Some controls that are doing several things may not matter that they take longer to execute - e.g. your 500us 'setting up FX' macro wouldn't really matter if it took even a second, as it isn't interacting with the audio - like loading a track to the deck - a 1 second load time is easy workable-with.

Um.. what else, oh yeah, will get a midiox dump of my pitch fader tonight. Had a quick read about that 14-bit stuff I was on about last time. It's called 'running mode/status'.

This running status mode prevents the device from repeating continuously the midi status mode header (note-on, pitch bend, control change, ...).
So, it sends the running status mode once (note-on on midi channel 1 for example) then sends the data related to this mode (the note number and the velocity) until a change of status (note-number, velocity, note, velo, note, velo, ...) is received.

Cool, better get back to work! Will send you several midiox data dumps tonight.

**escapemcp** · 12-02-2011, 10:45 AM

Handy guide here: http://home.roadrunner.com/~jgglatt/tech/midispec.htm
& go to bottom on LHS - click on running status (3rd from bottom),
OR just click here: http://home.roadrunner.com/~jgglatt/...dispec/run.htm (but you don't get the LHS 'chapter' thingy-ma-bob on this one).

**zestoi** · 12-02-2011, 12:37 PM

Originally Posted by escapemcp

Sorry, have been offline for last few days. With the latency thing, I think I noticed it when pressing play/cue. Will check tonight. I think that the volumes also felt laggy (couldn't be certain, but they just didn't seem to be as tight when using MM).

sure.... well the 1ms delay that i had in the main event loop really wouldn't have helped with that

will release a new version over the weekend with the new method in. unless so much midi was coming in that it was always having to process something it would have hit that 1ms delay (or at least part of it) most of the time. maybe 1ms isnt such a big deal - but ofc its all aggregated.

About the faders: On my midi controller, it does not send out 127 values when slamming (or even quickly moving) faders. This is because the hardware in the controller is only taking a reading of the fader every, say 1ms, so slamming the fader, which may take, say, 20ms, will only send out 20 values (1 for each ms). I would expect this to be the same on all controllers - I cannot see a need to update the controller position more often than 1ms, or it would just flood the midi bus.

sure, tho oddly my lpd8 seems to send out *every* message almost always no matter how fast you move a pot. all my other controllers work as u describe tho. so long as a high res fader works as u describe too then all is good ofc

I think that the 200us figure is a good one to go by. That way people will not notice if mm is running or not. Normally a good mac/PC has about 5ms latency, so mm would be adding only 4% extra time to the signal, which is perfectly acceptable. Those 500us times that are being edged toward are ok, but if you could get them running faster, then that would be good. Some controls that are doing several things may not matter that they take longer to execute - e.g. your 500us 'setting up FX' macro wouldn't really matter if it took even a second, as it isn't interacting with the audio - like loading a track to the deck - a 1 second load time is easy workable-with.

yep 500us is pushing it... but if it's something you press every now and again then should be fine - it's still a concern regarding mm running in a single thread tho. it used to be multi threaded, i changed that when i had issues in lua code. i might go back and see what i can do about that tho. mutex locking nightmare i suspect.

Um.. what else, oh yeah, will get a midiox dump of my pitch fader tonight. Had a quick read about that 14-bit stuff I was on about last time. It's called 'running mode/status'.

ah yep - i have read about running status, didnt realise that was quite related to 14bit messages too. it's just a method of not having to send so many bytes i guess? a 14bit message could also use the running status tho. i guess what i really need is a dump from my dump.exe
as that will always print out all the incoming bytes that i get from the RtMidi lib - so then i can see what processing it does (or not) to them first.

cheers for the web links

**escapemcp** · 12-05-2011, 12:29 PM

Here's a log from midiox. Started twiddling an endless encoder & then my jog wheel. Then moved pitch fader through it's full range from negative to positive. From playing about with the fader, I think it's got 10-bit resolution (I counted 100-ish messages when moving the fader through 1/10 of it's range (it's got 1/10 markings all along it)).

Yeah, you're right, running status can be used on 7 or 14 bit messages. I also cannot see the start message for running status (not too sure what I am looking for tho'!). I was under impression that 14 bit HAD to use it, but now not so sure.

Thx,

escapemcp

**escapemcp** · 12-05-2011, 12:36 PM

And here's the output from learn.exe. This time moving from +ve to -ve (although I think it chopped off the first few lines, as I didn't have the buffer for the 'dos' window set high enough - let me know if this is a problem and you require a full output. The fader/slider is on channel 2 btw.

Let me know if you need any more info on this.

Thanks again,

escapeMCP

PS Sorry it has taken me a few days to sort this out... been at a free party all weekend.

:eek:

**escapemcp** · 12-05-2011, 12:46 PM

Sorry, I read your message wrong.. you wanted the output from dump.exe, not learn.exe!

Here you go...

pitch-dumpexe is output from your program
pitchdumpcopied.txt is c&p from the dos window.

Think they are the same, but included both just in case.

Note - moved slider from -ve to +ve. Sped up the movement in the last 1/4 of the range (from what would be +4 to +8 on technics).