Traktor Pro 1.2 Known Bugs with SE

[EanGolden]

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.

[lsmith]

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.

[djmoonie]

The single mapping for decks is definitely a good idea, but I think 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.

[lsmith]

Ok, so for the VCI-100 with a 4 deck mapping, what would I be doing to map say the "play" button?

[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.

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.

[lsmith]

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)

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?

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.

[lsmith]

Actually, I just realized that we were having this discussion in the totally wrong forum. 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.

[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?

[djmoonie]

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!

[lsmith]

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.