"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 | |
| Neoma Picklesimer 18.12.2011 |
where did u manage to find an lpd8 for 25eur? sounds like a bargain... they don't seem to drop much in price when 2nd hand as not much can go wrong really. the pots can get a bit loose but that's about it - and only really if u change the caps.
Then again, he wants 37,50 for it, incl. shipping costs, coz he lives too far away, to come over. For 49 euro, u can buy it new, in your local musicstore. So I'm planning to get one, this week. Btw, I found some cool mappings on traktorbible.com for the LPD8. To give yourself some more groupies , why not post yours, aswell there? |
| Chasidy Heckenbach 14.12.2011 |
Originally Posted by decon
Originally Posted by bascurtiz
the twitch is awesome, would buy one if i had the cash. i do really want to pick up a k2 tho if i can afford one in the new year... where did u manage to find an lpd8 for 25eur? sounds like a bargain... they don't seem to drop much in price when 2nd hand as not much can go wrong really. the pots can get a bit loose but that's about it - and only really if u change the caps. |
| Chasidy Heckenbach 14.12.2011 |
Originally Posted by escapemcp
chris's solution on the blog post of jumping to a cue before then jumping forwards was great tho - sadly i didn't have enough brain cells to come up with that... previously the mm function was always trying to best-guess the current beat from the beat phase and jump fwd or back from there - but often screwed up when it got it wrong verses the quantize in traktor. |
| Sulema Eshel 13.12.2011 |
Originally Posted by bascurtiz
|
| Sulema Eshel 13.12.2011 |
Originally Posted by bascurtiz
Unit will be great for (in Traktor) a sample bank or 2xFX units - or both using the program change (whatever it's called) button - I prefer to avoid this though... with several controllers where I switch from one to the other, I can never remember which mode a controller is in if I have loads (even with lights, I forget to check)... I hate layers - although I'm great at programming them (sod's law)!! Spent ages sorting out an old mapping, only to find that by putting all the controls that I needed on one controller, and using several layers, I could never remember which layer I was on - resulting in some awful mixes - I'd always end up stopping the wrong deck! Getting a controller like the VCI-400 seems a good way to go.. having 4 mixer channels means that I can close the line fader (when in a hurry at the buildup) and know that I will fade out the right channel (well maybe the left channel, but you get what I mean ) |
| Neoma Picklesimer 11.12.2011 | I'd so buy an Akai LPD8 over the Korg Nanopad1/2 <- are famous for their crap-quality. Check the LPD8 out here: http://www.youtube.com/watch?v=kVJkLkLbdsY and here: http://www.akaipro.com/lpd8 Speaking of... I'm gonna buy an Akai LPD8 tomorrow for 25 euro I just can't wait to bank for a Twitch, so I wanna get my hands on the Slicer-mode, like yesterday Still following your geniality Zestoi |
| Khadijah Wojtach 09.12.2011 | Just got a new nanopad. I open the box, plug it in, and only the touchpad works :S I'll just be buying a MF instead. If the nanoPad is that fragile, then it's not really worth it. |
| Sulema Eshel 06.12.2011 |
Originally Posted by zestoi
Originally Posted by zestoi
Originally Posted by zestoi
I am believeing of getting/stealing(!) a VCI-400, but apparently it has some issues where you need to set the midi outputs to 'all devices' in Traktor, a result of which may mean that I have to keep my MP-X10 away from the same channels that the VCI-400 uses (about 8 channels), so would have to position my MP-X10 on it's unused ones.
Originally Posted by zestoi
Thx, escapemcp |
| Chasidy Heckenbach 05.12.2011 |
Originally Posted by escapemcp
the data from your pitch fader is just a channel pitch bend message, no running status or anything there afaik. it's just lsb/msb so nice and easy for me to implement if that fader is using pitch bend for channel 2 does your other one use the same message just on a different midi channel? the data makes waaay more sense looking at the data u attached compared to what my nanokey outputs when i press the buttons... thanks for the data, that's a really big help your jog wheel and encoders are just sending out normal res relative messages yep? so no issues with those ones? |
| Sulema Eshel 06.12.2011 | 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). |
| Sulema Eshel 06.12.2011 | And here's the output from learn.exe. This time moving from +ve to -ve (although I believe 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: |
| Sulema Eshel 06.12.2011 | 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 believe 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 |
| Chasidy Heckenbach 03.12.2011 |
Originally Posted by escapemcp
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 believe 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 toevening
. Had a quick read about that 14-bit stuff I was on about last time. It's called 'running mode/status'.
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 |
| Sulema Eshel 02.12.2011 | 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). |
| Sulema Eshel 02.12.2011 | Sorry, have been offline for last few days. With the latency thing, I believe I noticed it when pressing play/cue. Will check toevening
. I believe 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 believe 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 toevening . 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. |
| Chasidy Heckenbach 01.12.2011 | anyone have any info/thoughts on midi latency? i just read this article on the blog from 2008: http://www.djranking s.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)
|
| Chasidy Heckenbach 01.12.2011 | 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 Code:
[timer ] 49.9281 useconds [timer ] 44.3286 useconds [timer ] 50.8612 useconds [timer ] 52.2611 useconds [timer ] 61.1268 useconds Code:
[timer ] 99.3894 useconds [timer ] 146.051 useconds [timer ] 147.918 useconds [timer ] 115.254 useconds [timer ] 100.789 useconds Code:
[timer ] 140.452 useconds [timer ] 143.718 useconds [timer ] 269.705 useconds [timer ] 140.918 useconds [timer ] 140.918 useconds 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 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")
|
| Chasidy Heckenbach 01.12.2011 |
Originally Posted by decon
a nanopad2 as replacement would be nice... tho i've heard the pads are better on the mk1? |
| Khadijah Wojtach 01.12.2011 | 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. |
| Chasidy Heckenbach 30.11.2011 | 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...
Originally Posted by escapemcp
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 believeing 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 |
| Chasidy Heckenbach 30.11.2011 |
Originally Posted by escapemcp
BTW/FYI: not 100% on this, but I believe 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 believe 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.
a midiox output stream would be really useful. i believe 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??
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 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 evening mare 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. |
| Sulema Eshel 30.11.2011 |
Originally Posted by zestoi
|
| Sulema Eshel 30.11.2011 |
Originally Posted by escapemcp
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 believes 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 believeing that it is a different control. BTW/FYI: not 100% on this, but I believe 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 believe 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 |
| Sulema Eshel 30.11.2011 |
Originally Posted by zestoi
|
| Chasidy Heckenbach 30.11.2011 |
Originally Posted by escapemcp
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. |
| Chasidy Heckenbach 30.11.2011 |
Originally Posted by escapemcp
Code:
$ ./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 |
| Sulema Eshel 30.11.2011 |
Originally Posted by escapemcp
|
| Sulema Eshel 30.11.2011 | 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 |
| Chasidy Heckenbach 29.11.2011 |
Originally Posted by escapemcp
also i've been believeing 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 believe we can come up with better names, tho i'd have to go thru all the existing code that uses them. i still believe that appending the deck name etc makes the most sense tho probably. |
| Chasidy Heckenbach 29.11.2011 |
Originally Posted by escapemcp
Surely 8 would be better - 100 free may sound like a few, but with sample decks using quite a few, I could see it filling up fast.
Annoying thing is that I often use C&D for track decks and A&B for track/sample decks (have 2 controllers, and the one more suited to samples is my main A/B controller).. believe I may well have to complete all the MM mappings in Traktor!! :eek:
i never even considered someone wanting to use them that way round - unless they wanted to run all as sample decks ofc.
Yeah, and does your controller mapping screen now take ages to go from one logical device to the next? It was like this on the mac before, but now seems to be doing it on Traktor 2.1.1. as well.
maybe it would even make sense to break the tsi into smaller ones, like "decks a+b", "sample decks a+b" etc so the minimum needed can be loaded. there's currently 660 items in the midimasher.tsi and i can't believe that other people don't have a lot more than that - once u get into complex modifier dependant stuff etc. the time to change logical device etc tho seems to depend more on the total number of mapping entries. it was faster before i imported the instant grat ones anyway. each instant grat tsi seems to have about 50 "pages" of 8 per page-ish? so with all 4 of those loaded thats about 1200 controls mapped so i guess the midimasher one isn't so bad? as it's only the decks/same-decks stuff that needs to be duplicated for the missing decks it'd only be about 1000 controls by the end i guess. plus there's some existing ones that can be removed once some extra functionality is added to midimasher, like auto-repeat |
| Sulema Eshel 29.11.2011 | Oh, and gave the PC a evening 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. |
| Sulema Eshel 29.11.2011 |
Originally Posted by zestoi
Originally Posted by zestoi
Originally Posted by zestoi
|
| Chasidy Heckenbach 29.11.2011 |
Originally Posted by escapemcp
would be awesome if you could add in the controls for decks c+d would probably be easier to copy the tsi and create a midimasher_cd.tsi or something that just contains the missing stuff. plus then if people don't intend to use decks c+d as normal decks then they don't need to import that one too. creating that devices file and tsi was pretty boring... so i stopped at just doing decks a+b and sample decks c+d also there's a neat way of developing that... after it loads in devices/traktor.lua it then looks for devices/traktor.custom.lua and loads that in too. same for lib/traktor.lua and also the same for any device so u could put the missing controls in there and it will get loaded automatically i can't see me using up anything more than CC's so the idea was that people could use note's and put the controls in that custom lua file and never conflict with the main one ofc we'd want the decks c+d to be in devices/traktor.lua eventually, just start from midi channel 7 maybe, then i have about 100 free in channel 6 that i can add if i need to in the meantime edit: one nice thing i noticed about the latest tp2 btw is that it now doesn't matter whether u load midimasher before traktor or not, i.e: traktor no longer has the bug where it opens/locks midi ports that it shouldn't be. the bad part is that it seems less stable and uses more cpu on my laptop than the previous (2.0.3?) version u still need loopMIDI running before traktor ofc - but i just set that to autostart |
| Chasidy Heckenbach 29.11.2011 | everything you did looks right from what i can tell i created a simple debug config based on your config (using "volume_fader_a" instead of your "fader" only as that's what it's called - i'm trying to rename controls to match the traktor ones where possible now, but it's only a name) Code:
open_midi_device("traktor", "traktor", "Traktor to MM", "MM to Traktor");
open_midi_device("mpx10", "djm101", "DJM_101", "DJM_101")
pipe("mpx10", "volume_fader_a", 0, "traktor", "volume_fader_a");
Code:
* [mpx10 ] b0 41 4a [djm101] type=cc name=volume_fader_a value=74 [traktor ] volume_fader_a c=2 v=74 p=0 [traktor ] b1 54 4a [traktor] Code:
* [mpx10 ] b1 10 69 [mpx10] type=cc name=fader value=105 [traktor ] volume_fader_a c=2 v=105 p=0 [traktor ] b1 54 69 [traktor] when u ran midimasher u didn't see any errors/warnings? i.e: u saw something like this? Code:
loading: lib/startup.lua loading: config/debug.lua connect: in "Traktor to MM" device name=[Traktor to MM] is index=2 port=2 traktor: open midi.in.2: Traktor to MM connect: out "MM to Traktor" device name=[MM to Traktor] is index=14 port=2 traktor: open midi.out.2: MM to Traktor loading: devices/traktor.lua loading: lib/traktor.lua connect: in "DJM_101" device name=[DJM_101] is index=11 port=11 mpx10: open midi.in.11: DJM_101 connect: out "DJM_101" device name=[DJM_101] is index=24 port=12 mpx10: open midi.out.12: DJM_101 loading: devices/djm101.lua as u can see there i'm getting the correct data being sent to the "MM to Traktor" port. my guess is either the loopmidi ports weren't named exactly right, tho you'd see some warning when midimasher starts up, or theres some issue with the ports assignment in traktor |
| Sulema Eshel 28.11.2011 | After chatting on other thread (post fader FX), thought I should really check out this midimasher stuff, cause if I can get my head round it, I could do some crazy stuff with it. I believe I get how it should work, but it just isn't working! - spent 2 hours on it, and I am hoping for a quick pointer. What I did: 1) Installed loopmidi, created MM to Traktor & vice versa 2) 'Installed' MM. 3) Learn.exe'd one side of my unit (Citronic MP-X10, although will expand to BCD3000 and maybe Kaoss Pad (although KP has a superfader built in!)). 4) Made mpx10.lua in config folder. It consists of this: Code:
open_midi_device("traktor", "traktor", "Traktor to MM", "MM to Traktor");
open_midi_device("mpx10", "mpx10", "MP-X10", "MP-X10");
pipe("mpx10", "fader", 0, "traktor", "volume_fader_a");
5) Imported traktor.tsi into traktor + set in&out ports to MM. If I then load up in correct order (loopmidi>MM>Traktor), Traktor does not move the volume when I move mine, hell, it doesn't even receive any midi (other than an odd signal on 16 (CC i believe) very erraticly). Output from MM is: Code:
* [mpx10 ] b1 10 69 [mpx10] type=cc name=fader value=105 [traktor ] volume_fader_a c=2 v=105 p=0 [traktor ] b1 54 69 [traktor] Finally, am I going to have to go into traktor and manually create all commands and point them to a midi command if I want C&D as a track deck (if required, I will, which should help the project). Many thanks, escapeMCP |
| Chasidy Heckenbach 27.11.2011 | just experimenting with the post fader effects method described by DJ MiCL in another thread and also thought about the "fader fx" mode that the twitch has. turns out it's really simple to implement in midimasher, tho i did add a new function to lib/base.lua pipe_shift() since i didn't need the led feedback of button_shift() and also added some extra call back options so we can invert the value of the volume fader when controlling the fx unit wet/dry this mini config is just using my djm101 Code:
open_midi_device("traktor", "traktor", "Traktor to MM", "MM to Traktor");
open_midi_device("djm101", "djm101", "DJM_101", "DJM_101");
faderfx_a = toggle_modifier("djm101", "pfl_a", 0, ON, OFF, nil, function(d, e, v, p)
if v > 0 then send("traktor", "dry_wet_group_unit_1", 0) end
send("traktor", "effect_unit_1_on_a", v)
end)
faderfx_b = toggle_modifier("djm101", "pfl_b", 0, ON, OFF, nil, function(d, e, v, p)
if v > 0 then send("traktor", "dry_wet_group_unit_1", 0) end
send("traktor", "effect_unit_1_on_b", v)
end)
pipe_shift("djm101", "volume_fader_a", 0, "traktor", "volume_fader_a", "dry_wet_group_unit_1", faderfx_a, 0, { cb_shift = invert_value_cb})
pipe_shift("djm101", "volume_fader_b", 0, "traktor", "volume_fader_b", "dry_wet_group_unit_1", faderfx_b, 0, { cb_shift = invert_value_cb})
toggling one of them on sets the wet/dry of effects unit 1 to 0 and enables that effects unit for that deck, then the fader controls the wet/dry (with dry at the top and wet at the bottom). toggling it of just disables the effects unit for that deck and puts the fader back into normal mode. it's a lot of fun... i can see why people like fader fx stuff now... also would be easy enough to add code in there to turn a fader into a "super fader" but i'll probably add a new dedicated function for that later that sends out the extra events/messages |
| Chasidy Heckenbach 26.11.2011 | i've started writing some documentation on the various functions available, still plenty to do tho and will add more examples and better descriptions over time as well: http://midimasher.djism.com/doc/ it's a start tho edit: traktor functions: http://midimasher.djism.com/doc/lib--traktor.html edit2: a handy list of all traktor controls within the midimasher tsi http://midimasher.djism.com/doc/lib-...or-events.html |
| Chasidy Heckenbach 26.11.2011 | new version http://midimasher.djism.com/download...r-20111125.zip * fixes odd led issues when using slicer and switching pages * fixes flashing leds becoming normal leds on twitch area page switching * halved the frequency of flashing leds when sync'd to traktor * support for scrolling sub devices * added launchpad led fix functions to stop solid leds becoming flashing ones the scrolling device stuff probably doesn't interest many (any) people but there's a demo called "launchpad_scroll_demo.lua" that if u run creates a 64x16 grid with a few led's lit up that u can scroll around by using the launchpads up/down/left/right buttons. if u run debug.bat and select that demo file you'll see it sending out different midi messages depending on where it is scrolled to - so u basically have a 64x16 grid controller that u can "learn" etc with any app. usefull when 8x8 pads just aren't enough |
| Chasidy Heckenbach 24.11.2011 | launchpad flashing led shenanigans... i'm starting to believe that enabling flashing leds on the launchpad is more hassle than it's worth - but i started so i will finish.... the problem is that if u enable flashing colors on the launchpad and then send an 'off' zero message to a pad to turn it off, it won't. it will in effect turn a yellow solid pad into a flashing yellow pad as only one of the buffers will have been affected by the zero message. this is a royal pain when using some flashing leds with traktor (with midimashers handling of flashing colors) and then also using it to control something some other app that believes if it sends zero it will turn a pad off - as u would expect.... solution 1 instead of calling launchpad.init("lp") u can now call launchpad.init("lp", false) which won't enable flashing leds at all solution 2 calling enable_launchpad_led_fix("lp") will ensure that any zero message gets converted into 0x4 which means the copy bit is set and so it will actually turn off the led solution 3 calling enable_launchpad_led_fix("lp", 3) will ensure every midi message sent to page 3 of the launchpad will have the copy bit set, so disabling all flashing colors for just that page - so u don't have any unexpected leds start flashing when u didn't expect it i didn't want any device specific code in the midimasher core, but can't see any way round this and personally i really like the flashing leds, esp as when used with traktor they sync to the beat via the beatphase |
| Chasidy Heckenbach 23.11.2011 | it does sound like the beatmasher should do the loop roll stuff, like it is setup in the instant grat tsi and this launchpad config has a 4banks emulated midi fighter on page one for that anyway i have some more code to roll out, but will do it tomorrow once i've looked some more at why holding down a pad in my slicer seems to be a behind the beat a bit: * fix for flashing led's becoming non-flashing leds once u change a page in the twitch area (the launchpad led handling is quite cunning but also a bit of a pain. whenever u switch led pages to set a whole bunch in one hot you also *must* clear and reset any flashing ones too, even if they don't change) * fix for slicer leds getting munged in other pages. happens if u enable the slicer and switch to something like the page4 mixer - you'd see leds getting mixed up - a schoolboy error on my part with the led midi cache handing * halved the frequency of flashing leds on the launchpad - still in sync with traktor tho * whole new functionality that allows u to embed a much bigger grid within a page (like a 64x64 grid within one page of a 16x16 launchpad) and then optionally route all of that to another device (like for ableton). you can then scroll the grid around. will let me more easily map to my old version of ableton5 but should also be useful for any other apps that u want to use for triggering samples etc as u then have a much bigger grid controller u can use and just use the apps "learn" feature since each pad in the virtual grid sends+recvs different midi. only catch is that u only know where it's scrolled to by looking at the actual leds on the launchpad - tho since from lua u can access the current row,col offset you could set that somehow on some other pad if u had something useful for that out of interest this is my current test code for the scrollable grid stuff, just piping the big grid with my lpd8 so i can see data go both ways, but you'd normally use two virtual midi ports to connect to something like ableton most of this config code is just to assign 4 buttons to do the scrolling: Code:
open_midi_device("lpd8", "lpd8", "LPD8", "LPD8", 2);
open_midi_device("lp", "launchpad", "Launchpad", "Launchpad", 4)
attach_midi_subdevice("lp", grid("0,0", "7,7"), 1, "grid", 1, "grid_64x16")
set_device_route("grid", "lpd8")
set_device_route_status("grid", true)
set_device_route("lpd8", "grid")
set_device_route_status("lpd8", true)
launchpad.init("lp", false)
-- 4 buttons to scroll the grid
pipe_modifier("lp", "down", 1, lp_hi_yellow, lp_lo_yellow, nil, function(d,e,v,p)
if v > 0 then
launchpad.inc_offset("grid", 1, 0, "lp")
end
end)
pipe_modifier("lp", "up", 1, lp_hi_yellow, lp_lo_yellow, nil, function(d,e,v,p)
if v > 0 then
launchpad.inc_offset("grid", -1, 0, "lp")
end
end)
pipe_modifier("lp", "right", 1, lp_hi_yellow, lp_lo_yellow, nil, function(d,e,v,p)
if v > 0 then
launchpad.inc_offset("grid", 0, 1, "lp")
end
end)
pipe_modifier("lp", "left", 1, lp_hi_yellow, lp_lo_yellow, nil, function(d,e,v,p)
if v > 0 then
launchpad.inc_offset("grid", 0, -1, "lp")
end
end)
|
<< Back to Post and find Controller MappingsReply