Things I think could have been useful when I was setting up my rackspaces!

This is going to sound a bit spoilt and entitled, but please take this in the spirit it’s meant. It’s sort of a wishlist of things I’d have found very useful when creating my rackspaces. I spent upwards of 7 hours (at least) making various mistakes and learning lessons and have eventually settled on something that both looks good and works functionally the way I need it. It’s brilliant and I’m very happy, thanks for this software.

Here’s the list, I’d love to know your thoughts!

  • Save colour pallettes
  • Ability to use full 6 digit Hex values (for example, copy and paste from another source)
  • Copy and paste colour values
  • More “shapes”
  • Three way chrome toggle widget (we have a two way)
  • Ability to lock and unlock a widget or groups of widgets to prevent accidental changes to knobs
  • A grid for the rack panel
  • Ability to snap to grid
  • Snap to middle (X&Y axis) of closest item (a container shape or the rack panel itself, for example)
  • Snap to align with nearest widget/shape (a knob, for example) (I know we can align widgets with the controls you’ve given us, that’s very handy, thank you)
  • Group UI items so they can be clicked once and moved all together
  • More fonts (possibly from the Google fonts library, maybe?)

Coming from a design background, I realise how Adobe these all sound! :joy:

5 Likes

But then you cannot move a widget via a MIDI controller, right?

1 Like

That’s a good point, maybe there’d be a way to lock any on screen mouse control but allow MIDI control should the user decide. I realise that’s both having my cake and eating it. But it’s just an observation.

Where would you like to you HEX values and for which use case?

If I search google for a colour palette, I use an eye dropper tool on Firefox to copy the HEX value of the colour I like to the clip board.

So wherever we are able to choose colours from a colour picker, the ability to provide a HEX value would be better for me. Admittedly, it’s a very designer focussed thing, as we’re often fussy about specific colour pallettes and fonts. Which is probably another thing that could be added to the list, a broader spectrum of fonts to choose from.

Colors are already defined using HEX in GP, but you cannot copy a value from the clip board, that’s right.

Correct, I should rephrase my original to have the ability to just be able to input a hex value as a complete 6 digit alphanumerical value rather than separate 2 digit values. Which would be inline with some of the more standard design tools and of course, would help with copy and pasting from standard tools like eyedroppers. Also, for people who don’t know how HEX values are made up, it would be easier for them too.

2 Likes

This is fine for a GUI with a fixed size,
But GP is not fixed in size, so how could that work and always look the right way when the GUI is resized?

It already does work. When I centre something at small window size, it’s centred when blown to full size, for example. A grid would be no different, I expect.

1 Like

Ok, but that would mean that when resizing no auto snap to grid should happen.

I’d say that a “snap to grid” is mainly useful in edit mode, not while performing.

1 Like

Ok, but while editing a resize can be done.

I know this from making UI-forms in VBA or VB… everything snaps and matches perfectly, as long as you don’t decide to change the general size of the main frame/window, then it won’t fit anymore and you’d probably have to adjust all the elements again.
It’s again the same advice we all got so often: Just don’t do that! :wink: :smiley:

Sorry, I’m a little confused now.

Resizing in GP is more like a zoom. So if you resize while in Edit mode, the grid should also resize with it. At a certain point extra gridlines will be added, allowing you a finer adjustment of the widgets.

And then you make it smaller, what happens with the grid snap?
Should it snap again according to the smaller size?
And then you make the window bigger again, what about the previous grid position?

I think you may be overcomplicating it a little. The grid resizes with you. So as you scale, so does the grid, so everything stays in the same relative position/size. The grid should only works as an aid during editing, it wouldn’t be there during live mode.

Also, as I said before. If I position something on the panel, it stays in the same relative position and just grows. So the grid wouldn’t change that.

Widgets would only move if you physically move it. But yes, if you’ve shrunk the window size and the grid changes, if you then click and move the widget, it would snap to the visible grid.

Major +1 vote for some improvements to the visual editing of panels. Visual guides, grid/rulers, and especially being able to group widgets together in order to move and align them as a single object. I have a layout that includes multiple virtual guitar pedals, each with a toggle switch and three individual knobs. If I decide to rearrange them, it’s cumbersome at best. (Please don’t misunderstand these wants as lack of appreciation for an absolutely stunning piece of software).