i’ve had an aleph since pretty early on in the picture which i use very often but i never really got into the development side…I’ve always imagined a multitrack looper/buffer scene
eg. buttons 0-3 record into each of the four buffers, knobs 0-3 control loop point or pitch, grid features would be nice too i think…
Is it possible to make a mini party van type thing like this, or is that beyond it’s capabilites?
it’s possible to make a 2 track looper,
but limited to 2 because there’s only 2 buffers.
did you see the ‘better living through looping’ video i made? that might help you start.
I find the main problem is it’s hard to make a time accurate looper because the TIMER operator reports miliseconds but then sends it to the LINES module in the bees integer format which is then converted ‘back’ to seconds
you can use integer maths using DIV/MUL but it’s not accurate. @zebra mentioned a while ago that he might adapt LINES so it would accept a direct time value. maybe @ngwese knows how to do it?
glad you tagged those guys
@bkinsman i think there was a previous version of PRGM that had 4 buffers
never got it working on mine tho
now it has 8 channels but, to my knowledge, abandoned live looping in favour of sd-loaded samples
looping with buffers will be back in coming updates.
1 Like
excellent news! @Test2 what does loop mode do now? i pretty much use the delay, tape mode, and envelopes to add different feeling to the mix
i need to check it out again myself
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)
1 Like
@dspk just small correction, actually bees takes 16b signed parameter value from operator network, converts to seconds in 16.16 (that’s 16b integer, 16b fractional), and sends those 32b to lines module. then lines converts to samples.
ha, thanks!!
i never really got my head around the number formats! (still don’t understand what ‘signed’ means with parameters even after extensive googling!)
always just resorted to calling the ones without decimal points just integers! 
getting around the slightly off maths ( where 63.99822 in Lines = 32767 in Bees ) is still the timing thing i would love to solve.
loop is a sequenced mode with pitch per step 
1 Like
can someone just give rodrigo and aleph so he can make a a version of the party van for it please?
3 Likes
anyone interested may wish to resurrect the ‘lppr’ standalone app from an older state of git. (used in first aleph demo videos)
I think I found this but not sure of how to load it up… do I need to make a fix and add a .hex extension to it ? Would really like to try it out