aleph.

  • I realize that the aleph is not an exact substitute for any of the pedals out there but my pedal lust is mostly not due to the exact algorithm or functionality that they implement but rather the form factor - a simple hardware box that takes audio in, does something interesting to it with a simple interface, and spits it out. I probably will still invest in some pedals but it seems not smart to that before knowing what the aleph will do to my creative process. (BTW, I've been mostly looking at delay and looper pedals, like Red Panda's particle and Strymon's Timeline.)

    @gli, oh dear. I hope you are still eating properly. ;-)

  • don't overthink it. what you want are some cheap noisy pedals for aleph. you can get some amazing cheap pedals that do great things. a ds1 distortion is about 50 bucks. a behringer analog delay (vd400) is about 40. can't recomend the vd400 enough.

    a small stone phaser is about the same.

    there are any number of amazing fuzz pedal circuits that can be built with a handful of components.

    no need to look at 500 dollar delays IMO.

  • aleph makes me count like karaokaze ;)

  • @kotdotnot heh yeah

    i've held onto some things i might have sold + looked into certain gear i probably wouldve ignored before aleph came around



  • thinking about pedals, i really want to exploit the CV in/outs of the aleph. I'm interested in how to route an expression pedal in, but my knowledge of CV is pretty basic (non-existent). I have an old Roland expression pedal with a 1/4" TRS jack, am I right in assuming if i wire up a cable to split the TRS into two 3.5mm jacks I can plug that into to the CV as a potentiometer.. or will I have to be careful about voltage levels? don't want to blow up the Aleph on day two?
    any pointers to getting started with making CV based controller add-ons greatly appreciated!

  • Since we're on the topic of pedals and cv, will the aleph be capable of doing some sort of pitch to cv conversion? Kind of like the esp on the ms20 to control a vco frequency with a guitar, and an envelope follower for gate?

  • @duncan
    i believe this will be possible as most expression pedals are just potentiometers. i imagine someone will quickly create a wiring diagram and bees scene that shows how to do this shortly after shipping begins.

    @dr.tung
    theoretically possible, but computationally expensive. ezra has spoken of doing more general spectral analysis, which i imagine could be used for pitch tracking. envelope tracking is easier. i doubt this will be ready at ship date, but it is possible — just need someone with the time & knowledge to code it.

  • pitch->cv , certainly. there are 2 plans:

    1) relatively coarse tracking with bin amplitude in FFT as part of bigger spectral analysis suite.
    2) finer tracking with autocorrelation.

    both are perfectly feasible and straightforward, algorithmically and computationally. i'm hoping others will pitch in on implementation though, there's a lot on our plates.

    regarding documentation, code publishing: we will open up the repo very soon, but not much before we are actually ready to ship the things. as usual, there are hardware supply delays, nothing serious. brian will of course keep you all updated. in the meantime it seems best to get more work in on extending and polishing the architecture before sharing it with everyone. i sincerely believe this will minimize frustration and maximize fun.

    prioritization of features: it is a good question. some kind of wiki or something is being set up, and there will be formal issue requests. but (and i know you're tired of "wait and see" answers) - wait and see what the thing is capable of! also, keep learning c if you've just started on that road!

    i wouldn't buy any digital delay pedals. haha! as far as modelling analog nonlinearities, it's not really my favorite area of research, because i'm rarely happy with even the best commercial results. and in analog, it is so easy. that said, certainly we're putting some saturation algos in the dsp library, (they help make digital filters sing), and i do know how to make a quite nice chorus/phaser if that's your thing...

  • @zebra
    "also, keep learning c if you've just started on that road!"
    Maybe it's been said in this thread already but are there any recommendations on where to start with this, preferably something with a focus on what will be most useful for the aleph? This is coming from a complete beginner to coding.

  • learning programming is not an insubstantial undertaking. i'd start with learning javascript because it's straightforward and simplified while having similar syntax to c.

    keep in mind that that bees does a lot without programming. in fact, some will call using bees "programming" since it will require some practice, a reference guide, and you'll be able to "build" quite complex systems using it.

  • The bees route seems much more up my alley. I'll wait to learn more about what it does and its potential since I'm having a hard time conceptualizing it. Thanks!

  • correct book link!

  • I'll give that one a try.

    I learned w/ C Primer Plus back in the day. Lots of pages, yes, but much of that was white space. I remember being able to flip through the book and find exactly the code sample I needed. But my needs weren't so advanced at the time, and I didn't care all that much about efficiency or best practices.

  • if you want to try C without shelling out for a book

    WAAAPOWWW

    http://c.learncodethehardway.org/book/

  • really looking forward to using bees for programming and routing

    eventually i'll look into C as well so...@jhindsight thanks for the link!

  • +1 to @jhindsight 's suggestion . read k&r by all means, but be aware that the 2nd edition is from 1988, there are many new features and differences for c89 and c99, some subtle, some not. the "gnu c reference manual" covers everything and is more readable than the actual c standard.

    i always think the best way to learn an environment is by having a project. if you're a max user and you have an idea for an aleph control app, you could do worse than trying to implement its essential logic as an external using the max SDK, and go from there. there's no shortage of resources to turn to when you run into difficulties.

  • not to turn this thread into yet another c-standards discussion... but...

    fact-checking myself i see that k&r 2nd ed. is actually substantially identical to c89 / c90 (sometimes incorrectly called "ANSI C") - i guess the standards committee probably used it. if you write code conforming to these rules it will pretty much always be correct and work as expected.

    however, you may run into confusion when you start to look at modern C code that uses newer features, including the aleph codebase.

    off the top of my head, some of the more commonly-encountered such features are:
    "inline"
    new semantics for "static"
    designated initializers [e.g.: struct { int a; int b; } z = { .a = 10 }; ]
    flexible array members [ e.g.: typedef struct { int arr[] } varStruct; ]
    mixed code/declarations (i'd avoid these anyways, style-wise)
    for-loop initializers [e.g.: for(int i=0; i<10; ++i) { ;; } ]<br />

    so anyways, i recommend getting k&r, it is a great book, but get a more modern reference as well.

    my 2c is that o'reilly's "c in a nutshell" is actually pretty good - it covers c99 syntax and the standard library and has useful chapters on gnu make, gdb, and other related tools.

  • @zebra Have you had a chance to peruse Ben Klemens' "21st Century C"? If so, do you think it's worth picking up?

  • You gonna have a variable voltage setting for CV like on the Elektron A4? Also want about volts per octave vs hertz per volt?

  • @carp ah sorry i don't know that one. then again i haven't really spent all that much time reading c books, heh!

    @dimi3 aleph is a very open system, any mapping you want, whether it is midi in -> aleph cv out or aleph cv in -> synthesis, within tolerance of numerical representation (12b in, 16b out) and the range of the analog circuitry (0-10v.) given that, v in->hz (linear) is subject to the usual inherent limitations... i.e. it will seem chunkier at low frequencies if the target frequency range is big.

    sorry, i don't specifically know how the a4 works...

  • working hard on a system of parameter mapping operators within BEES that provide a good balance of simplicity / sophistication / tunability. this includes arbitrary scaling of midi note -> cv out, and a good selection of mappings from linear input to hz, including just intonation, micro-temperament, and straight linear. it's not really possible to have BEES accomodate every imaginable thing and still be usable! but it will do a lot of stuff. for custom code of course the thing will do whatever.

  • get to the charity shop kids! just picked this up for 75p ok it's from 1989 but i'll take the basics for less than a quid.

    2176 x 3264 - 1M
  • would it be possible to use aleph as some sort of a cv recorder/processor/mixer? with grid interface I think it would be great for people with small modulars.

  • ^^ I've been thinking about something along these lines. I'm going to try to outline my CV Hub idea in writing as well as share current maxforlive patches. The basic idea is

    Aleph CV Outs:

    1&2 provide 2 channels of gate pulses w/ 16 various (synced or free*) divisions controllable by rows 1+2 on a monome grid.
    3&4 provide 2 channels of LFO waveforms w/ various (synced or free*) waveforms selectable by rows 3+4 on the monome grid.

    *i suppose sync could be achieved via MIDI clock or CV input gate?

    Aleph CV Inputs:
    Mode: Accept incoming CV to control bees parameters
    Mode: Record incoming CV and route playback to a CV output
    Mode: Quantize incoming CV and route back to a a CV output or params

    ...anyway that's a rough sketch

  • does anyone have any insight into the differences between Objective-C and the type of C programming that will be required for Aleph? Of course Obj-C in its iOS incarnation has many Apple and interface-specific items, but other than that...? The reason I ask is I am well-versed in Obj-C but have very little experience with other C variants. Definitely will dive in myself once the Aleph arrives but am curious if others have waded in similar waters.

  • @zebra "working hard on a system of parameter mapping operators within BEES that provide a good balance of simplicity / sophistication / tunability"

    That is some heavy lifting you have planned for yourself!

    One thought is if you get it into the wild quicker, users may be able to give better insight into which parts are need more upfront. Just a thought....

  • all in due time

    this is gonna be so much fun

  • Can one expect to easily port C code generated by Max into aleph?

  • hi bafonso,

    are you speaking of C++ exported by Gen~? or are you referencing max objects developed in C?

  • Is there a in depth description of bees somewhere? or maybe plans philosophy...

  • @emergencyofstate like the idea of what you are saying. I like not having a computer in the loop. I would love to see the CVs either controlled by MIDI or a connected controller and extenuated by the Aleph.

    I have a few kits coming together which are tools in this realm but something like the Aleph reigns king.

  • @away message - You are right. Ideally I'd like to use c++ exported by Gen~ as it would allow me to prototype stuff in max/gen :-)

    I think the overall question is about how difficult it will be to adapt code from existing libraries such as CSound as well as many others. Basically trying to see how much of wheel re-inventing is needed for already existing stuff or if one should think about it as mostly to develop new code.

    cheers

  • @dimi3
    well yes it is rather heavy lifting! good news though is that we have been at it for a while and stuff actually works quite well. definitely looking forward to getting more input and contributions as you say, but i'll say again (and i doubt i will be convinced otherwise) that it is actually not so useful to have the codebase without the hardware. feedback will be more useful once people can run the application! anyways i expect some people will want to use/extend bees, and some will want to roll their own control patching / DSP management system. which is fine and great. anyways lots of documentation is forthcoming.

    @bafonso
    i just looked at some output of gen~ code export, although i can't really play around since i don't use max or even a compatible OS. bad news: exported code will not run efficiently on blackfin (no FPU/GPU) and would take some work to be useful, though it still might save some time compared to starting from scratch. good news: the most platform-specific stuff (generated AU boilerplate) is irrelevant and its analogous functions are well covered by the aleph blackfin library.

    adapting generic c/c++ code is straightforward, with some caveats for fixed-point math. assuming you are rather comfortable both with programming and with DSP concepts and limitations. in the end this is just a platform for running c code on a sample I/O loop, not dissimilar from any other such platform.

    Faust probably provides a more promising avenue for high level DSP / code generation, since it is open source and anyone could extend it with a blackfin architecture file.

    hope that sort-of answers your question!

    ok i'm gonna disappear for a while, lots to do... -ez

  • @zebra So will bees compile to the hardware directly? there will be no sim in bees?

    Seems without hardware yeah I agree, if there is no sim...

  • in the early stages of development it was necessarily hardware-agnostic, but since then we have been adding lots and lots of functionality, and not taking the time to maintain a simulation layer for our avr32 library (on top of which bees runs, and other apps too).

    i would certainly like to get back to reconstructing this (or maybe someone else wants to); it is not difficult from a technical standpoint but it does raise some design considerations - how to reasonably emulate or provide hooks for the hires encoder inputs and other hardware UI components.

    but shipping working aleph units is obviously top priority.

  • the next video will likely show bees in some capacity...which will be great

    but
    any chance we'll also see aleph + arc interaction on one of these clips?

  • Does anyone know where along the signal path the DSP code is affecting the signal?

    Let's say I want something through input 1 to be clean, then out through output 1, into input 2, and then have the code only run between input 2 and output 2.

  • all i/o is through the DSP.

    you can do what you describe with aleph-lines and 1-sample latency.