MIDIdef.sysrt( \tes1 , { arg name?; name?.postln } );
How to get midiclock value ?
I could not find argument name in document.
How could i know these arguments name ??
The arguments to the function you pass to sysrt are in the documentation for MIDIFunc.sysrt, I think.
In general, MIDI clocks don’t send a time - only ticks when the time advances. You have to keep track of the time yourself - I just built some infrastructure for this and I must say… it can be tricky. You can use the MIDISyncClock class in the ddwMIDI quark, which can achieve basic sync to let you play patterns along with your Patterns. But, there’s a lot more required to get rigorous sync working.
I may be able to write a longer post about this (MIDI clock sync workflows…) soon, if it’s useful to people?
2 Likes
Thank you help.
I still could not find the way to get argument data.
Anyone know it ??
ddwMIDI , I’ll try it.
You can’t get data associated with MIDI clock tick messages because there isn’t any. That’s what scztt was saying – “MIDI clocks don’t send a time - only ticks when the time advances.”
http://doc.sccode.org/Classes/MIDIIn.html#*sysrt
MIDI song pointer and song select messages send data. MIDISyncClock doesn’t read these, though. The clock start, stop and tick messages have no data – there’s nothing to get.
In general, MIDI clock is not a very strong way to achieve sync – it’s 40 year old technology. Why do you need to use MIDI? Depending on what you’re syncing to, another technology might be better.
hjh
Hello and thank you for your proposition,
It would be great to have advices on MIDI clock, sync workflow etc.
Sync in general: If the device or software supports Ableton Link, use it sooner than MIDI clock.
Perhaps I’m too opinionated here (I am not fond of MIDI clock at all), but my advice is: 1. Avoid MIDI clock if at all possible (if the device supports some other method, e.g. Ableton Link modules from Expert Sleepers). 2. If you can’t avoid it, try to use MIDI clock out from SC to the other device, rather than the other way around (much easier to handle latency).
It’s true that I wrote MIDISyncClock, but it really only barely works, and I don’t have any MIDI clock devices to test it with, so… I can’t really support it properly. I’d welcome suggestions from others (feel free to send pull requests to https://github.com/jamshark70/ddwMIDI if there’s something in it that you can improve).
hjh
1 Like
Thank you.
I misunderstood about what MIDI clocks sending.
I checked midi data with open frameworks , and it could get duration from midi clock , so i thought i could it with SC. But actually open frameworks calculate duration in source.
I want to try sync with analog modular , so i’m thinking sync SC and modular from midi clock device.
As noted, I’m opinionated 
– MIDI clock was designed at a time when devices didn’t have to consider soundcard latency. So it doesn’t handle latency, making it a poor solution for syncing computer audio. Great for drum machines – for computers, not so much.
Ableton Link is really a lot better.
There is a hardware module that syncs up to a Link network and outputs analog clock signals.
It might even be cheaper than the clock module you’re considering (the E-RM is 195 euros, The Missing Link is $195).
Link is truly amazing. It blows MIDI clock out of the water. Given a functioning WiFi network, it’s really as simple as TempoClock.default = LinkClock.new.latency_(s.latency) and you’re synced (not just following closely behind – synced, with timestamps and everything). With MIDI clock, you might get OK results. With LinkClock, you’ll get excellent results with a fraction of the fuss.
If you’re committed to the MIDI clock module, then run SC with the smallest hardware buffer size the CPU can handle.
hjh
1 Like
Oh , i didnot know this.
I’ll check it , thank you!!
Thank you hjh for your advice, your MIDISyncClock class and for the link to the missing link.
Yes, this would be useful to read…