Seriously, I like these enough that I'd just buy three PL-1's... but having to update TWELVE copies of each mapping every time I want to change one control, just because Behringer made a bad decision.... It's just not worth it.
Printable View
Seriously, I like these enough that I'd just buy three PL-1's... but having to update TWELVE copies of each mapping every time I want to change one control, just because Behringer made a bad decision.... It's just not worth it.
And as I've explained before, it's not about updating the firmware. I don't need to hire someone to do it - I already have a team that does that. I think that a flat mapping that relies on modifiers is MORE COMPLICATED for the user than a 1:1 mapping (which the PL-1 has). I think that a flat mapping is also less friendly to other applications that want to take advantage of the possible modality but don't have modifiers (or don't want to dedicate modifiers to deck switching).Quote:
Also, seriously, all Behringer has to do is pay someone to build a modifier into the driver and release an update to the firmware.
Since you've brought it up, let's talk about complexity. The way the PL-1 is set up, all a user has to do is press learn in the software, then press the button. It's all 1:1. If a user wants to change a single control (for example), they have to make 4 small changes to the mapping. That change would typically consist of adding in the command, pressing learn, then pressing a button. To do it YOUR way, the user has to do the same thing, but then also keep track of modifier states and logic. MY way is easier to understand for the vast majority of users. The TSI is also more clear with my "stupid system", because there aren't any double or triple mappings.
Opinions vary. And if the majority of users report that they would rather have a flat, modifier-based mapping, I'm sure we can accommodate. But YOU do not represent the majority. You represent a tiny minority of users that have a deep understanding of Traktor's MIDI configuration and create your own mappings. I'm not going to tailor these controllers to experts, because that isn't what they're about. CMD is about making controllers accessible. If you want a more advanced controller, there are certainly plenty of cool ones out there.
Dear god I hope it's not. Middleware sucks, give me class compliant midi devices!
CMD controllers are all class complaint for MIDI operation. The CMD Studio 4a needs an ASIO driver installed because you don't want Windows handling audio performance (in OSX no driver is needed for the 4a).
No, no, no, no, no. You're acting like I'm suggesting a "flat system" where the deck button is just a normal midi button, and all mapping should be done with modifiers. I've never once said that this is what you should do... And you know this, because in this same message you referred to the ACTUAL change I'm suggesting, which is that there needs to be a feature that allows you to turn off access to certain firmware pages on the PL-1. This way you could choose which pageswere part of the "list" scrolled through by the deck button. So if you turned off 2 and 4, the deck button would just alternate between 1 and 3, etc.
Okay so here, I'm going to explain as simply as possible, with examples, how much extra work is required for your work around, and how much more complicated it would be for the average user who doesn't know mapping very well. Then I'll explain how simple it would be if you just added the ability to toggle off access to certain decks. I'll explain with an example:
The goal of the user is to set up a mapping for two PL-1's to control four track decks, so that the left PL-1 controls A and C, and the right to control B and D. This is how the user would map, for example, the play/pause button, on decks A and C, on the left PL-1.
----
Your current way (the workaround for your own system):
1) create the play/pause control
2) set deck affected to A
3) select firmware page 1 with the deck button
4) click learn
5) press the play button
6) duplicate the control
7) set deck affected to A
8) select firmware page 2 with the deck button
9) click learn
10) press the play button
11) duplicate the control
12) set deck affected to C
13) select firmware page 3 with the deck button
14) click learn
15) press the play button
16) duplicate the control
17) set deck affected to C
18) select firmware page 4 with the deck button
19) click learn
20) press the play button
Just to map one control on one PL-1. This process has to be repeated for every single control and every single modifier.
Plus then, because this is a workaround, you always have to remember that the LED readout is now incorrect, and decks 1 and 3 are A, and decks 2 and 4 are B.
-----
With the edit I'm suggesting, with access to firmware pages 2 and 4 switched off.
1) create the play/pause control
2) set deck affected to A
3) select firmware page 1 with the deck button
4) click learn
5) press the play button
6) duplicate the control
7) set deck affected to C
8) select firmware page 3 with the deck button
9) click learn
10) press the play button
And then your deck button just toggles between 1 and 3, and your LEDs work accordingly.
----
So your workaround requires more than twice as many steps for each control you want to map, for each PL-1. In addition to that, the LED feedback for the selected deck doesn't work as intended in your workaround, where as it would work perfectly if you set up deck toggling in the firmware, like I'm suggesting.
jesus, arguing about midi mapping a controller that isn't even yet released. Thats serious business.
Do you realise what an idiot you sound.Quote:
Sob sob sob - I've waited months for a controller - I like it so much I want three of them - oh wait a minute, what's that?
I have to spend an hour setting it up how I want it....
Pfff, forget it pal - I'll get something else that is perfect for me - just me.
Me,me,me,me,me,me,me,me,me,me,me,me,me,me.
If you can set up a controller to do what you want it to in less than an hour you're a better man than me.Quote:
I have to spend an hour setting it up how I want it....