two issues
- efficiency. 4 buffers is def. well within capabilities of hardware as evinced by prgrm.
again, big inefficiency in the single-sample loop of blacfkin core library. that is still the top priority task for me [ https://github.com/tehn/aleph/issues/69 ] but i have no extra development time right now. it is possible that i will get to this before anyone else does but promising a timeline would be lying.
as it is, one could probably do 4 bufs in lines just by dropping flters and arbitrary mixing ( replace with boolean patch points as in waves, straight patching, stereo bus, etc)
- timing and numerical precision. not hard to make lines accept millsecond argument but in bees, this limits addressable time range to 32s.
much discussion on how ways to circumvent this on monome forum threads and here [ https://github.com/tehn/aleph/issues/204 ].
i agree that it would be a good idea to make a lines version with different time addressing. shouldn’t be a difficult exercise for module development to, say, add secondary and/or tertiary time parameters. maximally, each time value could be 3 params: base milliseconds, ratio multiplier, and sample-accurate fine tuning.
outside of bees, could send 32b control changes directly computed from app heartbeat, bypassing param scaling system.
underlying delay-line classes have a setter taking sample argument, and one taking 16.16 seconds (which just converts to samples first.) accepting 32b millisecond argument, just use sample setter and multiply input by 48 or whatever. [ https://github.com/tehn/aleph/blob/dev/dsp/delayFadeN.c#L163 ]
before you ask, the avr32 lib by default works on a millisecond heartbeat so that is the control input resolution limit in bees. custom app can override this.
anyone interested may wish to resurrect the ‘lppr’ standalone app from an older state of git. (used in first aleph demo videos)