Is there a "performance mode" for paging through ZS3s?

Development
, , ,
1

Hello!

I’m MD-ing a pantomime in December and using the Zynthian as my sound source in the pit (bearing in mind I have bought the V5 kit but it hasn’t arrived yet!) The show is 10–12 songs with 2–3 instrument changes each, so I’m looking at roughly 30–40 ZS3s across one snapshot.

I am considering writing a new menu item, because I don’t think what I would like exists.

What I’d like is a stripped-down performance view with two properties:

  1. Step forward/back through ZS3s in order — from the V5’s own buttons or from a MIDI foot controller. Not select-by-number; just next and previous, so I can go through the show in sequence without taking my hands off the keys.

  2. A display that shows almost nothing else — the ZS3 name in large text, plus a line of user-defined text I can set per state. In a pit, half-lit, with a cue coming, I want to glance down and read “Act 2 #7 – strings, sustain on” from a metre away. Everything else on screen is noise at that moment.

What I’ve found so far: ZS3s recall on Program Change, F1–F4 give me 8 states which isn’t nearly enough, and the MIDI profile has MASTER_PROGRAM_CHANGE_UP / MASTER_PROGRAM_CHANGE_DOWN alongside PROG_CHANGE_ZS3 — which looks like exactly the stepping mechanism I want. I haven’t yet worked out what those fields expect as a trigger (a CC? a raw MIDI event?), or whether the counter stays in sync if I recall a ZS3 from the touchscreen instead.

So, two questions:

  • Stepping: is MASTER_PROGRAM_CHANGE_UP/DOWN the right route, and what goes in those fields? Has anyone driven it from a footswitch?
  • Display: does anything like the big-text view exist, or has anyone attempted it? Is a custom view the sort of thing that’s approachable, or would I be fighting the UI architecture?

Hardware is a V5 running a pi 5, 4Gb ram. Foot controller will be a cheap 4-switch BLE/USB job that can send arbitrary CC, PC or notes on any channel (a Sonicake Pocket control, specifically).

Grateful for any pointers — including “you’re thinking about this the wrong way,” if that’s the answer.

3 Likes
2

What’s your rehearsal schedule like?

The first thing I would consider in such a dynamic environment, is what style of device I would, ideally, make these changes… A pad on a console, a set of push button stops , a touchscreen a rack of foot pedals?

You’ve specified elements and obviously considered it, but viewing the whole system as a single sourcing entity can help generalize the methods.

The zynth might well work as your implementation of this and I wonder if zynpad might offer you the sort of flexibility you require?
If you have food pedals or other good solid rugged stage inteface kit then that might well be the way to go. There is a risk of working hard to interpret the MIDI outpourings of various devices when realistically a higher level approach might reveal a simpler more sustainable and less brittle approach.

The zynth can almost certainly do it, but as with most problems the first requirement is defining the functions you want it to perform and given snapshot loading times how quickly you want to do them…

Oh and nicer people would have said Hi! at the start so consider this a retrospective welcome aboard!

3 Likes
3

Hi @KingParamount , for your goal I think a good approach is the use of a tablet (with MobileSheets app) connected vía USB to zynthian. You can create so many PDF as you need with the description text. Then you create a new song in Mibilesheets, asign the PDF and setup the midi message to be send to load the zs3, then you create a show list with all your songs. You can use a foot turnpager to go Up/down through the show song list. Obviously the larger the tablet is the easy to read Will be.

Regards.

1 Like
4

Thank you both! I’m not keen to use a tablet plus midi sheets because a)it’s just asking to get out of sync with itself, and b) my tablet will be slightly busy at the time showing me the music!

I’m controlling the page turns - and ideally, the patch changes - via a Sonicake midi foot switch thing.

I’m asking nice and early - rehearsals don’t even begin for another month…

Ideally I would have the sheet music saying “change to patch 3 here” and then I push a foot pedal and the next ZS3 loads. This might happen a couple of times per song, depending on how long a ZS3 takes to load. If it’s whole numbers of seconds, I am likely to collapse all of the patches needed for one song onto different portions of my 2x 88 key midi controllers…

5

An option for your question 1 - use function buttons to step through ZS3.

