Yeah there’s a fair amount of sophisticated action in the new chain mode.
In order to interleave the machine parameters, we need to accurately calculate the transmission latency. and then execute the parameter transmission at exactly the right time. This is all subject to the Midi Tempo and Turbo speed.
We also optimise the number of parameters that are transmitted, if a track already has the correct parameter loaded or machine type then we need not transmit it again. For this reason, payload sizes vary, and transmission latency needs to be dynamically calculated. Also need to make sure we know exactly what state the MD is in, and we do this by monitoring CC changes and occasionally retrieving the current kit.
The actual ‘chaining’ of multiple tracks is tricky to implement. Because you want the user to be able to load tracks on the fly, but also have the ‘auto-chaining’ to run in the background undisrupted. So I had to devise a queue system.
Every time a track is loaded or chained, each track is compared against each other, and the next transition event is determined based on tracks that match the nearest transition step. A routine task keeps checking the current step position. if we’re close to the transition step, then we start preparing for the transmission. Once machine parameters are sent, the next transmission event is determined, data is cached appropriately.
The SD Card is fast, but not fast enough for the timing accuracy required. Track data is therefor loaded from the SD Card and cached in the second memory bank, and then syphoned in to main memory when needed.
In addition to the above mechanics you also need to make sure tracks play in time, are queued up correctly. Make sure that data transmissions don’t interfere with MDExploit or delay the GUI by a noticeable amount.
A fair amount of GUI code has also been implemented to work with the above.
And I still need to back port for the HD44780 display.