Sync~ object ramp at 1/2, 1/4 1/8 etc of BPM?
Hi there! I’m creating all sorts of AV GL Feedback motion tracking sound synthesis patches, and I wanna have ramps sync’d with tap/midi BPM much slower than the actual 1 beat per minute.
Like it would follow the measures etc as opposed to individual beats.
I started stringing sync~ objects together with counters and other weirdness but I wondered if there were a better way.
Float output would be great too, especially if it’s less CPU hungry.
I am doing exactly that, but using [phasor] objects. To detect the beginning (0) of the phase, I use this scheme:
There is a "master phasor" which supplies this basic beat, but of course, it need not be a phasor. This basic beat feeds 16 bangs set with delays which are divisions of the basic beat. To use measures which are multiples of the basic beat or its subdivisions, I use [int] and [accum]. I am currently testing the whole patch which uses this subpatch, with the plan of posting it here on Saturday.
I posted something that’s similar to this a while back. It does
arbitrary divisions of the beat as well. (and you can do hierarchical
also see rate~
Ah, sweet. Thanks all!
I have posted the sync-subpatch which I am using in my looping-sampler. It is available at
The [rate] object is obviously the best way to synchronize various phasor-based timing needs, but, the same as [phasor], it doesn’t provide a message at the beginning of the phase, nor does it allow the possibility of decoupling itself from the main signal in the case that synchronization isn’t wished for.
In my tests, I can use as many [phasor]s as I want, and if I start them at the same time, they don’t get out of sync, even after more than 30 minutes. For this reason, using [poly] which contains a looper using [stutter], I use a separate [phasor] for each instance. This allows me to do all the individual pitch-bending I want, set and reset the loop lengths independently of each other or sync everything up without the necessity of having a global loop-length.
I have not implemented a BPM sync, but that would be easy enough using this patch.
All of this takes me one step closer to the goal of having a truly dynamic sampler-looper which operates with only a single footswitch or threshhold-trigger. The one I am using (and currently testing) seems to work fine, but I am still reluctant to post it until I have the feeling that there are no glaring errors in its functionality. Also, it needs and [adsr] before it is complete, but I want to test everything else before adding one.
Hope this helps,
Forums > MaxMSP