Ok I’ll probably have some questions about the GUI along the way, hence opening a thread for that.
Kicking it off with this one I’m currently interested in:
I’m trying to change the color of the indicator dots on the keyboard when CMD Multi is active.
They are exactly the same on every skin I’ve seen, so either nobody tried changing them or it’s not possible in the first place.
There are no (external) graphics files for them, maybe those are rendered/generated by the plugin. Still I think it might be possible to edit the color by adding that to the xml script.
But that would at least require to know exactly how this is named in the plugin code.
I’ve added a simple example line to the script, which I’m hoping could work out in the end.
Yea I’m afraid it simply isn’t set up to be customizable. On the other hand there’s a chance it just wasn’t added to the script.
Doesn’t make much sense though to blindly test it with randomly named designations…
Seems the GUI really isn’t very flexible
One thing I absolutely wanted to achieve was to provide a bit more functionality to the G-Env section on the main page. In particular being able to call up and also save G-Env presets. I always think it’s annoying having to open the editor page first only to load/switch a preset. Especially when you already created a bunch of presets you’re using on a regular basis. It simply would be way more handy to do this directly from the main page.
To me this is almost comparable as it would be required to open a different screen first, if you wanted to change the LFO shape from a Sine to a Triangle…
So I was moving things around a bit to create space for preset items (maybe a combobox or dropdown menu for loading, “save as” button) on the main G-Env section.
Since those items are already existing on the editor screen I thought it wouldn’t be too much of an issue to implement them on the main screen. But, well, it’s not working
Already tried a bunch of stuff in the script, like putting the two versions of “genvPresetsComboBox” in child/parent relation, but no success.
Totally seems ANA just can’t handle what she doesn’t explicit know.
In light of this I don’t think anymore it’s possible to change the color of the dots on the keyboard either
I’m fairly unhappy the preset stuff on the G-Env doesn’t seem to work, as I really think this would be a very nice little workflow improvement.
While on it I’ll take the chance and make this a feature request. Generally I assume it wouldn’t require all too much effort to implement this.
Guess I was just a bit frustrated yesterday that stuff like the G-Env preset thing isn’t possible with the ANA GUI.
After all it’s not that bad how it is. I’ll try working something out with the given possibilities, to give this a bit of a different feel.
It was disappointing that things like that aren’t working, as I also had in mind i.e. to throw an Arp Hold button onto the main interface (I often wish that could be turned on/off directly). But now I’m quite sure this won’t work either.
At least I’m starting to grasp what’s possible or not
Apparently the sizing of the big popup windows (G-Env Editor, Settings, Mod Matrix, MS Edit) isn’t correct on the factory skins (xml and actual image size).
“x” for them is set to 10, so 10 in from the left of the GUI. To step in 10 from the right as well and having the popups centered, the width should be 1034 px, not 1035 px like they are.
Doesn’t sound a lot but when using clean edges it becomes obvious this is off.
The yellow line on the right represents how it’s set up on the factory skins.
The way the factory skins are designed it doesn’t play too much of a role, but when using straight edges it becomes apparent something’s not right. Here’s how it would look if I’d use the factory 1035px:
It’s not that big of an issue, I’ll just change the width to 1034px. Those are simply the little details one has almost always to deal with when creating a skin. Just thought I’ll report it, might be nobody’s even aware of it.
EchoSoundWorks apparently noticed this, too. On his Drip Edition skin he worked around it by setting “x” to 0 and using the entire width of 1054px for the images. At least he did so for the big G-Env editor, on other popups he solved it differently.
For reference, here’s the octave of white keys I created:
The black areas are NOT the actual black keys. That’s only a dark area lying underneath, to simulate a bit how it looks on a real keyboard. The actual black keys sit on top of that, as shown on the first screenshot.
But as you can see, the placement is…
It’s even different from octave to octave and no real pattern to it.
And those positions aren’t determined in the xml script, so no chance for me to adjust that or to even comprehend what the exact placement of the black keys is.
It’s not even possible to calculate the inaccuracies in and adapt the graphics to the “errors”, because I only got one octave and the “errors” differ by octave lol.
So, probably I have to throw all that into the trahscan. Wasn’t really finished, colors, shadows and so on weren’t there yet. But the basics were done.
Stuff like that eats up so much more extra time… (and this one is already quite time intense anyway)
If i remember back the skin designs where originally made in the lower resolution version. in that version everything is probably more pixel accurate. the upscaling to HD version created some miss-alignment.
if you have an old 1080p screen you could use it to see the SD version.
Still thinking about how to handle the keyboard.
After what Phil said it’s safe to say there’s no way to prevent the black keys from behaving like they do (125% sizes upwards).
I just had an idea for a workaround that might be applicable. If I can integrate the final black keys (in “not pressed” state) into the graphics for the white keys, and then make the “not pressed” part of the actual black keys graphics fully transparent, the positioning won’t matter anymore because it’s simply not visible. Still it would seem they are there since they are implemented into the white keys.
Of course I’d need to keep the “pressed” state of the black keys graphics visible, but with those there’s more room to maneuver and it should be easier to conceal the inaccuracies.
Need to test if it’s working and how it possibly looks.
If it doesn’t turn out good, I’ll probably do this:
a) finishing this keyboard pretty much like intended, as it’s looking ok at least up to 100% sizes. Likely with some adjustments to the graphics to (hopefully) make the inaccuracies less obvious with 125%+ sizes.
b) creating an alternate keyboard that is less conventional, maybe something like those other folks did on the SD-1 skin. In the realm of Current or Arturia’s little hardware gem MicroFreak
In general I think a conventional keyboard is more suitable for ANA, but with an “out of the ordinary” keyboard it should be easier to handle the issue.
And likely I’ll provide that as an alternate option, depending on what it will look like in the end.
Screenshot taken with GUI size 125%.
Quite some difference compared to how it looked before. Still need to figure out how to make it look good when a black key is pressed. The “dummy” black keys likely won’t work as they are here. But that’s not so important for the moment. The main thing was to find out if that workaround method works in principle.
Seems it does, and this might even provide additional options.