#22

[quote=“dspk, post:21, topic:415”]
that amazing 128 and MPD video
[/quote]coincidentally, i just rewatched it a few days ago and it’s still inspiring

incredible performance of too many

#23

Thanks for the encouragement! I’m working toward a new set of technology that will allow me a similar sense of performance to match my current musical aesthetic…

Hence the interpolated buffer looper thing. In many ways it’s just a twisted version of lines but also includes many other goodies. For those interested in the DSP dev side of things, there’s a few new library classes for lowpass gate filters (not a buchla recreation, but a subtle HF rolloff attached to volume) and a ‘vactrol’ slew. I’ve been using the latter instead of ezra’s slew parameter approach, meaning there’s way less params but just enough smoothing to maintain transients but smooth sudden digital changes.

@dspk the interpolated read/write is working, but I’ve been having big aliasing issues when resampling feedback after changing the delay time. As with everything there’s many solutions, but it’s not as modular as I was hoping (my current solution involves processing delay feedback inside the class, restricting the modulations one could put in the loop).

#24

@Galapagoose where can we find these new library classes? would love to try these slew/filters on feedback loops.

#25

Sorry I haven’t pushed that stuff yet. I’ll throw up those classes tonight once I get home. I built the LPG class exactly for that purpose. It’s really nice in a feedback delay being used as a looper because you can just roll off a tiny bit of highs and it prints the ‘softened’ version to the buffer. Really nice to make a loop less present.

The vactrol class is only setup for control values (has time constants around 10-100ms) but I’ve been thinking about parameterizing it so the developer can use it as a full function generator / modifiable vactrol. The code is really basic - essentially a standard integrator (like the filter_1p_lp) but with different coefficients depending on whether it’s rising or falling. The really nice part (of vactrols and the code) is that the rate is also effected by the current state, ie. response is fastest when nearest maximum output, getting less responsive as the output nears minimum.

Sorry to tease!

#26

ha, ok, you lost me on that last sentence!!! is this in the Lines module you’re doing all this (fingers crossed ) or is it a self contained app?

#27

It’s a new module called rings but all the lpg / vactrol / interp’d-delay could be implemented in a lines like module. Definitely not a standalone app, so it’s designed to be used with bees, though I have thought about making a dedicated controller app to simplify the whole process.

The main difference between lines & rings is that rings focusses on BPM length delay time, while lines just does as long as fits in SDRAM. This is important to set properly in rings because the interpolation code can only increase the speed to 2x without further, much more DSP intensive, interpolation.

1 Like
#28

ah great news!.. i’m still really enjoying and pushing what bees can do, plus i still like switching between scenes rather than having to re-flash the whole thing.

i’m still really in the dark as to why the interpolation thing is such a pain on the Aleph? doesn’t it use the same chip as a teenage engineering OP-1? on those you can wind the audio at any speed?

#29

Exited for this :+1:

#30

@Galapagoose I just got to uploading the sample interpolation for loops that is part of the prgm app, it’s lofi but a first attempt… if you have the possibility I’d be up for sharing ideas, see link, and env_tcd_loop()
github prgm DSP core

1 Like
#31

Thanks for that - we’re using a pretty similar implementation for the interpolated read/write. Main difference is I was trying to externalize the feedback path rather than process it internally with a simple multiplier. Rewrote it last night to function internally but using the ‘LPG’ class I mention above – mostly challenging because it requires running an SRAM buffer so your interpolated values don’t get read/written more than once per loop.

Sounds more complicated than necessary so looking forward to getting it to a releasable state to talk about it with code.

Hopefully we can work on some faster sample I/O at some point soon too. Really interested to dig into your methods there once I have the actual DSP loop working as I want. For now dubbing loops to cassette is satisfying enough!

#32

sounds great! I finally got some time over, added a bunch of 4 point/3rd order interpolations, not sure if I got to implement them correctly, but it’s a first step. Also some confusion on how to handle fract32 constants larger than 1… anyway, have uploaded the code. +1 on faster sample I/O, that would be awesome!

#33

short answer: yes. someday

i have had to do other work for a while to make $. it’s good to see a wider range of developers starting to pitch in. hopefully this trend will keep growing as aleph units shuffle hands.

doing interpolated buffer reads is actually not hard. i promise i’ll make a module for it as soon as i can. it will not be aleph-lines though, it will be a different module (i’m thinking aleph-tape.) the reason is that we’ll have to lose some routing and SVF output mixing to accommodate. i’m thinking a simple static waveshaper and LPF, post-read.

i don’t know that “1.0” is ever gonna make sense for this codebase unless it is largely rewritten with a sizable development budget. and that would only happen with some kind of unexpected underwriting.

2 Likes
#34

Can’t wait for these new modules to slowly roll out. I hardly use the filters in lines so that’s no big loss over here :smile:

1 Like
#35

agreed on both counts @analogue01