We already have the ZS3’s name. You can rename ZS3s from the options menu.
Is the name not enough for you? Do you want an extra text?
Regards,
We already have the ZS3’s name. You can rename ZS3s from the options menu.
Is the name not enough for you? Do you want an extra text?
Regards,
Hurrah! I made a useful contribution!
About the cycling; I guess its a matter of personal taste if, when you get to the last cue, it simply refuse to move any further on, or if it cycles back to 1 again. In a live performance situation, there is an argument for the first option but either works fine.
Two things I’d watch when you apply it, both from the odd cases I tested:
▎
▎ - Cycle over the list from get_zs3_ids() rather than over self.zs3. If zs3-0 is in the ring you can land on it, and landing on it sets last_zs3_id back to None — which is the thing that stopped the pedal responding in the first place.
▎ - Keep a guard for the empty list. get_zs3_ids() comes back empty for a snapshot with no ZS3s, or one with only zs3-0, and % len() on that would raise. The if index >= len(zs3_ids) lines are what catch it at the moment.
▎
▎ Happy to send it as a small follow-up PR if that’s easier than doing it yourself.
I assume you always have a visual feedback. You can’t rely on sound feedback for this. Perhaps the difference is subtle, perhaps you can’t play notes out of song for testing the sound.
As you say, it’s a question of taste. And it can be changed easily if cause trouble.
Yes, absolutely. The name is fine, but in a performance situation I’d like more information which it wouldn’t be appropriate to put in the name.
This is the screen I’m building, so you can see what I mean:
The name is what I read at a glance from the keyboard, so it has to be big — which caps it at about 27 characters at that size. “GHOST GAG” is a good name: short, unambiguous, and it’s what the cue is called in the running order and on the band’s paperwork.
The note is doing a different job. “In on the THIRD ‘behind you’ — not before” is the sentence I need in the two seconds before I play it. It’s prose, it’s four times the length of the name, and it changes through rehearsals while the name stays put. Putting it in the name would make the name unreadable at the size that makes it useful, and it would churn the one label everyone else refers to.
So it’s the same ZS3 with two fields doing different jobs — hence asking where a note belongs rather than assuming.
If you’d rather not carry extra state in the ZS3, that’s genuinely fine and I’ll keep it in my branch; the view just loses that line. I’d rather ask than surprise you with it later.
Yes, exactly. In a live performance, you can’t tootle gently under the scene - the actors get very tetchy under those circumstances!
Yes, of course. zs3-0 is excluded from all this next/prev behaviour.
Done ![]()
Thanks!
Nice screen.
Have you thought about how to reach this screen?
It could be an alternate view for the current ZS3 screen, so you can reach it with the ZS3 button, The ALT mode can be defined for each screen and the toggle state (normal/ALT) is saved per-screen too.
I mean:
The best,
I think the ZS3 data is the right place for the note. Together with the title and other ZS3 related info.
Regarding the screen, please keep the style with other screens. I mean, the topbar background should use same color and include the DPM, status area,etc.
Thanks!
Excellent - thank you for the ideas! I will get to work and come back to you with a PR when I have something I consider to be high enough quality for the project.
I know you guys are well used to this, but as a newbie to this whole world it is pretty exciting to have made even the tiniest of tiny contributions to this project.
Simple ideas can be very powerful. I like your performance screen.
Good night!! It 's too late for me!
I think I would prefer to not cycle from top to bottom and from bottom to top. Imagine you have done a little rehearsal or test and need to get back to the start. Hitting DOWN many times is a way to get there without waiting and looking for each to load. If you know you are at CC9 then you could argue that you know you have to hit DOWN 8 times to get to CC1 and if you overshoot you can tap UP to get back, but my preference is to not wrap. (I guess wrapping can help if you have a lot of ZS3 and want to access from both ends.)
This is best acheived by deriving from zynthian_gui_base (or one of its derivatives) which provides consistent basis for look and behaviour. Indeed I would so strongly recommend this as to challenge the acceptance of any PR that does not adhere to it. There are some exceptions - we also have zynthian_gui_fullscreen_modal where there is benefit from hiding the topbar, but this is rarely used.
I’ve had the same thought, and literally every time I’ve thought a hard stop would be better, I’ve thought of a counter argument which means a loop would be better, and vice versa!
As far as I’m aware, if I create the screen as an ALT view of the ZS3 screen, I will get this for free anyway. I don’t have any strong feelings about this bit - it’s a total irrelevance in a band pit, in the dark, with the box on a stand, in the middle of a complicated song, but if it’s important for reasons of house style, then in it goes!
Yep! Me too on the wrap. I downgrade my “preference” to an “option”. ![]()
Deriving code from an existing class which derives from base class is perfectly fine. The need to derive from a base calls is not just house style, it is supportability. If we change some behaviour, we don’t want to search through every class to see what changes are required. This is why we use derived classes. A recent example is that I had to change the poistion and size of elemets in the topbar to fix an issue that was evident on smaller screens, e.g. 3.5". That would have been a nightmare if I had to review every GUI class.
Thanks for contributing. It is this kind of work that shapes the rich feature set in zynthian.
Noted! Every day is a school day…
And the Pull Request ritual expressionistic jazz dance? Do I have to carry on doing that? I’ve been practicing in the garden but the neighbours are giving me odd looks…
Great work @KingParamount, thanks a lot! This is a very useful feature for my workflow, and I will definitely use and abuse it when I move away from Oram for performances. Meanwhile I’ll investigate the best way to assign the up/down commands to my page turner pedal and M-Audio Keystation. Are you considering any offline/web tool to manage/edit the ZS3 alignments and corresponding Snapshots?
BTW, as mentioned in previous topic here, I’ve been using Songbook Pro but that only allows me to send the initial Program Change when I select song
Since you only get the comment upon triggering the ZS3 change, I wonder what tool or method do you use to guide you through the song flow. In my case, I think I’ll add notes/cues in the songbookpro song page.
It has some advantages too. For instance, when you are at end, you can start from the beginning with a click ![]()
But OK! You are the users. I probably never use this feature, so i personally don’t care too much. Real user’s comfort is the priority ![]()
Regards,
Done!
I would vote to end at the border, but have an override parameter to cycle.
That way, you can cycle through with a single pedal, and retain the behaviour people may be used to.