Traktor Pro 1.2 Known Bugs with SE

Home :: DJ TechTools' VCI-100 FAQ :: Traktor Pro 1.2 Known Bugs with SEReply
Traktor Pro 1.2 Known Bugs with SE
Posted on: 27.07.2009 by
Here are the bugs I have found with the SE mapping version 2.2 and traktor version 1.2

  • Filter: broken
  • pitch fader: basically broken


both of these problems are very easily fixed and a new TSI will be send out shortly. Please post any additional bugs here.
alfredo moreira
21.11.2009
Originally Posted by kilbot
i've also tried booting the 100se in 1.2 mode (the paper says to hold down the second small button in the top left when turning on) this also does not appear to do anything...
figured it out! it's the first small black button on the top left... which i suppose is technically the second button.... (had to re-watch some of ean's videos where he explained it)
alfredo moreira
21.11.2009
Originally Posted by lsmith
ok .. i fixed the issue by changing the knobs from "direct" to "relative". it seems the "relative filter/knob" controller type doesnt exist anymore.
i have the same problem with the filter knobs. i tried mapping them myself, but no luck. and changing to relative mode didn't seem to help at all.
so this seems to be the controller itself sending out multiple midi msgs from the 'filter' knobs.
is this a FW1.3 thing?
its very screwy, with my old silver 1.2 vci, it doesnt do this, and setting those knobs is no problem.
i've also tried booting the 100se in 1.2 mode (the paper says to hold down the second small button in the top left when turning on) this also does not appear to do anything...
Leota Saniuk
29.07.2009
Originally Posted by lsmith
When I checked the assignments, I noticed some errors that I was able to fix:
juggle knob modifier #3 out messages: here i just removed the M3=1 for Note E5 and Note G#3
deck D: here i removed the M8=2 for Note B4
left EQ/FX: here i removed the M1=1 for Note C5

This fixed my LED issues. Not sure if this was just some wierd import issue. I do not have my other laptop with the 1.1.2 install handy right now to check how things were mapped there.
I confirmed that the mapping was properly imported. However could it maybe be that there was a but in 1.1.2 that caused the superflous modifiers to be ignored for MIDI out messages?

Originally Posted by lsmith
Found another issue with the two filter knobs. I am not quite sure how these work exactly. They send different MIDI messages from left to the middle, right at the middle and right of the middle. As a result when turning the knobs from left to right the knobs actually turns through all the way twice. So in other words, when I move the knob to the middle position and move it left, it actually moves the actual setting to all the way to the right. And then i move it to the right from the middle position, the actual setting is set to all the way to the left. Is that a feature I just never realized before or is this a new issue with 1.2?
ok .. i fixed the issue by changing the knobs from "direct" to "relative". it seems the "relative filter/knob" controller type doesnt exist anymore.
Leota Saniuk
29.07.2009
Originally Posted by djmoonie
This does the same job at the 'tsi' mapping level. A single mapping of the command 'PLAY' would be propagated to all the physical controls that have been associated with it at the hardware map level.
i might be a bit dense here, but you still need to map out that play button for each deck separately. i can see it being nice to be able to pay it to a name, because then i supposed you could easily trigger multiple commands from one name.

like you map out buttons to the "sampler" command and then you say that "sampler" means load FX beatmasher into FX slot 2, turn down the length, turn up the dry wet etc.

so yeah for that kind of stuff this approach would be very nice indeed.

however the TP 1.2 approach tries to make a different use case efficient. right now the TP 1.2 solution is not yet finished for multi deck controllers. so lets talk about multiple 1 deck controllers. with TP 1.2 beta I would map that single deck controller once and can then buy 4 of them and run them off a single mapping.
Vernon Positano
29.07.2009
Originally Posted by lsmith
right .. but you still have 1 mapping for each deck you want to support. so this solution solves a different problem than the device target is trying to solve. the idea with the device target is to support multiple decks with a single mapping.
This does the same job at the 'tsi' mapping level. A single mapping of the command 'PLAY' would be propagated to all the physical controls that have been associated with it at the hardware map level.

If you are interested in the two tier approach, grab a copy of VDJ 6.0.1 demo and check out some of their config files, its an interesting approach. I also particularly love their new scripting engine, which basically allows you to do anything via midi, including complex multiple time based actions that currently are only available via something like bomes for traktor.

