So if you move the write head, do you get a pop when the read head
passes over the transition point (e.g. where the write head moved from?
yes, if you move the write head, or stop it, or change the pre/write level, and then read over the point where you moved/stopped/changed level, you’ll get a discontinuity of course. but as you say, that’s wasy to avoid in a traditional “delay” type application, where the buffer is being addressed in a circular way and write head is generally always moving.
still, idea for lines was to allow other, arbitrary structures. disabling the write head can be fun. clearly in a sampling/1-shot or looping playback kind of situation, you want to be able to arbitrarily reset the recording position.
lines does lack a couple of features to really make these use cases convenient and glitch-free (namely fade-in/out when starting/stopping the read head, crossfading around a loop point, and preroll/postroll for accurate timing.) but there are also numerical issues with timing accuracy when using lines with BEES (control side application)… basically a tradeoff between buffer length and accuracy… and that’s a whole other can of worms.
sin/cos crossfade… linear seemed fine.
yeah, this gets more noticeable when you are constantly crossfading or “granulating” - as when using the delay system as a pitch-shifter. then you kind of really want the equal-power envelope.
you mean, interpolation when playing the buffer at a different speed than it was recorded?
yeah, that’s what i mean. of course if you are speeding up by a integer factor you don’t need interpolation, but if you are speeding up by an arbitrary factor (or slowing down at all) then you do need it. and yeah, cubic interpolation is “better” and causes less distortion, although i’m actually with you in thinking that there’s rarely a noticeable improvement from linear interpolation for live processing applications of typical material.
developing complex code on the Teensy was quite challenging, when my only debugging tools were printf
yeah, i love the teensy but that’s a big downside. i kind of don’t understand why they didn’t expose SWD/JTAG pins on the board. on aleph we actually do have JTAG exposed for both processors, so it is possible to debug the DSP. i used a gnice+ when developing the low-level framework, would have been very challenging without it. now those things are hard to come by, and the blackfin jtag header isn’t populated be default, and it’s inside the case, so it’s more convenient to forgo that path when possible. we’re gradually building out more tools to improve developer workflow (or rather, @rick_monster has been).
generally though, it’s easiest to do as much work on the PC first. rick has also made fract_math primitives and an OSC test harness for emulating DSP. i do the same kinda thing with pd externals. ususally it’s
- make the algo work in floating point
- convert to fixed point and deal with any resulting issues
- migrate to the blackfin (or teensy or whatever)
