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

**zestoi** · 03-24-2012, 06:56 AM

you finding the delay is just with the slicer functions or beatjumps from within midimasher? i.e: you're still using midimasher for any multi pages or gone back to native traktor mapping?

led feedback on the launchpad is sloooow and i suspect that's where the issue is. looks like it won't take much code to create a new thread for each output anyway so then the main processing loop is never held up by any device. i probably should have thought of doing this from the getgo tbh.

**zestoi** · 03-24-2012, 07:13 AM

Originally Posted by drmore

Spent some more time testing this morning. There is defo a delay. After the first slice you start to miss a millisecond of the sound.

ah... missed that u said that before. so the first slice works ok - but not the others. that makes sense... since we have to add a 1ms delay in between the "jump to active cue" and the beatjump. not that u would notice something as small as 1ms, but in the meantime the main processing loop is having to update leds on the launchpad that all in all probably means the beajjump gets sent out too late. wouldn't need any of this logic if we could just send out the "jump to active cue" and "beatjump" together and traktor not get confused.

hopefully these new threads will solve the issue - won't have time to code/test that for a few days - but will be the first thing i'll do next in midimasher.

**zestoi** · 03-24-2012, 07:56 AM

another mod i think i'll do (not that it solves this issue directly) is use midi clock to sync the slicer actions now that midimasher decodes midi clock. it should provide more accurate control than the beat phase monitor and i can then probably remove that from the tsi which might have some effect overall - as there'll be less midi spewing into midimasher all the time. will have to see...

**derschaich** · 03-26-2012, 03:01 AM

gave MM a go this morning after being frustated by GlovePIE for the last couple of days.

tried the learn.exe, and everything went well except for me not being able to quit (same with hidlearn.exe)

i tried typing:
q
Quit
quit
QUIT
exit

nothing helped.

any idea what i am doing wrong?

WIN 7 here

**drmore** · 03-26-2012, 04:20 AM

I was going to sugest using the midi clock to time the jumps.

The way it looks/work in my head is as follows

A button sets drops a loop in traktor.

Same button starts Midimasher counting using midi clock for sync

Midimasher sets up a virtual grid of all the slices

When a grid button is pressed Midimasher crunches the numbers and spits out the correct size beat jump for Tracktor

Midimasher then issues a 1 beat backwards jump in time with midi clock while the button is held to create the 1 beat slice.

Midimasher continues its original count in the background.

When the grid button is released a beat jump is issued to get the play head back to the position in loop that it would of been if you had not pressed a slice button.

I have no idea if thats even posible but the idea is to issue as little sequential commands to Traktor as posible. Im also assuming c++ can process such a small sequence of events way quicker than 1ms delay required to issue a sequence to traktor.

**zestoi** · 03-26-2012, 05:10 AM

Originally Posted by derschaich

gave MM a go this morning after being frustated by GlovePIE for the last couple of days.

tried the learn.exe, and everything went well except for me not being able to quit (same with hidlearn.exe)

it seems i screwed up with some mods recently... fixed and new versions built: mm.djism.com/downloads

a few changes internally on some unfinished mods since my last release but hopefully nothing that will affect anything. what controller you trying to learn? i'm always keen to add new device config files to my releases ofc

**zestoi** · 03-26-2012, 05:28 AM

Originally Posted by drmore

I was going to sugest using the midi clock to time the jumps.

yep, it should be better as it won't be "after the fact", i.e: we know when to send a message to traktor instead of waiting for the beatphase (which means we are already too late ofc)

The way it looks/work in my head is as follows

A button sets drops a loop in traktor.

i've tried setting an actual loop in traktor, it's how i really wanted to do it, but the issue was sometimes the beatjump jumping outside of the loop and then it's game over... should work fine now that it sends a "jump to active" cue before any beatjumps tho.

When a grid button is pressed Midimasher crunches the numbers and spits out the correct size beat jump for Tracktor

this is how i first tried to do it but it was never very reliable. it's now basically using the method described on the djtt blog a while back which is to first jump to a cuepoint and then issues beatjumps. this means even if it messes up once when u press again the mess doesn't get any worse as we jump back to the active cue again before doing anything else.

Midimasher then issues a 1 beat backwards jump in time with midi clock while the button is held to create the 1 beat slice.

ah yep... for when you're holding down a pad, as opposed to just pressing a bunch. it sounds quite behind the beat atm when u hold down a pad. hopefully this can be fixed by using midi clock instead of the beatphase.

Midimasher continues its original count in the background.

When the grid button is released a beat jump is issued to get the play head back to the position in loop that it would of been if you had not pressed a slice button.

this would be very cool... i did have an implementation of this in my original version and should put that back in. even if not holding down a pad, but just pressing, it would be good for it to jump back to where it would have been after that beat has finished.

I have no idea if thats even posible but the idea is to issue as little sequential commands to Traktor as posible. Im also assuming c++ can process such a small sequence of events way quicker than 1ms delay required to issue a sequence to traktor.

the c/c++/lua code is quick enough i think, the biggest issue seems to be having to send multiple commands to traktor. nothing takes anything close to a full millisecond. i had timed one of my functions for setting up an effects unit traktor.fx_control(), that took around 0.4ms if it had to send out around 10 (i think) commands to traktor. even that tho will be reduced in my next version which will mean the main processing thread doesn't have to wait for any midi ports when sending out data.

mm keeps track of the current beat and knows what beat u want to jump to ofc, question is how to get there... if you are on beat 4 and pressed the pad for beat 2 my first attempt at a slicer would issue a jump -2 whereas this current one issues a cuejump and a beatjump +2. it's a lot more reliable but does mean an extra command+delay.

i'm keen to work on this slicer tho if anyone actually wants to use it... i had given up on it before as no one seemed all that interested and i'd been looking at other things

would be cool to know exactly what/how the vci400 implements the slicer... i haven't even seen a demo of that yet

**MiL0** · 03-26-2012, 08:41 AM

has anyone made a video of MM in action yet? keen to see what it can achieve

**derschaich** · 03-26-2012, 10:05 AM

works a charm now!

have a DIY midifighter clone here.

but want to define my own mapping, including slicer-like functions.

how can i access the midi-clock from traktor in MM?

**zestoi** · 03-26-2012, 12:45 PM

Originally Posted by MiL0

has anyone made a video of MM in action yet? keen to see what it can achieve

i had thought even a simple video showing multiple page switching with led recall and the slicer on a launchpad would be worth doing, also showing the virtual faders. i remember seeing a video with multiple pages and faders on a launchpad using midikatapult and that alone made me want to get a copy...