I’ve made a little module for bpm timing which controls alot of the automation in the main patch, and it seems to run reliably on its own, but once running as a subpatch then its timing seems to glitch out occasionally, pause momentarily now and then. Its not much but its enough to keep putting the tempo out of synch with the music. Any ideas of what i can do to keep it running at a constant speed?
I suspect its caused by switching between xfiles and spreads of images, which i’ve noticed causes a pause in the renderer, but i didn’t think it would pause vvvv entirely. If it is that causing the lag then is there a way to stop the loading of files pausing vvvv’s internal clock?
i’ve never seen anything that behaves that different in a subpatch…
Maybe post this module here and someone could find out why it doesn’t behave as you would expect when VVVV is under more heavy load…
Not knowing how your doing your timing makes it trickier to debug, but first, do you have a main loop node in there? Is it set to increment? This could happen if you’ve got a writerNRT patch in there…
As I understand it, as long as your set to raw in the main loop, vvvv’s frame rate shouldn’t affect an lfo etc, so if it freezes while loading an xfile etc it should continue from where it should be rather than where it was when it paused for loading…
A work around if this is a problem maybe remapping current time to drive your clock, do you know about the metronome sub patch by the way, there is a tap tempo already made…?
no, i have no main loop node present, which should leave it as the ‘raw’ default right?
Attached is the patch to see if anyone’s got any ideas (i bet there’s a zillion ways it could be optimised and improved, but just getting it to count reliably is my main concern!)
I only just heard about the metronome patch, but i’d already built myself a tap tempo patch, found tapping to be too inaccurate and built this one which gets the tempo from averaging beats over a definable period (e.g. 16 beats).
The real improvements might need to be made in the main patch to speed things up, but it sounds like you’re saying even problems in the main patch shouldn’t affect this sub patch’s lfos?..
bpm calculator.v4p (7.9 kB)
anyone got any more ideas on this?
Even with mainloop set to raw, minor slow-downs caused by switching between patches and spreads of xfiles or jpgs is affecting my tempo counter (which is the thing triggering the switches in the first place).
Any way to stop this happening? I don’t mind the momentary pauses (although getting rid of those would be great too) in the renderer, but when that then puts the tempo out of synch, requiring it to be reset its really annoying.
Sorry, what a moron.
bpm2 is the actual patch, i’d just built it into a nicer UI in bpm calculator.
ignore calculator and just look bpm2, thats the patch as used in my main patch.
bpm2.v4p (25.7 kB)