I appreciate that we may wish to abstract clock so that it is available to all modules. It may be advantageous to implement that with similar logic to what I have done within stepseq so that a user may select their source of clock from internal, zynmidirouter or a specific MIDI source. A use case may be that there are several MIDI devices sending clock and we need to choose just one.
My question wasn’t about selecting the clock source, it was why we don’t leave jack-midi-clock enabled and have it as a selectable source? Is there significant overhead? Do you envisage conflict with other clock sources?
Currently Zynthian can’t route “by device source”. All MIDI input is merged in a single stream, so until we implement per-device routing, we only have internal clock and external clock. If several external devices sends MIDI clock, it will be a mess, so only one external source should be sending MIDI clock. By now.
I feel we should be able to select which clock is used whilst retaining the plug and play simplicity. To that end I suggest:
Zynrouter should have an output called clock. This output should be routed to step sequencer input. Zynrouter’s clock output should be derived from one of:
jack-midi-clock
zynrouter main midi output
any physical MIDI input
any zynthian engine midi output
This selection should be done by a menu entry in the Admin menu which may be duplicated in the step sequencer menu. It should dynamically update with current list of sources. This may cause issue when sources disappear, e.g. USB MIDI interface removed or layers changed. I suggest having these because there may be use cases where a specific clock should be selected and it has been welcomed by some members of the community but if we find it technically challenging then we could (initially) limit to just the first two options. The advantage (and disadvantage) of using zynrouter output is that it allows mixing of different clock sources. This could be advantageous when you don’t know or care which device will be providing the clock and has the capacity for artistic use, e.g. varying the rate of different clocks would give an interesting dynamic to a sequence .
(Maybe step sequencer should have separate clock input - it probably doesn’t matter… will see how the code optimisation pans out.)
The reason I suggested an extra output called clock rather than just routing the selected source directly (which may actually be appropriate) is because we may wish to feed this signal to multiple modules and it makes it logically simpler to consider a single clock source that everything uses rather than selecting each clock source to each module. In code it may prove to be more efficient to do the latter.
We need to decide how this bit works to avoid autorouter and stepseq fighting with each other.
Stepseq could be something like a midi-plugin, so that every layer could have its own stepseq if needed.
Each Stepseq has its own patterset which is stored with the layer data, additional patterns can be stored and
loaded from / to SD card.
Stepseq gets an additional (list) view like in tracker sequencers.
Patterns can be switched from extern with program-change or maybe CC - or intern with songseq.
Songseq is located in the main-menue and controls all the stepseq. Tempo, what pattern and how long,
transpose, program change for external equipment … and so on.
“Live launcher” - do you mean like a jingle player where you hit a button and a sequence plays? Hitting it again will re-trigger the sequence from the start? Would we want it to have the option to play whilst a key is pressed and stop when the key is released and have an option to trigger on key press and ignore key release?
I see, so some sequences are configured to loop whilst others configured to play whilst pressed. I can’t see it in this interface but it may be advantageous to allow more modes:
Single shot, always play to end of sequence
Single shot, play whilst pressed stopping at end of sequence or when released
Loop, toggle on / off, stopping when off
Loop, toggle on / off, playing to end when off
Loop whilst pressed, stopping immediately when released
Loop whilst pressed, playing to end of sequence when released
First and last could be combined to a single mode, i.e. always play to end of loop and repeat whilst pressed. I would also want to decide whether triggering whilst a sequence is playing would retrigger from start or stop the playback. Within the GUI this could all be represented with icons and it could all be triggered by MIDI note on / off (although which channel to use is open to debate - the master channel is already used for CUIA).
I am working on the sequencer play engine and am considering constraining it to 16 tracks tied to MIDI channels. Are there compelling workflows to expand the quantity of replay tracks beyond 16? We currently have a constraint of 16 MIDI channels within the Zynthian but we may wish to use its sequencer to control external devices in which case we may wish to target sequencer tracks to specific MIDI output devices. This may require reworking the MIDI routing in the Zynthian and consideration of handling of temporary devices, e.g. USB MIDI. Thoughts?
One useful case for more tracks is splitting CC and notes to separate tracks that share the MIDI channel. That allows all sorts of expression/effect variations without duplicating the actual the notes by enabling and disabling the CC track(s).
Okay - I am working on the concept of a track which has a MIDI channel and a JACK output. In this way I can create a single JACK output and assign all the tracks to it and if we need more then we can create extra JACK outputs and / or have multiple tracks which share the same MIDI channel. I think this will work, remains relatively simple and starts off as appearing to the user as a 16 track step sequencer with one track per MIDI channel.
Please note that I have been elbow-deep in C++ code this week refactoring the whole thing hence no tangible progress or change but I think there is a twinkle of light that might be the end of this tunnel. All made more challenging by me feeling a little bit poorly but hopefully that is also passing. Depending on l commitments to the garden, house, family, etc. I may have something new by the end of the weekend or early next week… Keep safe out there!
So you won’t be able to have two different loops with the same sound unless you create a new layer on a new MIDI channel? That’s neither kiss nor beautiful.
For clarity… I assume a track does not mean a channel (16 MIDI channels, however many tracks).
I would certainly like to have multiple tracks that send CC data (perhaps of different lengths…) so I can have step LFO effects whilst playing an instrument live. Stay safe!
.
