You seem to be almost taking the UI change personally…I hope I did not insult!
I did not consider this polymodal because the same action that gets you into the context view also gets you out. I actually made this change for the same reasons that you site that I should not have done it. Very surprised! For example, previously the UP button was not only changing the focus to its previous target (the intended invariant purpose of that button), but it was also altering the state of the unit UI on the way. I was kind of uncomfortable with that secondary behavior.
I have been really used to the enter/up navigation. The “use a softbutton to cycle between modes” is a new workflow. My recall stack is pretty limited, especially when I’m focused on an artistic goal, which is fuzzy. An indication of what button is going to get me to a new screen would be very much appreciated.
There’s a fair amount of cognitive overhead built into the design of the workflow, in terms of the nested function generators. I think having wayfinding aids through that is pretty important.
I’m sorry for being snappish or churlish. I am told by people who know me well that I have a very rich inner life.
No, I mean the menu screen of a unit, where Rename Unit, Save Preset, Load Preset, etc live. FYI, the screen that you are referring to, I call it the Unit Chooser.
Yeah, that’s been a little bit of a challenge. That’s what lives behind the left-hand unit name box? Trying to remember where all the bits are is tricky;
Yes, definitely. However, if at all possible I would like to postpone putting in the veneer of wayfinding aids until I know the basic workflow will not change drastically.
I’ll try to keep that in mind but if you could put an asterix or something next to your name to help me remember that for next time, it would be great!
Here is my take away. I’ll look specifically into finding a way to indicate that a “focused press” will do something useful. In case you don’t know what I’m talking about: A “focused press” is something that I like to use in my UX. For example, if pressing X causes a certain element to be focused, then pressing X again when the element is already focused is called a “focused press”. It is like a double-tap in other UX but without any requirements on the timing.
Sorry to chime in here with something different. I’m fairly new to the er301 and one thing that bothered me a bit when learning how to navigate the system, was having to double press buttons a lot. which makes sense once you grasp the focus and fire paradigm. But: Wouldn’t it be nice if trigger events (eg. looper engage) we see on the screen would happen already on first press? IMO this would make it much more intuitive. my 2 cents.
fantastic work again with the update! can’t wait to dig deeper… in my case the er301(+teletype+grid) cured my GAS for octatrack
Although the ER-301 was never meant to be a playable trigger interface, I am also eager to have better access to those “fire” triggers. Keep in mind though, the chains and unit interface has patching as its primary purpose and that part will stay that way. In this particular area of the UI, it’s more important to be able to select a unit control and manipulate its attributes quickly then it is to “play” the unit.
My solution for your problem is to eventually provide a separate UI for quickly generating triggers or firing off commands (known as messages in MAX/MSP). This will integrate with the upcoming command bus too.
** Oh and btw, those are not the focus presses that I was talking about just in case it was not clear.
Seems like this kind of better access to “fire triggers” might be beneficial with the upcoming pedal style looper unit you mentioned might be in development?
Same. I would only vote for an additional One Shot sampler if it had useful, one-shot specific parameters like retrigger or voltage control over the current sample (The Digitakt is a great model for an efficient one-shot workflow). Even then, I like having the option of loop vs. once on the larger Sample Player.
The addition of the loop vs. once option was my favorite workflow improvement in 0.3 so far! There was previously too much friction if I wanted to add multiple drum hits to a project.
EDIT: Another really nice One Shot option would be velocity. It would only read the velocity upon a trigger and keep the sample at that amplitude until the next trigger. This would save a lot of patching and would lead to easy articulations without worrying about amplitude-jump discontinuities when S+Hing the output VCA.