That said, sounds like I am doing an ad for VDJ, but I find that traktor has the edge generally regarding live performance, but the gap is now not so obvious!
Leota Saniuk
28.07.2009
Originally Posted by djmoonie
In the traditional one layer method, you would have to associate both buttons to the play command separately, and each button twice for each condition, associated with decks a,b,c,d.
command = action?

so you define that CC/note XYZ (left side) should trigger the action "PLAY" on deck A (in normal mode) and deck C (in deck C mode)

you also define that CC/note ABC (right side) should trigger the action "PLAY" on deck B (in normal mode) and deck D (in deck D mode)

Originally Posted by djmoonie
With the two layer approach, you associate the play buttons as 'related', and define a context in which they relate. Your second level mapping file would then simply have one line in it.. which would be something like:-
not sure what you mean with related here?

Originally Posted by djmoonie
CONTROL="PLAY_BUTTON" ACTION="PLAY"

The main benefit of the two layer approach is that if the hardware changes, the tsi file wouldn't necessarily have to, you just redefine the hardware layer file.
right .. but you still have 1 mapping for each deck you want to support. so this solution solves a different problem than the device target is trying to solve. the idea with the device target is to support multiple decks with a single mapping.

27.07.2009
Here are the bugs I have found with the SE mapping version 2.2 and traktor version 1.2

  • Filter: broken
  • pitch fader: basically broken


both of these problems are very easily fixed and a new TSI will be send out shortly. Please post any additional bugs here.
alfredo moreira
21.11.2009
Originally Posted by kilbot
i've also tried booting the 100se in 1.2 mode (the paper says to hold down the second small button in the top left when turning on) this also does not appear to do anything...
figured it out! it's the first small black button on the top left... which i suppose is technically the second button.... (had to re-watch some of ean's videos where he explained it)
alfredo moreira
21.11.2009
Originally Posted by lsmith
ok .. i fixed the issue by changing the knobs from "direct" to "relative". it seems the "relative filter/knob" controller type doesnt exist anymore.
i have the same problem with the filter knobs. i tried mapping them myself, but no luck. and changing to relative mode didn't seem to help at all.
so this seems to be the controller itself sending out multiple midi msgs from the 'filter' knobs.
is this a FW1.3 thing?
its very screwy, with my old silver 1.2 vci, it doesnt do this, and setting those knobs is no problem.
i've also tried booting the 100se in 1.2 mode (the paper says to hold down the second small button in the top left when turning on) this also does not appear to do anything...
Madeline Rega
22.10.2009
Thought it was a problem with 1.2 firmware, but I updated a couple weeks ago and I'm still having the problem. Sometimes when I hold down the juggle button it hangs up and sends my vci into juggle mode even though the knob isn't turned. I've read around and haven't heard of anybody else having this problem. Anybody?
komodia bee
04.08.2009
hi fellows,

i haven't posted much here but i've been using Ean's tks-tsi for such a long time. i've adventured myself to update traktor with the beta version since i was praying to have the proggressive pitch bend functionality.

but by doing so... currently i believe i've messed completely my setup, which was quite balanced in 1.1.2, thanks to the 2.2 tsi.

i have close to zero idea in terms of midi mapping, to be honest i'd work with it if the proper tools were provided but i can't hold more than half an hour dealing with the tiny controller mapping window without getting very nervous.

i take advantage in this post to thank Ean for his hard work and the amazing tools he provides here, again and again.

that said, here go my observations about 2.2.8 + traktor scratch pro 1.2:

when pressing the juggle button together with any of the buttons below the wheels, trying to sample, it now SETS cue markers instead of recalling them. crazy!

midi outs do not work at all. pressing juggle button lids up the keys as if the vci was in juggle mode, but when i let the button go, leds remain lid up.

reading rainer's pdf update (thank you for taking care of us as well!) i saw there's a new functionality named tempo bend (stepless). i tried to modify the tsi to check the news, however i've found myself surprised because Ean has 4 mappings for tempo bend per deck, and there are notes which i appear to believe that not all them (4) are related to the jog wheels. there are 2 up and 2 down, but some of them do not match with the notes that the wheel is sending. in summary, i'm really confused/lost...

2 questions here:

