Fx automation and sample sequencing inside of Traktor (not simple but possible)
Home :: Post and find Controller Mappings :: Fx automation and sample sequencing inside of Traktor (not simple but possible)Reply
Fx automation and sample sequencing inside of Traktor (not simple but possible) Posted on: 24.04.2012 by Angella Mosiniak ... | |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
Ummm... btw I need a laser/photo sensor to encodes the strobedots on my TTs as a midi note, you got any ideas? Right now it looks like I'm going to have to build the thing myself with arduino boards or something... would be nice to just buy one.
|
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
so you're got 8 samples loaded into the sample decks from a key press or something - and automating the playing of samples 1 thru 8, changing on each beat correct? when someone presses say beat3 when it's playing a diff one i guess you map all other samples to mute or stop on that button press? that all seems fairly straightforward (well relatively ) still not sure about the loading of different samples tho while it's playing. be cool if it works tho. you're setting loops on the main deck and copying those to the sample decks or via the loop recorder? |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
every 8 beats you'll need to reload all 8 samples - or u intent continually loading them while other samples are being played? not sure that'd work as you won't have beats 1-8 for the current 8 beats loaded? or is this a one shot deal? i.e: click to load all samples into the 8 sample decks? once they're loaded the only automation needed will be to trigger them consecutively *but* not if the user has pressed a button to jump to a different one. doing it this way would be extremely simple using some midimasher code ofc - i wanted to slice the current track continually as it's playing - but your idea of just loading into sample decks is pretty cool too... i've added some timing code into dump.exe and here's a simulation of what i do to get to beat #7 using this debug config: Code:
open_midi_device("traktor", "traktor", "", "V:fake");
print "waiting..."
msleep(5000)
print "sending"
send("traktor", "jump_to_active_cue_point_a", ON)
send("traktor", "beatjump_+4_a", ON, 0, 1)
send("traktor", "beatjump_+4_a", OFF, 0, 2)
send("traktor", "beatjump_+2_a", ON, 0, 3)
send("traktor", "beatjump_+2_a", OFF, 0, 4)
send("traktor", "beatjump_+1_a", ON, 0, 5)
Code:
log filename (press enter for none): 1: Midi Through:0 2: LPD8:0 3: fake:0 choose a device: 3 q to quit CC 51 127 0xb5 0x33 0x7f chan=6 elapsed=3330.3 CC 21 127 0xb1 0x15 0x7f chan=2 elapsed=1.2 CC 21 0 0xb1 0x15 0x0 chan=2 elapsed=1.1 CC 20 127 0xb1 0x14 0x7f chan=2 elapsed=1.1 CC 20 0 0xb1 0x14 0x0 chan=2 elapsed=1.1 CC 19 127 0xb1 0x13 0x7f chan=2 elapsed=1.1 u can see it's not bang on 1ms between events but pretty damn close i ran that on linux - u can see how easy virtual midi ports are on mac and linux. loopMIDI does have a dll available for creating ports but i haven't managed to get access to it's api yet. if i can that would be a solution for windows - or maybe sometime i'll have a go at writing my own virtual midi port driver and just embed it into midimasher (for windows only) u can also see from that with coding in midimasher actually rarely needs midi details - it's all done via event names. u *can* also send midi if wanted ofc edit: so the timing info i added to dump.exe seems to work ok - will be in the next midimasher release or i can upload a copy sooner if u want it |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
you do love your TLA's - u should work for IBM seriously... that place is full of them. but the first thing u should do here is *stop* using them and just call your tsi a "LFO generator" or something - people will at least have some idea of what that means. best thing is to post a tsi and let people have a go i guess? i'll try it out anyway |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
worst case scenario in my code would be to jump to the 7th beat: * jump to active cue * beatjump +4 * beatjump +2 * beatjump +1 i don't use any delay between the "jump to active cue" and the first beatjump, after that i add a 1ms delay between each midi ON and OFF message, so the final beatjump+1 would get sent 5ms after the initial jump to active cue this is almost unusable btw - u can def hear the delay. you need to aim for less than 3ms in total for anything like this probably. tho sounds like we are talking about different things as u mentioned "samples"? the whole point of the slicer is to continually slicer 8 beats through whatever track is playing - optionally looping back to the first beat and also optionally jumping back to the beat where it would have been as if you hadn't pressed the pad at all (this 2nd case i don't have implemented atm - used to have and may put it back in sometime) this 2nd case is quite cool, so while usually it will slice 1,2,3,4,5,6,7,8 if you press the 6th pad on the 3 count it will in effect play 1,2,6,4,5,6,7,8. atm in my code it will play 1,2,6,7,8,1,2,3,4... having the option to slice the same 8 beats is nice if u find an area u really want to mash up for a few seconds - but continually slicing thru the whole track is the most useful way of using it usually in loop mode midimasher drops the active cue at the current location on beat 1 - so basically just moving the grid of 8 beats through the track you're using 8 samples? one in each sample deck and auto loading them at a given point in time when a button is pressed or something? that would also be very cool - kind of grabbing a section of the tune mpc style - but not a slicer like the twitch has if the 30s is the setup time to grab those samples then that's not a biggie - you just need to ensure any performance-dependant delays are kept to a minimum |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
not easy to time tho... the actual logic basically just queue's up any messages to be sent out instantly via a different thread and to another queue for any messages to be sent out in the future - where we have to leave about 2ms between each message we send for *certain* stacking of commands. actual processing of logic in midimasher ofc has to take a lot less than 1 ms. i was getting around 400 micro seconds to process fairly complicated logic a few months ago, but there's been a lot of performance improvements since then with the multi threading and other mods. it's not so easy to time how long things now take in midimasher with the various threads performing different tasks. *most* processing is quite simple ofc, i.e: outputting some value based on the input and maybe a conditional case. for midi timing u can download RtMidi C++ library and run the cmidi example that comes with it. it includes the delta time since the last event. i could add a timing option to dump(.exe) that comes with midimasher (that uses RtMidi anyway) if you needed a compiled binary. for pure performance testing you really want to do very little processing and just output the timing info i guess. i could add a flag in to do that if needed. the standard app on windows that people use is midi-ox, i'm not sure if that includes timestamps though. also once you need to start measuring times smaller than 1ms you have to take into account the jitter since windows is pretty far away from being a real time system. |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
Originally Posted by Phi
also it's not bound to just traktor - and personally i'm now doing almost all my effects in ableton live (with traktor routed into it). there's no comparison in flexibility between traktor and ableton. all i'm using traktor for is for the basic dj control over 2 decks and sometimes the sample decks. all eq+effects i am doing in ableton. as for the midi port issue - it's never going to be as easy on windows as mac or linux. just one reason why most serious musicians use mac. if i can i will build a virtual midi port into the windows version tho sometime. i'm almost finished with a new simple scripting format for midimasher, might even get a release out today. i'm using the LPEG lib to to the transation, you may not know any LUA but you might find this interesting anyway http://www.inf.puc-rio.br/~roberto/lpeg/. you sound like u have a mathematical mind and coding+grammars etc is only applied mathematics.
Example: getting a single button press to trigger multiple outputs is easy, and I can introduce internal rhythms and cycles across multiple logical controllers that act like separate logic-engines or events. So it looks to me like outside of changing the actual midi-note/channel, there isn't a real difference when it comes to automation within Traktor.
I see that MM is setting up logical conditions outside of the program, and MLA uses the built in conditional variables, so possibly, MM can use extra logic on top of Traktor's to get around the two condition limit, but MLA can also shoot the output to another LC for processing with it's own separate conditions and send the output back to the original controller. I'm not familiar enough with MM to actually know what it is capable of BUT it does seem like it still is limited in the exact same respects as MLA because they both ultimately feed into Traktor for the final processing, correct?
when using mm with traktor (i'm using it with traktor+mixxx+ableton atm) then ofc it can only make traktor do what traktor can do
Btw please don't read this as criticism, because I DO understand the value of a cross-platform midi in/out manipulator and I believe MM sounds like an incredible program and I will definitely use it out of genuine curiosity I just am only looking at automation in Traktor and the idea of using external logic or processing to do the same tasks that the program can handle internally seems obtuse.
there's no way i want to waste all the effort i am putting into my setup. with midimasher it's almost plug and play between different controllers and apps. the device definition file takes care of isolating the midi/hid specific implementation for any controller or application (they're both just seen as devices in mm that it can read/write to) |
| Chasidy Heckenbach 27.04.2012 |
Originally Posted by Phi
also setup is currently a pain on windows as it doesn't have builtin virtual midi ports - it does on mac and linux. midimasher is my own pet project, just in my spare time, and at this stage of the game it's the antithesis to what u want re: easy setup for the user. on mac if a user doesn't want to edit configs all they need to do is download and run. tho it does also require it's tsi to be loaded. i'm happy with the core functionality of midimasher but it needs some polish
I've always wanted to use mixx or anything like that, but as a turntablist my main concern has been on the timecode stickerdrift and whatnot. Do you know how they stack up against Traktor in the scratching/juggling department?
from what i've read vdj is at least as good as traktor in that regard - but mixxx has some stability issues. mixxx uses the code from xwax which itself is very good when used standalone but doesn't provide extra stuff like controller support or midi mapping. it's *just* a dvs - but does that very well. also xwax and vdj can use almost any timecode - so you're not locked into proprietary hardware. |
| Chasidy Heckenbach 27.04.2012 |
Originally Posted by Phi
I'm comming from the perspective of the User end of the Stanton scs.3 system, and just having to manually open "darouter" before using Traktor is a negative in user experience.
the thing is tho... that a lot of manufacturers do something similar to darouter but they package it up as a "driver" when it's not really. if darouter was set to auto start when u plugged in the scs.3d and ran silently as an icon in the taskbar then people wouldn't know about it and wouldn't care.
If you can make the user experience seamless, sure put all the extra stuff in there, but just remember that most people want more functionality with less "hands on" time. Another problem I had was that I needed to modify a darouter preset, and was instructed to buy BMT or get someone with it to author me a new preset, but I couldn't get a response on their community
so I was stuck with needing a button at the bottom of my fader until I realized how to do the instant gratification with only modifiers. So yeah, consistent filetypes are a concern for the user.
there's also some chatter going on on the mixxx mailing list about midi scripting and setup. if we can get that right (and get the app itself usable) then mixxx should be able to do all this stuff internally and be nice and seamless for the end user. vdj8 is also looking very interesting. one advantage for me of midimasher is that since it is external to any app, and device/app specific midi are isolated separately to the actual config code, then i can in theory use a config that makes a vdi100 work with traktor and then use the *exact same* config and use a mixtrack with vdj in the same way (so long as the mixtrack and vci100 have the same main set of controls and the features being used in traktor are also available in vdj) so someone can come up with cool features/layouts/plugins for their own controller+software and it can be used by someone else even if they're not using the same controller or even software. |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
Ummm... btw I need a laser/photo sensor to encodes the strobedots on my TTs as a midi note, you got any ideas? Right now it looks like I'm going to have to build the thing myself with arduino boards or something... would be nice to just buy one.
|
| Angella Mosiniak 29.04.2012 | ... |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
so you're got 8 samples loaded into the sample decks from a key press or something - and automating the playing of samples 1 thru 8, changing on each beat correct? when someone presses say beat3 when it's playing a diff one i guess you map all other samples to mute or stop on that button press? that all seems fairly straightforward (well relatively ) still not sure about the loading of different samples tho while it's playing. be cool if it works tho. you're setting loops on the main deck and copying those to the sample decks or via the loop recorder? |
| Angella Mosiniak 29.04.2012 | ... |
| Angella Mosiniak 29.04.2012 | ... |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
every 8 beats you'll need to reload all 8 samples - or u intent continually loading them while other samples are being played? not sure that'd work as you won't have beats 1-8 for the current 8 beats loaded? or is this a one shot deal? i.e: click to load all samples into the 8 sample decks? once they're loaded the only automation needed will be to trigger them consecutively *but* not if the user has pressed a button to jump to a different one. doing it this way would be extremely simple using some midimasher code ofc - i wanted to slice the current track continually as it's playing - but your idea of just loading into sample decks is pretty cool too... i've added some timing code into dump.exe and here's a simulation of what i do to get to beat #7 using this debug config: Code:
open_midi_device("traktor", "traktor", "", "V:fake");
print "waiting..."
msleep(5000)
print "sending"
send("traktor", "jump_to_active_cue_point_a", ON)
send("traktor", "beatjump_+4_a", ON, 0, 1)
send("traktor", "beatjump_+4_a", OFF, 0, 2)
send("traktor", "beatjump_+2_a", ON, 0, 3)
send("traktor", "beatjump_+2_a", OFF, 0, 4)
send("traktor", "beatjump_+1_a", ON, 0, 5)
Code:
log filename (press enter for none): 1: Midi Through:0 2: LPD8:0 3: fake:0 choose a device: 3 q to quit CC 51 127 0xb5 0x33 0x7f chan=6 elapsed=3330.3 CC 21 127 0xb1 0x15 0x7f chan=2 elapsed=1.2 CC 21 0 0xb1 0x15 0x0 chan=2 elapsed=1.1 CC 20 127 0xb1 0x14 0x7f chan=2 elapsed=1.1 CC 20 0 0xb1 0x14 0x0 chan=2 elapsed=1.1 CC 19 127 0xb1 0x13 0x7f chan=2 elapsed=1.1 u can see it's not bang on 1ms between events but pretty damn close i ran that on linux - u can see how easy virtual midi ports are on mac and linux. loopMIDI does have a dll available for creating ports but i haven't managed to get access to it's api yet. if i can that would be a solution for windows - or maybe sometime i'll have a go at writing my own virtual midi port driver and just embed it into midimasher (for windows only) u can also see from that with coding in midimasher actually rarely needs midi details - it's all done via event names. u *can* also send midi if wanted ofc edit: so the timing info i added to dump.exe seems to work ok - will be in the next midimasher release or i can upload a copy sooner if u want it |
| Angella Mosiniak 29.04.2012 | ... |
| Angella Mosiniak 29.04.2012 | ... |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
you do love your TLA's - u should work for IBM seriously... that place is full of them. but the first thing u should do here is *stop* using them and just call your tsi a "LFO generator" or something - people will at least have some idea of what that means. best thing is to post a tsi and let people have a go i guess? i'll try it out anyway |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
worst case scenario in my code would be to jump to the 7th beat: * jump to active cue * beatjump +4 * beatjump +2 * beatjump +1 i don't use any delay between the "jump to active cue" and the first beatjump, after that i add a 1ms delay between each midi ON and OFF message, so the final beatjump+1 would get sent 5ms after the initial jump to active cue this is almost unusable btw - u can def hear the delay. you need to aim for less than 3ms in total for anything like this probably. tho sounds like we are talking about different things as u mentioned "samples"? the whole point of the slicer is to continually slicer 8 beats through whatever track is playing - optionally looping back to the first beat and also optionally jumping back to the beat where it would have been as if you hadn't pressed the pad at all (this 2nd case i don't have implemented atm - used to have and may put it back in sometime) this 2nd case is quite cool, so while usually it will slice 1,2,3,4,5,6,7,8 if you press the 6th pad on the 3 count it will in effect play 1,2,6,4,5,6,7,8. atm in my code it will play 1,2,6,7,8,1,2,3,4... having the option to slice the same 8 beats is nice if u find an area u really want to mash up for a few seconds - but continually slicing thru the whole track is the most useful way of using it usually in loop mode midimasher drops the active cue at the current location on beat 1 - so basically just moving the grid of 8 beats through the track you're using 8 samples? one in each sample deck and auto loading them at a given point in time when a button is pressed or something? that would also be very cool - kind of grabbing a section of the tune mpc style - but not a slicer like the twitch has if the 30s is the setup time to grab those samples then that's not a biggie - you just need to ensure any performance-dependant delays are kept to a minimum |
| Angella Mosiniak 29.04.2012 | ... |
| Angella Mosiniak 29.04.2012 | ... |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
not easy to time tho... the actual logic basically just queue's up any messages to be sent out instantly via a different thread and to another queue for any messages to be sent out in the future - where we have to leave about 2ms between each message we send for *certain* stacking of commands. actual processing of logic in midimasher ofc has to take a lot less than 1 ms. i was getting around 400 micro seconds to process fairly complicated logic a few months ago, but there's been a lot of performance improvements since then with the multi threading and other mods. it's not so easy to time how long things now take in midimasher with the various threads performing different tasks. *most* processing is quite simple ofc, i.e: outputting some value based on the input and maybe a conditional case. for midi timing u can download RtMidi C++ library and run the cmidi example that comes with it. it includes the delta time since the last event. i could add a timing option to dump(.exe) that comes with midimasher (that uses RtMidi anyway) if you needed a compiled binary. for pure performance testing you really want to do very little processing and just output the timing info i guess. i could add a flag in to do that if needed. the standard app on windows that people use is midi-ox, i'm not sure if that includes timestamps though. also once you need to start measuring times smaller than 1ms you have to take into account the jitter since windows is pretty far away from being a real time system. |
| Angella Mosiniak 29.04.2012 | Btw how many ms does your beatslicer take in total? Also, if you are using a windows friendly program to time midi I'd really appreciate a link. Thanx |
| Chasidy Heckenbach 29.04.2012 |
Originally Posted by Phi
Originally Posted by Phi
also it's not bound to just traktor - and personally i'm now doing almost all my effects in ableton live (with traktor routed into it). there's no comparison in flexibility between traktor and ableton. all i'm using traktor for is for the basic dj control over 2 decks and sometimes the sample decks. all eq+effects i am doing in ableton. as for the midi port issue - it's never going to be as easy on windows as mac or linux. just one reason why most serious musicians use mac. if i can i will build a virtual midi port into the windows version tho sometime. i'm almost finished with a new simple scripting format for midimasher, might even get a release out today. i'm using the LPEG lib to to the transation, you may not know any LUA but you might find this interesting anyway http://www.inf.puc-rio.br/~roberto/lpeg/. you sound like u have a mathematical mind and coding+grammars etc is only applied mathematics.
Example: getting a single button press to trigger multiple outputs is easy, and I can introduce internal rhythms and cycles across multiple logical controllers that act like separate logic-engines or events. So it looks to me like outside of changing the actual midi-note/channel, there isn't a real difference when it comes to automation within Traktor.
I see that MM is setting up logical conditions outside of the program, and MLA uses the built in conditional variables, so possibly, MM can use extra logic on top of Traktor's to get around the two condition limit, but MLA can also shoot the output to another LC for processing with it's own separate conditions and send the output back to the original controller. I'm not familiar enough with MM to actually know what it is capable of BUT it does seem like it still is limited in the exact same respects as MLA because they both ultimately feed into Traktor for the final processing, correct?
when using mm with traktor (i'm using it with traktor+mixxx+ableton atm) then ofc it can only make traktor do what traktor can do
Btw please don't read this as criticism, because I DO understand the value of a cross-platform midi in/out manipulator and I believe MM sounds like an incredible program and I will definitely use it out of genuine curiosity I just am only looking at automation in Traktor and the idea of using external logic or processing to do the same tasks that the program can handle internally seems obtuse.
there's no way i want to waste all the effort i am putting into my setup. with midimasher it's almost plug and play between different controllers and apps. the device definition file takes care of isolating the midi/hid specific implementation for any controller or application (they're both just seen as devices in mm that it can read/write to) |
| Angella Mosiniak 28.04.2012 | ... |
| Angella Mosiniak 28.04.2012 | ... |
| Chasidy Heckenbach 27.04.2012 |
Originally Posted by Phi
also setup is currently a pain on windows as it doesn't have builtin virtual midi ports - it does on mac and linux. midimasher is my own pet project, just in my spare time, and at this stage of the game it's the antithesis to what u want re: easy setup for the user. on mac if a user doesn't want to edit configs all they need to do is download and run. tho it does also require it's tsi to be loaded. i'm happy with the core functionality of midimasher but it needs some polish
I've always wanted to use mixx or anything like that, but as a turntablist my main concern has been on the timecode stickerdrift and whatnot. Do you know how they stack up against Traktor in the scratching/juggling department?
from what i've read vdj is at least as good as traktor in that regard - but mixxx has some stability issues. mixxx uses the code from xwax which itself is very good when used standalone but doesn't provide extra stuff like controller support or midi mapping. it's *just* a dvs - but does that very well. also xwax and vdj can use almost any timecode - so you're not locked into proprietary hardware. |
| Chasidy Heckenbach 27.04.2012 |
Originally Posted by Phi
I'm comming from the perspective of the User end of the Stanton scs.3 system, and just having to manually open "darouter" before using Traktor is a negative in user experience.
the thing is tho... that a lot of manufacturers do something similar to darouter but they package it up as a "driver" when it's not really. if darouter was set to auto start when u plugged in the scs.3d and ran silently as an icon in the taskbar then people wouldn't know about it and wouldn't care.
If you can make the user experience seamless, sure put all the extra stuff in there, but just remember that most people want more functionality with less "hands on" time. Another problem I had was that I needed to modify a darouter preset, and was instructed to buy BMT or get someone with it to author me a new preset, but I couldn't get a response on their community
so I was stuck with needing a button at the bottom of my fader until I realized how to do the instant gratification with only modifiers. So yeah, consistent filetypes are a concern for the user.
there's also some chatter going on on the mixxx mailing list about midi scripting and setup. if we can get that right (and get the app itself usable) then mixxx should be able to do all this stuff internally and be nice and seamless for the end user. vdj8 is also looking very interesting. one advantage for me of midimasher is that since it is external to any app, and device/app specific midi are isolated separately to the actual config code, then i can in theory use a config that makes a vdi100 work with traktor and then use the *exact same* config and use a mixtrack with vdj in the same way (so long as the mixtrack and vci100 have the same main set of controls and the features being used in traktor are also available in vdj) so someone can come up with cool features/layouts/plugins for their own controller+software and it can be used by someone else even if they're not using the same controller or even software. |
| Angella Mosiniak 27.04.2012 | Midimasher sounds pretty cool, I'll go give it a shot in a while... I've always wanted to use mixx or anything like that, but as a turntablist my main concern has been on the timecode stickerdrift and whatnot. Do you know how they stack up against Traktor in the scratching/juggling department? The idea of learning how to write scripts in one of these programs seems a little intimidating since I don't have any experience with programming. I also really like TSPs FX too, but I believe that routing audio through Ableton will eventually give me more flexibility. Oh yeah! and I want to stay on TSP for the maschine integration that is somewhere on their timeline I just want to see Traktor use all the raw power that it has built into the modified system. |
| Angella Mosiniak 27.04.2012 | No you don't sound negative at all. Thank you. You have no idea how much it helps me to actually talk to someone who knows about these kinds of things. I'm comming from the perspective of the User end of the Stanton scs.3 system, and just having to manually open "darouter" before using Traktor is a negative in user experience. If you can make the user experience seamless, sure put all the extra stuff in there, but just remember that most people want more functionality with less "hands on" time. Another problem I had was that I needed to modify a darouter preset, and was instructed to buy BMT or get someone with it to author me a new preset, but I couldn't get a response on their community , so I was stuck with needing a button at the bottom of my fader until I realized how to do the instant gratification with only modifiers on a fader. So yeah, consistent filetypes are a concern for the user. |
| Chasidy Heckenbach 27.04.2012 |
Originally Posted by Phi
if you're on mac then you already have virtual midi port functionality builtin via the IAC driver. i presume you could just create one port (that could be created on the fly by some extra app/driver like midimasher does) and read+write to it in traktor. windows is more of a pain tho - you have to use extra vmidi software. i used to use loopMIDI when i had to run windows.
and it would be in a consistent file format to easily update existing feature sets as new automation scripts are written. we just need a developers tool for working with midi-loop-automation on the programming end.
if on mac, and you can do all the logic in the tsi, then you could use the same backdoor that xtrememapping uses for reading/writing tsi files. i'm not aware of any way of modifying tsi's outside of the traktor controller editor on windows. you used to be able to before they encrypted them (pre traktor pro)
Thanks for the good input zestoi. It is much appreciated.
for me the whole traktor mapping method is a pain and limited compared to apps like vdj or mixxx - which is why i started my midimasher project. it also has all the same kind of functionality as midikatapult which lets u create virtual layers and coloured layouts on a controller like a launchpad and lets you do all your mapping within it's own config files using a big tsi file that it hooks into. |
| Angella Mosiniak 26.04.2012 |
Originally Posted by zestoi
No downloads, not something you need to run in the background, not something the end user pays for, or even knows is there, complete plug-n-play automation built into Traktor controllers. that would be a vast difference than what we have now... and it would be in a consistent file format to easily update existing feature sets as new automation scripts are written. we just need a developers tool for working with midi-loop-automation on the programming end. ok, I'm off work so now I'll try to work on the beatslicer. Thanks for the good input zestoi. It is much appreciated. |
| Chasidy Heckenbach 26.04.2012 |
Originally Posted by Phi
would be very useful if with some set of cascading modifiers u could say "to automatically fire an event on offbeat of beat 3 use these as conditions: MX=A and MY=B" if it all works then u could come up with a table of those conditions be even better if u could apply more than 2 modifier conditions to a control as then u could use extra modifier conditions to enable/disable events |
| Chasidy Heckenbach 26.04.2012 | it's definitely the most interesting possible solution to the issue i've heard so far... if you can cascade the counting from M1 thru to say M8 and if that gives u a fine enough timing and all counters are reset to zero at the start of a beat u could then just do something like: jump to active cue: cond M1=0, M8=0 beatjump+1 : cond M1=0, M8=1 beatjump+2 : cond M1=0, M8=2 since the modifier conditions should mask any other logic that traktor is applying to the mapping no issue with using up all modifiers ofc as u can just use a separate generic midi device for this mapping this would also work for me... i'd just map extra midimasher events like jumptobeat_4_a, jumptobeat_3_a etc |
| Angella Mosiniak 26.04.2012 | You really don't see a company being able to build plug-n-play automation into Traktor controllers as being REALLY useful in the controller industry? |
| Angella Mosiniak 26.04.2012 | ... |
| Chasidy Heckenbach 26.04.2012 |
Originally Posted by photojojo
and if u try to just stack the jump1+jump2 to the same control within your tsi traktor uses the first one u mapped and ignores the 2nd. quite interesting that *sometimes* the order u add stuff to your tsi *does* matter u can use an "inverted direct" control to map the jump+2 to the same pad as the jump+1, since then it only fires when u release, but that adds in more of a delay than the needed 2ms anyway i also don't remember off hand what happens if u map "jump to active cue" and jump+2 to the same button but i believe that bit works... |
| Leeanna Ayla 26.04.2012 | This stuff is mostly way over my head, but on jumping three beats could you jump 1 beat, 1 beat then 2 1/2 beats or is that not the same thing? |
| Chasidy Heckenbach 26.04.2012 | cool - i'll be interested in anything u come up with |
| Angella Mosiniak 26.04.2012 | I'm going to work on it toevening ... Maybe have a .tsi by dawn, thanks for the help |
<< Back to Post and find Controller MappingsReply