> Sorry for the delay, holiday times... > > That's ok, things are chaotic here too :-)
> > Yes, none of it is that easy. Well done for sticking with it... > > This did indeed require some persistence... But now I have it working; since yesterday Fluxa will slave to my Korg Electribe groovebox, since today jitter is down to below what I consciously notice, live-ammo field test on local radio scheduled for tomorrow, commit once I'm sure it's all proper and when I get my work computer on the internet net again. I'm doing some things a bit differently, that seems to make sense as MIDI is quite different from "slub-sync" or netclock and the like. Basically I'm slaving it to MIDI directly, at the resolution set by the fluxus midi-signature but with a delay of exactly one bar. For simplicity I'm having it slave to midi as soon as a midiin in opened that has a clock signal coming in and at that moment I'm ignoring the tempo set by the return value of "seq". This seems to work quite well and using midi-set-signature we can still set the resolution. I'm also re-using your "set-global-offset" to compensate for latency at either end. So far I like it, I'm not sure what the repercussions of this strategy are, if any, but I quite like the idea of livecoding synced to drummachines, grooveboxes and potentially those modern DJ applications. New stuff I made to realize this; (midi-beat-dur) ; duration of a midi beat in seconds where what a "beat" is is defined by the set signature (midi-bar-dur) ; as above for a bar (I needed this for the delay mentioned above as multiplying a beat gave needless jitter) (midi-last-beat-time) ; time at which the last beat came in as determined by the signature and in the standard set by (time-now) and fluxa's "time". This too is set in the C++ midi-callback function which I believe should prevent frame-rate induced jitter. I'm not a 100% sure there yet; if that's wrong then I have a problem. Yours, Kas.
