locoDog
I've customised this device skin before for people, nothing major just an fx page added and minor tweaks, and I've had no complaints. But my next job has me slightly weary as it's not a small thing.
I want to add a page of banks of buttons and I worry it might be a bit much.
The page will need;
4*(64 buttons) banks of buttons
256 string variables [user gets to give buttons names]
256 multibutton scripts [pretty much all of them are quite tame, except one that needs to do a "next available hotcue check" and that checks numbers between 11 and 1035 (so not a small script)
A rough check from previous jobs that included this page, is ~300kB of text to add.
For the render side of things, I think it's pretty low impact, everything is vector squares, there's no moving parts or bits that would want a high refresh rate. Visibility checks are the bare minimum, everything is skin_panel_group 'd so I'm only checking against a single variable.
I guess I'm just going to have to make it to really know, but I'm asking if I'm going to run into any problems that are obvious to the HW experts?
[If I could test locally, I'd not ask I'd just make, but testing via proxy can offer challenges]
I guess I have the same question but applied to a remote skin [tablet] as well.
I want to add a page of banks of buttons and I worry it might be a bit much.
The page will need;
4*(64 buttons) banks of buttons
256 string variables [user gets to give buttons names]
256 multibutton scripts [pretty much all of them are quite tame, except one that needs to do a "next available hotcue check" and that checks numbers between 11 and 1035 (so not a small script)
A rough check from previous jobs that included this page, is ~300kB of text to add.
For the render side of things, I think it's pretty low impact, everything is vector squares, there's no moving parts or bits that would want a high refresh rate. Visibility checks are the bare minimum, everything is skin_panel_group 'd so I'm only checking against a single variable.
I guess I'm just going to have to make it to really know, but I'm asking if I'm going to run into any problems that are obvious to the HW experts?
[If I could test locally, I'd not ask I'd just make, but testing via proxy can offer challenges]
I guess I have the same question but applied to a remote skin [tablet] as well.
Posté 7 days ago @ 5:13 pm
locoDog
A further question because I don't have the HW in front of me;
I'm unsure on controllerscreen_deck is it automatically inherited? so that I only need to place a button once and the action_deck is implied, or is it a case I have to place for every deck and do a visibility condition like below
group visibility="controllerscreen_deck 1 ? true : false
deck deck=1
...buttons...
/deck
/group
group visibility="controllerscreen_deck 2 ? true : false
deck deck=2
...buttons...
/deck
/group
I'm unsure on controllerscreen_deck is it automatically inherited? so that I only need to place a button once and the action_deck is implied, or is it a case I have to place for every deck and do a visibility condition like below
group visibility="controllerscreen_deck 1 ? true : false
deck deck=1
...buttons...
/deck
/group
group visibility="controllerscreen_deck 2 ? true : false
deck deck=2
...buttons...
/deck
/group
Posté 7 days ago @ 8:33 pm
Adion
For performance, in general cpu usage can be checked on computer as well, that won't make any difference.
For what is sent to the device, you can use debug drawing to verify which parts change and would have to be sent to the device.
For what is sent to the device, you can use debug drawing to verify which parts change and would have to be sent to the device.
Posté 6 days ago @ 6:40 am
locoDog
Thanks, if dirty ==0.0 is good then I think I'm good. [remix skin was 0.0 too... I don't know how I managed that]
I think I've got the controllerscreendeck thing understood.
I think I've got the controllerscreendeck thing understood.
Posté 6 days ago @ 7:16 am
the SOUND INSURGENT
This makes me very very happy 😝
Posté 6 days ago @ 12:20 pm
locoDog
Just a little log of the changes I made to the sc5k skin, it also applies to sc6k [they use the same skin]
The last pic has yet to be tested [I'll know pretty soon]. It's a specialist midi thing for lamping, but it could be easily changed to work as a custom; tagging, fx calls, ... anything type of page
It's a little bit of a shame that vdj is the only software that lets you reskin device screens, because it's literally unlimited buttons and sliders.
Once you can* [or ask me to] add your own stuff to the device screen would you ever really need to upgrade to the mk2?
Maybe you would for some hardware fx, but it becomes a lot more questionable when you have infinite buttons & sliders backed up with vdj script.
Posté 4 days ago @ 9:45 pm
groovindj
I just wish the hardware manufacturers would see the benefit of user skinnable device screens.
Denon recently released a rejigged GUI for their Prime units, and IMO it's actually worse than their previous efforts. It's clear they're using some form of skinning, but it's buried deep within their firmware and not user accessible. Letting the user decide what they want on screen makes much more sense.
Denon recently released a rejigged GUI for their Prime units, and IMO it's actually worse than their previous efforts. It's clear they're using some form of skinning, but it's buried deep within their firmware and not user accessible. Letting the user decide what they want on screen makes much more sense.
Posté 3 days ago @ 7:53 am
the SOUND INSURGENT
That last Denon update is awesome!! No more flipping through screens, Groovin you nuts lol!!
Posté 3 days ago @ 2:02 pm
groovindj
I'm using a Prime 4, and IMO the layout of info in the decks could be improved. They're gradually decreasing the size of the deck area in favour of bigger scrolling waveforms, and because everthing's being squeezed in to a small space, certain things take a hit.
The artist and title info is given less than half the width of each deck, because they stuck BPM, key, track time and cover art on the same line. IMO all the numerical stuff should be on a line below.
Earlier GUIs were better in that respect.
Atomix have the right idea:
The artist and title info is given less than half the width of each deck, because they stuck BPM, key, track time and cover art on the same line. IMO all the numerical stuff should be on a line below.
Earlier GUIs were better in that respect.
Atomix have the right idea:
Posté 3 days ago @ 3:14 pm