#14

i need to scrub this list. some of them are fantasy features, some are ill-defined.

#15

Are you using WAVES mostly, @KthulhTriokus? I find it feels a little less complete than LINES… mostly because I find using amplitude slew instead of an envelope function weird. I wish there was an AD or AHD op… or even just something like ~line…

#16

The buffer clearing code works for the most part in Lines, just need to uncomment the ‘memset’ line (not the for loop) in the init function, then be tested especially when recalled from different scenes.

I’m going to push that change up along with some file naming fixes which should solve (some of?) the load-hang issues. Unfortunately such changes require all the scenes to be edited to rename the DSP module. If you beat me to the punch by all means submit a pull request!

#17

I’m using WAVES a lot and yes I 'm also for ASR envelopes.

#18

I remember ezra said something about building an envelope out of presets, but I was never able to wrap my head around it.

#19

for AD have a look at the LFO tutorials that @Galapagoose made - http://monome.org/docs/aleph:bees:tutorial4 I think using the Triangle LFO as a starting pointa combination of ACC and IS to reverse the direction could do it. To trigger the triangle you’d need to create something that would start/stop the metro and reset the ACC value. Changing the value of the metro would change the speed of the ramp too. (with a delay operator you could prob also make it into an AHD by delaying the downward run of the ACC. )

2 Likes
#21

interpolated reading and a buffer clearing code?! these things would mean you would instantly become a god!!! … especially the interpolation… being able to bend the read/write speed would open up the Aleph to such an incredible set of new possibilities!!! I guess the ‘minor numerical challenge’ it was described as when the Aleph was released turned out to be not so minor!!!

( and also then I’d maybe forgive you for making that amazing 128 and MPD video ages ago that was the reason I travelled down this whole Monome/Aleph wormhole wink )

For the renaming thing do you mean we’d have to rebuild all scenes from scratch if Lines is updated? I only get hangs if I’m doing something crazy with rapid resizing of delay and loop length. haven’t been able to pinpoint/replicate the hanging moments yet though.

#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