Midi Clock Sender

.lov.'s picture


i just trying to build a midi clock signal plugin, which basically works, but not accurate. Think i missed some basic stuff about how QC works. Looks like a plugin executed only 1/60 sec intervals, and UI changes (dragging something for example) blocks the rendering.

Am i true?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

smokris's picture
Re: Midi Clock Sender

Yes. Patches are executed on-demand, usually synchronized to the graphics output. If you turn off VBL syncing (option-preferences / (Editor) / disableVBLSyncing), the graph has a chance of executing faster than 60fps when run in the editor (but each rendering application still decides for itself whether to synchronize to VBL, etc).

Your custom patch can spin off threads to process in the background, independent from the QC graph evaluation, but it will only be able to feed data into the QC graph during its turn in graph evaluation.

.lov.'s picture
Re: Midi Clock Sender

I'm tested turning off VBL Syncing and put the signal sending to a background thread, but no luck.

If i correctly understand you, my patch never be accurate due the QC 'limitations' - which is not a bad thing, because QC is a graphical software to process graph data, not audio.

jrs's picture
Re: Midi Clock Sender

Are you trying to process all of the MIDI data or only pulling out the relevant parts?

By this I mean that you will need to track the time since the last frame was rendered and skip some of your midi clock data. If you store the system time next to the midi clock data each time you read that in as well then you should be able to work out value in your midi clock data array to use.

Does this make sense?

.lov.'s picture
Re: Midi Clock Sender

I just sending the Midi Clock signal (using the VVMIDI framework which is very handy). The Midi Clock message have to sent 24 times/quartet, 96 times/messure, so i can't skip any messages.

sbn..'s picture
Re: Midi Clock Sender

A separate thread could handle this with its own timer, no? I'm unsure if Cocoa and NSTimer etc. are a good fit for this since it uses the dynamic messaging system. That may mean some lower level / other level stuff, unless there's a handy library for this.

Anyway, what you could do if QC gives you timing issues (preventing you from running your own loop accurately), is doing a small helper app that listens to QC signals (start / stop / tempo / approximate timing), then communicates accurate MIDI outwards, and a simplified protocol to the QC plugin. Use a singleton pattern. Both time as a number, and something like a boolean outptut from the plugin that returns true whenever a quarter note has occurred since last frame.

Just brainstorming here...

.lov.'s picture
Re: Midi Clock Sender

NSTimer not to accurate to do this (from NSTimer refence: "a timer is limited to on the order of 50-100 milliseconds"). Hmm, i'll upload my code somewhere and you'll take a look into.

dust's picture
Re: Midi Clock Sender

yeah the vv midi osc frameworks are pretty cool. i just got one of those rock band drum kits for ten bucks and have been starting to make a rock band kind of game although i don't have a play station or nor have i played the game but so far i have got a midi clock in qc working within a four bar loop. so its patch time via stop watch that equals time. take midi bpm and divide by time then divide midi beat by the product of bpm/time so i guess it would look like


then round the product of that equation and you get a fairly good approximation of measures. i haven't made the graphics context yet but have been able to feed in a midi loop and play the drums to that loop and spit out the percentage of correct hits as well do 255 band structured dump to evaluate pitch. i have tested this with auto tune and it works pretty good in when i am testing against a file haven't got to test via live input yet.

i did notice the above calculation falls off after a bit of time so to get an accurate percentage of hits i have to re-trigger the time at the start of every loop. i'm sure there is a work around and also sure i will run into problems soon as i get graphics running. i'm thinking that running with vbl sync off at a static frame rate will let met get some more accurate results. i will upload the finished patch later. almost complete.