Cycling 74 » Topic: Looking for "better" tap tempo abstraction http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/feed Wed, 19 Jun 2013 08:25:18 +0000 http://bbpress.org/?v=2.2.4 http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-60450 <![CDATA[Looking for "better" tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-60450 Sun, 04 Dec 2011 05:48:02 +0000 dhjdhjdhj I’m looking for a tap tempo algorithm in Max that does better time detection than the examples I’ve found. In particular, I’m looking for something that can both lock in to a tempo quickly but yet be able to adjust as I tap without taking too long to match my new tempo but not be too jumpy. I’ve played around with the examples, changing the number of taps being averaged, etc, but I can’t get it work nearly as well as the tap tempo detection that I have on either my Korg Oasys or on my Boss Digital Space Echo (which seems to work even better than the Oasys). On these, I can let them free-run but if I start tapping, they very quickly adjust to my new tempo with any sudden changes. I suspect they’re using some non-linear weighted system for adjusting the tempo based on “recent” taps.

Anyone know of a more sophisticated tap tempo system for Max?

Thanks,
D

]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217563 <![CDATA[Re: Looking for “better” tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217563 Sun, 04 Dec 2011 10:58:38 +0000 n00b_meister Hi
“more sophisticated” than what? You don’t mention the method you’re using; I would suggest [timer] followed by some [zl] objects for averaging, like this:

– Pasted Max Patch, click to expand. –

The minute fluctuations in timings between physical taps WILL create jumps, unless you use some heavy-handed interpolation – which will introduce a delay. Maybe add a [line] at the output?

Brendan

EDIT: added a synced beat generator

]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217564 <![CDATA[Re: Looking for “better” tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217564 Sun, 04 Dec 2011 11:53:45 +0000 dhjdhjdhj I had looked at (http://www.cycling74.com/forums/topic.php?id=23813) and also at jb.taptempo (http://www.greyfade.com/joe/maxmsp.html)

They both felt like “engineering” / “mechanical” solutions but neither of them “felt” right, at least compared to the way tap tempo works on the instruments and devices I mentioned, both of which I’ve used in live situations with a band and was able to easily sync my sequenced arpegggiators to the drummer. There were no noticeable jumps nor was there any significant delay.

I’ve done a little bit of reading since posting the question and as far as I can tell, it’s not sufficient to just take the moving average of some number of taps. The articles I’ve seen seem to have some non-linear (weighted) bias as well as some beat prediction capabilities.

To paraphrase the judge, this is one of those things that I know what feels right but I don’t know why.

I’ll take a look at your patch when I’m in front of my computer later today.

]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217565 <![CDATA[Re: Looking for “better” tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217565 Sun, 04 Dec 2011 12:17:19 +0000 n00b_meister Ah, ok

then perhaps my ‘solution’ is a little simplistic for your needs – no weighted bias or predictive capabilities, just some averaging, but with the [zl] and [line] objects it works for me.

sorry to disappoint :(

Brendan

]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217566 <![CDATA[Re: Looking for “better” tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217566 Sun, 04 Dec 2011 12:19:29 +0000 n00b_meister ps

if you keep this thread live over the next week or so, I have no doubt that a maths guru will jump in with some [expr] or other function that does what you need……

pseudo-code:

-average the first N timings
-accept subsequent timings only within that measurement
-set new tempo only after N measurements are completed

?

]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217567 <![CDATA[Re: Looking for “better” tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217567 Sun, 04 Dec 2011 13:07:07 +0000 dhjdhjdhj First of all, you’re not disappointing, I truly appreciate getting responses — sometimes such dialogs help guide towards solutions.
Nor am I suggesting that such things as “weighted bias” and/or “predictive capabilities” ARE the solution, it’s just that as I look around, I’m seeing references to such things.

Now, I just had a chance to play with your patch and as it turns out, your timer triggering that metro actually seems to work quite well EXCEPT that as I manually tap, I think it’s generating both the automatic beat as well as my tap, so I get two taps close together.

(By the way, I’m less interested in actually seeing the BPM value, than just getting a smooth beat that’s responsive to manual tapping)

]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217568 <![CDATA[Re: Looking for “better” tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217568 Sun, 04 Dec 2011 19:53:13 +0000 n00b_meister Again, ah yes

I overlooked that bang duplication;

maybe a simple [onebang] with a small delayed reset, c. 5-20ms, off the top of my head?

Brendan

]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217569 <![CDATA[Re: Looking for “better” tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217569 Fri, 03 Feb 2012 22:22:37 +0000 grizzzly540 I have found success with the [zl stream] object with the [mean] object underneath it. Using an argument of 3 or 4 is pretty smooth comparatively.

]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217570 <![CDATA[Re: Looking for “better” tap tempo abstraction]]> http://cycling74.com/forums/topic/looking-for-better-tap-tempo-abstraction/#post-217570 Sat, 04 Feb 2012 07:40:06 +0000 woodslanding How does this compare to the tap tempo in the sync~ object, does anyone know? Can these solutions be used to affect max’s global tempo setting?

]]>