You can configure the F1-4 buttons in webconf HARDWARE->Wiring.

Configure:
Switch-1 Action = “UI Action Release”, Short = “Program Change”, param = “-,0”
Switch-2 Action = “UI Action Release”, Short = “Program Change”, param = “+,0”

This will send Program Change on MIDI channel 1 (0 indexed) when pressing the F1 & F2 buttons. The program number will decrement with F1 and increment with F2.
In webcong INTERFACE->MIDI Options, enable Program Change ZS3 (Program Change for SubSnapShots). (This can also be toggled in UI admin menu.) This will change ZS3 when a MIDI Program Change is received.

Create you ZS3 then go to the ZS3 menu and send the required MIDI Program Change, e.g. you could press F2 to send the next PC.

Now, pressing F1/F2 will step through your ZS3. This sounds like what you requested. The problem here is that you don’t have an indication during setup of what PC is being sent so you need to be very methodical, but once you have all your ZS3 created and assigned to program changes, you see the ZS3 name in the topbar as you select them.

The problem with not knowing where you are in the program change increment can also be awkward during performance, e.g. if you are outside the range of your ZS3, e.g. PC=100, you won’t know how many times to hit F1 or F2 to get back into the range.

The reason for including the MIDI channel (,0) in the config is because zynthian remembers where you are in PC selection for each channel and in active mode without this config the active channel is used, so if you are using active mode you have different PC for each selected chain (MIDI channel).

[Edit] If you are solving question 2 with some custom design, you could also show the last received program change to reduce the impact of the issues I highlighted.

4 Likes
6

Ooh that’s really useful info thanks, because it means I can equally well set up my foot pedal to do the same thing on channel 1, assuming I maintain good message discipline.

Follow-up on the channel point, since I’ll have two keyboards on separate MIDI channels (say 2 and 3) with the ZS3 program changes pinned to channel 1:
If one of my keyboards transmits its own Program Change when I switch voices on it, and that arrives on channel 2, will it recall a ZS3? Or does “Program Change for SubSnapShots” only act on the channel the ZS3 was learned to?
Basically I’m trying to work out whether I need to disable PC transmit on the keyboards themselves, or whether pinning the ZS3s to channel 1 is enough to protect me.

7

Hi

If you don’t have problems with programming, I would use a midi device and write a CTRLDEV driver for that midi device.

I did one to drive my 11 songs. I wanted them in order , so all my Zs3 are settings for each song.

I named my Zs3 like that 01_First song name, 02_Second song name,…

So in my driver I have a function to get the list of all the Zs3 songs in the right order. After that it is easy to change the songs up or down or a specific song. In my case I use an Apc Mini where 11 pads are orange to show the 11 songs and the selected one pad is green. So. Can switch the pad I want for the song I want, then the pad is green.

Oh and I call a function to load a specific Zs3.

1 Like
8

Yeah - I did consider that bt it’s just more kit on a crowded stand in a crowded pit…

@riban — thanks, the F1–F4 config works, and your edit about showing the last received
PC is more or less the thing being asked about below.

I shoud be clear that I am using Claude Code to help me, well, Code. I’m not a total newbie but I as a coder, I make an excellent musician… I am, however keeping tight constraints on what is may or may not do, because past experience shows me it will deliver the exact median solution with no regard for house style or previous convention unless you guide it every step of the way.

Here is what it has to say so far; if anybody knows the answers to the questions I would be super grateful to know them!

On the channel question in post #6: reading oram, pinning the ZS3 program changes to
channel 1 does not look like protection. The internal PC that F1/F2 sends is stamped
izmip == 0xFF, and on that path both the learn (zynthian_state_manager.py:865-866)
and the recall (:875) build the key as */{pgm} — the channel is discarded, so the
,0 in "+,0" doesn’t scope anything. An externally received PC tries {chan}/{pgm}
first and then falls back to */{pgm} (:1393-1395). So a keyboard sending PC 7 on
channel 2 will fall through to the */7 that F2 created and recall it. Disabling PC
transmit on the keyboards looks like the only reliable fix at present. This is inference
from reading the source rather than something tested on hardware, so correction welcome.

That leads to three questions.

