how to have sample accurate syncing from Live's Transport (plugsync~ seems innacurate and inconsistent)
i want to have an envelope triggered by Live's transport, every 1 beat for example.
initially i tried using the current_song_time property through an observer, but the envelope seems to be delayed and not consistent.
i read in various threads that plugsync~ or plugphasor~ was intended for such purposes, but still the triggering is delayed by a varying number of samples from beat to beat.
i tried the "current beat count" outlet first, and then the raw ticks output, as suggested in some forum posts.
i read somewhere that "plugsync~ sends all data continuously at intervals of 64 samples, ie. about 1.5ms."
anyone know if this is true? if it is, then that may be the cause of the inconsistencies.
i thought to try the "sample count" outlet, in case it's more accurate, but it keeps running even when playback is OFF, so not any use for syncing.
finally the plugphasor~ object! it outputs at signal rate! but still.. inaccurate, and inconsistent.
i don't know what else to try. anybody had any luck with this?
[phasor~ 1.0.0 @lock 1]
thanks! it seems to be much tighter in it's timing than the other approaches, but still it's not sample accurate (tested by triggering a [click~], all the signal path is running at signal rate):
[phasor~ 0.1.0 @lock 1]
|
[delta~]
|
[<~ 0.]
|
[click~]
however it's not possible to trigger the [function] object (which i want to use for the envelope) with signal rate messages. it's only possible to trigger by a bang, which is schedule rate, and i guess will muck up the timing again, as i tested by adding an [edge~] before [click~] to trigger it with a bang instead of a signal.
is it possible to send a bang at signal rate in some mysterious way?
I dont believe so.
Are you strictly tied to using [function] for your envelope or can you make a signal domain equivalent? (is there a technical advantage to using function or is it a convenience for or existing code?)
well i just need [function] for the convenient user interface.
i guess you're right in that it's probably not possible to trigger the [function] itself at signal rate~. so i have an idea that maybe possible? to use it just for "setting" the values for the curve~, and trigger the [curve~] instead of the [function]. but unfortunately curve~ (or line~) can't be triggered at signal rate.
so maybe i could replace curve~ with something like zigzag~? and maybe save the "shape" of the [function] into a buffer~ somehow? maybe wave~ can be of use? perhaps techno~ could do the job? i suppose with some combination of some of these objects it should be possible to achieve sample accuracy, but i have never used most of them, so any advice would be greatly appreciated!
Following! Having tested many of different methods, it seems extremely difficult to sync m4l devices to live transport in an accurate manner comparable to say, the ableton arpeggiator device. I wish there were some object implemented that made this more immediate.
so which methods have you tried? were there some more or less accurate than others?
for example double_ug's recommendation for phasor~ worked better than plugsync~ as i reported above.
can anyone suggest a simple method for accurate testing?
the click~ method i used isn't perfect. it generates a pulse wave that starts before the peak, so it's not so easy to determine exact latency.