"Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain)
Home :: Post and find Controller Mappings :: "Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain)Reply
"Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain) Posted on: 16.06.2011 by Arcelia Siebeneck IntroductionJust wanted to start a discussion thread regarding the shortcomings of mapping midi controllers using Traktors default mapping options. And by that, I don't just mean the annoying non-resizeable window, lack of serious copy/paste/clipboard functions and the recent inablity to directly edit the xml mapping files with a text editor. What I'm really talking about is the limitations of the default Traktor midi mapping window to achieve more powerful, dynamic and complex mappings... mappings that go well beyond what Traktor is normally capable of. So what do I mean by this? Well if we look at the djtt firmwares for the vci-100 and midifighter as an example you can see that Traktor is capable of some amazing things. Superfaders, fx triggers, etc are made possible by combining various midi commands into one control which are then executed in a certain way. The only realistic way to achieve this is by re-writing the firmware on a midi controller at a hardware level. Yes, it's true that some of these effects can be done via a plain old Traktor mapping - but it gets very complicated and isn't as full featured. The obvious disadvantage with using modified firmwares is that only a few people have the skill and know how to write them. Also, the firmware will only work on specific midi hardware. What I propose is some sort of intermediary midi software that sits between Traktor and your hardware. A utility that allows full access to every midi command available in Traktor with the aim of achieving the kind of custom mappings only normally available via custom firmwares. The solution This isn't an easy undertaking so I'm hoping that the clever people on DJTT can get involved in the discussion and hopeful development of such a tool. In the absence of any sort of Traktor public SDK, here's how it could be achieved: Traktor - A mapping is created that maps literally every control to a different midi CC. All these controls are set to receive midi from a virtual midi device such as LoopBe. The midi commands are then routed via LoopBe from the mapping utility which could be created via one of the following programs: Synthmaker/SynthEdit - Both Windows programs which allow the creation of midi plugins/vst's. Usually the plugins are effects/synths for DAW's such as Cubase, Ableton Live, etc however they can also export standalone Windows executables with midi in/out functionality. Reaktor - Same as Synthmaker/Synthedit but probably more powerful and there may be more people on here that know how to use Reaktor properly. Trouble is, I don't believe there's a plugin export function so you'd need to run Reaktor in the background.. not ideal. Emulator - the new version of Emulator allows you to design your own touchscreen interface GUI and map midi commands to each button/control. GlovePie - probably quite a good option as their is decent scripting and midi support. Disadvantage is that it's a bit unstable in my experience. Autohotkey - my area of expertise (lol) but not really designed for such a job... I might use it to knock up a prototype though. VisualStudio - probably the most viable and professional option... a decent programming language that is stable, fast and powerful. So what would the custom midi mapping software look like? and what kind of things could it do? This is obviously up for discussion, but the first and most important function should be a wholesale replacement of the standard Traktor mapping window. The tool should allow easy duplicating, adding, deleting, etc of all the various Traktor controls and the ability to setup modifiers etc. Once this is implemented, we can look at ways to achieve complex midi mappings based on rules, scripts, etc. This might enable functions such as superfaders and other midifighter features but also: - complex ADSR/LFO based controls - sequenced/pre-scripted midi control - Serato-style continuous play in the background after beatjuggling has ended - GUI editor for custom diy controllers (edit the midi controls in a more visual manner) - simpler midi LED mappings - stuff I haven't even thought of...! How you can help Feel free to contribute to this thread... let me know if this is something that you would find useful and what you would do differently. The suggestions I've listed above are just ideas and I'm keen to get something developed that will be useful for everyone so get posting | |
| Chasidy Heckenbach 16.10.2011 | big update... especially the extra launchpad support stuff... * http://djism.com/mm/midimasher-20111016.zip launchpad support: * modded launchpad.init(), faster test of leds, enables flashing leds * launchpad flashing leds now work, just select a flashing color like lp_flash_hi_red instead of lp_hi_red * new func launchpad.traktor_sync() which will sync the flashing leds to traktor beats * new launchpad.set_page() that ensures flashing leds still work as expected after page switching and makes led updates 'appear' instant using the double buffering of the launchpad * new launchpad.set_contrast() function * new "heartbeat" event from traktor that uses either of deck A or deck B beat phase and will flip if the active one stops * play+kill toggles now flash in time to traktor the launchpad.lua config * add_control() can now has a new 3 arg form ** e.g: add_control("play_a", 1, "C#-2") or add_control("play_a", 1, "CC001") * add_grid_control() has a similar 4 arg form as well as the old 5 arg one ** e.g: add_grid_control(0, 2, 1, "C#2") * virtual yfaders now have 3 modes: ** normal: just a fader with feedback from traktor etc (+option to set leds without midi feedback) ** vumeter: pass in extra device/event args at the end, like traktor/monitor_deck_afl_mono_a etc ** shifted vumeter: switch to vumeter mode when a shift (or toggle) is set, pass the name of a shift variable as the final arg (this is how i have it setup in config/launchpad.lua at the moment, the new toggle is top/right by the mixer button) * bug fix: where feedback from traktor wasn't only sent to the required page on the lp * bug fix: virtual faders not always showing correct value * bug fix: virtual_midifighter() function now works it turns out the instability issues i was blaming on the lp before was due to me using traktor with the internal soundcard in my laptop, where i usually use a usb attached device. odd tho? edit: and a devices/mixtrack.lua file |
| Arcelia Siebeneck 16.10.2011 | glad this thread has taken off I'm concentrating on an actual diy build at the moment so the mapping stuff will come later.... still interesting following the progress in this thread though - keep it up |
| Nana Mohs 15.10.2011 | I'm having trouble with midi_monome so for now I'm just mlrizing ableton. Working fine so far |
| Chasidy Heckenbach 15.10.2011 |
Originally Posted by Onimode
Maaaaaaaybe.
http://pastebin.com/gtEjj9H5 i do have a newer version that i'm itching to release, also has the new version of add_control(), i'm still trying to check what code might have been causing the lockups with the launchpad. worst case scenario i'll release it later today with the new page switch and flashing led related code commented out for now. |
| Kayce Mesia 15.10.2011 |
Originally Posted by zestoi
But what you've put here looks different than your latest release. :P
Originally Posted by zestoi
http://pastebin.com/gtEjj9H5 |
| Chasidy Heckenbach 15.10.2011 |
Originally Posted by Onimode
|
| Chasidy Heckenbach 15.10.2011 |
Originally Posted by Onimode
Speaking of changed to the API and whatnot, is there a way currently to have a "shift" button as a toggle-able button? button_shift() makes a momentary button only. I'm currently mapping my MixTrack out of fun, but seeking full original functionality.
Code:
hold_modifier("lp", "arm", 0, lp_hi_yellow, lp_lo_red, "lp_shift")
Code:
toggle_modifier("lp", "solo", 0, lp_hi_yellow, lp_lo_red, "lp_toggle")
button_shift() was probably a bad name - i just wanted a quick and dirty function that i could give two different events to send to traktor depending on the state of a shift button. feel free to come up with a new name for it also, if u look in lib/base.lua you'll see other functions you can use for routing data in different ways: Code:
-- Function Toggled Target Local Ignore Src Routing -- Led Set Off Events -- -- pipe() no device no no A ---> B -- join() no device no no A <--> B -- -- trigger() no device yes yes A ---> B -- button() no device yes no A <--> B -- button_shift() no device yes no A ---> B -- toggle() yes device yes no A <--> B -- -- pipe_modifier() no var yes no A ---> V -- hold_modifier() no var yes no A <--> V -- toggle_modifier() yes var yes no A <--> V |
| Kayce Mesia 15.10.2011 |
Originally Posted by muffintop
Originally Posted by zestoi
|
| Chasidy Heckenbach 14.10.2011 |
Originally Posted by muffintop
|
| Nana Mohs 14.10.2011 | I'm actually just using the automap screen shot from omnimode to do the monome_midi device. I'm sure I'll do it the other way when it's made available. Turns out. The old method isn't too hard with a reference handy. |
| Chasidy Heckenbach 14.10.2011 |
Originally Posted by muffintop
so you'll be able to call add_control() with either 3 or 4 args, which will use the old and new methods. as you can probably guess... add_control() was one of the very very first bits of code i wrote, originally in the C++ core too until i got lua running. |
| Nana Mohs 14.10.2011 |
Originally Posted by Onimode
Should have some fun stuff to play with very soon. |
| Chasidy Heckenbach 14.10.2011 |
Originally Posted by Onimode
so it starts at C-2 then i was just believeing if i was about to go the wrong way or not lol. at the moment it uses "D#2" for "E flat 2" which i guess i'll have to stick to as the flat character isn't a normal/easy one? |
| Kayce Mesia 14.10.2011 | Took a screenshot from Automap for ya. |
| Chasidy Heckenbach 14.10.2011 |
Originally Posted by Onimode
btw if you use a config file with only this in: Code:
open_midi_device("lp", "", "Launchpad", "Launchpad")
Code:
* [lp ] b0 68 7f [] type=cc name=CC104 value=127 * [lp ] b0 68 00 [] type=cc name=CC104 value=0 * [lp ] b0 69 7f [] type=cc name=CC105 value=127 * [lp ] b0 69 00 [] type=cc name=CC105 value=0 * [lp ] 90 00 7f [] type=note-on name=C-1 value=127 * [lp ] 90 00 00 [] type=note-on name=C-1 value=0 * [lp ] 90 01 7f [] type=note-on name=C#-1 value=127 * [lp ] 90 01 00 [] type=note-on name=C#-1 value=0 |
| Chasidy Heckenbach 14.10.2011 |
Originally Posted by muffintop
also btw midimasher does understand stuff like "C#2" etc in send() but not in add_control() at the moment, but i can add that in. so i could create an alternative version that instead of taking something like this: Code:
add_control("deck_a", 1, "note", 0x71)
Code:
add_control("deck_a", 1, "C#1")
add_control("deck_b", 1, "CC002")
add_control("deck_c", 1, "PC3")
and then midimasher would map it back internally. midimashers decode/encode tho is in line with traktors, which i believe is one ocatave out from everyone else, which is why i don't use it too much. there again i could always switch it to the more normal mode as stuff like "C#2" isn't really being used in any code at the moment at all. |
| Chasidy Heckenbach 14.10.2011 |
Originally Posted by muffintop
Code:
add_control("btn1", 1, "note", 44)
btw just finishing up testing a new version that enables seemless page switches and flashing colors that can also be synched to traktor if wanted. all you need to do is use one of the colors with 'flash' in their names and then they'll automatically flash in sync with the traktors beat finally got my head round the launchpad double buffering mechanism. plus a couple of bug fixes... |
| Nana Mohs 13.10.2011 |
Originally Posted by Onimode
Also, there is either something seriously jacked with the Midifighter in normal mode or I'm doing something wrong. Can't seem to find any order, but all of the buttons seem to be mixed up. |
| Kayce Mesia 13.10.2011 |
Originally Posted by muffintop
|
| Nana Mohs 13.10.2011 | Does the midi note have to be cc or can it be actual note value? I need it to be real notes to hack the mlrv page to work. I believe it's doable though |
| Chasidy Heckenbach 13.10.2011 | @muffintop you don't *have* to create a devices/name.lua file for the app if u don't want to - tho it probably makes sense in the long run. it just means you can't use stuff like send("myapp", "some-action", 127) but you can still use send_midi() or send_midi_raw() send_midi(device, channel, type, value, velocity) e.g: send_midi("myapp", 1, MIDI_NOTE_ON, 64, 127) 'type' can be any of MIDI_NOTE_ON, MIDI_NOTE_OFF, MIDI_CC or MIDI_PCif you want to send anything else then u have to use send_midi_raw() that just takes the device name and list of raw midi data (can be any length) e.g: send_midi_raw("scs3d", 240, 0, 1, 96, 1, 0, 247) numbers can be in decimal or hex like 0x20 using the devices/ files means we can keep all the nasty actual midi implementation out of other user files tho... |
| Chasidy Heckenbach 13.10.2011 |
Originally Posted by muffintop
|
| Nana Mohs 13.10.2011 | Mlrv2 and up can be mapped to any grid controller from what I understand. It's a very cool max patch. Also it can be synced to midi clock, so I'll probably use it instead of sample decks |
| Chasidy Heckenbach 13.10.2011 |
Originally Posted by muffintop
you can create any new lua file in the config folder which will then get shown when in the list mm.exe -i is run. if u mean a new device file - like the traktor one - then u can use the learn.exe to map most/all of the controls for a new device. the traktor one is a bit different from the rest as i had no choice but to manually edit that with whatever values i put in the traktor.tsi file. mapping physical devices is simpler tho. the point of any devices/ file tho is to say what control maps to what midi data and then add in any extra functions that might be useful for that device - tho i'm believeing that kind of stuff is probably better in a lib/ file - not sure - and not all that important at this stage anyway. fire away with any more questions when u have them edit: ah... that's an app? then yep, you'll need to manually create a devices/mlrv.lua file like i have for traktor. and add a new open_midi_device() call to it in your config file. |
| Chasidy Heckenbach 13.10.2011 |
Originally Posted by muffintop
i'd say keep the same lua filename or rename - up to you. just be cool to have a decent launchpad mapping i could always create a file called launchpad_twitch.lua or something for a "twitch" like mapping. btw i've just enabled flashing leds on my launchpad. might be useful for when samples are playing or something. by default it flashes at it's own speed but i'll probably try to tie it into the beatphase from traktor. basically you just use those *_flash colors, that don't do anything in previous versions. there'll also be flashing versions of all shades available. i just hadn't looked into the lp's buffering and the way of flashing leds before now. |
| Nana Mohs 13.10.2011 | I'm kind of believeing about putting the mixer page on page 2 and turning page 4 into mlrv control. do I need to make a new .lua file for that in the config folder? Any help here would be great Mainly just with starting the new .lua If it's anything like the traktor.lua (which I'm assuming it is) I can probably figure it out I haven't really looked at the traktor one too much and won't be able to for a couple hours. Iwill probably have a more specific question then... Just throwing it out there for now |
| Chasidy Heckenbach 13.10.2011 |
Originally Posted by muffintop
Code:
add_control("send_monitor_state", 6, "cc", 1);
add_control("show_slider_values", 6, "cc", 12);
add_control("snap_mode", 6, "cc", 2);
add_control("quant_on", 6, "cc", 3);
add_control("fx_panel_mode_unit1_group", 6, "cc", 4);
add_control("fx_panel_mode_unit1_single", 6, "cc", 5);
add_control("fx_panel_mode_unit2_group", 6, "cc", 6);
add_control("fx_panel_mode_unit2_single", 6, "cc", 7);
add_control("fx_panel_mode_unit3_group", 6, "cc", 8);
add_control("fx_panel_mode_unit3_single", 6, "cc", 9);
add_control("fx_panel_mode_unit4_group", 6, "cc", 10);
add_control("fx_panel_mode_unit4_single", 6, "cc", 11);
let me know if u find any bugs or need some more lua putting in the main libs etc... |
| Nana Mohs 13.10.2011 | I am believeing about putting sample deck controls on page 3 (if I add sample decks to the LP at all). The nanokontrol is just so perfect for sample decks/loop recorder. I had to change up the tsi already to make the loop buttons work how I wanted. Changed all of the loop size commands to loop size + set. |
| Chasidy Heckenbach 13.10.2011 |
Originally Posted by muffintop
i did add a few more things to the latest version too, which i forgot to mention. just some controls for changing the effects units modes and stuff like "send monitor state" that i don't understand as i had assumed it would send back the status of all controls after it received that? i.e: to sync up the leds for eq+levels on the launchpad initially... don't forget i'll be releasing a version with "twitch" like areas at the bottom of page 1 that could be used for loops+hotcues+mashing etc ala "itch" there again thats the only multi page support that the twitch has i guess, so that might be over kill on a launchpad config with multiple pages? i'll finish and release the code anyway tho, in case it's useful for people in the future. it basically just allows the creation of any size grid (or on any buttons etc for that matter) on any page, with a set of page select toggles above (or anywhere) like the top right we have in this launchpad config. i'm really chuffed you're using midimasher to create your config - can't wait to see and try it |
| Chasidy Heckenbach 13.10.2011 |
Originally Posted by Onimode
the launchpad does have some features for refreshing all leds faster, but turns out u need to refresh *all* of them, so only makes sense when more than half need changing and it already only sends out updates for leds that actually need changing, so not sure whether it's worth using the other method. tried to send the sysex for enabling flashing of leds but *all* leds started flashing so i suspect i need to update the lp color variables first * new apc40 support added * previous fix rolled in * now issues a device reset to the launchpad * virtual faders now move via midi, from traktor etc * http://djism.com/mm/midimasher-20111013.zip |
| Nana Mohs 13.10.2011 | @zestoi and anyone interested/using a launchpad with midimasher I'm working on making page 2 take care of loops, plooping, hotcues, moving the top row from page 1 onto page 2 as well. That leaves me with 2 more rows of 4 buttons for each deck left over. Any ideas? Suggestions? Requests? I'll post the changed files as soon as I have them done. |
| Kayce Mesia 13.10.2011 |
Originally Posted by zestoi
Mo' tables = mo' winnin'? |
| Chasidy Heckenbach 13.10.2011 |
Originally Posted by Onimode
wasn't sure what u had decided on the apc40 devices file, something like this? Code:
apc40 = {}
-- clip launch grid LED colors
apc40.clip_off = 0
apc40.clip_green = 1
apc40.clip_red = 3
apc40.clip_yellow = 5
apc40.clip_greenflash = 2
apc40.clip_redflash = 4
apc40.clip_yellowflash = 6
|
| Kayce Mesia 13.10.2011 |
Originally Posted by zestoi
What about rolling back those changes? :P |
| Chasidy Heckenbach 13.10.2011 |
Originally Posted by Onimode
someone has *almost* deciphered the nocturn protocol and i wouldn't mind having a hack at it myself: https://github.com/timoahummel/noctu...master/game.py i bought my scs.3d's instead of the nocturn in the end - to use them in the same way i'd use encoders with multiple layers. and i will probably forget all about ever wanting a nocturn once i get my hands on a K2 in a few months btw i've just fixed led feedback for the virtual faders in midimasher - so they now update when you move the controls in traktor. it used to work until i broke it recently changing some api stuff |
| Kayce Mesia 13.10.2011 |
Originally Posted by zestoi
|
| Chasidy Heckenbach 12.10.2011 |
Originally Posted by Onimode
if u add two more virtual midi ports then you can also connect ableton live in the same way traktor is connected, maybe using some launchpad pages to control ableton and some traktor. even without any interaction between controllers/software you'd still need any u wanted to use with midimasher at one time to be in the same config. you could use separate files tho and include them via lines like i use in lib/startup.lua |
| Kayce Mesia 11.10.2011 |
Originally Posted by zestoi
|
| Chasidy Heckenbach 11.10.2011 |
Originally Posted by muffintop
you can add as many different controllers to a single midimasher config btw. but if u already have a decent tsi for your nanokontrol then no reason to fix something that isn't broken ofc. adding near the top (or anywhere before u try to add controls to it) tho would connect midimasher to your nanokontrol: open_midi_device("nanokontrol", "nanokontrol", "nanoKONTROL", "nanoKONTROL") the devices/nanokontrol.lua file was created using learn.exe from mine and i haven't included a dump of it's config from the korg editor thing - but i don't believe i ever changed anything from the defaults. also i only used the first "scene" in there. |
| Nana Mohs 11.10.2011 | You have freed up my nanokontrol to take care of sample decks and loop recorder. Appreciate it a lot |
<< Back to Post and find Controller MappingsReply