Evan

I'm working on some stuff that need BPM and transport start/stop information and have been looking at different options. One is plugsync~ which gives me both bits of info I'm looking for. The other option is using live.observers that point to the BPM and transport state. I am mostly concerned with tight timing in the transport state, and I am assuming that plugsync~ will be more accurate than the Live API. But would plugsync~ ever produce an issue because it is sending this info at signal rate? I use a change object after, so any downstream process aren't triggered repeatedly.

Curious if anyone has any insight or opinion.

I'm working on some stuff that need BPM and transport start/stop information and have been looking at different options. One is plugsync~ which gives me both bits of info I'm looking for. The other option is using live.observers that point to the BPM and transport state. I am mostly concerned with tight timing in the transport state, and I am assuming that plugsync~ will be more accurate than the Live API. But would plugsync~ ever produce an issue because it is sending this info at signal rate? I use a change object after, so any downstream process aren't triggered repeatedly. 

Curious if anyone has any insight or opinion.


practical-differences-between-plugsync-and-live-observer-in-m4l-patches

No doubt plugsync~ is better. It sends the info every 64 samples (vector size).

One more related question, would [plugphasor~] and [phasor~ 4n @lock1] be equivalent? I would hope they would, but if there's any difference it would be nice to know.

Another quick question. Are these methods equivalent? 

Practical differences between plugsync~ and live.observer in M4L patches