- Wouldn't it be enough with one up, one down, which happens to be A#3 (up) and B3 (down) as an example using left jogwheel?

- in case it's not enough.. Which is the use of the other two commands? (D8 (down) and C#8 (up) for Deck A)

also, there's the chance to swich the 'old' tempo bend assignments to a new mode: 'encoder', instead of the previous 'button'.

so, i've ended basically marking the checkbox 'pitch bend progressive sensitivity', setting the sensibility to 15% which is close to what i like by now.

anyway, i'd like to understand which is the difference between tempo bend (as i have it now, button mode, although assigned to an encoder, the jogwheel) and tempo bend stepless (and the possible variations.. button, encoder..?)

so i'm going to try...

however, I would love to have an Ean's tsi for this beta... i feel like.. you know.. out of control modifying these things by myself

thanks!!!
Leota Saniuk
29.07.2009
Originally Posted by lsmith
When I checked the assignments, I noticed some errors that I was able to fix:
juggle knob modifier #3 out messages: here i just removed the M3=1 for Note E5 and Note G#3
deck D: here i removed the M8=2 for Note B4
left EQ/FX: here i removed the M1=1 for Note C5

This fixed my LED issues. Not sure if this was just some wierd import issue. I do not have my other laptop with the 1.1.2 install handy right now to check how things were mapped there.
I confirmed that the mapping was properly imported. However could it maybe be that there was a but in 1.1.2 that caused the superflous modifiers to be ignored for MIDI out messages?

Originally Posted by lsmith
Found another issue with the two filter knobs. I am not quite sure how these work exactly. They send different MIDI messages from left to the middle, right at the middle and right of the middle. As a result when turning the knobs from left to right the knobs actually turns through all the way twice. So in other words, when I move the knob to the middle position and move it left, it actually moves the actual setting to all the way to the right. And then i move it to the right from the middle position, the actual setting is set to all the way to the left. Is that a feature I just never realized before or is this a new issue with 1.2?
ok .. i fixed the issue by changing the knobs from "direct" to "relative". it seems the "relative filter/knob" controller type doesnt exist anymore.
Leota Saniuk
29.07.2009
Originally Posted by djmoonie
This does the same job at the 'tsi' mapping level. A single mapping of the command 'PLAY' would be propagated to all the physical controls that have been associated with it at the hardware map level.
i might be a bit dense here, but you still need to map out that play button for each deck separately. i can see it being nice to be able to pay it to a name, because then i supposed you could easily trigger multiple commands from one name.

like you map out buttons to the "sampler" command and then you say that "sampler" means load FX beatmasher into FX slot 2, turn down the length, turn up the dry wet etc.

so yeah for that kind of stuff this approach would be very nice indeed.

however the TP 1.2 approach tries to make a different use case efficient. right now the TP 1.2 solution is not yet finished for multi deck controllers. so lets talk about multiple 1 deck controllers. with TP 1.2 beta I would map that single deck controller once and can then buy 4 of them and run them off a single mapping.
Vernon Positano
29.07.2009
Originally Posted by lsmith
right .. but you still have 1 mapping for each deck you want to support. so this solution solves a different problem than the device target is trying to solve. the idea with the device target is to support multiple decks with a single mapping.
This does the same job at the 'tsi' mapping level. A single mapping of the command 'PLAY' would be propagated to all the physical controls that have been associated with it at the hardware map level.

If you are interested in the two tier approach, grab a copy of VDJ 6.0.1 demo and check out some of their config files, its an interesting approach. I also particularly love their new scripting engine, which basically allows you to do anything via midi, including complex multiple time based actions that currently are only available via something like bomes for traktor.

That said, sounds like I am doing an ad for VDJ, but I find that traktor has the edge generally regarding live performance, but the gap is now not so obvious!
Leota Saniuk
29.07.2009
Found another issue with the two filter knobs. I am not quite sure how these work exactly. They send different MIDI messages from left to the middle, right at the middle and right of the middle. As a result when turning the knobs from left to right the knobs actually turns through all the way twice. So in other words, when I move the knob to the middle position and move it left, it actually moves the actual setting to all the way to the right. And then i move it to the right from the middle position, the actual setting is set to all the way to the left. Is that a feature I just never realized before or is this a new issue with 1.2?
Leota Saniuk
29.07.2009
Actually, I just realized that we were having this discussion in the totally wrong community . Sorry for even having put in that side comment. If one of the moderators can move this side discussion I would appreciate it.

