Hi all, Just to remember, there is already a midi sync part in Fluxus. There is clock, signature, beat and bars supports. Only bpm is not calculated. Maybe it could be reused for Fluxa.
Cheers, Ted > > 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. >
