#21

found a workaround! storing a temporary edit value in a 64 bit variable keeps it from flipping over! :soccer:

1 Like
#22

opening up for a discussion on a couple of things I hope to add to Aleph apps/modules, but got stuck along the way on, hoping to share some ideas around these topics!

clip/overflow detection
have looked thru the bfin math library for a multiply function that could return a value on overflow, unfortunately it does not look like there is any, have not understood if the source code is available for a mod, another idea would be to use 64 bit variables and no overflow protection, that would probably be possible but also it may slow things down, that’s where I’m at, next up…

oversampling
would like to test interpolation with 8x oversampling but I haven’t got around on how to figure this one out at all…

click-removal/cross-zero detection
I have tried to different ways, one using a slew filter and the other simply only allowing mute on/off when the output value is below 0xf, both work but I would like to try and add a true zero phase detection to make it sound even better, one question where ‘zero’ actually is located in an s32 value, 0 or 0x3fffffff ?

feedback damping
maybe a slew filter would work, looking for a way to slow this without adding to many calculations, mainly to remove hi-f digital hiss, but also to prevent lo-f overflow that eventually leads to audio drop outs.

semi-logarithmic vca response
looking for an algorithm to use on the avr32 that does not use lookup-tables, have not got started on this yet.

1 Like
#23

you will want to use inline assembly. (the math intrinsics are just that anyways.) many of the math instructions set a status bit on overflow/saturate. unfortunately 32x32 to a dreg is not one of them. couple options off the top of my head:

  • multiply to one of the 40-bit accumulators, sets status bit if exceeds 32b boundary.
  • before performing the 32x32, perform a 16x16 with the MSBs and check the status bit.
  • do the clipping check some place where you’re mixing signals, use a saturated ADD.

see the Blackfin Programming Reference for details (p. 600, 641 and elsewhere)

.[quote=“Test2, post:22, topic:177”]
feedback damping
maybe a slew filter would work, looking for a way to slow this
[/quote]

hm, i’m not totally sure what application you’re talking about. like, feedback in a delay line? i made a 2-pole highpass that might be helpful, its in the dsp folder and i used it on white noise for dsyn. the lowpass form is stubbed in bt i didn’t bother to fill out coeffecients for it since we weren’t using it anywhere.

.[quote=“Test2, post:22, topic:177”]
one question where ‘zero’ actually is located in an s32 value, 0 or 0x3fffffff ?
[/quote]

zero = 0

when oversampling for plugins (distortion and SVF) i have gone the common route of zero-padding followed by FIR interpolator. this works well for most things, and i recommend it over zero-order hold. i have seen some clever tricks to skip the zero-padding step by flipping between sets of FIR taps. (sorry for being vague but it’s been a long time and i can’t find a good reference online right now.) bear in mind that this adds latency, maybe lots of latency if you want that high an upsampling ratio (use polyphase FIR.)

bear in mind too that it is theoretically possible to just run the aleph’s audio codec at a higher sampling rate in the first place (up to 192k.) this will involve sending some control registers to the AD1939 over SPI at startup (see the ad1939 datasheet and put the code after codec reset in init.c) this is what i would try really. better with block processing (it really does work, i promise, i just have not done anything with it!)

cool, but i’m curious why? LUTs are cheap and simple. linear interpolation on a 512-point LUT is surely accurate enough. (smaller probably fine too.) and you can build in a taper to zero at the bottom, which you probably want.

the problem with approximations, say taylor series, is that they are gonna require a lot of calculations anyways, and in fixed-point it will be problematic. for example

ln(x) ~= (x-1) - (((x-1)^2) /2) + (((x-1)^3) /3) - ...

