Rack Performer (RP) - Graphical User Interface (GUI)
#1
The sense I get from using RP is that it is a very powerful and robust tool. The internal logic suggests enormous potential. Unfortunately I find the GUI is too opaque and is probably the greatest weakness of RP since it isn't very intuitive.
Suggestions:
- Each 'edit mode' wrapper should have activity (MIDI, audio) indicators/LEDs.
- Each 'edit mode' wrapper should show on/off/bypass/solo buttons.
- Each 'edit mode' wrapper should show basic connectivity info: MIDI/Bus Channel, CC activated, etc.
- Each 'edit mode' wrapper should show menu bars to access the parameters. Generally too much is hidden and requires too many clicks to be found.
- I wonder if controller data connections between devices can be implemented in patch mode in a way similar to audio connections, but with a different type of graphic treatment, perhaps color coded or dashes/dots, etc. Maybe these lines can have labels with parameter editing menus in them.
- I wonder if 'Patch' mode graphics can be 'live updated' with thumb-nailed image of actual VSTs used in patch.
- I'm not sure I like the "dispatch" grid system. Perhaps, alternatively, each wrapper could be minimized or cascaded to a 'tab' with color coding and a label. I like the way Adobe implements tool bar pallets that can be large with many parameters, smaller with fewer or hidden or docked.
- I generally like to view my plugins in "edit view" following the same signal path logic as in "patch view". The forced grid of "dispatch" is too rigid to allow for this when there are lots of VSTs. This is not always the fault of RP, as many VSTs have unnecessarily large GUIs.
- In 'patch' mode, labels for devices should be inside the "module". That way it can't get lost behind another module and it would be clearer which module is which and would take up less screen space. Font for labels could be smaller.
- 'Patch' mode module graphics could be smaller and made with a cleaner design. I have Ideas we can discuss further.
- It would be very helpful if mixers could have labels indicating what device is connected to which knob/fader. This is very important when two instances of a device are used in a patch. Ideally this would be done automatically based on the label of the device connected to it in the "edit" view. I hate having to switch back an forth between edit and patch mode to remember what is connected to which mixer channel.
- Edit mode modules that can have i/o count changes with +/- buttons needs a better interface. I think I would prefer to always see all available sockets with an on/off click for each. I don't like that when I click a "+" all the other sockets move.
I hope this isn't too overwhelming.
Suggestions:
- Each 'edit mode' wrapper should have activity (MIDI, audio) indicators/LEDs.
- Each 'edit mode' wrapper should show on/off/bypass/solo buttons.
- Each 'edit mode' wrapper should show basic connectivity info: MIDI/Bus Channel, CC activated, etc.
- Each 'edit mode' wrapper should show menu bars to access the parameters. Generally too much is hidden and requires too many clicks to be found.
- I wonder if controller data connections between devices can be implemented in patch mode in a way similar to audio connections, but with a different type of graphic treatment, perhaps color coded or dashes/dots, etc. Maybe these lines can have labels with parameter editing menus in them.
- I wonder if 'Patch' mode graphics can be 'live updated' with thumb-nailed image of actual VSTs used in patch.
- I'm not sure I like the "dispatch" grid system. Perhaps, alternatively, each wrapper could be minimized or cascaded to a 'tab' with color coding and a label. I like the way Adobe implements tool bar pallets that can be large with many parameters, smaller with fewer or hidden or docked.
- I generally like to view my plugins in "edit view" following the same signal path logic as in "patch view". The forced grid of "dispatch" is too rigid to allow for this when there are lots of VSTs. This is not always the fault of RP, as many VSTs have unnecessarily large GUIs.
- In 'patch' mode, labels for devices should be inside the "module". That way it can't get lost behind another module and it would be clearer which module is which and would take up less screen space. Font for labels could be smaller.
- 'Patch' mode module graphics could be smaller and made with a cleaner design. I have Ideas we can discuss further.
- It would be very helpful if mixers could have labels indicating what device is connected to which knob/fader. This is very important when two instances of a device are used in a patch. Ideally this would be done automatically based on the label of the device connected to it in the "edit" view. I hate having to switch back an forth between edit and patch mode to remember what is connected to which mixer channel.
- Edit mode modules that can have i/o count changes with +/- buttons needs a better interface. I think I would prefer to always see all available sockets with an on/off click for each. I don't like that when I click a "+" all the other sockets move.
I hope this isn't too overwhelming.
H / UDmr
Member info
United Deviations
Country: Canada
Joined: Oct 25 2011
Joined: Oct 25 2011
Not at all but there are a lot of points in your post, many being very interesting, and some would need to be discussed in length.
We try our best to make the application as idiot-proof as possible, but given its intrinsic complexity it is not a trivial task. I could add that the upcoming user manual should hopefully make the learning process easier. But there is a learning curve, like with every advanced tool.
Now I will try to comment on your suggestions as much as possible, but not necessarily in order.
Nearly all internal modules support up to 8 channels (7.1 or 8.0 depending on the way you work) but most users will use them in mono or stereo mode. As you can see for instance with the CamoMixer x32, the module in patcher becomes quite large when you increase its I/O pin bundles. Having it fully expanded by default would be quite impractical.
Also the multi-pin patching mechanism (using shift or control key while dragging a link) depends on the visible pin count to work. For instance if you have 4 visible pins on the source and target modules, the multi-pin patching will connect all 4 channels at once. If all 8 pins were visible it would connect 8 channels.
Now the good news is: we did not like the screen scrolling when increasing the pin bundles neither, and it has been fixed in 0.99-beta2!
We like the idea of automatically filling the labels with the connected module name. It would just be a little strange if several modules are connected to the same mixer input, in which case the name would probably be "Audio Bus #N" (as under the hood bus modules are automatically inserted in the patch when you connect multiple sources to an input pin)
More "proper" mixer modules are on their way for next release (as the current offer is very minimal/barebone), along with many many more modules. We will make sure they include labels.
As with everything aesthetical, the discussion and argument can be potentially endless... We can discuss your ideas but keep in mind that the actual patch objects size is mostly dictated by the audio pins size, which can not be shrinked more as it must be usable with touch-enabled input devices (and they are already a bit too small one could say)
The surrounding black borders could be improved and the entire patcher graphics are potentially skinnable, but it is not a priority for now.
So where exactly would you see it? Over the module thumbnail? I'm affraid it would make it hard to read for one, and completely ugly as in many cases the label is wider than the patch object itself... so the text would overlap on both sides...
I don't know for the size. Not all people have eagle eyes! :p And you can always use the mouse wheel to scroll the patcher out, making everything look smaller in the process, including the module name labels.
That's not necessarily trivial to achieve technically speaking, but could be done. Now the question is: to what extent would that slow down the patcher drawing? (as it means one custom texture per loaded VST module) We need to perform tests. But this is rather a gadget and again not a priority, and the ratio of work involved vs practical gain is not really favorable.
Having read your mail about that competitor product, I see where you are going here. But we deliberately chose another approach for control signals patching in our apps. Instead of having a static patching for control and automation, like in other modular environments, our architecture allows to have dynamic links for these kind of control signals.
This is why all control patching/routing is done in edit mode and not in patch mode. A first example is the VST MIDI interlinks: those are dynamic in their assignment (ie the patch is not re-built when you select a target) Another example is the RBC LFO target: it is also assigned dynamically but furthermore you can switch targets on the fly and in real-time (try for instance by saving two presets with two different targets)
So this offers a lof of extra flexibility because a single controller-class module (ex: sequencer, automation, LFO etc) can be used to control different modules depending on the situation (ex: the different parts/songs of your liveset) meaning you only have to create MIDI mappings for that single controller module once.
This approach has a drawback though: you need to adjust the patch execution order in some advanced cases. But otherwise we think it is better, especially in live performance situations.
- Each 'edit mode' wrapper should show on/off/bypass/solo buttons.
- Each 'edit mode' wrapper should show basic connectivity info: MIDI/Bus Channel, CC activated, etc.
- Each 'edit mode' wrapper should show menu bars to access the parameters. Generally too much is hidden and requires too many clicks to be found.
In fact our philosophy is "hide everything that you don't need when performing music live on stage". You really need to distinguish the setup phase, when you create your document at home or in the studio, from the performance phase, when you play music live on stage.
Everything that would be "parasitic information" when playing is hidden on purpose. We also tried to make all advanced features hidden by default so that they don't come in your way until you start using them. For instance if only 10% of the user base is using feature A, it would annoy 90% of the users to have it visible by default (vs having it discoverable or accessible via context menus)
That being said, it is clear that you need to learn how to use the right click context menus in RP, both in patcher and on the module GUIs in edit mode, otherwise you miss a lot of the fun!
Now onto your suggestions: when you mean each edit mode wrapper, you mean for each and every module? Or only for VST plugins? As you can imagine, adding extra controls to internal modules GUIs will be quite complicated as they are all very packed and compact already. Having an extra control bar on top of every of them would waste a lot of screen real-estate too.
For VST modules on the other hand, we could add extra GUI wrappers, with one possibly having a control bar on top with program display/selection and a few shortcuts/indicators. We could also improve the existing wrappers to include some indicators when the size allows for it.
I'm not convinced everything you listed would make sense. For instance the MIDI routing (source channel(s)) is not something you need when playing, rather something you setup once and forget. Same for the MIDI CC mappings, once your controller is setup you just use the knobs but don't need to know what CC number they are configured to send. The activity LEDs make sense but we already have the presence meter module for the audio LED...and they would have a small but real CPU impact, so having them for every module is debatable.
Bypass/mute shortcut could be done but solo is more something you expect to see on a mixer module than something patch-wise. It's more challenging technically but the idea is interesting, we took note.
- I generally like to view my plugins in "edit view" following the same signal path logic as in "patch view". The forced grid of "dispatch" is too rigid to allow for this when there are lots of VSTs. This is not always the fault of RP, as many VSTs have unnecessarily large GUIs.
Here I think we won't agree. The static grid approach + virtual screens really is a must for us when playing live, compared to most other competiting products. Having overlapping windows when playing on stage is just a mess and frustration source. On the other hand when everything is exactly at the place your brain expects it to be, you can be way more efficient and concentrate on music playing.
The idea is again to hide everything that you don't need when playing music on stage. For instance most of the time you need to see a few instruments and effects but the other effects are only setup during the preparation phase and sometimes you don't even need to display their GUI at all anymore.
So you would put all important modules on the first few virtual screens and the rest on the remaining screens. Note that you can switch screens by using the F1 to F8 keyboard keys or with your MIDI controller.
Then we also have the various GUI wrappers to follow the idea further: you can setup a VST module using its internal GUI, then switch to a more compact GUI wrapper (like the PopupDesign ones for instance) when playing. This way you gain a lot of space on screen while still retaining the ability to control the module (because control focus still works and you have control shortcuts on some wrappers, like the Fader-box one, so you can still see and edit the important parameters while those you don't use are hidden)
But overall our GUIs can hardly be made dynamic in size I'm affraid. It would be too much of a paradigm shift and not something we are specially fond of.
Live Factory Team
Member info
Joined: Nov 15 2009
I do not see any difference. Is version 0.99.3.8 not part of beta2?
I agree completely with this. The two phases are completely different. I think the performance aspect of RP is very good. Unfortunately I feel that the "setup" phase in RP currently is not conducive to creative explorations. I get the feeling that the "Live" aspect takes over too soon from the "setup" process. Perhaps there needs to be an extra mode introduced after "patch" mode and before "Play Live" mode.
Setting up requires too many clicks and too many things are hidden. For example, why must the "presets" GUI always disappear after almost every operation? Why can't more than one presets GUI be open at one time? I understand that these GUIs are not needed to play live, but when editing I don't want to be constantly fishing around for them.
The idea of Live/Synopsis menu is good. I do want to see an overview of all my cc settings. But as implemented, I have to click through every plugin and every plugin parameter to see if it has a MIDI or keyboard mapping. I'd like to see a window that shows all mapped parameters, perhaps as a grid, matrix or tree view; with names, cc numbers and variables. At least, until a better view could be implemented, if the Live/Synopsis view could have an asterisk next to each parameter that was mapped so I would know where to look.
I think that "forgetting" is a very big problem. Especially with software like this that has so much potential complexity. There has to be a way to troubleshoot patches, especially when there are multiple layers of MIDI controllers involved. Sure, when playing you shouldn't have to think about it, but there is a lot to be done (or potentially could be done with software this powerful) before the actual playing. If a cc can be routed to multiple destinations it might be difficult to 'remember' them all, especially after coming back to it after a few weeks or months. There might be errors or the need for changes to a routing. There should be a quick way to see how things are setup.
Again, while I agree that the "live" aspect of RP is primary, I think the "setting up" needs to be given more space if the potential of RP is to be exploited to its fullest.
---
Member info
Joined: Oct 25 2011
Aye! This is embarrassing! It seems it was only partially fixed and indeed it does still scroll the view in some cases... The fix was not tested thoroughly enough, sorry.
It is clear that we focused on this aspect, because with the competition any company is facing today, one really needs to stand-out, so we want our product to be good for this particular thing, live performance. But we agree that we still got a lot of work to do in other areas, and we appreciate your feedback.
A (lack of) documentation issue, and also because it could be made simpler perhaps... Here is how it currently works:
The presets management floating window (Presets window for short) has two operation modes:
The first mode happens when you right-click in the presets box control on the module GUI, or if you select "Presets" in the module context menu. The Presets window pops-up and is displayed close to the mouse cursor, allowing to select any preset with one click (or two clicks if you need to change the bank) then the window disappears.
So this is the mode you would use when recalling presets with the mouse when playing (of course you could also change the presets with your MIDI controller and not use the mouse at all, but this is not the point) It's as fast as possible (provided the module GUI has a presets box, but most have one*) and it's also non intrusive as the Presets window is only visible for the time you need it.
The second mode works differently, as the Presets window stays on top and acts as a centralized place to manage all module presets. In fact, the Presets window is part of the "floating tools" layer, like the Audio Monitor, the Metronome etc. When it is displayed in floating mode, it will automatically follow the Module Control Focus and show the presets for the focused module.
To display the Presets window you can use the "View -> Presets" main menu entry or the Ctrl+P keyboard shortcut. Then when you set the control focus (green frame around GUI**) on any module having a presets port (nearly all modules have one, to the exception of parameter-less modules etc) the Presets window will be updated and will display the presets for that module.
In this mode you can store, rename, arrange (copy/cut/paste) individual presets and banks. Copy/pasting between modules of the same type is also possible. But most importantly, the Presets window never hides, meaning it is an entirely different use case that is also valid when playing live, where you set the focus on a module, change its preset number, then set the focus on another module then change etc
** Note that the control focus can be set with the keyboard mapper (in the module context menu just select "Quick KBD map..." and press a key, this key will then from now on set the control focus to that particular module) Setting the control focus via MIDI is not implemented yet.
* We will try to add a presets box to the VST GUI wrappers that don't have one, or eventually add extra wrappers per your recommendations
Alright, two things here: there is already a visual cue on the live synopsis icons (it's very small I must say but yet it's functional) When a parameter has a midi mapping there is a small red M overlay, and when it has a keyboard mapping there is a small K (and both when... oh well you get it!)
Now what you are missing indeed is what we call the MIDI Mapper window, which would be similar to the current Keyboard Mapper window (both in the "floating tools" layer btw) Where you would have the "inverted" point of view: instead of starting from modules and going to midi mappings, you would start from the MIDI channels and available mapping sources and work your way down to the modules.
Unfortunately this feature has been postponed for after 1.0, but it will be implemented in the future.
Yes, that would be handled by this MIDI Mapper window, like the keyboard mapper you would see in a glance what CC (and other sources) are mapped (per channel) and selecting a CC will display the mapping(s) for it.
Yes we agree. But making a complex application user friendly (and idiot proof) is a real challenge. What looks simple from the user point of view often implies a lot of extra work from the coder point of view. Not that they would by default produce complex interfaces because they are engineers, but because the computers by their very own nature tend to produce "by default" interfaces that are more suitable for machines than for humans.
Live Factory Team
Member info
Joined: Nov 15 2009