Proof of concept of a new single page interface

[olt]

I tinkered with a new interface, that shows all information from the three pages at once.
The interface needs a bit more tweaking, and the code needs a cleanup and a few comments.
That said, I do think the interface contains all relevant parts.

Description

• The bottom shows the current page, and the active knob/encoder actions. There is room to also show the inactive actions and use level to indicate which one is active.
• c/f is indicated behind the action[1]
• Left bar is volume, second bar is feedback. Volume is level(1) when muted.
• All parts that are active (e.g. can be controlled right now) are highlighted.
• LR is used with level to show the pan position, (e.g. L gets darker and R gets brighter while you pan to the right). C for center.
• REC when recording is active.
• Speed is indicated as text and a bar. Right for forward, left for backward. A small tick indicates the offset, when LFO is enabled.
• The right border of the buffer display is always the current end, the left border is always 0s and the start position moves. So you can see what is in the buffer before, but not after. This is a compromise as the buffer display would not be usable if it is always 60s long.

Further ideas (for now or later)

How to enable single page mode?
Adding it as a fourth page is not an option, as it relies on the three-page control interface. I'm thinking of adding it as a param option that you enable from the EDIT menu. I also want to try to implement a more sophisticated E1 implementation where you need to twist the encoder twice in the same direction to move to the single page. Not sure how well this would work...

Buffer display: Only show the current active buffer (so left border is the start position). Buffer display would get more detailed if the time is shorter. On the other hand you could not see what is before the start position. Alternative implementation would be to show a bit left from the start and a bit right to the end position.

[1] Having this linked to the action would make it possible to disable fine control for level, pan and feedback, which works well enough in coarse mode, and do not need fine adjustments like the other parameters.

[olt]

Hi Mat,
here is my proof of concept, as discussed on lines. Let me know what you think if you have a spare moment.
As I said, I will refine the code a little bit more, so it is not finished.

[justmat]

hey hey! thanks for the PR! i'll hopefully have some time this weekend or next to check it out.

[higaru2]

fabulous news!:) looking fwd to it. one idea... dunno if its good but what about releasing the otis with one controll screen as "oTTis" - like Otis 2 !? that way, who wants the old one still uses the old and who wants the new one uses this new one. maybe its better for its code to stay cleaner!? just throwing an idea. I'll be happy with it in any form:) thank you!

…

On Thu, Mar 6, 2025 at 7:03 PM mat ***@***.***> wrote: hey hey! thanks for the PR! i'll hopefully have some time this weekend or next to check it out. — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3ZRBO22HRZHXMJFYNT43D2TB5U3AVCNFSM6AAAAABYKRZL42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBUGQZDONZRGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: justmat]*justmat* left a comment (justmat/otis#8) <#8 (comment)> hey hey! thanks for the PR! i'll hopefully have some time this weekend or next to check it out. — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3ZRBO22HRZHXMJFYNT43D2TB5U3AVCNFSM6AAAAABYKRZL42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBUGQZDONZRGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[justmat]

i am totally on board with that, if @olt wants to! it would also open things up for more exploration while they're getting their head around norns scripting

[olt]

Sure! I don't want to impose my design on your script, but I also don't want to just take your wonderful code, slap a new UI on it, and "call it mine". So I'll go with whichever way works best for you.

I can create a fork with a different name. I guess others could try it out more easily this way since Otis would still be available?! I'll try to keep the changes as close to the original codebase as possible so that merging back remains an option.

[olt]

My changes are now available at https://github.com/olt/sito and installable with ;install https://github.com/olt/sito.git. The script and engine are renamed so that it can be installed in parallel with otis.

Changes to otis:

• single page interface,
• speed, flip and LFO now behave the same whether quantization is enabled or not,
• fine parameter adjustments differ depending on the parameter (more coarse for volume, but identical for start position),
• reduce E1 sensitivity, allowing easier selection of pages

[olt]

@justmat is it ok if I post this here https://llllllll.co/t/otis/22149, or should I create a new topic? Not sure what the preferred way for these types of forks is on lines, and how you feel about.

[justmat]

i think where to share really comes down to your goals with your fork. if you think it's done, so there is very little different, in the way of functionality, from otis... i'd say the otis thread is the place to post it. however, if you think you'll keep experimenting with it, adding/changing features and whatnot, i'd say make a new thread. i am totally happy with either approach, and i'll be installing sito this evening to play with it :D