just finished first cv recordings with BLOCK, and I can’t help but wondering if there is a possibility to reconfigure the input range. the optimal would be to be able to use the whole 12 bit range on positive values to the 0-5V, envelopes are usually in the former range so that would definitely work.
I’m happy getting this far but I guess I just need to ask the questions before I can put this to rest
edited several times: some more tests later and several moments of ignorance (maybe still so) it looks like values over 127 will be interpreted as negative during the conversion to .wav, so the captured input will now simply be shifted down from 0-4096 to 0-127 range, maybe the proper way would have been be to convert to floating point, or shift up to fract32… anyway, this is the final edit of this post now.
How does the aleph act when connected to a computer via usb? Does it turn into a super powered audio interface? Can you direct things from audio outputs to the cv and 1/4 ins and outs? Can audio input go to the computer via USB or cv or audio in? I can imagine this being an es-8 strapped into a pedalboard…
sorry but no, its not a class-compliant USB audio interface. it is a USB serial device.
by and large it is up to the user to design and implement serial I/O applications.
i often use the aleph as a controller via the SERIAL bees op, reporting encoder, key and footswitch values. you could use the same method to report captured 10v values, but not at audio rates.
the other use case in the wild is for general remote control of bees functions from the host machine. (see skektek’s branch, which we’re in the process of upstreaming.) this includes producing 10v values or arbitrarily controlling DSP that does so.
sorry, i’m not sure what is going on for you with the input range… i checked and it is working OK for me; the driver produces values in [0, 0xfff] corresponding to [0v, 10v] input. these are just written to a S16 for passage through the event loop and into Bees.
i seem to vaguely remember there might have been a hardware issue around this, wrong reference V or something?
does bees ADC op work for you to capture the full [0, 10v]?
just tested in bees by sending cv-in/val0 to bignum/val and I get 3977 at 5.0V, my instrument clips at 5.1V so 4095 would be a just little bit over. from my point of view I prefer this to a 10V scale, after finding out that what I need to do is simply to study how to convert them to s32 and double formats
ok so the sequencer works, it is a bit heavy on the Aleph but very much fun. The only thing I noticed though is that STEP is not getting initialized properly when loading the scene. I did notice how White Whale and Kria are loading properly now, so I thought maybe you’d know how to fix that? Also, it seems MEM1D does not keep all of its values when a session is saved and then reloaded: I used about 112, and after the 16 first ones I get somehow a lot of zeroes. Not during the session, but when I save it and load it again. Any idea?
By the way, including FOCUS on the input page of GRIDRAW was a great idea I must say. You have been solving some of my issues without me ever asking, and I am very thankful for that! Oh and I definitely think having the option to save the output visibility would be neat: I ran into a case or two where it does wonder and makes a whole patch way easier to play with.
If I were to make a delay effect on aleph, in bees or otherwise, can you do really long delays? Like 30 seconds?
I’ve read a lot about mono synths, can you make polyphonic synths?
I’m looking at picking up an aleph, but don’t have one so that is why I’m asking some very basic questions. I want to see if some of my most basic ideas are in line with the possibilities of the aleph.
there is 64MB of SDRAM. the delay module i made (lines) has two buffers that are each 60s long and rather arbitrarily addressable. not sure about others.
there is no polysynth module implemented, but it can be done within CPU limitations (would have to be pretty minimal)
other important things to know:
aleph is not much like a “normal” computer, it is an MCU + DSP with no operating system
BEES is a program that runs on the MCU. it doesn’t implement audio DSP directly and runs on a 1ms tick. it is analogous to “Max” in Max/MSP or (loosely) to sclang in supercollider, though much more primitive than either. you don’t have to run this program, it is built on a version of libavr32 like the teletype firmware.
if you want to make your own audio DSP you have to implement it in C using fixed point math, this is not everyone’s idea of fun.
the whole experience is rather more “blank slate” than a lot of people would really want/need, compared to (say) a machine that runs linux.
Thanks for the detailed reply. You helped clarify some things and gave a small glimpse into the deep.
The ‘form factor’ of the aleph is the most intriguing element, to have all your ins and outs and the encoders and your processing in one small box is really amazing.
I’ve found myself further and further towards developer on the musician-developer spectrum in the last couple years, and I’ve been enjoying it more and more. While the C code is beyond my level as of now, I’ve progressed quite a bit with my knowledge of SuperCollider, which has been a big step in comparison to my fairly recent times using ableton and then max. I believe the aleph could, in time, offer a platform for learning low level coding.
Anyways thanks, and I’ll get out of the way until I’m a real “aleph user”!
ENC operator bangs it’s output when you change it’s min/max/val inputs.
I’m gonna go ahead & call this a bug because it breaks a canonical use-case for the preset system.
I’d expect encoder outputs to stay silent when you recall a preset for their inputs. My proposed change means you can assign a ‘bank’ of DSP parameters to the 4 encoders by recalling a preset. Then the DSP param will only get updated when you actually twist the encoder.
Maybe there’s some reason ENC operator was designed this way? If there is, I don’t see it!
there was definitely a reason but it surely can’t have been a good enough reason since i can’t remember it. you’re absolutely right that it’s a limitation more often than not.
maybe a compromise would be, “if the old value was outside of the new range, then constrain it and bang the new value.”
yea can see the logic there… Needs thinking about more as I play around.
Building a kind of scene where encoder param banks are selected from a grid. I keep getting stuck at the part where you use a ‘special’ preset to draw a glyph onto the grid, a visual aid to the function of these different ‘encoder banks’.
Also I think there might still be a remaining bug in preset system when you insert/delete operators into the netlist ‘under’ nodes included in presets, so that’s not helping…
There is a confirmed bug there indeed: I just rebuilt an old scene for compatibility purposes, and inserting or deleting an operator after some elements included in already existing presets makes the whole OUTPUT page wrong from that point on and downwards, everything getting moved one line up or down. Weird, I was pretty sure everything was working there!
I was just browsing thru the dev dsp library, is there an aleph version of the lowpass 2 pole filter somewhere, or a reference describing it’s algorithm?
looking briefly, seems like my implementation of the highpass in dsp/filter_2p is direct form I biquad, with some kind of funky refactoring to save a multiply when in highpass configuration (b2 == b0, b1 == -2*b0, using the a/b notation from biquad.c. (NB: the posts below from earlevel use the opposite convention: a for numerators/zeroes/feedforward, b for denomiators/poles/feedback; there is no historical agreement on this but the convention in biquad.c has been dominant in recent years.)
and it looks like the implementation in dsp/biquad is also DF1, however the update function is generic, and conversely only the lowpass form of coefficient calculation is provided.
this could all be cleaned up and made more consistent. e.g. by just adding the other coefficient formulas to biquad and ditching filter_2p. the nice thnig about the generic form is it can change modes on the fly. but could also have a separate update func for each mode to save a multiply or at least replace a mult with a shift.
another thing is that biquad.c uses 8.24 coefficients, which is smart and saves some scaling gymnastics. i’d be curious to look at disassembly for both these implementations.
