I have a Phasor that writes to an audio rate bus, that is used as a phase input for recording and playback.
For example, when I stop the recording, I want to save its value to a variable in order to know the length of the recorded material. I must be missing something simple, but I don’t find an easy way to do that. I think I can’t use a control rate bus and do .getSynchronous, because the phase signal won’t be updated fast enough, or?
Of course I could mirror the audio rate bus to control rate bus in order to have language access, but is that the best way?
If you’re stopping the recording by sending a n_set message, then there are two cases:
With timestamp (latency = small positive float): The n_set message will execute on the control block boundary on or just before the given timestamp.
No timestamp (latency = nil): The message will execute on the next hardware buffer boundary (which must coincide with a control block boundary).
That is, you only have control rate timing resolution for the “stop” anyway, thus the phase position can be reported back to the language only with control rate resolution. So there’s no harm in mirroring it to a control bus.
SendReply.ar can report with audio rate timing resolution if the trigger is being generated at audio rate, but if the trigger is being received from the language (n_set) then the trigger is at control rate.
So it’s up to you, whether you send the phase value via SendReply or use a control bus. Either way I think the timing resolution will be the same. (This is the likely reason why there is no a_get server command, only c_get – because, even with a timestamp, it would be scheduled with control rate resolution, thus, kinda useless.)
Btw the “synchronous” in getSynchronous does not mean control-block synchronous – it only means that the method returns immediately with a value, without requiring a callback function. The server executes all at once enough control blocks to fill a hardware buffer. getSynchronous can read the bus only between these cycles. Hence with getSynchronous you get hardware buffer timing resolution, which will be more coarse even than control rate. So I wouldn’t recommend getSynchronous for this case.