1. Given the existing {chan}/{pgm} → */{pgm} fallback on the receive path, would
changing the internal lookup at :875 from */{pgm} to {chan}/{pgm} be viable? It
appears backward compatible — existing */N bindings still match via the fallback — and
it would make channel-scoped ZS3s reachable from F1–F4, so a stray PC from another
controller couldn’t fire them. Is there a reason not to, or something on the learn side
being missed here?

2. SS_MIDI_PC is emitted inside if send_signal:, where send_signal is
load_zs3()'s return (:872-886), so no signal fires when a PC fails to match a
ZS3. That’s exactly the “you’re at PC 100 and don’t know how many presses gets you
home” case, and it means a display can’t learn about it from signals alone. Deliberate?
Would a patch making the signal carry the outcome be welcome, and if so — extra kwarg or
a new subsignal? (The mixer’s midi_pc_cb takes three args, so an extra kwarg isn’t
free.)

3. For a per-ZS3 user note line: save_zs3 rebuilds the ZS3 dict from scratch
(:1617-1621), so a custom key is lost on re-save unless carried forward explicitly the
way title is. Is following that precedent the right approach, and would an optional
key warrant a SNAPSHOT_SCHEMA_VERSION bump?

And one aside: anything above that differs on vangelis beyond SS_LOAD_ZS3 moving
onto zynsigman?

9

When coding with AI a test based procedure seems least disruptive.

Building a constantly growing test suite means you can identify situations where the context drifts and simply declaring this test has failed and save yourself hours of unravelling.

I have found that AI coding can be far more structural than the little ‘I wonder if this will work’ experiments that have a nasty habit of growing into critical, brittle chunks of spagetti code…

And boy can they refactor well if you have the tests.

2 Likes
10

Hi @KingParamount,

Oram is at end of life
Please, target Vangelis for any modification you plan to do.
Developers are working in Vangelis from a long time ago and don’t even remember how things work in Oram. Getting good answers for Vangelis is easier and faster for all (you and us).

Please, forget the Master Channel functionality for changing snapshots:

MASTER_PROGRAM_CHANGE_UP / MASTER_PROGRAM_CHANGE_DOWN

This is not for ZS3.

I think you probably would like to use these 2 CUIAs instead:

  • CUIA_ZS3_NEXT
  • CUIA_ZS3_PREV

That you can easily bind to any key (note) using master channel MIDI bindings. Alternately you can use OSC or program a specific ctrldev driver for driving this from your favorite MIDI controller.
With this you would have the first check in your list.

For getting the second check, having the ZS3 title in the screen, you have 3 options:

  • Use the current Mixer view that shows, in the title bar, the last recalled ZS3
  • Use the current ZS3 view, that shows “selected” the last recalled ZS3
  • Program a specific view for showing this as big as you need.

All the best,

11

Great, thanks for the help!

I absolutely will be programming for Vangelis eventually, but my panto is in December, and I am worried that using beta software in a live situation will be an interesting risk…

Or am I wrong? Should I just buy into Vangelis from the start? I don’t know how “beta” beta is…

12

Hi

Just consider that CTRLDEV driver do not need more hardware. You can use your midi foot pedal or keyboards if they have pads or switches…

You could use your driver to program a specific UI.

An other think : in my case, I use 2 midi controllers : one for my song lists and effects switches on/off and an other to manage up to 6 looper tracks, with records and mutes. I did not imagine all that in once , I began using midi Cuia and program changes and… but after a time, I realized it was simpler and more power to program the 2 CTRLDEV drivers…

13

Had this code (last commit) lying about for a while to have a single HDI pedal cycling through zs3s, just polished it a bit. May be of use.

If interest is there, I’ll make a PR.

1 Like
14

Vangelis has been available for testing since December and had a lot of testing. We just migrated to Debian 13 (Trixie) and released the beta image. Obviously, changing OS version is a big step but most of the other code is pretty stable. We fixed all the bugs tagged for vangelis release before we released the beta and have been adding new bugs to the issue tracker since. If you put an image on your machine and test your workflows thorouly, then you can stick on that version. You could have a second uSD card which you could try newer versions if you want or need to keep current, knowing that you have a working version to fall back to. That is a bit of a faff but it is our recommendation for those wanting to work at the bleeding edge.

1 Like