another newbie midi/time-question :)

yoki's picture

Yo!

So I am using the Global Midi Clock Reciever to drive my little sequencer using the Beats-output and it is working great.. However I need higher resolution than 1 beat, i would like a timer which enables me to use 1/4 and perhaps 1/8 notes as well. For this I need a counter which counts exactly 4 or 8 times faster than the Beats-output (faster, not larger steps).. How do I do that? :)

cwright's picture
hmmm....

The underlying mechanism behind the midi clock is a 1/24-beat tick. The patch internally captures these ticks at this 1/24th beat resolution, and then does the math to turn it into beats and measures.

I suppose you have 2 options: You can have us modify the patch to also export the raw clock data (the 1/24th beat timer stuff) -- this isn't particularly difficult. OR, you can use the measure output (which is a non-integer value that secretly exposes this data also) -- however due to math stuff you'll need to multiply it by 96 to restore the original "tick" count. For consistency, I'd prefer just using the second solution.

So instead of using the beats output (which is always an integer), use the measures output, plugged into a math patch (or math expression, or whatever).

yoki's picture
bug?

i went for option no 2 which almost worked perfect except for something which seems to be a bug in the patch :)

the timing of the measures-output is being disturbed by user-input which makes the timing very unstable.

by just grabbing a patch in QC and "shaking it" with the mouse i can make the integer-part of the measures-output lag several units behind the beat-output which is not affected at all and seems very stable. it is also being disturbed by user-input in other applications than QC.. making the sound stutter a lot compared to when i used the beat output (and faked 1/4th notes by quadrupling the BPM) :/

(it sounds nice as long as i dont move my mouse though :) )

cwright's picture
shaking

shaking a patch is a known bug in QC (the QC engine will incorrectly re-evaluate parts of the graph when you drag and drop patches, even without changing connections). This is discussed a bit more here: http://kineme.net/GLToolsPatch20071103beta#comment-412

as for other user input (i.e. keyboard and mouse without interacting with the editor window), I don't know how/why that would affect the patch; the beat and measure counters are updated at the same time through the same code, so there's not really a way for them to get unsynchronized -- I'll try to do some testing on this sometime this week if I get a chance, but in the mean time can you make a simple demo composition that I can use to verify this?

yoki's picture
test-composition

if this unstableness was only noticable when shaking patches i wouldnt care since i usually never do that :) but just opening the drop-down menu in safari can make the measures-output lag for a fraction of a beat which makes the audio stutter.. its possible to make it lag just by shaking the mouse without even dragging something in QC or even have QC as the active application.. when i used the beat-output to drive my sequencer, it would sync perfectly with loops in ableton live for about 1 hour (it actually never got out of sync when using beat-output, but i had a beat running for 1 hour while playing around), now i am happy if it's in sync for more than 4 bars :)

about the test-composition the only thing which differs between the two outputs are the logic for turning the measure-output into a 1/x note which is the 96x-multiplication + a few modulos which certainly wont take >1beat to perform. when i feed the patch with a 120bpm midi-clock from ableton live it wont take long before the measure-counter will be lagging 5-10 beats after the beats-counter.

connect some drumssounds to the midi-out:s and the lag will be hearable (the beats-counter going straight and the measure-counter lagging sometimes)

i really hope tthat it is just me being stupid though :) cheers

markus

PreviewAttachmentSize
shaketest.qtz10.93 KB

cwright's picture
maybe bad

I've not got a midi setup to test it with yet, but I'm guessing that driving midi output based on midi input would be an extraordinarily bad idea in QC -- QC's not really realtime enough for audio (or midi, as you've noticed), due to how the graph evaluates (bottom up, rather than top down).

QC also tends to run on the main thread, so UI updates can stall it for short amounts of time; normally not a problem, until you start using audio, where even 1ms can be a catastrophe.

120bpm * 24 packets per beat is something like 48 packets per frame (assuming 60fps), and in QC-time, that's just one execution cycle -- probably a lot more lag than you're wanting.

