how to have sample accurate syncing from Live's Transport (plugsync~ seems innacurate and inconsistent)

    Jan 06 2020 | 7:22 pm
    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?

    • Jan 06 2020 | 8:02 pm
      [phasor~ 1.0.0 @lock 1]
    • Jan 06 2020 | 9:45 pm
      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?
    • Jan 08 2020 | 9:36 pm
      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?)
    • Jan 09 2020 | 4:51 pm
      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!
    • Jan 10 2020 | 12:46 am
      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.
    • Jan 11 2020 | 9:19 pm
      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.