I have been considering how we might record to a MIDI file the Zynthian configuration to allow recall of engines, presets, parameters, etc during playback. MIDI files allow things like program change, bank change, sysex. I have been concentrating on sysex as that is the natural or obvious method but a significant obstacle is the requirement for a (rather expensive and ongoing cost) manufacturer’s id.
I wonder if there is a way to use bank and program change on the “Master” channel to assign engines and their configurations to the Zynthian, i.e. specify a snapshot configuration with standard MIDI commands.
Regarding the way of storing the zynthian related metadata, master program change could be used for loading a snapshot from the zynthian, but if we want to store the snapshot in the SMF, then SysEx should be used.
Also, we have to manage the fact that engines and layers takes some time to be created a ready to play …
Finally, we could create a “bundle format”, including the SMF (.mid) and the snapshot (.zss) in a “tar” file…
The delay taken for loading snapshots “could” (if this is possible of course) be solved with a Setlist, in which the machine would pre-load 3 Snapshots: the previous one, the present one and the next one. This way it would be able to be using a snapshot while the next one was being pre-loaded, being this way ready for usage later when called.
This would require the Raspberry Pi to be able to handle that in terms of processor capability, memory size and speed and also if it is possible to run more than one instance of some of the processes taken by Zynthian when a Snapshot is loaded.
… all this while not compromising Zynthian performance as a musical instrument.
… then i woke-up.
Pickling the python objects might keep abstraction high but would restrict you to a python world, and then it’s still got to go down a 7 bit channel . . .
Presumably it’s another chunk of context so json/yaml? and then piped down SysEx?
Quite what would it contain?
Im loosing track of quite what would be the contents of such an object, so could someone describe their view of the structure?
I would like to see a hash id for engine identification with it’s appropriate parameter set and MIDI setups. That way I can differentiate between sound sources on different devices, and you can be far more sure that the snapshot loaded on the headless is talking to the engine it expects on the renderer.
If a snapshot IS loaded with no accompanying engine tag.
Grey the display text & highlight bar
SysEx message to ‘look’ for engines,
engines found SysEx back :
light up the display to declare it active on that head. . .
Do manufacturers routinely poll with in these sorts of situations . . .? and if so how frequently .?
Otherwise how about converting the data to 7-bit values and using RPN and/or NRPN . That would bypass sys-ex and easily be integrated with any MIDI interface (some cheap USB ones are unable to do large sys-ex streams).
You make a good point. One might expect that a Zynthian would be prepared for performance and then use standard control messages to manipulate during performance, i.e. note on / off, continuous controllers, program and bank change, etc. The user will have already configured the engines / patches / snapshots and load them into the Zynthian ready for performance.
Within the rehearsal space one might play with what is already available and save snapshots to the Zynthian.
Within the studio / home environment one might use computer interfaces or other file shares and webconf to manage the snapshots and perform configuration and soundscape editing, etc.
So maybe the only thing we need to provide is a method of saving the configuration data to a midi file to allow simple and consistent transport of full configuration. This could be a dedicated MIDI recorder and player within Zynthian (replacing current off-the-shelf apps) which use the metadata to store this information. This does not allow MIDI to be sent to the Zynthian from an external sequencer with all this info but I am not sure that is of much benefit. (Sysex is defo the right way to do that!)
Thanks @B00t-eek for pointing that out. I hadn’t thought of it and it is a good idea. Anyone see any holes in this idea? (Yes - I know we need to prove it will work, define a schema, write bespoke record and playback applications… anything is possible - nothing is easy!!!)
On the other hand… maybe we just create a proprietary file format for saving and loading (and sharing) Zynthian songs. I see we can map many of the snapshot elements to standard MIDI file metadata, e.g. device might map to engine name / type but there are other elements like controller mapping that won’t be so easy to map. The point of this is to be able to save some work and restore it at another time.
This can (probably) be done now by saving the snapshot and saving the MIDI file then later restoring the snapshot and playing the MIDI file. If this is true then maybe we simply create an archive of both of these files, i.e. put the snapshot and MIDI files into a zip (or similar). Or maybe we just document the workflow that saving these two files will provide a mechanism to record your work for prosperity.
I said “probably” because I don’t know whether a snapshot file will save everything required to restore the hardware configuration and whether a MIDI file will hold all the performance data. I hope so and expect so - hence if it doesn’t we should fix it.
The new (soon to be provisioned or maybe pre-existing) ability to save and restore snapshots will allow validation of this process and inform how we might modify the product to match any common workflow.
I love the ability to record my noodling but am currently frustrated at the effort required to store that in an easy to restore way. My workflow wants to be something like:
Configure engines
Start recording
Stop recording
Save results with some metadata, e.g. notes about what it is or how it might be used
Then at a later date:
Review metadata of saved stuff
Restore a saved dataset
Play MIDI file to hear what I did
Include MIDI file in a composition, e.g. import into a DAW
Connect an external sequencer / DAW to play the restored Zynthian configuration
Perhaps this is a case of ‘sledgehammer to crack a nut’? As the UI is MIDI controllable… we only need to reproduce the MIDI data to create the snapshot - no need for sys-ex…
Not quite. If you have added engines in some order and selected presets for each of those engines and added effect chains and tweaked parameters then record yourself playing some notes and decide, “that sounds nice” and want to keep it then, in a few years when you are sifting through your “ideas snippets” you want to hear why you thought it sounded good but it sounds pants when played through a OPL3 sound module.
We do need a simple way to capture the snapshot and associate it with a recording. I want to stop taking copious notes on scraps of paper and sticking them inside the compact cassette cases which hold my attempts at greatness.
Absolutely.
A snapshot is about repeatability but the context is essential. It’s the font problem in browsers all over again, Fred used An available piano sound to record this and sent it to me to jam with. I don’t have The afore-mentioned piano sound but would like to fall back to something sensible. I may not want it on the same MIDI channel as it left fred’s and anyway I keep my xylophone on that Layer (MIDI channel), so how do we play overwrites ? I prefer do least change so that you are flagged when you can’t overwrite, but Fred may well prefer that it does overwrite so he can expect material back in the same places . . .
In our world the 16 Channel MIDI world implied by the MIDI Router seems a sensible network topology to support, so I would suggest we use that and ensure a snapshot can move seemlessly around in that world.Perhaps Load/Save Snapshot Menu may need Publish & Consume as well to allow dumping and reloading from sequencers and such.
The snapshot is the embodiment of the zynthian object and as such represents how our universe is structured.
Recording Meta Data is an excellent idea. An Audio recording of a snapshot with MIDI attached, allows you instant sorting by key for instance, which amongst enormous snatches of material would be a real bonus.
A collection of all snapshots using organ sounds is really only a definition of genre type in engine ( see previous rants) away, So give me all the rock organs in the key of A# . . . Even if the MIDI track that gets recorded is AubioNotes versus a 12 string guitar …