you will want, i dunno, 4 or 5 of these terms at least, and each mul/div will lose precision because on avr32 you will essentially need to limit the operands to 16b and shift the result. the cumulative error could be pretty bad.
`

1 Like
#24

delay line and feedback between (software) channels, a 2 pole would work but I have had trouble with the filter algorithm as it distorts very easily, this filter could be fixed as well which I hope can open up a possibility to handle it with less calculations.

I want to try using mdma without block processing first, but I’m all for it, however there is a knowledge “block” too that needs to be tendered!

to save memory, basically, and it doesnt seem like the avr is working very hard atm, I have also ported some (much more simple though) LFO type calculations from the bfin to the avr32 and a nice bonus is that I can then visualize the LFO on screen using the same algorithm in real time.

thanks.

#25

an idea that came up is to combine clip and phase detection problem, eg two very similar functions, one for zero-cross detection and another for cross 0x40000000 detection, or maybe both detections in the same function if it does not suffer too many cpu cycles, will dig in when time permits!

#26

i think we’ve got a handful of new users
[along with the regulars]

what is everyone been up to?

#27

I’m working on an prgm update, not sure when it will be ready, small steps.

stumbled on a weird error when adding functionality on the avr32-side to recall patterns and scenes. hoping to increase the number of patterns (for a composition mode). thought I had it solved but… will keep testing.

one of the weirdest bugs ever, if pattern files names have different lengths, it is only possible to load a few, however if names have the same length it just works. can this be a real bug or am I going crazy?

1 Like
#28

ha - well as soon as you can reproduce consistently it’s a ‘real bug’! There’s a quote generally attributed to Einstein that defines madness something like ‘doing the same thing again and again expecting different results’.

So as long as you’re doing something different and getting different results every time, you’re probably not going mad! I try to take a scientific/deductive approach to debugging, rather than actually trying to read whatever brain-damaged piece of spaghetti code is malfunctioning in whatever inexplicable way.

e.g when the bug makes no sense, instead of asking the question ‘why is this code doing X?’ (where X is the bug in question) try asking ‘what happens if I prod the same piece of code with Y?’ (where Y is something similar to the apparent cause of X)

EDIT:
apologies if this advice/approach seems obvious and patronising - just an observation of mine that even some pretty brilliant programmers struggle to debug when they approach the problem from their mental model of the design, rather than the reality of what the code is really doing…

#29

I usually pursue debugging from a code perspective, going mad with this one because I see a likely possibility that I need to work my way all down to the drivers for this one, something I’m not exactly thrilled about… but it will at least be rewarding if I get around to solve it.

#30

do you also have a debugger dongle for the avr32? If so what are you using? I was trying to figure out at one point whether the cheap and easily available avrdragon would work with aleph, but never followed it through…

Would be much more able/willing to sort out remaining things irking me about BEES with:
A) Faster flashing avr32
B) gdb catching segfaults and zooming emacs buffers up & down the stack trace when things explode

#31

nope, I use the usb output and a logic analyser, recently figured out how to send debug messages from the bfin too. I’m a happy camper. :camping:

#32

care to share the magic spells for this? Often thought that could come in handy…

#33

oh. I just mean parameter exchange, as we discussed on github https://github.com/monome/aleph/issues/244 no magic spells here!

#34

hey guys,

i am finally ready to work on the aleph a little bit.

@Test2 i can probably help with the string issue. i suspect you are using the file-handling code from bees. this stuff is really nasty and indeed uses hardcoded string buffer lengths. that’s why it’s not a part of the general avr32 lib.

point me at your code and maybe i can suggest something.

4 Likes
#35

thanks that would be great, one caveat is that I have a hard time uploading this to github atm because there are much things in there for a project that I want to release first before releasing any code for it, but I could post an issue on github once the project is ready.

still, here is shortly what I stumbled upon. I started out with the bees code to search for a given filename in a listed directory, using these objects:

FL_DIR dirstat;
struct fs_dir_ent dirent;
void *fp;

first I suspected something alloc/free-related but (to my surprise), using same number of characters in each file name (in this specific folder) did make it possible to load more files. I did have a look at the fs_dir_ent struct but could not find anything in there that seem to control file name length. when it bugs it looks like files still load, but data is garbage.

#36

hm… maybe you could post it in a secret gist for me, or something?

or is there something you could point to here:

like with a new issue on your fork?

'fraid i can’t tell much without knowing how/what you’re trying to do.

edit: its not impossible that there’s some bug in the fat library we used. @tehn had better luck integrating the atmel fat drivers to teletype, than i did in initial aleph development. so maybe it’s worth considering swapping them now.

1 Like
#37

I can do some tests with the drivers for teletype as a first step, happy to report back on that in a while!

#38

Fun DSP module idea:

3 Likes
#39

hey

I’ll talk out loud in case the discussion would benefit with additional heads
feel free to dm if you prefer

  • still trying to wrap my head around grains as a sampler any tips that have worked for you?

  • what ever happened to picolisp on aleph? if I wanted to take baby steps using it or building something for it what do you recommend?

#40

hey - well I was trying to use grains as a sampler for this weeks disquiet junto.

The simple answer is it doesn’t currently work well all that well as a performance sampler! You can do something sampler-ish by setting (in this order):

  • fadelength to 0
  • echoEdgeBehaviour to 1 (repeat)
  • echoSpeed to 1
  • echoMin to 0
  • echoMax to 3000 (ish)
  • echoTime to 0
  • writeEnable to 1

Then record some sound and quickly flick writeEnable to 0. the last second of recorded audio should now play on a loop - you can trim the loop using echoMin/echoMax, speed it up/down using echoSpeed, change the pitch with the scrub params…

If you flick echoEdgeBehaviour to 0, it will go to one-shot mode. And repeatedly banging echoEdgeBehaviour with 0 should retrigger. Banging echotime does a crazy sounding scrub, then also retriggers. Pretty glitchy if you’re into that, but can’t control timing much…

Dedicated sampler module would also be awesome & all the DSP building blocks are in place there. The main difference from grains would be a ‘record button’ - where you could hold down a button to record however much audio. Maybe that feature could be built into grains - not sure.

But a simpler DSP that just tries to be a performance sampler would be cool and probably the single most interesting thing I could add to my rig (I have a ‘working’ rig now - yay!)

EDIT:
As for the picolisp question - I wouldn’t reccomend looking at that for now unless you want to hack on a programming language (I did). Pretty sure it was suffering very rare random, undebuggable crashes where I left it. Can’t see how to hunt down the problem without a proper debugger cable.

I’ve been developing a framework for embedded linux using common lisp (not picolisp) to act as a central nervous system & sequencer for my headless rig, where aleph is the dedicated sound-mincer. This sidesteps the annoying problem of no usb hub support on avr32 and provides interactive development for my ‘apps’ (currently I have only a prototype white-whale-ish thing called sguenz). One step in the near future will be to add a bees module which provides fixed inputs & outputs from the embedded linux device.

1 Like