This should be an easy one to implement, but useful.
Option within pulldown menu to hide beatgrid, BPM etc.
Use case 1: beatgrid is off on a newly scanned track and there is no time to fiddle. I’d love to be able to hide the beatgrid and BPM as it’s just a distraction.
Use case 2: personal preference. Many old school DJs prefer to mix by ear and find the BPM and beatgrid cumbersome and that it can get in the way.
Use case 3: training. Can be used as a tool to train student DJs to mix by ear.
It’s surprising how many features are so easy.
I think there’s already a request for this, although with very few votes. There’s always the LC6000 if you wanted an visually mute alternative
An easier workaround, but still removing “unwanted” elements of the display is to change the screen view to a library search, or preferences screen, other layer etc
https://community.enginedj.com/t/toggle-bpm-display/47321/71
Here is the feature request, add your vote to it and double the popularity.
Changing to the browser or another layer is insufficient, as some of the info is still on screen, and several features become inaccessible.
Easiest way to implement this (and several other requests) is just giving people the ability to change the color of every on screen element in their profile. Track tempo, BPM counter, moving waveform, beat counter, etc.
Is that easy is it? Do we know this for sure or are you just spitballing here? it doesnt quite work the same way as you pick colours in Microsoft Paint I hope you realise.
You can already customize a bunch of the other colors. And we’re talking about multiple requests from multiple people for a bunch of different needs: people who want a certain coloring of RGB waveform. The color blind. People who want to hide certain on screen information entirely. That’s how you do it for VDJ XML skins. Considering some of this customization is already possible, expanding that to every on screen element, which must have color codes hidden in the firmware currently, and giving the option to choose the color for anything on screen seems like a vastly more parsimonious and easy solution to all of them. I don’t see why something like holding shift + tapping an element on screen couldn’t pop up a color selector for it, and then store it in your profile. Or you could just go into your profile and manually change them in there once they’re added… especially for the LEDs that are engineered with multiple colors. For instance, in this Axure mock up I did, I was easily able to change any color to anything else I wanted. Try double clicking on the blank space to switch some of the elements to a night mode.
Because from a coding perspective it’s not as easy as you’re implying, regardless of how many people have requested it.
Because you’re thinking multiple on screen elements might be sharing the same color codes in the firmware? As a first step, the discrete color codes that are individualized could be made available to change initially before expanding it to more color codes for more elements. I realize that not every on screen element might be immediately available to alter.
Back to VDJ, this is what’s very easy to do in the skin XML with black on black color codes:
I don’t know what the base code is behind the prime GUI, but as an example take a look at the html colour picker and see the strings involved, it’s massive and complex. It would have to be embedded into every single part of the GUI and its functions, then tested beyond belief to ensure none of that code interferes with the functional code.
Each element of that screen will have its own packages and those packages would need that embedding, it would require the ‘if’ part of the statements to be modified so they display a chosen colour and not the one that’s been hard coded, that means layering up multiple rules which adds further complexity.
For example FX off could be light grey, on is yellow, that’s a fairly easy piece of code to write, add in FX off = chosen colour from user and FX on = chosen colour from user but can’t = FX off as it would clash.
Suddenly you have an extremely bloated piece of firmware that takes months and months of effort to write, just to appease a few people on a forum.
Comparing to something like VDJ is kind of pointless too, very different applications running on very different hardware.
I don’t see why the color picker itself for shift + tapping on the element couldn’t be common code that’s pulled up regardless of which element you tap, and then alters the color code for that element without getting bloated by repeating it over and over again. Also, obviously you’d want Engine Desktop to provide a mock up of the Engine OS interface for you to also do it there ‘offline’ so to speak, for people that don’t want to manually edit the user profile in a text editor. This certainly seems like one feature request that would satisfy multiple other feature requests and a variety of very specific preferences users have.
Because you still have to link it to every single part of the GUI, regardless of it being common code or not. The colour picker isn’t the problem, embedding it into the GUI to modify every single piece of static and interactive function is.
Perhaps it’s best to leave the experts to decide what’s easily doable and what isn’t, these people do 5yr University degrees to qualify for their careers, would you walk into a fire station and start telling people how to go about putting fires out? Or tell Lewis Hamilton how best to steer a car? I don’t see how this constant ‘should be easy for them to implement’ attitude is any different.
Sure seems like doing one thing like that should be easier than a bpm toggle off, moving waveform off, an RGB waveform #1 mode, an RGB waveform #2 mode, a Deuteranomaly mode, a Protanomaly mode, a Tritanomaly mode, etc. And still you’d end up with people not satisfied with the inability to turn off something else or change an element to another color not yet included. When we did C programming in some of my prep classes, we’d do lookup tables for values used that would then reside in the RAM until the program was terminated. I don’t know that they’re hard coding every color of on screen elements in the firmware here rather than putting it in a table or matrix, but I sure hope they’ve got some more simple way of changing this stuff. On the Gemini MDJs that also ran on SoC Cortex ARM stuff and predated Denon DJ and Pioneer forays into that hardware, they didn’t do it in assembly, but rather just used Linux. Then again, I don’t really mind the colors used currently. Just shift + tapping on on screen elements causing them to disappear would probably suffice for me. Ditto for the LEDs… I just want the ability to make that white ring be blank instead.
What an utter waste.
The idea of making an on-screen graphic or on-screen text “disappear”. Kindergarten or what? The way to make the writing on a green background disappear is to paint the writing green?
So just keep the CPU wasting cycles calculating that “unwanted” info, and keep the GPU wasting cycles drawing something that can’t be seen anyway.
If the request ever gets actioned, then hopefully a much much much more viable, more modern day, and less Crayola than making the text color match the background color
From a testing standpoint for those who will be using blanked out stuff, it would make more sense to actually do black on black, because if you’re lowering CPU & GPU usage, you could create a false sense of stability and unrealistic lack of latency. On the Gemini MDJ line, though, things were so unstable that turning stuff completely off like all analysis, all waveforms, and tempo/BPM counters was useful for narrowing down where issues were, but short of that, it is true that completely eliminating on screen elements and not just going black on black would be something you wouldn’t want to do when testing. I’m glad you brought that up. Ironically, or maybe not so ironically and perhaps precisely because we proved the line required it, the Gemini SDJ all-in-one unit I don’t believe even does on board analysis anymore… if you haven’t pre-analyzed in V-Case, it’s effectively like the MDJ set to analysis OFF in the options menu.
