Expose tracker playback state over virtual MIDI port

[LeStahL]

Sointu could create a virtual midi port and send the following messages into it:

• time code while playback is active or when current playback cursor is set manually
• start, stop messages
• sysex for all sync tracks each time sync values change, with payload "sync track index" and "sync track value" in full 8-bit resolution (Could send control change here, but those only have 7 bits resolution, which is less than Sointu allows)

This would enable intro player code to get remote-controlled by the Sointu tracker (or even the plugin), which makes faster iteration of intros possible.

https://pkg.go.dev/gitlab.com/gomidi/midi might be suitable.

[vsariola]

MIDI integration would be great; even accepting MIDI events to the stand-alone tracker like they come now to the VST. I remember checking into gomidi and having some issue with it, but maybe things have been resolved by now.

[vsariola]

Although I started thinking if MIDI is the best way to go about it in this direction, wouldn't a socket be much easier? A bit similar to how rocket works. We could even send the sync values from the tracker through this socket. I actually had something like this, implemented using the golang RPC, but in that case the other ends also needs to be written in golang (which I had). The synchronization of the visuals to the music was not that great, which is why the rocket way of doing it i.e. having the music played in the same application where the visuals are rendered would be better.

One idea is to send periodically the entire rendered song from sointu to whatever app you have for visuals as a buffer, or as a song data structure and then use sointu as a library to render it. Then the visuals app could play the song and visuals in perfect sync with each other.

[LeStahL]

The main idea behind the feature is being able to live-debug sync using the player controls in the tracker; so the task of communicating the current sample position in the track remains even when transferring rendered samples to a gfx player over a socket.

I think using MIDI ports is not the best strategy for this; because there is a certain wonkyness of the virtual midi ports rtmidi creates on windows.

Using the MIDI protocol to send start, stop, timestamp, sync and sample data chunks over a socket could be smart. Or does OSC cover our use case well?