When on the Pads or Pattern Editor screen, spinning the Snapshot encoder will adjust the tempo, with the current BPM being displayed in the status are at the top left.
1 Like
This would be perfect!
Another question regarding ZynSeq, is there a technical reason why .zynseq files binary instead of plain text?
For the sake of openness and hackability, having the patterns stored in a standard open plaintext format (maybe SMF?) with the rest of the settings settings stored in JSON or similar would offer some interesting possibilities.
Iām thinking things like quickly generating Bank/Song templates with mappings, drag and drop replacement of individual patterns, programmatic creating of entire songs etc etc.
Iām also thinking of a simple desktop sequence editor, which is possible anyway of course, but would be far easier to put something together in other languages if the file format was plain text and in some kind of standard format.
(Apologies if this has changed since in recent updates, my digging around happened the other day immediately after the update.)
@Jtunes as @gr0k says, Tempo can be adjusted with the SNAPSHOT encoder and also from the menu, e.g. for touchscreen-only users. The current tempo (and beats per bar / time signature) are saved in the snapshot. There will be the ability to add tempo changes during a sequence but that is not yet fully implemented. That would allow you to have a sequence that adjusted the tempo, e.g. slow everything down or set the tempo for a song and will also allow changes of tempo during a traditional linear song, i.e. use one pad as your full length song.
@gr0k the file started as a JSON file and the code started as Python but it soon became obvious that Python would not pass muster so the c++ library was created at which point it became easier and faster to use a standard IFF type binary file than a human readable file like JSON. The file format is described in the source code repository so anyone can see it and interface with it. I did start to write a Python interface to the binary code when we had some file version compatibility issues recently. (You may have sore memories of that!) It isnāt too difficult. I donāt mind which we use as long as it is performant and extensible. I want to avoid changing things unless we need to so donāt propose changes to file format today. 
The library could be used to interface with the file, e.g. load the library in an application (c++, c, Python, whatever), load the file, manipulate the data, save the file but I guess that is what Zythian does!
1 Like
Ooops, I hadnāt seen that file! Thanks for pointing it out.
If there are advantages to the the binary format Iām happy, so long as the format is open and documented. Your documentation is better than most, I think Iāll be able to hack it up in PHP, because I like doing stupid things with inappropriate tools.
Turns out itās not that stupid after all, I just found this page that explains things.
hahahaha oh wait, itās back to being stupid, this article is from a series called āYou Want to Do WHAT with PHP?ā
But I have been daydreaming about a decent tool to manage / tag / etc my recordings. Why has no-one made a decent stand-alone media manager?! (for Linux)
Edit: the connection between the media manager and wanting to read/edit ZynSeq files in PHP is that Iām dreaming about a web interface for ZynSeq files that I could similarly catalogue and visualise.
Edit2: the file format documentation looks to be describing the old format, using songs instead of banks? It doesnāt reference midi input channel, trigger channel, or note-on bindings. (which might explain why trigger channel doesnāt appear to stick - it defaults to 16, but I should change to that anyway - hopefully avoiding existing bindings haha)
No rush on the updates tho, the new features are well worth outdated documentation 
Iāve already got lots to play with right now, and am way behind work as it is because of it hahah
1 Like
This would certainly be an elegant solution (at the expense of an extra prompt at snapshot load time.) Maybe at this prompt show high level the snapshot contents (#layers, #sequences or something of that sort as a confirmation) and allow for a cancel optionā¦
This path leads us to a question of how to organise and find back the pure sequences (or other blocks in the futureā¦) among the varied snapshots.
It actually might help to be able to see on device if a snapshot contains layers, sequences or both since it might get confusing quickly. Or possibly simply a manual or automatic ābankā / folder to organise the pure sequence snapshots. Renaming in webUI would still be possible naturally, but thatās off device.
Actually having the sequence data in the snapshots opens the door to be able to inspect the snapshot/sequence contents at higher level from the webUI.
Possibly view/edit even in the future.
Iām not sure if any of this is helpful or makes a lot of sense at this point, Iām sure something nice will evolve as the community will wholeheartedly adopt zynseq soon!
1 Like
Iām not convinced that such a workflow is optimal but if we go down this route we could have the same snapshot behaviour as now, i.e. short press to load and then add context menu to build press including showing each element allowing loading of each and deletion of snapshot.
Not sure if it will help or confuse things, but Iāve basically been treating snapshots like songs.
I donāt know if this is how others are doing it, but without being able to make on-device presets for effects and instruments I canāt figure out a better way.
Very much open to suggestions tho.
Edit: which is why Iām keen to be able to peek inside the zynseq files, and be able to transplant sequences etc from my computer.
Iām not convinced either. I think we should keep things as simple as possible for a time. Letās wait to have more feedback about how the zynseq+layers+snapshots are used together and make the right movement then. In the right time, the right solution will emerge.
Until then, letās play with it as much as we can!! 
Enjoy!
2 Likes
@riban @gr0k Thanks for the help. Unfortunately, I independently discovered the tempo control this morning! 
I better compensate you guys for your trouble with a 
! Stay tunedā¦
2 Likes
Thinking aloud and briefly exploring the space of more complexity and possibly confusing everybody even more, what is the worst that would happen if we combine both storage approaches?
Is there any harm in having an extra (optional) load/save/copy/paste/clone of just the sequences in zynseq? The file format could also be 100% compatible with the snapshot format, by using a strict subset and only saving sequencer data. The implementation would, while more complex, remain consistent.
This would allow more varied workflows but still easy, self-contained snapshot+sequence files that can be shared, loaded instantly and ready to go.
At least in some synths containing a sequencer the complexity is similar, sequences are combined with presets for instant ātrackā loading, but itās usually possible to clone/copy a sequence for reuse or āmusical mutationā even to other presets.
Or maybe this is where the analogy of an external sequencer with its own memory completely independent of the instruments/presets also holds, and the question then becomes if zynseq should also be able to fully behave as one and retain a certain amount of independence for its sequence storage as wellā¦ (for example to operate without Zynthian midi layers and interface with external devices).
It really depends on the fact if zynseq wants to be a virtual āindependantā external sequencer, an integrated sequencer like many synths have, or - quite possibly - both, retaining the best of both worlds into something uniquely Zynthian.
Confusing indeed, there are many workflows possible, but itās also prudent to stabilise the storage model before too many masterpieces get saved as well and things get lost in translation/migration.
I hope this doesnāt launch a full philosophical debate on thisā¦
Full snapshot loading/saving, partial snapshot loading, pure sequence saving/loading all seem to be compatible enough to facilitate various creative workflows. But it might get confusing.
Iām very confident an enlightened path will emerge after some more sequence workflow experimentation 
Sequence on!
1 Like
would zynseq run successfully on a Pi zeroā¦?
5 Likes
@wyleu - very nice question !
@wyleu - possibly!
@dhrupadiya - stop encouraging him!
5 Likes
I discovered a bug which will delay shipping so whilst I spend the next few hours / days banging my head against a black, wedge shaped box I thought it might be interesting to compare some of the features provided by ZynSeq and those provided by Pyramid which is mentioned a lot as a competitor! Letās take Pyramidās list of features and see how ZynSeq compares. (Note that Pyramid is a most excellent product and I have not tried to emulate it so this will be interesting to see how the different approaches compare.)
| Feature | Pyramid | ZynSeq |
|---|---|---|
| Core player | ||
| Maximum number of tracks played at the same time | 64 | Unlimited |
| Maximum number of patterns per track | 32 | Unlimited |
| Maximum number of sequences (group of tracks & patterns) | 32 | Unlimited |
| Maximum number of projects | 256 | 64 banks per snapshot, unlimited snapshots |
| Maximum number of events (notes, CC, ā¦) per project | 10000 | Unlimited |
| Maximum number of effects per project | 320 | Unlimited (MIDI FX in Layers) |
| Track length | 1/4 bar (a quarter note) to 384 bars | Unlimited |
| Track time signature | 1/1 to 24/16 or 1:1 to 24:16 | 1 to 64 beats per bar global |
| Recording resolution | 96ppqn | 24ppqn |
| Tempo | 10.0 to 999.9 BPM | 1 to 480 BPM |
| Tracks | ||
| Maximum number of notes per step (polyphony) | unlimited | 127 |
| Maximum number of CC automation per step | unlimited | Not yet implemented |
| Maximum number of FX automation per step | unlimited | Not yet implemented |
| Maximum number of effects per track | 5 | Unlimited (MIDI FX in Layers) |
| Maximum number of assignations per track | 131 | ??? |
| Note pitch | C-1 to G9 | C-1 to G9 |
| Note velocity | 0 to 127 | 0 to 127 |
| Note width | 1/96th to 384 bars | 1 step to length of pattern |
| Note Offset | 0% to 99% | Not yet implemented |
| Zoom | /4 (1 step = 4 quarter notes) to x16 (1 step = 1/64th note) | 1 to 64 beats in arranger |
| Automation recording, drawing, importing, exporting | CC0 to CC119, pitch, mono pressure, program change, effects parameters, BPM | Not yet implemented |
| Inputs | ||
| MIDI in | 1 | 1 |
| Plug and play USB MIDI in | Y | Y |
| CV in [0 to 5V] | 4 | 4 (with expansion board) |
| PEDAL in | 2 | up to 16 (with expansion board) |
| Outputs | ||
| MIDI out | 2 | 1 |
| Plug and play USB MIDI out | Y | Y |
| DYN sync out | Y | N |
| CV out [0 to 5V] | 1 | up to 16 (with expansion board) |
| ENV out [0 to 5V] | 1 | 0 |
| GATE out [0 to 5V] | 1 | up to 16 (with expansion board) |
| User interface | ||
| backlit silicon button pads | 35 | None |
| Menu clickable encoder | Y | Y |
| assignable clickable encoders | 5 | 4 |
| Assignable touchpad | 105x65mm | XY Controller on touch screen |
| Display | White backlit high contrast LCD screen (15Āµm dot gap) | 3.5" colour touchscreen |
| SD card slot | Y | Not removable but can use USB flash |
| Other | ||
| Power supply | mini USB bus (5V, 500mA) (included) | USB-C (not included) |
| Housing | machined aluminium 2mm, dark black | machined steel 2mm, dark black |
| Size | 206x268x44mm | 173x102x57mm |
| Weight | 1.6 kg (3.5 lbs) | 472 g (1 lbs) |
| Kensington security lock | Y | N |
Not everything has an exact like-for-like comparison but it is pretty close. Most workflows can be achieved by both devices. ZynSeq currently lacks sequencing of continuous controllers but the concept is designed in awaiting implementation. Some of the unlimited parameters are not tested to destruction so there may be some real-life limitations that will need to be identified during testing. Some workflows can be achieved in different ways and each probably has its own unique elements but the comparison chart shows they are quite similar devices.
Of course the real test comes when we release this and users start exercising it to see how it really works under demand. It would be good to see an independant review.
10 Likes
Donāt forget the midi usb host functionality of the zynthian, itās pretty huge for some setups.
As I said I do have one, so, if you need any info on how some workflows are implemented on the pyramid, or some of the gripes/limitations it has, we can have a chat and I can show you, I could actually loan you the unit but covid/brexit make it hard to feel safe about shipping anything
2 Likes
The Pyramid can also generate Euclidian Rythm tracks like these which is really handy to very quickly generate known or novel pleasing sounding patterns into a track.
The number of parameters are easily operated with a few turns of an encoder (#on notes, total notes, note width, note offset)
Maybe an idea for a far future, post-shipment
1 Like
I based the comparison chart on the list of Pyramid features and did not add any unique to Zynthian.
Hi @zynthianers!
Iām really excited with the imminent merging and the official release of the zynstep. Itās been a HUGE effort from Mr. @riban (almost 1 year of work!!!) , and i must say that the result is absolutely amazing and so fuuuuuny to use!! Yessssss! 
Zynstep closes the loop and transform zynthian in a self sufficient machine. My (our?) uDAW dream is now almost a reality. Of course, the room for improving and adding new features is also huge. We (all of us wanting to collaborate) have to sit down and think about it for a time, but why not, we can brainstorm too. The excitement is so big that it will be difficult to stop it
-
Sample player with time stretching and tune adjustment
-
Euclidean Rythm Generator (and other pattern generators, including arpeggiators, etc.) =>
- GitHub - WilCrofter/Euclidean_Rhythms: A python script to derive and play Euclidean rhythms as described in The Distance Geometry of Music by E. D. Demaine et. al. (2007)
- GitHub - lapets/egcd: Easy-to-import Python module with a basic, efficient, native implementation of the extended Euclidean algorithm.
- GitHub - ideoforms/isobar: A Python library for creating and manipulating musical patterns, designed for use in algorithmic composition, generative music and sonification. Can be used to generate MIDI events, MIDI files, OSC messages, or custom events.
-
CC automation
-
And much more ā¦
But before all this, a last breathe before the merging ā¦ and a HUGE acclaim for Mr, @riban!!
You really did it, mate!!! Congratulations and infinite gratitude for making zynthian bigger and better!!!
Enjoy!!!
14 Likes
2 Likes