• @visinin: actually didn't use libmonome, it seemed like overkill in this fixed environment.

  • and it begins again! congrats b/k/e, i can't wait to play

  • ok sorry that was long. but i realized i missed a point. @ioflow, you mention "userspace," and i'm not sure exactly what you mean. on the aleph control side,
    there is a code layer that functions as a sort of kernel, and there is a much more abstract code layer where the applications are actually written, and there is an API between the two, but in the end all are compiled to a single executable for the control side. the DSP side is totally independent, so one controller application can be used, lightly modified or reconfigured, to operate a different sound application. the two apps shown in the video are pretty tightly-focused; some will be more flexible.

    as far as computer interaction, all communication is by simple serial streams over USB or through the sdcard filesystem. so this is entirely host OS-agnostic. in this respect, it is similar to using, say, arduino or any other embedded computer. we'll be thinking hard about specific protocols for host-aleph communication as use cases arise, and of course such protocols can be entirely ad-hoc if thats what you want.

  • I have to say wow pulling it all together this surely changes how I look at music amazing work

  • @ezra: thanks for the long post. that explained a lot more details and makes me even more excited. great work!

  • so excited for the possibilities this will bring.
    reeeeeaaaallly wonderful work B,K+E.
    all smiles here.

  • Haha, I woke up in the middle of the night, feeling hungry. Now I'm sitting in the kitchen at 5:30am and smiling like a little boy :D

    I'm stunned, apps are all coded in C? I can't believe it - great! That almost sounds like it would be possible to code in C++ as well (although I'm aware that this would probably not be the most efficient way).
    To me it sounds a bit like the midibox approach: Compiling the app and the "os" into a single binary. That would clearly allow to use any language extension you want. Cooooooool

    Now I need to find something to sell so I can afford this....

  • @zebra:

    thanks for the detailed responses! (and congrats on the culmination on all your efforts.)

    to clarify, by "userspace" i meant all the front-facing software, like management utilities, plugins, that sort of thing. however folks would interact with this on a computer, whether that means uploading, configuring, etc.

    i was under the impression that aleph is a performance/composition box that could replace at least parts of the daw/computer workflow, much the way my mpc is turning out to be. it seems a bit comparable to the OP-1 in terms of being able to do a bunch of stuff onboard, all at once. especially after watching the live looper/perc synthesis video...very inspiring! just today i was thinking about how my mpc works for samples, but can't do much in the way of adding FX to them, nor can it do any kind of synthesis. whereas the aleph, on the other hand...seems to have a lot more possibilities. filling in those gaps. even if i have to code 'em using the C building blocks provided. am greatly looking forward to reading the docs so i have a better idea of what can be done.

    everything about bees sounds fantastic -- and i would actually be willing to learn C if done from the aleph perspective, if it's friendly and approachable enough, to a non-programmer/non-patcher such as myself. that seems like a worthy goal. given how flexible this box is, it sounds like everything i've wished strymon and akai would have done for their pedals & mpcs; to open up the underlying bits so that all that hardware & processing power could be used however i want.

    one more question, since you mentioned synthesis:

    i have some old analog synths that only speak sysex. is there, or will there be, some capability for aleph to interact with them? if it can support class-compliant usb-to-midi controllers and interfaces, i'm hoping there's a way to not just be controlled by an mpd32, but send sysex/CC data to connected polysynths, for a good ol' fashioned hardware creative session. i may not have modular synths to patch with it, but aleph seems like it could still become the new center of my studio.

  • ah jeez, i can't keep up... ! ;)

    below is my response to your earlier, later question. as for sysex, it is just MIDI with special bytes. you would want a cheap usb-midi converter, one of those single-cable things. a sysex management utility app would be helpful for lots of folks, we should put that on our list of app ideas. in fact we should probably make a thread for those.

    as for front-facing host-side patch design apps, i personally am going to leave the design of those to the members of our community who are supremely gifted in such things. again the actual communication with the aleph is with simple serial data. that data could come from whatever. javascript. i dunno. it will be fun.

    @ioflow (6:25pm)

    1) yes. so far we've implemented USB host drivers for: monomes of course, class-compliant usb-midi, standard HID subclasses (mouse and keyboard), and generic hid (e.g. gamepads.) i'll tackle hub support next (after i take about 5 naps). then we can think about more unusual specimens like soundplane (tricky, but doable) and shinth (easy.)

    2) the 8 small jacks on the front panel are 10-volt control voltage compatible with modular synths including euro, buchla, serge, etc. there are 4 inputs and 4 outputs. for sure you could loop back outs to ins. for example, this would be an easy way to hook up a passive controller like an expression pedal (or any other form of potentiometer.) there are 4 audio outputs and 4 inputs; we deliberately included this many for easy insertion of, say, a fuzz pedal into, say, a delay or filter feedback path.

    as far as glitch / indeterminism, well... hacks are hacks, i will always say go for it, but don't be surprised if you smoke something by putting +10v where it doesn't belong.*

    fortunately the DSP is right there for your (safe) hacking pleasure, one billion horrible noises are only a typo away!

    or if you like your chaos a little more controlled, chaotic algorithms are easy as pie. here's one of my faves, cubic recursive map:

    x[n] = a * (x[n-1]^3) + ((1-a) * x[n-1])
    a in (3, 4) gives the gnarliest orbits.

    and with that... goodnight!


    * i am kidding, hacking up the aleph's CV circuitry is highly inadvisable.

  • How about host support for Manta?

  • ----------begin_max5_patcher----------

  • Heyo,

    Will there be an option for banana jacks on the CV section?

    Would it be possible to mod it for banana jacks? How much space is inside the box? Are the CV jacks freestanding or are they soldered direct to the board?


  • great stuff! ordered...

  • I'm gonna install Linux on mine. :)

  • laborcamp brings up an interesting question.

    Manta is a class compliant HID interface, so it shouldn't be too different from the game controllers. I imagine the drivers for one device can be adapted fairly easily to support the other. Assuming Ezra and the monome team don't have a Manta onhand, is that a transformation the user could perform themselves?

    Or in broader terms, if we're feeling ambitious, can we compile and upload our own drivers for unsupported hardware?

    (my guess is "of course; this is an open platform. just don't expect that to be as easy or well documented as creating an app")

  • @zebra thx for explaining. think i'm starting to get the picture though can't wait to see some more vids of the kind of things that are possible to really get a feel for it all!

  • manta easy. drivers yes.

  • wow. what an exciting and ambitious piece of work! congratulations. wish I had the time/money!

  • Wow! Sounds like it has been an exciting and extremely eventful release! It looks amazing and sounds really interesting. Looking forward to seeing how it grows and as well, the C-programming documentation. Congrats on the exciting achievement guys! Hope it sells like hot cakes!

  • what's the image on the top of the aleph page? looks like a giant submerged pcb

  • So, the question is how many interesting programmers this will pull from the scene of people developing software for the laptop-monome/arc setup.

    Is software made for aleph compatible with other platforms?

  • @karakokaze

    "software is just algorithms, once you've learned the algorithms, though code might not be directly transferable, it's still easily translatable."

    So, at its foundation, is human speech. That doesn’t mean its easy to interpret. I get your point though.

    What im saying is, I think a lot of developers got inspired by big names in the community when starting to develop applications. The big contributors may end up committed to the Aleph platform. Or they may stay with Max and their usual development platform, since they have made a commitment to that system.

    Anyways, will be really interesting to see where the evolution of this piece goes. Will be watching. Will be crying.

    A general comment: who the frak needed Max or Ableton anyway.

  • Well, i'm happy to say i ordered mine !
    Really looking forward to what's gonna happen to this device. Also really curious to see how much coding i'll be able to learn.
    I was looking at my current setup and it became so obvious that aleph would replace the computer :
    A modular synth, a MachineDrum, An A4 (only for clocking the modular and adding reverb and providing MIDI sync), a 256 sequencing the MD (with the need of a computer).
    So in my case i could imagine the aleph replacing the MD, A4 and computer...

  • The project is amazing! and so open...

    I was attracted by the ADDAC VCC for building my own modular routines, i guess with an aleph we can go much much further!

    Congrats every one!

  • a question for ezra or tehn

    soundplane has been mentioned briefly...does that mean i can control/interact with aalto or kaivo with this? if not, will that be possible in the future?

    shnth compatibility was also touched on (yes!)
    from day one i could warp its audio output w/ aleph...what else do you have planned? could we possibly use other controllers thru aleph to control an app like justints?

  • having preordered an aleph, this is actually the first time I am actually tempted to learn a programming language. I know that ezra and brian are planning to put up a lot more information about that later, but if any of you guys could already point me into a direction on where to start with programming c (in the context of later developing for Aleph), i'd be very thankful.

  • huge food for thought...

    1. do you ever plan to make it available as a kit?

    2. would you consider a non-dsp entry level version? (a 'silent-aleph' that I can plug my monome directly into, and then run minimised-GUI ported versions of monome sequencer apps in aleph to midi out to other boxes). Perhaps initially omit as many of the more expensive hardware components as possible (for later optional upgrade to a full aleph if you want to add the DSP/audio/controller components at a later time?)

  • one last

    any details on the aleph tour?

    it'd be cool if DC is one of the stops
    if not i may travel up to Baltimore, Philly, or New York shows if you have em

  • Congrats on the launch!

    Wish I coud afford it right now. Maybe next batch..

    RaspberryBees anyone? :D

    Definitely very interested in the API aswell

  • Congratulations for aleph! I'll spread the word too. Cheers!

  • What ADC/DAC is in this thing?

  • the photo is by kelli, cancale.

    max and ableton, still useful. don't write them off. the aleph has much promise but this needs to be calibrated. you won't want to or be able to do a 2 hour DJ set with all your tracks using the aleph and a monome. that's simply not our intention and the interface wouldn't be appropriate. ableton is good at doing ableton!

    soundplane-- aalto will continue to live on the laptop. it's likely impractical to replicate aalto in the aleph-- though some sound engine similar may be possible. the interface is simply unmanageable given the OLED-- it'd need to be reinterpreted. a most realistic possibility for the soundplane is using it with the aleph as a CV bridge, or controlling an aleph-based synth.

    no plans for a kit. it doesn't make sense and wouldn't accomplish either a goal of customization or price reduction.

    a non-dsp control-only version has crossed my mind, though unless there are some other radical considerations (ie, euro-rack so there's almost no enclosure or power supply) and removing all the expensive stuff (encoders, screen, etc) it'd be cheaper, but starts to miss the point perhaps.

    aleph tour would probably be early next year once we have units ready. the next two months will be production and programming intensive.

    the audio codec is an AD1939, a very high quality chip. CV out is 16 bit, CV in is 12 bit.

  • @tehn

    "a non-dsp control-only version has crossed my mind, though unless there are some other radical considerations (ie, euro-rack so there's almost no enclosure or power supply) and removing all the expensive stuff (encoders, screen, etc) it'd be cheaper, but starts to miss the point perhaps."

    I dont think the modular adaptation is a bad idea at all. The current CV options are still really useful for stand-alone analogue synthesizers, but for the Aleph to be attractive in a modular setup, it needs more I/O CV for reasons of competing with other data->modular interfaces (Expertsleepers etc.). What would set this unit it apart in a modular format, making it extremely attractive, is that its software platform is open source (no need for expensive software licenses). Also, there are no modules I know of that implement very sensitive rotary encoders. That would very likely bring in a large community of software developers as well.

  • How is the AD1939 compared to other devices? Is it used in any soundcard? Is it comparable to the OP-1 ADC/DAC or better?

  • Will Aleph also be able to run monome apps like MLR onboard?

  • @mrdave1981

    given that aleph only has 64MB RAM, i would say it is unlikely to see mlr 'as we know it' adapted for aleph.

    especially since mlr is max/msp only.

    but some mlr-like programs, i don't see why not...

  • rove could possibly run with a bit of porting, since is written in C already. however, like every other mlr-like app it's designed to load samples into RAM at startup, so it would need refactoring to read from the sd card much more often.

  • @mrdave,

    It won't run any existing versions of monome apps onboard, as those require max/msp, and max/msp is another company's proprietary technology which has its own software dependencies.

    However, apps can rewritten and optimized for aleph when it makes sense to do so, and in the case of mlr, you have to know that's the first thing the community will port if tehn doesn't do that himself.

    Will there be a simple translation matrix from max to C, and an organized effort to port every app like we had with the serialOSC transition? I'd guess no to both parts, and that most apps won't ever be ported.

    ...but wouldn't you rather see new things developed specifically for this?

  • what about the c++ code you can generate with max/msp gen? is that any use?

  • the AD1939 is an outstanding chip. it's insanely quiet. i'm not sure what soundcards might use it-- is there a list of codecs that each soundcard use? that'd be interesting. but yes, we basically created a fancy soundcard for this dsp, it's very nice. the analog gain stages work well.

    we won't be creating mlr "as we know it"-- the file management is simply impractical, and the user interface would be unwieldily. but! we already implemented mlr-like functionality into the looper/echo module, i plan on making a more extensive mlr for live material, in addition to being able to load sounds off the card. so yes, mlr will exist, it just won't be exactly like earlier incarnations. in my opinion it'll be better than earlier versions-- tighter timing, better x-fading, more gestures. but not a super-sample-bank with tons of buffers. that's what computers are good at.

    we talked about gen~. much to be explored. seems possible.

  • very nice work brian! All the best as this unfolds and develops!

  • @myecholalia
    this is an excellent and comprehensive free book on c,
    maybe a little too comprehensive but oh well

    c++ should work. both avr32 and blackfin toolchains nominally support it but its certainly not as popular for these targets. i think the reason has less to do with runtime efficiency and more about executable size and the "opacity" of the compiler, if you will.

  • @gli
    what we are thinking of for soundplane support is mostly along the lines of the aleph providing "glue" between SP and hardware (CV or digital). the 'plane produces a massive amount of data; one would use the aleph's DSP to boil it down to gestures, as is done on the host computer when you use it with aalto or max.

    i've been chatting with peter blasser a little about shinth stuff. justints is a pretty sweet software instrument and i'd like to port it some time. a more ambitious project would be to write a shlisp interpreter for aleph/bfin by porting each shlisp opcode from ARM assembly to C... not for the faint of heart!

    we'll start with basic support for the shinth as a usb controller.

  • @ootini
    as brian says, gen~ compatibility is on the table and we'll see where it goes. i'm also a fan of Faust, which has a similar purpose. ( ) both of these would require some work to efficiently target fixed-point DSP architectures like the blackfin.

    the problem with an open architecture and a small team: too many possibilities to choose! so we are just going to start by making the instruments that we want to play, and see what happens after that.

    in any case, some sort of code-generation / scripting stuff will happen. i've already found myself making ad-hoc code generation scripts for DSP development; some of these modules have hundreds of parameters and the typing would be just too tedious otherwise.

  • I tried searching for soundcards with AD1939 but could not find any.

    So, in theory, the aleph could act as a nice 4-in 4-out soundcard aswell? Nice.

  • @Vurma, @karaokaze
    as raja says, DSP algorithms tend to be pretty portable. writing audio code for the aleph is not dissimilar from writing for AU / VST / whatever, simpler in some ways, weirder in others. like most audio frameworks, you basically get an audio-processing callback and a parameter change handler.

    on aleph, the callback is on each sample rather than on an audio buffer, though you could buffer stuff if, for example, you need to do expensive computations on parameter changes but not on samples. bonus: no buffer latency.

    weird part: the blackfin doesn't have a floating point unit, so float computations are slow. OTOH, it has very very fast intrinsics for operating on 32-bit fractional data, in which a standard integer type represents the numerical range [-1, 1), and this is where sound data generally lives.

    anyways, the point is that you can mostly replace the arithmetic operations in floating-point code with function calls and be good to go. there are some caveats but they're not too hard to deal with. and we will be spending the next weeks both extending the library of existing DSP code and refining the API to be as painless as possible.

    i love using C by the way. max and supercollider and that stuff is great (SC is my jam and i couldn't live without it), but there's something so satisfying about knowing exactly what your program is doing. you can build on others work but it is all totally transparent and there's no sense of relying on anyone to keep their environment working on your setup.

  • oh i should mention that i generally write audio code on linux first. i've made linux functions that emulate the blackfin intrinsics and wrapped the whole thing in a portaudio program, so code written in this environment can be compiled directly to the aleph. these tools are personal and ugly right now but we'll make them prettier.