Anyways I have reinstalled everything again. In terms of bugs I am now only having some issues with the LED's. Specifically the juggle LED, the left EQ/FX LED and the deck D LED remain lid if they are enabled once. The underlying functionality works properly though.

When I checked the assignments, I noticed some errors that I was able to fix:
juggle knob modifier #3 out messages: here i just removed the M3=1 for Note E5 and Note G#3
deck D: here i removed the M8=2 for Note B4
left EQ/FX: here i removed the M1=1 for Note C5

This fixed my LED issues. Not sure if this was just some wierd import issue. I do not have my other laptop with the 1.1.2 install handy right now to check how things were mapped there.
Leota Saniuk
28.07.2009
Originally Posted by djmoonie
In the traditional one layer method, you would have to associate both buttons to the play command separately, and each button twice for each condition, associated with decks a,b,c,d.
command = action?

so you define that CC/note XYZ (left side) should trigger the action "PLAY" on deck A (in normal mode) and deck C (in deck C mode)

you also define that CC/note ABC (right side) should trigger the action "PLAY" on deck B (in normal mode) and deck D (in deck D mode)

Originally Posted by djmoonie
With the two layer approach, you associate the play buttons as 'related', and define a context in which they relate. Your second level mapping file would then simply have one line in it.. which would be something like:-
not sure what you mean with related here?

Originally Posted by djmoonie
CONTROL="PLAY_BUTTON" ACTION="PLAY"

The main benefit of the two layer approach is that if the hardware changes, the tsi file wouldn't necessarily have to, you just redefine the hardware layer file.
right .. but you still have 1 mapping for each deck you want to support. so this solution solves a different problem than the device target is trying to solve. the idea with the device target is to support multiple decks with a single mapping.
Vernon Positano
28.07.2009
In the traditional one layer method, you would have to associate both buttons to the play command separately, and each button twice for each condition, associated with decks a,b,c,d.

With the two layer approach, you associate the play buttons as 'related', and define a context in which they relate. Your second level mapping file would then simply have one line in it.. which would be something like:-

CONTROL="PLAY_BUTTON" ACTION="PLAY"

The main benefit of the two layer approach is that if the hardware changes, the tsi file wouldn't necessarily have to, you just redefine the hardware layer file.
Leota Saniuk
28.07.2009
Ok, so for the VCI-100 with a 4 deck mapping, what would I be doing to map say the "play" button?
Vernon Positano
28.07.2009
The single mapping for decks is definitely a good idea, but I believe there is a better way to do it, an approach infact that virtual dj have taken.

You have two layers of configuration.. one to define the hardware, and how it handles midi, including what controls share the same functionality, and a second layer, which we already know as the tsi file.

The only difference then, would be that the tsi file maps commands to named controls, rather than directly to notes and cc's. It would be the hardware config file that tells you what buttons, knobs and sliders have what names, and what notes/cc they relate to.

Using this approach, you have ultimate flexibility.
Leota Saniuk
27.07.2009
hrmm .. this is really odd. i tried on two laptops and things were all over the place with my vci-100se. back to 1.1 and all is well. then again i would be surprised if the level of breakage i am seeing would be representative of what other people are seeing, because then armies of users would be up in arms.

anyways good to hear that my issues as severe as they seem to be are isolated to my setyup. now i just gotta figure out whats going wrong with my setup.

btw: ean i really hope you can encourage NI to enable you to only have to maintain a single mapping for deck A/C and B/D. plus I see potential for a new vestax firmware that would turn each of the sides of the vci into a virtual midi controller that sends the same messages for both sides of the deck. if NI would then support selecting the deck target via a global modifier, all 4 decks could be handled by a single mapping. this could be a huge simplication and ease maintenance. also it would be kind of neat if the device target would also be supported for the fx units. like i said on the blog, NI is opening the door to a lot of goodness .. however there are a few minor features to add to make it all come together nicely.

<< Back to DJ TechTools' VCI-100 FAQReply

Copyright 2012-2023
DJRANKINGS.ORG n.g.o.
Chuo-ku, Osaka, Japan

Created by Ajaxel CMS

Terms & Privacy