The Bart, The.
601 karma · joined November 15, 2012
Here's a little announcement video I put together a week ago for an earlier version:
The approach doesn't seem popular for professional plug-ins likely because it wasn't viable for real time until modern CPU enhancements became available. Performance scales with frequency of the input which is interesting and seems to be a consequence of using an iterative solver on a system of equations and using the previous sample's state vector as a guess for the current sample.
On my MacBook M3 it requires between 50 to 70% of a single core to produce a 2x oversampled output at 48000Hz. This can be scaled back by reducing the solution tolerance bounds and get down near 25% with minimal quality loss.
For instance, the offset of an instruction two instructions away would be calculated as `lfsr(lfsr(pc))` (off-by-one bugs notwithstanding), right?
Buffered IO would have the CPU processing acting as a natural backpressure mechanism to prevent downloading too much content and also prevent unbounded memory allocation. Each CPU worker only needs to allocate a single small buffer for what it processes and it can refill that same buffer with the next IO request. Your memory usage becomes entirely predictable and will only scale with how many concurrent threads you can actually execute at once.
Also, no matter how you artificially rate limit the virtual thread scheduling (e.g. via semaphore), if you still insist on downloading the entire content into memory before starting processing then obviously you cannot process any single piece of content larger than what can fit into available memory at any given time.
I raised the issue that we have about 14 years left of ASP+VBScript literally being able to execute properly and calculate dates (sans any large date additions remaining). Guess it'll be sooner than that based on this post but 14 years is definitely the upper bound if your VBScript code even touches dates.