My current plan is to have a player which can have one or more tracks. Each track can be assigned a MIDI channel and an JACK output port. The track may contain non-overlapping notes of varying length and controller changes of varying length. Each event would have a start and duration with start and end values allowing gradual variation within an event of a controller value. This should allow 16 MIDI channels of notes and controllers per JACK output derived from any quantity of tracks. Any quantity of JACK outputs can be created with them all being routed via Zynthian router control (TBC.)
(I have currently designed non-overlapping controllers but realise this may be prohibitive so may change that.)
Day one implementation will be a single track pattern editor feeding a single JACK output (which is the same as the PoC currently in GitHub). After that I will add a song editor with multiple tracks, probably initially limited to one JACK output and hence 16 MIDI channels but quantity of tracks should be unlimited. Subsequent development may allow more JACK outputs for more MIDI channels, live trigger of sequences, etc.
I have refactored the core code into several C++ classes and am now putting it all back together to re-provision the same functionality as the PoC (but without the x-runs). Watch this spaceā¦
By non overlapping notes do you mean a specific note? So C4 which starts at 23:59:59:24 and finishes at 00:00:00:01 is NOT allowed as there is already a note C4 starting at 00:00:00:00 ?
The top left encoder opens up the function menu but the encoder doesnāt change the value as I believe is the correct operation. (The encoder works on parameters in layers )
Some very regimented Mike Oldfield. Sequence running on zynthian-ceed.local (the dev environment) & played on zynthian4-steel.local, the synth in a hifiberry case using qmidinet, with the GuI driven by vnc . . . .
I have changed the file format saved to disk in the next version (not yet available) so donāt prepare any opus . The new file format is RIFF but I found MIDI file format does not suit this use so designed my own RIFF format. I hope to get over the tricky replay coding I am currently refactoring soon so I can push an update. Watch this space .
Iāve had the Oldfield playing for a while now and it does miss the occasional note, but you probably know that. (teeth grinding mutter at python . . . )
@mheidt I wrote a RIFF encoder and decoder from scratch. When I publish the code (hopefully this week) you will be able to see. It is fairly simple, just write / read header then write / read block data. I could probably add more error handling and I think I my code currently expects blocks in prescribed order but that is a requirement of this implementation.
@wyleu yes! Python is the main cause. From the Python JACK library docs:
I made a little mistake when rebasing some ādisperseā commits and merged the stepseq branch on master. As itās quite self-contained and doesnāt affect the normal behaviur, i will keep things like that, so everybody can test the @ribanās stepseq proof of concept.
I added a note for remarking itās on āalphaā stage ā¦
Of course, if you perceive some problem regarding this, i would disable the stepseq until itās on ābetaā stage
Ha! It is fun to have early glimpse of stuff. Call it a technology preview . Just to reiterate an earlier comment and underline @jofemodoās comments, this will cause x-runs and the file format will change. @jofemodo you may wish to test the impact of x-runs with this version. I am close to providing the improved version so you may assess the risk of a temporary degradation.
I have committed the new version of step sequencer to github feature/stepseq branch for your enjoyment. This has a library which provides the low-level functionality including file storage (using new RIFF format), JACK interface, pattern and sequence management, etc. Features are broadly the same as PoC. There may be the odd change and I think GUI performance may be a little less performant but JACK is not xrunning frequently like it was with the purely Python version.
Please have a play and let me know of any issues or changes you think may be beneficial. You can also let me know if you like it .
Note that this version does not rely on jack-midi-clock, instead implementing its own internal clock. Sync to external MIDI clock is currently disabled but I will re-enable that in a future version.
This version only has the pattern editor view. I will start to implement song editor and live pad trigger view next.
I can confirm that problem. Also, the step view can scroll up and down, but not sideways. With the default sequencer settings, that means I canāt see most of the sequence.
The whole sequence is displayed horizontally. There is no horizontal scroll or zoom.
There is vertical scroll and zoom available. You should be able to see the whole timeline at all times.
. The new file format is RIFF but I found MIDI file format does not suit this use so designed my own RIFF format. I hope to get over the tricky replay coding I am currently refactoring soon so I can push an update. Watch this space 
.
. Just to reiterate an earlier comment and underline 
.