<div dir="auto"><div>Wouldn't need to be a phase vocoder necessarily – it could be done with a rather crude overlap-add and a wide hop and still be ok enough for what it's supposed to be doing. Simply interpolating over the data would cause a probably unwanted pitch shift.</div><div dir="auto"><br></div><div dir="auto">I've thought about the DSP graph problem. Miller has communicated the need for this at least in [clone], so that you could allocate and destroy instances on the fly. The constraints are really hard if the instances communicate with the outside, since there's no regimented bus system as in supercollider and csound, so the web of connections is potentially much more convoluted.<br><div dir="auto"><br></div><div dir="auto"><br></div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, May 21, 2020, 9:24 AM Ivica Bukvic <<a href="mailto:ico@vt.edu">ico@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div data-smartmail="gmail_signature" dir="auto">As always, I enjoy your thoughtful emails, Jonathan. Please see below for my 5c worth:</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...</blockquote></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So-- could the scheduler be changed to resume from a dropout over a<br>
longer period of time than zero, by interpolating among that 1 second<br>
of lost blocks to output an accelerated version of them until the<br>
engine catches back up with the present?<br></blockquote></div><div dir="auto"><br></div><div dir="auto">Of course it could, by building a persistent phase vocoder that would compress saved buffer data whenever an xrun occurred, while requiring the output to process any missed samples. This would sap precious CPU cycles (since we are not relying on a streaming codec that is likely responsible for this and which may even rely on a GPU or a dedicated part of a CPU, as is the case with ARM chips) most of the time unnecessarily, and on top of the xrun potentially permanently introduce additional latency since vocoder will need to be in the DSP chain, and partially mangle additional n seconds of sound and even potentially cause cascading xruns due to the newfound spike in needed CPU usage. Undoubtedly, the implementation would be laborious and may cause significant vanilla codebase parity issues. So, while we could do all this, the question is why would we want to?</div><div dir="auto"><br></div><div dir="auto">A thing that in my opinion is much more relevant than this is an ability to seamlessly transition from the old DSP tree onto a new one when deleting and/or creating new object(s) and connections, so as to allow for the xrun-free live coding. IIRC Nova pd-like abandonware project may have done this in the early 2000s.</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto"><br></div><div dir="auto">Ico</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" rel="noreferrer">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div></div></div>