"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 01.05.2012 | cool i was hoping the syntax would be fairly easy to get the basics of quickly. i've had quite a bit if help from synthet1c in refining the syntax too - to hopefully find the middle ground between being understandable and usable. i'll mess with some configs in my spare time over the next few days to see if there's any common corner cases that i could improve on (to avoid needing to code raw lua too often) and release a new version - most likely in a new thread as this one is getting a bit messy.... edit: i'm sure some of it can be done in a better way, but this is the full grammar for now http://midimasher.djism.com/script.txt |
| Angella Mosiniak 01.05.2012 | I completely get the syntax immediately. I just had to check the raw code to make sure I understood where the conditions were thnx I'm sold if can use that kind of format! |
| Chasidy Heckenbach 30.04.2012 |
Originally Posted by Phi
# connect the midi devices we need midi_device traktor traktor "V:Traktor to MM" "V:MM to Traktor" midi_device ableton ableton "V:Ableton to MM" "V:MM to Ableton" midi_device lpd8 lpd8 LPD8 LPD8 8 midi_device lp launchpad Launchpad Launchpad ## ## basic routing of controls ## # route page 3 of the launchpad to ableton and back, except for controls with custom maps route lp 3 <=> ableton # route all controls including ones you custom map routeall lp 3 <=> ableton # just route from ableton to page 3 of the launchpad (but not back) route ableton => lp 3 # route a single control one way route 2,2 => traktor play_a # route a single control both ways to get led feedback route 2,2 <=> traktor play_a ## ## custom mappings ## # select device to map device lp # a simple map (equivalent to "route 0,0 => traktor play_a") map 0,0 : traktor cue_a # use 'toggle' instead of 'map' to toggle play from the button toggle 0,1 : traktor play_a # make the led light up yellow when pressed, red otherwise map 0,1 : pressed ? 50 : 16 # use of a shift map 1,0 : set $shift map 1,1 : $shift ? traktor select_set_store_hotcue_1_a : traktor delete_hotcue_1_a # only map a control when the button is pressed or released map 1,2 : pressed ? traktor play_a map 1,3 : released ? traktor play_a # reverse the action for press and release map 1,2 : pressed ? traktor play_a off map 1,3 : released ? traktor play_a on # chaining using the & character map 1,4 : $shift & pressed ? traktor play_a on & traktor play_b on # add some led feedback using the & character map 2,2 : pressed ? traktor play_a & 50 : 16 map 2,3 : released ? traktor play_a & 50 : 16 # multiple maps in one line using the ; character map 1,5 : pressed ? traktor play_a ; released ? traktor play_a # specify feedback from a different device map traktor play_a : lp 1,6 # some buttons for changing page on the launchpad map user1 : set_page 1 map user2 : set_page 2 # the same page change buttons which toggle the others led and light themselves map user1 : set_page 1; lp user2 lp_lo_red ; lp_hi_yellow map user2 : set_page 2; lp user1 lp_lo_red ; lp_hi_yellow # map something to page 3 of the current device (launchpad) page 3 map 0,0 : traktor play_a # multiple conditions to create an if... else if... else... map 0,1 : $shift ? traktor play_a : $shift2 ? traktor play_b : traktor play_a off & traktor play_b off # switch to mapping page 2 of the lpd8 device lpd8 page 2 # use comment: and :comment tags to create a comment block comment: anything in here is... ...ignored :comment # use code: and :code tags to wrap around lua code code: send("traktor", "master_tempo_clock_send", ON) traktor.loops("lp", grid("6,0", "7,3"), 3, lp_hi_green, lp_lo_green, "a", "lp_shift", loop_sizes) :code and a quick example of the code it outputs... this is from the "if... elseif..." example above: Code:
capture("lp", "0,1", ALL, 3, function(d, e, v, p)
if get("shift") > 0 then
send("traktor", "play_a", v)
else
if get("shift2") > 0 then
send("traktor", "play_b", v)
else
send("traktor", "play_a", off)
send("traktor", "play_b", off)
end
end
end)
|
| Angella Mosiniak 30.04.2012 | Hey, that looks really good! I want to play! I'm definatly going to check this out. Thank you |
| Chasidy Heckenbach 29.04.2012 | quick update... i'm almost finished with a much simpler config format for midimasher scripting. it compiles to lua - so internally works the same. here's a couple of examples (the last "map" is quite contrived - just to show some possibilities with it) Code:
device: lpd8 map fader1 : traktor volume_fader_a map 0,1 : toggle traktor play_a map 0,1 : traktor cue_a map 0,2 : $shift ? traktor select_set_store_hotcue_1_a : traktor delete_hotcue_1_a map 1,3 : set $shift map 1,0 : pressed & $shift ? traktor play_a on & traktor_play_b on ; released ? traktor play_a off & traktor play_b off lua: -- raw lua code can go here :lua the names like "0,0" are just the names given to the pads on the lpd8 (row,column) but can be whatever u want to call the controls on your controller. |
| Chasidy Heckenbach 05.04.2012 | thats the 2nd spam bot post in *this* thread the last week or so |
| Chasidy Heckenbach 04.04.2012 |
Originally Posted by aplus
it's a decent app but agree some stuff i want to change still seems to take too many clicks. i've been using xtrememapping to create the master midimasher.tsi file as its much nicer to use than the traktor window. even simple stuff like scrolling is easier one thing that bugs the hell out of me tho is that if u choose to say only display "Filteres: Effects Units" as thats what you're working on, and then add a new one... it just goes back to displaying "all" again afterwards. i did end up adding the last few controls directly within traktor as it's not ideal having to edit->save->run traktor->import etc each time. when you're testing out stuff u have no choice really but to work within traktor. really wish they'd improve on the mapping window in traktor at least a *bit* sometime... |
| Ciera Roarke 03.04.2012 | maybe you should take a look at these guys http://www.xtrememapping.com/ its a mac app available in the app store. I bought it last evening cus I was fed up with the shitty interface that traktor has. It is definitely an improvement over traktor's but its not great. I dont like the fact you cant set the target deck on a bunch of selected mappings, so its one at a time. Luckily you can change midi channel on a bunch of mappings but its buried in a stupid 3 tiered menu. Hopefully they can make some simple tweaks and really blow the doors open on the power of the app, cus theyve done most of the legwork reading and writing the tsi's and making an interface for it. |
| Chasidy Heckenbach 03.04.2012 | i presume u had "Send MIDI Clock" enabled in "prefs > MIDI Clock"? i should save that with the midimasher.tsi file but it'd still only get set via a "big import button" import anyway |
| Chasidy Heckenbach 02.04.2012 |
Originally Posted by derschaich
if you're connected to traktor via two ports with something like this it should be fine: open_midi_device("traktor", "traktor", "V:Traktor to MM", "V:MM to Traktor") u wanted to do something with that 'beat' event? it should be able to read clock from something like ableton too, it's just midi, but will need to be able to read from the device. i haven't done much testing on windows recently, mostly mac and linux, but there *shouldnt* be any reason why it wouldn't work on windows too. |
| Allene Manitta 02.04.2012 | had the midi clock running for a while, then canged something in traktors controllermanager... gave up for today. will MM scan all ports for the midi clcok, or just the opened ports? |
| Chasidy Heckenbach 02.04.2012 |
Originally Posted by derschaich
if u wanted some finer control using your gamepad based pots u could try mapping them to pitch bend messages too. most of the time i believe a range of 0 to 127 is fine, but it's no extra effort now to get twice the resolution out of them. i had coded most of the midi clock stuff before but hadn't actually *used* it for anything one note tho on the midi clock... *any* device can send clock to midimasher but make sure only one app is - else it will get very confused... |
| Allene Manitta 02.04.2012 | will reply, when massive midi-clipped mapping has finished! thank you so much for this quick update with the midi-clock! |
| Chasidy Heckenbach 01.04.2012 | ok chaps, quite a few changes in this latest version. figured i should put out a decent update for my 2000th post. download: http://midimasher.djism.com/downloads/ the full changelog is on that page but the important updates are: * new worker thread responsible for writing to each midi device - has reduced quite a bit of latency * full support for pitchbend messages and added some for traktor for controlling pitch, xfader and volume faders * u can map a pitch bend msg to a normal midi message, to another pitch bend msg, a hid device input to a pitch bend or any other combination * slicer now using midi clock for sync which seems much more stable - u can also tweak it's phase to line it up properly * added some buttons to the launchpad mapping... midi clock send on/off toggle (vol), midi clock send sync (pan), midi clock phase adjust +/- on snda and sndb buttons * midi clock also being used to sync flashing launchpad led's * new option to scale input/output ranges in pipe() and the core route{} function. u can now use any gamepad to control your pitch fader with twice the resolution of most midi controllers pipe("gamepad", "volume_fader_a", 0, "traktor", "tempo_fader_a_hires", 0, MIDI_HIRES_RANGE / 256) edit: the slicer and other timings doesn't rely on the absolute bpm calculated but u can use this code to see how stable (or not) it is: capture("_global", "beat", ALL, 0, function(d,e,v,p) local bpm = get_bpm() end)print("bpm="..bpm) it's pretty stable using my macbook once it zones in (which takes a few beats, it samples 8 beats worth) - not checked on windows the timing stuff just relies on a beat starting every 24 midi clock ticks |
| Chasidy Heckenbach 30.03.2012 | improved performance when using slow controllers like a launchpad... not released yet as i've just been experimenting but by spawning a new thread to handle writing data to each attached midi device i've seen some big improvements. the worst thing about the launchpad is the slow led update time, due (only?) to being usb1. not a big deal with most controllers but with the lp sometimes u have a whole heap of led's to update - tho maybe this will also benefit other controllers too. a couple of times when doing page flips with some debug output i can see there's up to 36 messages queued up to be sent out to the launchpad, so can make quite a big difference, allowing the main thread to get back to more important stuff. a lot of the time the controller update thread keeps up with the messages needing to be sent out but not always... it should decrease latency overall as the time spent waiting for the lp to update an led before was wasted while now the main thread gets on with processing the next event - maybe also for the lp but maybe for a different controller. edit: according to the launchpad doc:
Launchpad uses a low-speed version of USB. A limitation of this is that it accepts a maximum of
400 messages per second that's 90 milliseconds! plus the fact that before the working out what led to update would be done in series with this waiting (i.e: calc led val1, update launchpad, calc led val2, update launchad...) so i believe this should make quite a difference, esp for launchpad use. |
| Chasidy Heckenbach 30.03.2012 | 13 posts in and this bot is still spamming the community then? <sarcasm>oh great...</sarcasm> |
| Chasidy Heckenbach 29.03.2012 |
Originally Posted by MiL0
edit: if i do it will be after the traktor 2.5 release and i have my f1 emulation in, plus may also have the live sequencer and some other enhancements done by then. edit2: don't believe it's djtt blog material anyway - maybe one day if it was completely finished or something. atm it's a bit too tricky for most normal people to pick up and use really... tho i *will* sometime/soon have at least a finished launchpad+nanokontrol mapping for traktor 2.5 that i'll create a new thread for |
| Arcelia Siebeneck 29.03.2012 |
Originally Posted by zestoi
|
| Chasidy Heckenbach 27.03.2012 | quick(ish) note... the ability to create events in the future is quite handy and can be used for auto-repeat on buttons like this: Code:
capture("lp", "0,0", ALL, 0, function(d, e, v, p)
if v > 0 then
print "do something..."
create(d, e, v, p, 100) -- repeat the event 100ms later
else
clear(d, e) -- clear any queued events
end
end)
|
| Chasidy Heckenbach 27.03.2012 |
Originally Posted by derschaich
will continue posting functions that i consider helpful for everyone. 1/16 would be nice, although it might be wise to handle the clock events completely internally to prevent a potential overflow of the midi signal.
btw: do you want to keep this open source? - would be a WIN for the whole community!
for now i want to keep control over the code and ofc it's only the core compiled stuff that people can't modify, but going open source in the future, if that makes sense, is def an option.
+ this thread blows off, we should keep an eye open for other options of communication (maybe get an own subcommunity
here on DJTT)
+ maybe lauching sort of MIDI-clips (timed via clock) would be a great thing for automation!
i mostly added in the midi clock decode for a new internal sequencer i've been working on. basically it lets u say "repeat this midi message on beat X.Y and repeat every 8 beats" and also the ability to dynamically clear them. i want to be able to use the new remix deck stuff for programming beats basically... i believe it should work ok and be tight enough but it's not at a testable stage yet. u will also be able to say "send this midi on beat X.Y once" ofc for launching a midi clip. u can already specify a command to be sent out a certain number of milliseconds in the future like this: Code:
send("traktor", "play_a", ON, 0, 2000)
|
| Allene Manitta 27.03.2012 | glad you're working on this for the community! will continue posting functions that i consider helpful for everyone. 1/16 would be nice, although it might be wise to handle the clock events completely internally to prevent a potential overflow of the midi signal. btw: do you want to keep this open source? - would be a WIN for the whole community! EDIT: + this thread blows off, we should keep an eye open for other options of communication (maybe get an own subcommunity here on DJTT) + maybe lauching sort of MIDI-clips (timed via clock) would be a great thing for automation! |
| Chasidy Heckenbach 27.03.2012 |
Originally Posted by woorszt
and sure, i'm commiting all changes using 'git' so i always know exactly what goes in, i'll make sure to add a changelog in future. cheers for the feedback |
| Rosetta Jungmeyer 27.03.2012 | midimasher is great and unique tool. works perfectly with my launchpad. Already created my own mapping. Just one thing: Can you please provide a changelog on your homepage? |
| Chasidy Heckenbach 27.03.2012 |
Originally Posted by derschaich
would be nice to add this function to the pool, as the HID-Faders only cover the first half of the way by default if you pipe them (e.g. you push the fader to half, and it already sends 127):
Code:
function hid_fader(input_device, event_i, value_i, p)
value_o = value_i/2
send("cl", event_i, value_o)
end
-- call it via:
capture("gp", "fader1", ALL, 0, "hid_fader")
Code:
capture("gp", "fader1", ALL, 0, "hid_fader", "cl")
Code:
capture("gp", "fader1", ALL, 0, function(input_device, event_i, value_i, p)
value_o = value_i/2
send("cl", event_i, value_o)
end)
up till that point it was easy... i didn't support pitch bend (or any other hi res messages) and only midi, so *every* input and output had a max value of 127. what i'm doing now is adding intelligence in so it will automatically scale any value to the output based on the input and output ranges. i.e: in your case the 0-255 will get scaled to 0-127 and if you wanted to map it to a pitch bend message it would auto scale to the output range of 0-16383. this will also have the nice side effect that a controller based on a gamepad can have twice the resolution for it's pots in traktor (or whatever app) if u use the 16 available pitch bend messages
as a whishlist for the clock input:
- 24 messages per beat are not necessary in my opinion - tempo [BMP] would be nice - beat counter with reset function to set it to zero would be great! i'll make available a 'beat' event for each beat, that maybe cycles round values 1-16 or 1-8 or something? that would let u do what u want. i'll also store the actual bpm in some variable in case it's useful to get hold of it. fantastic to get some feedback from some custom config code |
| Allene Manitta 27.03.2012 |
Originally Posted by zestoi
hid is working fine, faders (potis on thumbsticks, etc...) are working properly now. would be nice to add this function to the pool, as the HID-Faders only cover the first half of the way by default if you pipe them (e.g. you push the fader to half, and it already sends 127): Code:
function hid_fader(input_device, event_i, value_i, p)
value_o = value_i/2
send("cl", event_i, value_o)
end
-- call it via:
capture("gp", "fader1", ALL, 0, "hid_fader")
- 24 messages per beat are not necessary in my opinion - tempo [BMP] would be nice - beat counter with reset function to set it to zero would be great! i imagine usages like: *click button* Code:
do beat 1: beatmasher 1 beat beat 2: beatmasher 1/2 beat beat 3: beatmasher 1/4 beat beat 4: beatmasher 1/8 beat beat 5-6: beatmasher 1/16 beat transform FX from 0 to 127 end |
| Chasidy Heckenbach 26.03.2012 |
Originally Posted by muffintop
|
| Chasidy Heckenbach 26.03.2012 |
Originally Posted by muffintop
Code:
$ cd src/midimasher/ $ ./midimasher.sh midimasher: build 20120326 (Linux) #1: launchpad.lua #2: debug.lua #3: default.lua #4: mpd18_midifighter_4banks.lua #5: lpd8_midifighter_4banks.lua #6: lpd8.lua #7: mpd32_midifighter_4banks.lua #8: gamepad_midifighter_4banks.lua #9: launchpad_scroll_demo.lua #10: midifighter_4banks.lua #11: launchpad_twitch.lua select a config > Code:
#!/usr/bin/env bash ./mm -f launchpad.lua i'll debug your actual issue tho if u can post a bigger photo or just cut&paste any output. |
| Nana Mohs 26.03.2012 | I don't get it... Here are screenshots of my problem... Also, to run MM i have to double click on the midimasher.sh and run it in terminal. Double clicking on mm does nada. ---EDIT--- WORKS!!!! thanks zestoi, you're the man |
| Chasidy Heckenbach 27.03.2012 |
Originally Posted by derschaich
what config are u loading atm? mappings can be completely customised and aren't too tricky once u get your head round them. they're just based around writing snippets of code that deal with what happens when a message comes in that u are interested in. the file config/launchpad.lua is the most complete mapping atm, but is also quite complex so a bit confusing... i need to add more documentation to the webpage sometime. i'm up for answering any question on using lua in midimasher anyway you can't access midi clock atm. it's being decoded and used by the internal sequencer i've been working on but will need to make it available anyway now for the slicer stuff. what data do u want to get from the clock? i presume not all the 24 ticks per beat... being able to capture() and do stuff on the beat via the midi clock is what i need and also wouldn't hurt to be able to get hold of the actual bpm in a variable for other use. so i can do something on each beat based on it. |
| Chasidy Heckenbach 27.03.2012 |
Originally Posted by MiL0
|
| Allene Manitta 26.03.2012 | works a charm now! have a DIY midifighter clone here. but want to define my own mapping, including slicer-like functions. how can i access the midi-clock from traktor in MM? |
| Arcelia Siebeneck 26.03.2012 | has anyone made a video of MM in action yet? keen to see what it can achieve |
| Chasidy Heckenbach 26.03.2012 |
Originally Posted by drmore
The way it looks/work in my head is as follows
A button sets drops a loop in traktor.
When a grid button is pressed Midimasher crunches the numbers and spits out the correct size beat jump for Tracktor
Midimasher then issues a 1 beat backwards jump in time with midi clock while the button is held to create the 1 beat slice.
Midimasher continues its original count in the background.
When the grid button is released a beat jump is issued to get the play head back to the position in loop that it would of been if you had not pressed a slice button.
I have no idea if thats even posible but the idea is to issue as little sequential commands to Traktor as posible. Im also assuming c++ can process such a small sequence of events way quicker than 1ms delay required to issue a sequence to traktor.
mm keeps track of the current beat and knows what beat u want to jump to ofc, question is how to get there... if you are on beat 4 and pressed the pad for beat 2 my first attempt at a slicer would issue a jump -2 whereas this current one issues a cuejump and a beatjump +2. it's a lot more reliable but does mean an extra command+delay. i'm keen to work on this slicer tho if anyone actually wants to use it... i had given up on it before as no one seemed all that interested and i'd been looking at other things would be cool to know exactly what/how the vci400 implements the slicer... i haven't even seen a demo of that yet |
| Chasidy Heckenbach 26.03.2012 |
Originally Posted by derschaich
a few changes internally on some unfinished mods since my last release but hopefully nothing that will affect anything. what controller you trying to learn? i'm always keen to add new device config files to my releases ofc |
| Tawna Ulmen 26.03.2012 | I was going to sugest using the midi clock to time the jumps. The way it looks/work in my head is as follows A button sets drops a loop in traktor. Same button starts Midimasher counting using midi clock for sync Midimasher sets up a virtual grid of all the slices When a grid button is pressed Midimasher crunches the numbers and spits out the correct size beat jump for Tracktor Midimasher then issues a 1 beat backwards jump in time with midi clock while the button is held to create the 1 beat slice. Midimasher continues its original count in the background. When the grid button is released a beat jump is issued to get the play head back to the position in loop that it would of been if you had not pressed a slice button. I have no idea if thats even posible but the idea is to issue as little sequential commands to Traktor as posible. Im also assuming c++ can process such a small sequence of events way quicker than 1ms delay required to issue a sequence to traktor. |
| Allene Manitta 26.03.2012 | gave MM a go this morning after being frustated by GlovePIE for the last couple of days. tried the learn.exe, and everything went well except for me not being able to quit (same with hidlearn.exe) i tried typing: q Quit quit QUIT exit nothing helped. any idea what i am doing wrong? WIN 7 here |
| Chasidy Heckenbach 24.03.2012 | another mod i believe i'll do (not that it solves this issue directly) is use midi clock to sync the slicer actions now that midimasher decodes midi clock. it should provide more accurate control than the beat phase monitor and i can then probably remove that from the tsi which might have some effect overall - as there'll be less midi spewing into midimasher all the time. will have to see... |
| Chasidy Heckenbach 24.03.2012 |
Originally Posted by drmore
hopefully these new threads will solve the issue - won't have time to code/test that for a few days - but will be the first thing i'll do next in midimasher. |
| Chasidy Heckenbach 24.03.2012 | you finding the delay is just with the slicer functions or beatjumps from within midimasher? i.e: you're still using midimasher for any multi pages or gone back to native traktor mapping? led feedback on the launchpad is sloooow and i suspect that's where the issue is. looks like it won't take much code to create a new thread for each output anyway so then the main processing loop is never held up by any device. i probably should have thought of doing this from the getgo tbh. |
| Tawna Ulmen 24.03.2012 | Spent some more time testing this morning. There is defo a delay. After the first slice you start to miss a millisecond of the sound. For now im just using a grid of 8 pre defined beatjumps. That combined with beatmasher, gater, flangers and delays gives me all the crazy sounds I could need. Worked out how to use a free modifier as a page select button so now I can flick between 8 hotcue or 8 beatjumos without altering the rest of the pad. |
<< Back to Post and find Controller MappingsReply