Re: FFT first window and problematic NRT delay
| Newsgroups | gmane.comp.audio.supercollider.user |
|---|---|
| Message-ID | <CAFniQ7UAMrv6o90PycLQ9bux06eKzeidSQ=9An-3gkPwU8z9qw@mail.gmail.com> |
On Fri, Mar 19, 2021 at 3:35 AM <[email protected]> wrote: > Yeah, I thought about that -- but I'd have to propagate timing shifts to an unknown number of events, and furthermore I'd like to align this score with other scores as tracks in a sequencer. This introduces a potential circularity. Not to mention that it's possible that some chain of events could end up doing an FFT/IFFT more than once. So it would be really messy to keep track of everything, and I'd end up with a generated score with timings different than those in the structures that generated them. Impossible to debug. It would be much better if I could make each synth output at the time it's supposed to! As I understand it, this is a literal impossibility with the current server design. Solving the problem would require (AFAICS) a completely different server architecture for NRT. The reason why is that the current server architecture assumes that all of the audio streams will be running concurrently, and "now" only moves forward in time. The only difference between a real-time scsynth instance's audio processing and that of a NRT server instance is that the real-time server's processing is triggered by callbacks from the OS's audio system, while the NRT server runs under its own power, as fast as possible. Running scsynth in NRT mode does not change the time relationships between the concurrent audio streams. To change the time relationships between the concurrent audio streams would require considerable surgery in the backend. So, unfortunately, the choice presently is between two solutions that are difficult to implement: - One is, as you said, to track the FFT delays across multiple sources and compensate for them in the NRT score. Difficult, but possible. - The other is to create an alternate NRT server executable in C++. I'm going to guess that the first one is easier. hjh _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/