You can try disabling VBLSync (option-preferences) to see if that does anything for this simple composition, but it isn't really a good solution for more complex ones; for that kind of stuff, you'll want some kind of custom processing that's tied to midi packets, not video rendering.

cwright's picture
counters

Upon more reflection, I think counters in this context is also a bit wrong: because the composition will munch 48 clock ticks per frame, all at once, and it'll drift around depending on load, there will be times when it'll "skip" counting because the modulo part will output the same value on subsequent frames due to how it'll wrap with a bunch of packets at once.

The composition is designed such that, if QC was extraordinarily fast and executed the graph for every midi packet, it'd produce correct results. Unfortunately, it's not, so it will jitter.

yoki's picture
hmmm

i guess i have been spoiled with max/msp :)

but since the composition i'm working on (which is far more complex than the example one although the midi-in and midi-out works in the same way) works 100% rock-solid when driving the beats-output with an external 400BPM-pulse in order to get 1/4-notes in 100BPM i guess it would all work if the logic for creating a faster pulse would be inside the midi-patch itself? is the code for the midi-clock-patch available somewhere so i could fix that myself?

cheers

markus

cwright's picture
weird

Are you sure you're using it the same way with the integer beats (i.e. counters and everything)? They're seriously in the exact same piece of code:

for(i = 0; i < pktlist->numPackets; ++i)
{
   if(packet->length == 1 && (packet->data[0]&0xf0) == 0xf0)
   {
      switch(packet->data[0])
      {
         case 0xf8:      // MIDI clock byte
         if(clock->_running == TRUE)
         {
            clock->_clockCounter++;
            clock->currentClockMeasures = (double)clock->_clockCounter/96.0;
            clock->currentClockBeats = clock->_clockCounter/24;
         }
         break;
      }
   }
}

Could you try delta-tracking (take measures96 and subtract beats24) to see if they get unsynchronized from there? It shouldn't happen (minus small variations due to measures having fractional precision). The delta should never exceed 1.0 I think.

If you'd like, I can add an output that gives you the raw clock count (the 1/24-beat counter), so you can divide that to get a beat-related pulse.

. o O (The code's not available yet because it's still in beta, and there are some nasty bugs that we're still working on before a public release with code. I could send it, but then we'd end up with forked versions polluting QC-space -- let me know if you're still interested, and we can work together on that to keep things fork-free)

yoki's picture
no counters

no, i am not using counters with the integer beat, im just feeding it straight into my sequencer. so it seems that it is the counters+modulo logic i use in QC to "count" every 24/x-tick (to create an 1/x note-tick) that causes the fuzz as you pointed out..

what i would like (and possibly some other people who easily want to musically sync their qc-patches without hassle) is a custom 1/x note-tick counter from the plugin..

something like

   clock->_clockCounter++;
   clock->currentClockMeasures = (double)clock->_clockCounter/96.0;
   clock->currentClockBeats = clock->_clockCounter/24;
   clock->currentClockNote = clock->_clockCounter/(24/_inputNoteValue)

so if feeding the plugin (int _inputNoteValue) with a 2 i would get a continuous counter which counts in the speed of half-notes, with a 4 i get 1/4-notes and so on.. (this single line of code equals all the ugly-counter/modulo-logic i was forced to do in QC :D )

i would gladly like to help out with unforked improvement/bugfixes of the midi-patches since i use QC mainly for vj:ing/musical purposes.. i am also much more familiar with traditional oo-programming than QC.. but if this is a feature you don't want into the patch i would be very happy to get the source to make a custom patch just for this project i am working with :)

//markus

yoki's picture
svn?

so whats up? :) do you have a svn or other version control system?

cwright's picture
yep @ svn

internally we use svn, but we don't have public access (it's not currently set up to properly not share stuff that shouldn't be public ;) --- we're working on this (and by "we", I mean smokris).

yoki's picture
oops

i just realized that my composition was really idiotic.. all those counters could be exchanged for a simple Math-patch :O.. now things sound quite nice actually, it stutters sometimes adding some random QC-groove to the beat but i could live with that :)