"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 11.02.2012 | this all seems a bit too easy... but here's output from midimasher running on osx with a midifighter classic and gamepad for input. i used the builtin iac midi driver which prepends "IAC Driver " to the start of each port name, so after first looking for the full name midimasher strips off that and looks again when opening ports. similar to having to strip off stuff like "1- " on windows when u connect a controller to different usb ports. only thing now i'm on macosx is i realise how important usb hubs are when a macbook pro only has 2 Code:
bash-3.2$ ./mm -f debug.lua midimasher: build 20120212 midi: scan devices... midi.in.0: IAC Driver Bus 1 midi.in.1: Midi Fighter Classic midi.in.2: IAC Driver MM to Traktor midi.in.3: IAC Driver Traktor to MM midi.in.4: IAC Driver MidiFighter1 Input midi.in.5: IAC Driver MidiFighter1 Output midi.out.0: IAC Driver Bus 1 midi.out.1: Midi Fighter Classic midi.out.2: IAC Driver MM to Traktor midi.out.3: IAC Driver Traktor to MM midi.out.4: IAC Driver MidiFighter1 Input midi.out.5: IAC Driver MidiFighter1 Output hid: scan devices... hid.0: Apple IR hid.1: Apple Internal Keyboard / Trackpad hid.2: Apple Internal Keyboard / Trackpad hid.3: USB Gamepad hid.4: Apple Mikey HID Driver hid.5: Apple Internal Keyboard / Trackpad hid.6: Apple Internal Keyboard / Trackpad lua: register functions... lua: run embedded lua... loading: lib/startup.lua loading: config/debug.lua traktor: open midi.in.3: Traktor to MM traktor: open midi.out.2: MM to Traktor loading: devices/traktor.lua loading: lib/traktor.lua gp: open hid.3: USB Gamepad loading: devices/gamepad_12btn.lua mf1: open midi.in.4: MidiFighter1 Input mf1: open midi.out.5: MidiFighter1 Output running... <ctrl>-<c> to quit. |
| Chasidy Heckenbach 11.02.2012 | wasn't all that tricky to do, as i hoped. mostly due to developing on cygwin for windows i guess. will probably release in a day or so, was believeing about maybe adding some more controls to my launchpad mapping and then creating a new thread with info on that and download links for mac and windows edit: hid input support in midimasher for mac osx is even better than the windows version. in the windows version i couldn't get blocking i/o to work so it just processes any hid input every 1ms which could be fixable, might be due to me compiling under cygwin. all fine on the osx version so midimasher just processes any input as soon as u use them. i don't believe a 1ms delay is any big deal for gamepad inputs anyway but i do hope to fix that in the windows version too. the windows version still should have less latency than something like glovepie tho in theory. |
| Chasidy Heckenbach 11.02.2012 |
Originally Posted by JimE3
|
| Josephine Flemens 10.02.2012 | I like that idea, more banks are always good. |
| Chasidy Heckenbach 08.02.2012 | i figured i'd use my midi fighter a lot more if it just had more banks... with the 4 buttons in various combos you could have a heap of banks, tho if just using those with adjacent buttons it gives you 10 which is plenty and the 10th one (where u have to hold down all 4) is a bit much anyway... still 9 useful ones then the normal 4 ones could be configured to send the usual 4banks messages direct to traktor (for instant grat etc) leaving the rest (5 or 6) for other stuff... the led's stay lit to tell u which bank you're in so u have decent feedback. not sure i'd ever use as much as 10 but a couple more than the standard 4 seem pretty handy anyway... code will be in the next release if anyone is interested... |
| Chasidy Heckenbach 08.02.2012 | new version 20120208 u can grab from http://midimasher.djism.com/downloads/ * fix to the new delayed message queue code * new hid (input) support * new apps hiddump.exe and hidlearn.exe * included a config gamepad_midifighter_4banks.lua that turns a 12button gamepad into a 4banks midifighter (tho only 2 banks really as it only has 12 buttons ) since the delayed message queuing fully works now u can set up auto-repeat for buttons. i haven't worked out how best to fit it into the existing functions but this is essentially what it will do. this example causes that action to be repeated every 100ms until the button is released: Code:
capture("gp", "0,0", ALL, 0, function(d,e,v,p)
if v > 0 then
print "do something..."
create(d,e,v,p,100)
else
clear(d, e)
end
end)
in theory the hid support should be much more responsive and efficient than using something like glovepie. glovepie processes your entire script approx 20 times a second (so once every 50ms) and performs any actions needed. midimasher doesn't do anything until u actually press a button/fader on your hid controller and then just runs the code needed for that individual control. i fancy the idea of adding some kind of sequencer next... i could really use some kind of real time rhythm recorder where i can add/delete individual beats, select quantize etc. i don't believe that will overlap with whatever NI has planned for 2.5. some kind of clips launching/relaunching might also be cool - so then i can just use some external sample player or something without relying on a full blown ableton live and/or what NI does put in 2.5... i believe maybe it's time for me to finally put together a decent launchpad config and create a new thread for it with images etc will probably wait until i have the mac port done tho. |
| Chasidy Heckenbach 08.02.2012 | for anyone wanting a simple way to try out the instant grat tsi from a cheapo gamepad this little config works fine: Code:
open_hid_device("gp", "gamepad", "USB Gamepad")
open_midi_device("mf1", "generic", "MidiFighter1 Input", "MidiFighter1 Output")
virtual_midifighter_4banks("gp", 0, "mf1", 0, 0)
|
| Chasidy Heckenbach 07.02.2012 | just added hid/gamepad support... only have a 14 button gamepad here to test with but seems to work well. for most purposes a hid device is treated just like a midi controller. quick example that maps my start and select buttons to cue+play in traktor: Code:
open_midi_device("traktor", "traktor", "Traktor to MM", "MM to Traktor")
open_hid_device("gp", "gamepad", "USB Gamepad")
toggle("gp", "start", 0, ON, OFF, "traktor", "play_a")
button("gp", "select", 0, ON, OFF, "traktor", "cue_a")
Code:
--
-- direction buttons act as faders even on digital gamepads
--
add_hid_control("left_right", "fader", 3, 0xff)
add_hid_control("up_down", "fader", 4, 0xff)
--
-- bit masks for the rest of the buttons
--
add_hid_control("select", "button", 6, 0x10)
add_hid_control("start", "button", 6, 0x20)
add_hid_control("button1", "button", 5, 0x10)
add_hid_control("button2", "button", 5, 0x20)
add_hid_control("button3", "button", 5, 0x40)
add_hid_control("button4", "button", 5, 0x80)
--
-- the 4 buttons on the back of a gamepad
--
add_hid_control("left1", "button", 6, 0x01)
add_hid_control("right1", "button", 6, 0x02)
add_hid_control("left2", "button", 6, 0x04)
add_hid_control("right2", "button", 6, 0x08)
|
| Chasidy Heckenbach 03.02.2012 | porting to osx... all going to plan i'll be getting a macbook pro next week or the week after, so then i'll ofc be porting midimasher to osx i'll probably also check+build it on linux while i'm at it, tho i'm not sure anyone would really need a linux version. trickiest bit after that will be building/testing on each platform for each release tho i presume i'll be able to ssh into the macbook from my windows laptop and automate the build at least |
| Chasidy Heckenbach 02.02.2012 | hopefully i haven't broken anything too royally but there's a new version if you want it: http://midimasher.djism.com/downloads/midimasher-20120202.zip i believe there's been some tweaks to the tsi since last time so you'll need to (re)load the tsi from the settings dir this has a completely rewritten core for processing incoming midi messages, that should be faster, more efficient with hopefully less latency. i've tested the launchpad and lpd8 configs - both have twitch style slicers, which now doesn't hold up the processing of other messages when it needs to stack messages for traktor that need a delay in between. install info etc as usual is here and api docs here tho i haven't updated those docs yet with the extra 'delay' param that send()/create() etc can use midi clock stuff is in - it's just not used by anything yet. but i suspect some kind of sequencer will be appearing this weekend... i'm really dying to know what will be in traktor 2.5 tho to really know what would be useful. edit: first update in over 2 months... just took me a while to work out what/how to improve on latency etc |
| Chasidy Heckenbach 02.02.2012 | the calculated bpm (from the midi clock ticks) seems to fluctuate a bit from about 140.6 to 139.7 when i have it set to 140.0 in traktor. be interesting to see how it works anyway once we have some actual sequencer code in this bit of code prints out the current bpm once a second. we need to reset the print_bpm value to OFF else the next ON event won't fire, so we queue up a value of OFF (0) 1 millisecond after the ON (127) one. as well as set() the functions send(), send_midi(), send_midi_raw() and create() all take an optional final parameter which is how many milliseconds in the future to execute it. Code:
capture("_varchange", "print_bpm", ON, 0, function()
print("bpm=" .. get_bpm())
set("print_bpm", ON, 1000)
set("print_bpm", OFF, 1001)
end)
set("print_bpm", ON, 1000)
|
| Chasidy Heckenbach 02.02.2012 |
Originally Posted by muffintop
messages can be queued at fractions of millisecs in the future but they're all checked approx once every millisec. sequencer code needs to be slightly different as we'd want to be able to say something like "send X to ableton on beat Y each time". i guess we're only talking about a 8beat sequence here or 16 or 24 maybe? if it was 16 and u had specified something to trigger on the 1st beat of a 8bar loop - then ofc it would actually have to trigger on beats 1 and 9 of a 16 one. just want to work out how complicated this needs to be so it's flexible enough. it now decodes the midi 'start playing' message which resets the current beat number and the midi 'timing ticks' to work out the current tempo. we get 24 of those ticks per beat which equates to something like 30ms between each 16th note for a tempo around 120bpm so the new sequencer, once we've worked out what it needs (and doesn't need) to be able to do, will use all that stuff. not sure whether i can just fire off the midi when we need to, or whether we would also need to send out midi clock too as then u can specify ahead of time that a midi message should be sent "on the next click" etc. will only know if it sounds tight enough when trying i guess... |
| Chasidy Heckenbach 02.02.2012 |
Originally Posted by bascurtiz
i forgot i had managed to cram in so many controls in that lpd8 mapping... i *believe* it still makes sense? pots: eq+levels for decks A+B PAD mode: 7 transport type controls, 1 button toggles between decks A+B CC mode: itch style slicer (if activated) else hot cues PC mode: beat jumps (are limitted to what can go here) maybe i'll do some graphics for the layout and create a new thread for this one. the slicer "loop mode toggle" isn't uber important and could then be used for something else - and the PC mode buttons could be change, tho since the lpd8 doesn't send out a message on pad release not many things can use that. maybe a 4beat slicer would make more sense for an lpd8? would free up some pads - tho would only be half as fun |
| Chasidy Heckenbach 28.01.2012 |
Originally Posted by JoeM
for some reason i had no luck mutex locking before. either i was just being stupid (quite possible) or putting them in the wrong place and/or it was my use of pthread_mutex_lock() which i assumed would work under cygwin. i've changed to using native windows calls and it seems fine... now my callback function gets called by RtMidi as soon as a message comes in, i lock/wait on a mutex and release when all processing has been done - nice and simple and none of that processing loop shenanigans or any extra delays... does mean i need an extra thread now to handle queued up messages to be sent out in the future (stacked traktor messages needed a delay inbetween and/or arpeggios etc) but that's no biggie. |
| Chasidy Heckenbach 28.01.2012 |
Originally Posted by muffintop
we'd need midimasher to process midi timeclock, but apart from that the standard queuing stuff i'm adding, with some custom code should be enough.
I would also be interested in helping getting it to work if need be. Just would need a push or 2 in the right direction.
Thanks again for all of your hard work. Looking forward to making a logical layout for the LP in ableton also will be fixing the lpd8 issue that someone pointed out the other week |
| Nana Mohs 27.01.2012 | I'm about to build a serious ableton layout... Is there any possibility of a MM step sequencer anytime? I would love to have one ( or 8 )on a page with some basic controls at least. I would also be interested in helping getting it to work if need be. Just would need a push or 2 in the right direction. Thanks again for all of your hard work. Looking forward to making a logical layout for the LP in ableton |
| Chasidy Heckenbach 27.01.2012 |
Originally Posted by JoeM
anyone, if they tried hard enough, should be able to add in some simple logic using lua as it's constructs are just so simple. also - i don't see lua being the only/main front end to midimasher long term as most things people want to do should be possible with an even simpler config format, that would then in turn call internal functions or lua. most of the time people only need to be able to do stuff like: * route midi event X to output target Y with value Z * toggle the input midi event * when midi event X comes in send back event Y to light up the pads led * any of the above but only when some other pad is held down or toggled so that's what i'll be looking at sometime - simplifying custom configs for users while allowing them to use lua, or define custom lua funcs when what they need to do doesn't quite fall into that set cheers for your feedback - much appreciated |
| Chasidy Heckenbach 27.01.2012 |
Originally Posted by JoeM
ideally i'd like to just process each RtMidi event as it comes in, multi threaded. the only reason for me not doing that now is that any calls to (and from) lua causes all worlds of pain and crashes. execution can ping ping between the C core and LUA several times of depending on whether the LUA code is creating events or sending out midi and/or calling extra funcs from C.
Secondly, if you're not in love with LUA, I'd recommend running away while you still can. I have to use it for my job, but it's a horrible language really. There's not enough cross platform frameworks and the OO frameworks always seems hacky to me. Since a lot of controllers share similiar concepts (pots, pads, grids, faders, leds) it's just easier to use a scripting language with better OO support.
edit: i wouldn't say having some kind of OO framework would be an advantage for what midimasher wants the LUA config to do. it would certainly raise the bar for who could even use it. OO is fine in it's place - but that place isn't everywhere.
Also for your host app, you might want to look into C# over C++ if you plan to support OS X. The addition of interfaces and the fact that you can run the same binaries (if you're careful to split OS specific functions in a sane way) using Mono and .Net on Windows make help in the long run. MonoMacs C# support for the CoreMIDI/Audio apis is very thorough (I help port those as well ) and you'll get all sort of bonus in async thread handling that can be a evening
mare to do cross platform. My current app for my employer is a cross platform realtime audio app and we've had a lot of success plugging in different audio modules for CoreAudio, Windows sound, alsa and port audio on linux. Interfaces really save the day with cross platform.
there again maybe a midimasher2 could see the light of day in C# if i fancied it - just not had any real experience of C# so not an option for me at this point. i don't have enough free time from my work clients as it is to work on midimasher as much as i'd like to.
Then again, you could also do what I'm doing and use Max since it already handels MIDI in realtime across platform, and you can distribute the compiled patches for free. The lua interprator libs are really basic and compile without hassle on all platforms and you could probably easily write a Max C/Java interface to pass midi along, if someone hasn't already written this.
i'm not worried about cross platform issues atm - my code has been mostly written so it should compile anywhere and the only libs i am using (LUA, RtMidi and hidapi) all support osx and windows. i should be getting a mac in a month or so will look at osx support then. cheers for the info i'll be sticking with C+LUA most likely but am open to other ways of handling the main run loop - tho atm this latest version i have here doesn't seem to add any extra delays in. some more complicated callbacks, like the one to enabled/setup various effects unit parameters can take around 0.4ms to complete. doesn't sound like a lot but i guess it all adds up. the biggest issue (i believe) i was having before this latest version was with with my slicer implementation enabled - since that had to add delays in between messages which then delayed the whole process (kind of like the audio glitches that used to come from traktor pro1 when sending lots of led updates to a launchpad) it's not the absolute latency i'm so worried about, it's the jitter (the variance) and the actual "feel" of using it. if it "feels" laggy then ofc people won't want to use it. having native virtual midi ports instead of using an external loopback device would help too - as then processing wouldn't be going via the windows midi stack twice. |
| Chasidy Heckenbach 27.01.2012 |
Originally Posted by bascurtiz
|
| Vince Donohoue 26.01.2012 |
Originally Posted by zestoi
First, at this point most any scripting language will be fast enough. My major project right now uses OO Javascript (Mootools) with lots of inheritance running inside of a Max patch. I'm able to "crab scratch" effects on my padKontrol faster than the Traktor UI can update the LEDs. The JS engine in Max 5 isn't even the best, though I hear they're using the newer stuff in Max 6. My point is, anything will probably be fast enough. I'm using a 4 year old computer and through a USB hub (adds a few ms of delay, did I mention I've written USB drivers before too). You're biggest flaw is probably your runloop. You should try to find a way to use an even queue with no polling and async events. Try googling for realtime runloops, as most of the types you'll find are usually game oriented with UI runloops synced to FPS. Secondly, if you're not in love with LUA, I'd recommend running away while you still can. I have to use it for my job, but it's a horrible language really. There's not enough cross platform frameworks and the OO frameworks always seems hacky to me. Since a lot of controllers share similiar concepts (pots, pads, grids, faders, leds) it's just easier to use a scripting language with better OO support. Also for your host app, you might want to look into C# over C++ if you plan to support OS X. The addition of interfaces and the fact that you can run the same binaries (if you're careful to split OS specific functions in a sane way) using Mono and .Net on Windows make help in the long run. MonoMacs C# support for the CoreMIDI/Audio apis is very thorough (I help port those as well ) and you'll get all sort of bonus in async thread handling that can be a evening mare to do cross platform. My current app for my employer is a cross platform realtime audio app and we've had a lot of success plugging in different audio modules for CoreAudio, Windows sound, alsa and port audio on linux. Interfaces really save the day with cross platform. Then again, you could also do what I'm doing and use Max since it already handels MIDI in realtime across platform, and you can distribute the compiled patches for free. The lua interprator libs are really basic and compile without hassle on all platforms and you could probably easily write a Max C/Java interface to pass midi along, if someone hasn't already written this. Just some thoughts, hope it helps. |
| Neoma Picklesimer 21.01.2012 | Hey mate, How's the new version working out 4 ya? |
| Chasidy Heckenbach 15.01.2012 |
Originally Posted by bascurtiz
it's about time i finished testing the version i was working on before new year too which has some performance improvements in. also about time i got my lpd8 out again anyway |
| Neoma Picklesimer 15.01.2012 | Hey Zestoi, I hope this *bump* will make u consider to do a new version, whereas the LPD8 will function properly I've tried out an earlier version, and in that, I don't get the suddenly shut-down of Midimasher after loading the LPD8-config, so yeah, I guess indeed, there's a bug when it comes down to the LPD8. |
| Chasidy Heckenbach 11.01.2012 |
Originally Posted by Mitchell1122
osx if i get a mac (which hopefully is likely) or i might try to build/test in a virtual osx session - just don't have any spare time atm. there's no technical reason why it shouldn't build on any platform. i chose the RtMidi lib for that reason - and LUA builds on just about anything. some beta code i've been working on for HID support should be fine too - as uses hidapi which says it works on linux/win/osx i guess those are the big 3 u are referring to? or some curve ball like BeOS? edit: pretty sure i just replied to a bot looking at those image urls - but it was a sensible question anyway |
| Chasidy Heckenbach 11.01.2012 |
Originally Posted by tdmusic
I've had the same idea before, the closest I got was writing a C++ application a few years ago which converted Traktor's OSC output to MIDI (as Traktor 2 and 3 used to only output OSC for control values if I remember correctly, no MIDI feedback), and did some special mapping for the BCR2000 (e.g. storing effect parameters in arrays so it would recall the correct effect parameteers)... started out as Python, which was too slow (although I didn't know a lot about performance optimization back then so I'm sure I could improve that) and then ported to Java for the Mac, but stopped needing it when Traktor Pro came out so that was as far as I got!
i guess python would be too slow. you found java was fast enough? i find LUA pretty quick, tho still could be better, when fractions of milliseconds matter. current unreleased version is quite a bit better i believe as i had a main event loop which slept for 1ms if there were no incoming events to process and functions like the slicer had to have embedded sleeps in to send out multiple commands to traktor and have them all recognised. code is almost finished that lets any function queue up messages to be send out a certain time in the future which prevents all the midi not being processed during that time. could also be used to trigger a set of samples for a drum riff or arpeggio ofc i also fancy having a built in sequencer so i can use sample decks in traktor like a mini ableton. it's just single threaded atm (apart from the use of RtMidi which is threaded to listen to multiple midi ports) which seems the best way when using LUA. RtMidi seems to work nicely with multithreaded apps - but even with more mutex locks than i can remember i still for some odd reason had issues with the LUA.
Any plans to port to the Mac, or to release the source, in which case I'd love to try and get it up and running?
|
| Maybell Corb 11.01.2012 | This looks pretty amazing. I've had the same idea before, the closest I got was writing a C++ application a few years ago which converted Traktor's OSC output to MIDI (as Traktor 2 and 3 used to only output OSC for control values if I remember correctly, no MIDI feedback), and did some special mapping for the BCR2000 (e.g. storing effect parameters in arrays so it would recall the correct effect parameteers)... started out as Python, which was too slow (although I didn't know a lot about performance optimization back then so I'm sure I could improve that) and then ported to Java for the Mac, but stopped needing it when Traktor Pro came out so that was as far as I got! Any plans to port to the Mac, or to release the source, in which case I'd love to try and get it up and running? |
| Chasidy Heckenbach 05.01.2012 |
Originally Posted by cantaloop
|
| Tyra Fines 05.01.2012 |
Originally Posted by cantaloop
okay i got it...i forgot to extrakt... |
| Tyra Fines 05.01.2012 | hi there! i tried to install midimasher but it said it cant find mm.exe ! do u have any suggestion? running windows 7 on Macbook... |
| Chasidy Heckenbach 03.01.2012 |
Originally Posted by ZiiK
Just checking if it would be possible to make the launchpad 8x8 grid a device similar to the virtual midifighter and use pre made launchpad mappings for each page.
Code:
function lp_something(device, page)
pipe(device, "0,0", page, "traktor", "play_a")
pipe(device, "0,1", page, "traktor", "play_b")
end
lp_something("launchpad", 2)
if you put those functions in lib/launchpad.custom.lua then it will get automatically loaded when u attach a launchpad device in your main config. or just load via a require() in your config |
| Chasidy Heckenbach 03.01.2012 |
Originally Posted by ZiiK
Don't quite get the color array set up for hotcues in your launchpad config. It still just use the first color right? Hi yellow are typed in five/six times followed by red. A little puzzled. It all works just fine, I'm just curious.
Is there a list of all your "named" colors somewhere? I ended upp using the midinumbers since I wanted some other colors then used in your examples. Which is cool. Real easy to get flashing to since half the midi notes give flashing leds... The flashing is somewhat unpredictable though. I know it's synced to traktor. So obviously it will be faster when messing with short loops etc. but it slows down when the warning for track ending is sent, somewhat annoying.
hadn't noticed the slowing down... the call to launchpad.traktor_sync("lp") makes any flashing ones flash to whatever the beatphase is. without calling that they flash at the launchpads internal rate. the flashing leds have been the biggest pain for me with the launchpad support - esp keeping them flashing on page switches/refreshes.
Would it be possible to use other "gates" that if & and? I would love to have access to the or command. That would give great possibility for instant grat mappings...
Code:
capture("traktor", "play_a", ALL, 0, function(d,e,v,p)
if get('foo') and get('bar') or get('fish') then
send("launchpad", "3,4", 127)
set('fubar', 42)
end
end)
General q, you use cc's for everything in the traktor.tsi is there a reason for that? I lack some knowledge in midi and read as much as I can but don't get everything yet. Seems like notes should be sufficient for a lot of things...
And also, I would be greatful if someone could explain what a midi pc is, can't seem to find that. No problem looking other stuff up in midi documentations.
A small "bug" the play button willl remain lit when track has ended since no off message is sent.
And one more thing, to be able to make the specific mappings I'm after I would have to make a lot of custom traktor stuff and add them to the tsi. Is there a simple way to keep my customizations separate? Is there a certain note or cc range I should stick to? I want my setup to be compatible with future versions
I hope I don't sound ungreatfull with all these q's and ideas... I love the extra power this gives my launchpad and have a hard time deciding how to proceed.
Going the midimasher route all the way or to create traktor tsi's for each layer since I seem to need a lot of custom stuff anyways. I know leds are harder...
But some work has do be done twice with the masher, first mapped then coded. Think the code setup is great though! So much faster. BTW, could I debug my config if I make a mistake in code? Now I just know that there is a problem if the app shut down on initiation =) No big deal, but I might aswell ask.
I'm stoked and seem to spend to much time experimenting and learning and to little sleeping
I'm willing to help out with mappings and such if help is needed. Just send a PM if so. cheers and keep up the good work! |
| Santiago Brasier 03.01.2012 | sorry for the mammoth post the other day. Just checking if it would be possible to make the launchpad 8x8 grid a device similar to the virtual midifighter and use pre made launchpad mappings for each page. Can't see why it would not work, but would like confirmation since I am very new to this. Been having great fun learning so far! Thanks zestoi for this awesome app! Cheers |
| Chasidy Heckenbach 02.01.2012 |
Originally Posted by bascurtiz
i reworked almost all of the slicer code the other month and tested on a launchpad. pretty sure i didn't go back and check the lpd8 slicer config to make any changes. will make sure i look at that in my next set of updates. |
| Chasidy Heckenbach 02.01.2012 |
Originally Posted by ZiiK
Automation of fx from counters or some other great solution.
Soft fadermovements like in katapult. So that the fader doesn't jump straight to the 5th value when pressed. could be messy to for sure. But nice to have the choice =)
Another q, a mate of mine wants to make a very specific mapping. And would need to ignore the note of in a clever manner if other buttons are pushed.
something like this which would always send out the ON event but only the OFF event when the modifier is set/pressed: Code:
capture("launchpad", "0,0", ALL, 0, function(d,e,v,p)
if v > 0 or get("some_modifier") > 0 then
send("traktor", "some-event", v)
end
end)
Suppose it would also be possible to make a different TSI for torq or other software... Could perhaps help with that to in time.
One q about the slicer. Spent some time on the real one since I used to own a twitch. Suppose the slice size and playback length functions are left out?
|
| Neoma Picklesimer 26.12.2011 | Ehh... is this ok ? (happens with Debug / Midimasher.bat / and the other one) After it, it closes the software. This does look good tho..? Then again... end result: - Instant Grat FX MF 1.03.tsi seems to be working, just have to figure out, the mapping. - Slicer mode doesnt work at all. Any suggestions Zestoi? |
| Santiago Brasier 24.12.2011 | Merry christmas fellas! Been playing around with the midimasher now and then... Since new to programming it sometimes takes a little time before I sort things out, but being stubborn helps I'm a bit torn at this point, believe the midimasher is great in some ways and at the same time a little cumbersome at times. A lot easier to map LEDs for sure. Have some issues with a couple of things and a lot of q's.... So I'll just throw then out. Some are probably stupid and others might not be. We'll see. Think I read about noterepead somewhere in this thread, is that availible, will it be added later or do I have to sort that out in traktor? Don't quite get the color array set up for hotcues in your launchpad config. It still just use the first color right? Hi yellow are typed in five/six times followed by red. A little puzzled. It all works just fine, I'm just curious. Is there a list of all your "named" colors somewhere? I ended upp using the midinumbers since I wanted some other colors then used in your examples. Which is cool. Real easy to get flashing to since half the midi notes give flashing leds... The flashing is somewhat unpredictable though. I know it's synced to traktor. So obviously it will be faster when messing with short loops etc. but it slows down when the warning for track ending is sent, somewhat annoying. Would it be possible to use other "gates" that if & and? I would love to have access to the or command. That would give great possibility for instant grat mappings... General q, you use cc's for everything in the traktor.tsi is there a reason for that? I lack some knowledge in midi and read as much as I can but don't get everything yet. Seems like notes should be sufficient for a lot of things... And also, I would be greatful if someone could explain what a midi pc is, can't seem to find that. No problem looking other stuff up in midi documentations. A small "bug" the play button willl remain lit when track has ended since no off message is sent. And one more thing, to be able to make the specific mappings I'm after I would have to make a lot of custom traktor stuff and add them to the tsi. Is there a simple way to keep my customizations separate? Is there a certain note or cc range I should stick to? I want my setup to be compatible with future versions I hope I don't sound ungreatfull with all these q's and ideas... I love the extra power this gives my launchpad and have a hard time deciding how to proceed. Going the midimasher route all the way or to create traktor tsi's for each layer since I seem to need a lot of custom stuff anyways. I know leds are harder... But some work has do be done twice with the masher, first mapped then coded. Think the code setup is great though! So much faster. BTW, could I debug my config if I make a mistake in code? Now I just know that there is a problem if the app shut down on initiation =) No big deal, but I might aswell ask. I'm stoked and seem to spend to much time experimenting and learning and to little sleeping I'm willing to help out with mappings and such if help is needed. Just send a PM if so. cheers and keep up the good work! |
| Neoma Picklesimer 21.12.2011 | Okies, ordered the Akai LPD8, and I expect it to be delivered tomorrow I'm very excited to play with it, and esp. the Slicer-function by u, Zestoi... Where do I start? Download Midimasher... what's next? |
| Santiago Brasier 19.12.2011 | That was a massive read! Just plowed through the 28 pages of thread... Been using MM for a couple of days now. Got it up and running after some trial and error... The thing I got wrong at first was the ins and outs for virtual mf's in traktor. I was looking at it from traktors viewpoint and nott from mm's so first tried to set them the other way around. Anyways, superstoked and all good so far! From now on it seems the controllers without layers in firmware will be superior due to the flexibility this app add's. A couple of things that spring to mind that could be implemented. Automation of fx from counters or some other great solution. Soft fadermovements like in katapult. So that the fader doesn't jump straight to the 5th value when pressed. could be messy to for sure. But nice to have the choice =) Think I had something else in mind around page 15 but can't seem to recall that at the moment. Due to my limitations in pragramming skills I probably won't add much in that department. Could however do some labor when it comes to adding traktorfunctions. Liked the idea with a slit tsi. either by deck or by functiongroup. Suppose in the end since we all have our own workflow it's hard to find a standard that fits everyone... Checking so I got it right, for now it's best to leave traktor buttons on hold to be able to hold or toggle in mm. Another q, a mate of mine wants to make a very specific mapping. And would need to ignore the note of in a clever manner if other buttons are pushed. It's the next logical step from the instant grat mapping. Instead of firing supercombos he would like to be able to let go of the first buttons in a combo and start executing a different one with two or three fingers. Not sure that made sense... Probably won't find time to make my own confic for a few more days but looking forward to get it done. I will need deck C and D though. Pretty much decided to trigger samples in external software. Suppose it would also be possible to make a different TSI for torq or other software... Could perhaps help with that to in time. One q about the slicer. Spent some time on the real one since I used to own a twitch. Suppose the slice size and playback length functions are left out? Didn't have much time to try stuff out the other day. I'll stop for now, seems like I produced an awful lot of text! Cheers //Joel |
| Arcelia Siebeneck 18.12.2011 | I'll sell my LPD8 for 25 euros if anyone's interested? |
| Chasidy Heckenbach 18.12.2011 |
Originally Posted by bascurtiz
|
<< Back to Post and find Controller MappingsReply