[<<][meta][>>][..]
Fri May 10 10:32:34 EDT 2013

Delay lines

- Uses a pool of delay lines cycled in a single buffer.

- Effective memory use is delay_size + 1.  One element is used for
  writing.

- Apart from modulo, bounds are not checked on the lowest level.  For
  variable length delay, use an extra abstraction.


The problem isn't really the low-level stuff, it's how the
specification fits into the update wrapper.

Basically, in the implementation above, a delay line's state is
virtual.  So how to handle virtual state objects?  They do not need to
be saved in the global state dictionary.

Well, let's save them anyway in the first pass, but skip them in the
second pass.  I.e. instead of passing #<delayline 10>, this is
translated to index 10 into a delay line.

Basic principle: no inplace update!  Updating an array always needs to
go through a virtual object that simulates the replacement of the
whole array with a new one.



So, I'm goig like this:
- Generic vbuf mechanism to abstract in-place array updates.
- Build delay lines on top of that using Int index computations

TODO: How to get at the delay offsets?
Should it be part of vbuf read reference?

So indexing works (using vbuf attributes)
now just modulo indexing.

Maybe this is something to solve at the lower layer, using a sizeof()
macro?  Since the size is not yet available when the code is actually
generated.

So it looks like it's all there.

next: support.  Add "proc_storage" allocation in host.

Ok, basic idea works.  Delay is going the wrong way though (needs
decrement) and probably best to stick to "and" for buffer wrap-around.




[Reply][About]
[<<][meta][>>][..]