I think AI should decide what you want and apply it regardless of your actual desires!!! 
5 Likes
Disregarding anything AI wants, this implements what I was talking about. Pretty rough, if any param in the cuia is given it will wrap (but I cannot imagine right now what other params could be invented in the future).
3 Likes
Hello! Sorry for the Radio Silence… I was away, but my Zynthian finally arrived and is built!
So, further to my grand plan above, I have got on with part 2 - following up on the ALT-mode performance view we worked out earlier in this thread. The good news is I’ve got it running on the V5.1 now, and there’s a short demo attached.
What I did was this: it shows the current cue’s title large enough to read from behind a keyboard, with its program-change number and its position in the running order (something like “4 / 10”) along the bottom. As @jofemodo suggested, I built it as an ALT mode of the existing ZS3 screen rather than a new screen, so it keeps the house topbar and doesn’t need a new CUIA, and it only redraws when a ZS3 loads or saves; nothing is polled.
There are a few smaller touches on top: long titles shorten themselves to fit rather than running off the edge, there’s a “NO CUE” state at startup that tells you which cue comes first, and the arrow keys step through the cues while you’re in ALT mode — a backup for when the foot pedal fails or gets kicked out of reach mid-show.
Under the hood I kept all the decision-making in a small import-free module with its own tests, so the drawing layer stays thin. The PR is here: ZS3 performance view — an ALT mode of the ZS3 screen by KingParamount · Pull Request #594 · zynthian/zynthian-ui · GitHub — I’d welcome any feedback. (The per-cue note we talked about will follow as a small separate change to save_zs3.)
I would appreciate any feedback you have to give!
5 Likes
It’s merged, @KingParamount !
Congratulations for your first addition to the Zynthian UI!! You stepped in really strong, mate!
I’m awaiting to see your next step with cue notes 
And please, explain again how did you configure your pedal controller for sending the NEXT/PREV CUIAs.
Thanks!
1 Like
Thank you, @jofemodo - I am unreasonably proud of myself for doing an actual thing!
And thanks for taking the time to review it and make suggestions. The ALT-mode suggestion made it a much smaller and much better change than what I first proposed.
Cue notes next, as promised:
Here are my disordered thoughts about the pedal, in to sections: the controller, then Zynthian.
1. The controller (Sonicake Pocket Control)
Its stock preset was no use: switches sent CC on channel 1 with a fixed value of 0. I reprogrammed both switches to send Note On, channel 13, velocity 127 - switch A = note 60, switch B = note 62.
Notes rather than CC is what I landed on eventually. The master-channel → CUIA route only accepts note-ons (zyngine/zynthian_state_manager.py:816-837); the master-channel CC branch just above it handles bank change, CC120 and CC123 and nothing else. So if a pedal can only send CC, it needs a filter rule to become a note first:
MAP CH#12 CC#80 => CH#12 NON#60
(filter-rule channels are 0-based, so CH#12 there is the same MIDI channel 13 written as “13” in the master-channel setting - that caught me out once!)
2. Zynthian (webconf → MIDI, i.e. /zynthian/config/midi-profiles/default.sh)
ZYNTHIAN_MIDI_MASTER_CHANNEL="13"
ZYNTHIAN_MIDI_MASTER_NOTE_CUIA="62: ZS3_NEXT 1\n60: ZS3_PREV 1"
That’s the whole thing, and I managed it with no code, exactly as you said on 8 August.
Three things I’d tell my past self:
- The master channel setting is 1-based, while the filter rules are 0-based. Both appear on the same webconf page.
- The trailing “1” is the cycle argument from @niels’ #593. Bare
ZS3_NEXTstops at the last cue;ZS3_NEXT 1wraps to the wrapping form on purpose — in a tech rehearsal you jump around the running order, and stopping dead at an end wastes everyone’s time… - Setting MASTER_NOTE_CUIA replaces the built-in defaults wholesale, not merges with them — about thirty mappings vanish, including
12: ALL_NOTES_OFFand14: ALL_SOUNDS_OFF. I’d re-list at least the panic pair.
And the reason the master channel must be one nothing else uses: events are captured for the UI and never reach the routing loop (zyncoder/zynmidirouter.c:1480-1485). That’s exactly what you want for a stepping pedal; the press is silent, but it also means a keyboard parked on that channel goes deaf, and a program change on it loads a whole snapshot. Mine is 13 because my two keyboards live on 14–16.
One small thing I noticed while reading #593, not worth a PR: the steppers
test cycle is not None, and parse_cuia_params turns “0” into the integer 0.
So ZS3_NEXT 0 wraps, which is the opposite of what someone writing 0 to
mean “no cycling” would expect. Only the bare form stops. Harmless if you know,
but it’ll cost somebody an evening.
Time to get on with the last bit!
2 Likes
Thanks again for merging the performance view, @jofemodo. I promised you a follow PR, but I have actually produced 2, sorry…
#595 — an optional note on each ZS3.
This is the cue note we discussed, in the place you suggested: on the ZS3 itself, alongside
the title. There’s a “Note” entry beside “Rename” in the ZS3 options, it reuses the
on-screen keyboard, and the performance view draws it under the cue title.
Note that that save_zs3() rebuilds the ZS3 entry from scratch, so the note has to be carried across an overwrite the way the title already is. It follows the existing restore_midi_learn pattern rather than inventing a second one, and the key is only written when a note is actually set, so existing snapshots are untouched and nothing needs migrating.
I’ve tested it on the V5.1 rather than just compiling it: a note typed on the touchscreen
displays, survives an Overwrite of that same ZS3, and survives a full round trip out to
last_state.zss and back after a restart. Comparing the snapshot before and after, the only
difference across all eleven ZS3s is the one added key.
#596 — a colour hierarchy for the performance view.
This one came out of actually playing from the screen, which I hadn’t done when I wrote the
first version.
Everything on that screen was carrying roughly equal weight: white cue title, two fairly
loud yellow readouts along the bottom, and the standard white topbar title. Sitting at the
keyboard in a dark room, the eye has to hunt for the one thing that matters mid-number,
which is which cue you’re on. So: the cue title takes the yellow and leads, the program
change and position readouts go green and dimmer so you can find them when you go looking
without them competing when you don’t, and the topbar title dims while the performance
face is showing and is restored on the way out.
That last one uses the per-call fg that set_title() already supports, so it touches
nothing global and no other screen changes. I’ve deliberately left the status area alone —
the DPM and its indicators are house furniture that every screen carries, and you asked for
that furniture specifically, so a single screen has no business restyling it.
The two PRs are independent and can be taken in either order, though #595 reads better
first since the note is another thing the hierarchy has to make room for. Either can be
refused without affecting the other.
And one final thing - the “dimmer green” on the screen is not actually in zynthian_gui_config, but it’s basically a dimmer version of the one that it - I hope that’s all right!
2 Likes
Super nice, @KingParamount ! Congrats!
Both PRs are now merged. I added a little fix to avoid the hardcoded color value for the low green.
The best,
1 Like
I think we still could use a way to re-order the zs3s other than finicking with a snapshot file.
Adding a reordering thing to the zs3 menu - combined with these latest changes - I think would solve Registration sequence for ZS3, with pedal control · Issue #1056 · zynthian/zynthian-issue-tracking · GitHub. So I am hesitant of creating another Feature Request.
By the way, great work @KingParamount !
I am 100% on it and hope to have a PR for you tonight; I was just waiting a bit because I assume @jofemodo needs at least some time to sleep!
Cool, what makes you think the man needs any sleep?
Oh, well, in that case:
@jofemodo , One thing I noticed: 49e3c730 changed arrow up/down to not cycle, but left/right still do, and the comment above them still claims all four wrap. Was the intent for all four to stop? Happy to send a one-liner making them agree and fixing the comment, plus tidying the color_readout comment now the question’s answered; just say which way you’d like the arrows. Personally I would prefer them all to wrap, but I am happy to be wrong!
I’d vote to wrap, and do not like to be wrong.
It adds a Position entry to the ZS3 options menu, using the same param editor the
program change number uses, so a ZS3 moves anywhere in one gesture. With thirty or forty
ZS3s on a 5" screen, “move up / move down” would have meant an awful lot of presses.
The change is smaller than I expected. Stepping walks the zs3 dictionary in insertion
order, so reordering is just rebuilding that dictionary with the keys in a new order; JSON
preserves the order in both directions already, so snapshots need no change, and stepping
follows for free because it reads the same dictionary. zs3-0 keeps whatever slot it had,
since it isn’t part of the stepping order.
Tested on the box: moved a cue from the end of a ten-cue set into the middle, then shuffled
it about several more times. The list and the foot pedal agree about the new order, nothing
is lost, and it survives a round trip through the snapshot file.
And I think you’re right about #1056. If ZS3s can be reordered, a repeating sequence is
duplicating a ZS3 and moving the copy where you want it. No new state, no new CUIAs, no
editor screen. I’ve put that argument in the PR body so @jofemodo can say whether he agrees
before anyone builds the larger half. The one gap is that there’s no duplicate function
today: the nearest thing is loading a ZS3 and using “Save as new ZS3”, which works but
captures live state rather than copying the entry. That might be the next small piece, if
the sequence idea is worth pursuing that way.
SLEEP??? WHO NEEDS SLEEP???
1 Like
It’s on purpose. Use left/right to cycle. Use Up/down to not cycle.
I think this is enough. No need for a “duplicate” function.
The only thing with this being that “save as new snapshot” doesn’t duplicate the snapshot; it saves the current state. It’s the same thing so long as you don’t touch anything; if you are happy with that then I’m happy, but worth noting that is a potential failure mode for a new user!
Re: the cursors. Absolutely fine - suits me. Would you like me to change the comment to make that clear?
Thank you!
From my POV it’s perfectly OK. You don’t have a duplicate file in your text editor. Or in a word processor. You have the “save as”, and everybody is happy because this is what users normally need.
I mean, normally you don"t want a repeated item with different name in the same container.You want a modified one. This is precisely what the “save as” does.
Regards
Yes; that’s a fair point, but then of course that is precisely the point; in a word processor, you don’t want to have two identical files because two word documents are never lined up for live performance reading.
In a show, however, you absolutely do want two identical files; Boogie Wonderland in act 1, and Boogie Wonderland (reprise) in Act 2.
As you say, it’s easy enough to “save as…” with a ZS3, but it is particularly easy to accidentally change something - knock a rotary encoder, send an unintentional CC message, or just not realise that you made changes whilst you were fiddling (the new user issue), and then all of a sudden you have Boogie Wonderland (Act 1) and Brass Band Wonderland (Act 2)…
2 Likes
Nice. I tried it out and it works well enough.
As you noted in the PR, changing the Program Change Number silently moves it to the end. The same holds true for changing the Program Change Channel.
Let’s make a request… after sleep (which I do need).
OK. Now i understand.
I still think this doesn’t justify a duplicate function, but i’m not against if several users think it’s convenient.
Regards