Making a tempo-synced visual metronome in M4L
Hi all,
First off a disclaimer in my defense :)
My discovery of Max and M4L have been very slow to say the least.. For the past few years I've only dabbled with Max and M4L, tried to get things working, frustrated, given up..
I don't know what it is exactly but Max has never clicked with me? I have never understood the "left to right" orders, (I have some programming experience with textual programming languages, they always seemed more logical!) why things lag and have latency etc... But as Max 6 is coming and the platform seems stronger than ever, I want to try again.. /disclaimer
Ok, now to the issue(s) at hand. I am trying to build a visual metronome strobe for M4L. All it has to do is to flash a white light on every beat, following the Live transport's speed and sync. I want to have this strobe in an external window so that I may fullscreen it into a secondary monitor.
Now, I have managed to make a Live's transports following strobe. It is a crude hack but it works. But for the life of me I cannot figure out why I cannot dump the "strobe" from the matrix into a jit.window - If I attempt to patch a jit.window into the matrix, I get nothing into the window. What am I doing wrong?
Second question - For some reason I am unable to get stable strobe performance if I make the "whitestate" last less than 50 ms.. I take it that it has something to do with my particular hack? Furthermore, what would be a more reliable/optimized method to produce the strobe (using OpenGL perhaps?)
Please help me! I want to learn Max this time.. I will be humble, promise!
TIA & Cheers
PS: If I would be able to make this a really well functioning patch I'd most certainly post it into maxforlive.com for everyone to use & learn...
You had been always there...
But put a warning into it for epileptics, and I'd enhance it and give each beat a different color...;-)
And if you got this going, you would probably start to turn it into a complete light show for your home disco...
It would be more efficient to use tempo-relative timing for metro and delay (which is, after all, what the transport is all about). That way you bang transport only once, on the downbeat of each measure (thus no need for 200 bangs per second coming out of the metro, nor for the change object checking for tons of duplicate numbers).
As for flashes faster than 20 times per second not working, that's probably because the delay object discards a scheduled bang if it receives another one in the meantime. (Tempo-relative timing addresses that, because the delay time adjusts to the transport tempo.)
Thank you very much for this! Your help is certainly appreciated.
@stefantiedje: No need for a home disco - this is for our drummer (he dislikes using a headphone click for syncing to Live), a simple flash on the ones is enough!
@christopher dobrian: Thanks for explaining the benefits of sync'd metros/delays on this one.. Will make the patch much more optimized (I'll throw the change object away - it caused a bug anyway, upon stopping and rewinding the transport I would get a flash since value changed back to 1) :)
Cheers
EDIT: Now everything else works beautifully, but the metros are synced to measures instead of beats. I guess the deciding factor in the behaviour is:
metro 1.0.0 @quantize 1 @active 1
Trying to decypher this with my meager abilities tells me that:
"@active 1" tells the metro to automatically start (eliminating the need for a loadbang)
"@quantize 1" tells the metro to quantize all ticks into transport's measures?? Is this the section that I would change to get the quant to snap to bars instead of measures?
"metro 1.0.0" - No idea whatsoever on what this does :p
Thanks
EDIT2: I see now that it was the "metro 1.0.0" that was the one.. setting it to "metro 0.1.0" gave me beats instead of measures, Brilliante!
Cheers
Well, now it is working, but still not quite satisfied with the overall performance.. If I go above 220 BPM, it starts to drop flashes.. Even on lower tempos, at around 170 or so, the performance of the matrix window starts to suffer (but the windowed display still keeps up at this point)..
I had a functioning BPM settable VGA strobo on my 286-processor PC that performed better than this (1992)! There must be either something wrong with my system or this code could perform a lot tighter somehow.. Or is it M4L? I know that Max for Live is not as tight with the clock that could potentially be (?)
Yes, timing in M4L is a tricky issue. Maybe if you post your actual patch somebody finds a cure.
All righty.. here is the updated patch:
You will notice that I "borrowed" code from Christopher's example (well, his code seemed more efficient so..) :)
Any insights would be appreciated.
Ok, I've corrected some typos and inserted a [deferlow]. Not sure if it helps, please try.
Thanks broc - whoa! I didn't know that a maxpatch can even function with typos in the code :) A bit dangerous though - I'm used to more "strict" programming environments that (usually) halt all execution on a typoed line of code.. Does the Max window display errors like this upon execution?
The deferlow might also help.. seems to behave better now at least! Reading about the object made me also find this infopage, I wish I would have found this when I got into Max in the first place:
Takes a lot of mystery out of the environment :)
Cheers
Yes, I've got error messages about matrix dimensions but apparently Max just used some default values.
Regarding deferlow: unfortunately such essential information is not explained in a basic tutorial.
And with M4L there are many other timing issues not properly covered in the documentation.
Much obliged broc! I feel a lot more confident about making max patches now than before. This information should be more accessibly indicated in the tutorials etc.
Perhaps now I can re-open my earlier step sequencer projects that I abandoned due to poor stability/timing issues.. ;)
Cheers