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.

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.

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?

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.

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...

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.

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

((beat/(bpm/time))

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.