[L2Ork-dev] damage-control scheduler

Matt Barber brbrofsvl at gmail.com
Thu May 21 13:08:19 EDT 2020


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.

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.




On Thu, May 21, 2020, 9:24 AM Ivica Bukvic <ico at vt.edu> wrote:

> As always, I enjoy your thoughtful emails, Jonathan. Please see below for
> my 5c worth:
>
> ...
>
>
> So-- could the scheduler be changed to resume from a dropout over a
>> longer period of time than zero, by interpolating among that 1 second
>> of lost blocks to output an accelerated version of them until the
>> engine catches back up with the present?
>>
>
> 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?
>
> 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.
>
> Best,
>
> Ico
>
>> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200521/e205cb45/attachment.html>


More information about the L2Ork-dev mailing list