V0.3.x Firmware Workout: Better late than never

Actually, I’m aware of this one but thank you!. The reason for this is that individual grains themselves are not aware of slice boundaries. I will address this soon

Should I get rid of the “How Often? once vs loop” option and just make a separate One-shot Player and Loop Player?

cap001

:grin:

Golly, can this be better labeled? Its lack was a severely dis-incentivizing moment for me. (To the extent of looking up OTs on Reverb.com instead of playing with the new feature set.) I got past it, and the Freeverb is really nice. Still. I’ve been really used to the “up” convention getting me out of the current view, and this is a significant departure from that.

If this kind of thing is disruptive for you then I would strongly recommend staying away from the unstable firmware until I can get the kinks ironed out. :sweat_smile:

As for the UI change, I’m still feeling my way with these contextual views but I really want to make them proper citizens of the UI and not just momentary things that go away when not focused. Hence the change but I’m all ears.

1 Like

I’m not sure if it was the same in 0.2.x but I’m liking the “enter” button to open and close the waveform view and NOT having to press the button under the shift or punch or whatever fader.

As I say, there’s always the possibility that this existed before and I had been doing it wrong!

Weirdly, however, I’ve also been looking for second hand octatracks today!

Wayfinding is non-optional for me. This navigation is not indicated as an affordance. So that takes me out of the moment of thinking musically and puts me back on my computer. At which point, I may as well be in my DAW, with all its inherent distractions.

I realize that with the real estate so severely limited, navigation is not necessarily going to be able to be consistent (e.g. the up-button convention). Non-consistent navigation needs indication, of some variety. Maybe a hyper-link style underline? An asterisk? Something to indicate poly-modal functions not otherwise accounted for in the “usual” workflow style.

Unlabeled polymodal behavior is a deal-breaker for me.

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’m thinking that where I really failed you is neglecting to tell you about the change.

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.

I’ll see what I can do! :man_factory_worker:

Oh and by the way, does that mean the unit menu is behind a confusing UX for you also?

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. :alien:

No, the downward arrow and insert workflow is well-indicated.

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! :joy:

4 Likes

Done.

3 Likes

Unit Header and yes.

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.

1 Like

Okay. I got a good laugh out of that one. :lollipop::laughing:

5 Likes

I appreciate it. Thank you for hearing my “argh.”

3 Likes

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 :stuck_out_tongue: