• very interesting

  • Greetings, a new monome / aleph convert here.

    A question about CV range, it's listed as 0-10V. Does it mean it doesn't go into negative range? It can be easily offset in the modular, of course, just curious if that's the actual range or if it's meant as -10...10V.

  • 0 to +10v, unipolar

  • the idea is that the laptop doesn't have to be there for this sort of communication.

    the stribe is an arduino, so you can plug it in via USB. i'm not sure what the serial protocol of the stribe looks like, but i doubt it's very difficult. we'd need to write a driver in c. we'll have a generic arduino-ftdi-serial driver that can do simple parameter sending with index-value pairs.

    you could of course use the aleph's resources to calibrate/etc the stribe. monome devices are pretty dumb without a defined interaction in software, so it's the same case.

    re: using a laptop, we'll expose an OSC layer (this is still being designed) for calls to/from a laptop. so if there is a laptop in the middle, this will also be a negotiable situation.

  • Thanks E! What about the CV inputs, do negative values get treated as 0v?

  • also 0 to +10v

    i'll clarify the specs, sorry!

  • So if the voltage is in the negative Aleph would read it as 0? Say if an LFO -5..+5 is patched into one of the CV inputs Aleph would see it as changing from 0 to +5 to 0 and then it will stay at 0 for half a cycle?

  • @ultra

    ah, the stribe looks really cool..
    well, aleph is a usb host, it should be able to do what you want in terms of bi-directional communication.
    that said, i can't tell from a quick glance at the site, what the stribe protocol is.
    if it speaks a monome serial protocol then the driver is already done.
    if it is some other serial protocol that also uses FTDI,
    then it will be enumerated and detected and you just have to add the actual serial parsing routines.
    similarly for HID.
    if it is something else it will take a little more work.


    aleph is designed to connect to digital controllers without a computer.
    hence the usb host post.
    for example, the monome sequencer in the preview video is running on aleph, there is no laptop.
    i2c is provided as a sort of blank-slate com protocol for digital inter-device communication.
    it is much simpler than USB.


    if you mean the wiimote, it is blutetooth and aleph doesn't have that.
    last i checked there were several DIY platforms for bluetooth, like the xbee arduino shield.
    so, if you're into wireless control, a DIY bluetooth "hub" that speaks i2c, or monome usb protocol, could be a very worthy project!
    similarly for wifi...


    yes indeed, there is a sandbox / emulation project for the DSP. i think i mentioned this above somewhere.
    emulating the control side would be a little harder since its behavior is deeply linked to physical inputs (encoders, usb) and hardware peripherals (timers, interrupt handlers)

    in general, its good to develop in a modular fashion, so that you can test important logical units in toy programs.
    for example, the logic module of a sequencer can be easily tested on the commandline with standard i/o and sleep().

    for quick tests of audio algorithms, i highly recommend getting portaudio and hacking up some of their example programs.
    the aleph DSP emulator is essentially this with a layer that emulates the fixed-point math intrinsics from the blackfin.

    this will all be a lot clearer once we can release the source code. working hard on it...!

  • @scanner
    yes i think thats what will happen. strangely i don't have any bipolar 10v gear to test it. (i just thave buchla stuff and some flowerelectronics.) maybe brian can look at that... ;)

    edit: i take it back, think the flower oscs might do it. will check when i get home

  • @zebra
    i was gonna ask whether aleph supported wireless communication
    so thanks for the info on that

    a wiimote/bluetooth mod is certainly a worthy project

    i'm actually more interested in the potential of the nunchuk attachment. apparently it communicates with the remote via i2c (which is what brought it to mind).

    i found an adapter with wii jack and a usb plug on the other end so maybe that would work using the aleph as usb host

    might need tweaking

    edit: also is there a limit to the number of devices aleph will recognizes thru a hub?

  • @tehn @zebra for the stribe I used the FTDI driver and made my own serial protocol in the Arduino - then used Max to convert the serial stream to OSC and MIDI, and to send LED commands back into the Stribe. Arduino handled AtoD conversion for the sensors and talked to (and powered) the LED driver chips. I can stick with Arduino but I was wondering if it could be bypassed and the device made more dumb, putting more of the work onto the host.

  • @ultra maybe i'm confused what you'd like to take away. you'll absolutely still need a microcontroller in there. it'll need to connect either via usb or i2c. with usb it'll be a trivial modification to the monome code to make a stribe driver.

  • Apologies for mental denseness, I'm still getting my head back into controller-making after a hiatus. Very excited and inspired by the possibilities of the aleph!


    very balanced, well written appraisal of the release

  • @gli: thanks! nice to see someone not just cut and paste.

  • @tehn thats why it stood out...

    kinda sad that decent writing is so rare these days but it really was enjoyable to read his perspective on things

  • How customizable is the OLED display UI? Is a framework used that impose a certain type of menu system or is a developer free to put whatever text and graphics he or she wants on the display? Without having to develop your own firmware I mean.

  • well bees has a menu system as well as a "play mode" where graphic display is more customizable, including pixel-level drawing, graphics primitives, and arbitrary text. beyond that a "developer" must "develop." hope that answers your question!

  • How well suited is Aleph to multi-tasking duties? For instance could we have the DSP processing audio with delay, using the device as a midi to cv converter for a controller, and sending CV out simultaneously?

  • yes you could do that. arbitrary audio i/o mixing and direct CV out are part of the boilerplate for all DSP modules, and delay is pretty cheap. any kind of sophisticated synthesis tends to be more expensive

  • good question + good news

  • @gli (9/30)

    re: wiimote
    oh i see, yeah i guess you could just make a physical plug adaptor for the nunchuck and use it with i2c. as we've said, the i2c is the one part of the system that is truly "blank" so far; maybe this is one of the use cases to pay specific attention to.

    as far as a wireless "hub", i was thinking of a standalone device based on arduino with xbee (or whatever is the latest wireless shield), using either usb or i2c to send to aleph.

    i wouldn't plan on making any mods to the aleph hardware itself, besides the ones we've planned for (basically, populating JTAG and auxiliary UART headers for intensive development.) and maybe some component values in the analog section if you need tons more gain or something. but modding the aleph will be pretty hard.

  • well raj, i am glad to clarify, not all these answers are very detailed. then again the questions sometimes need clarifying too; what is "multi-tasking" anyways? ;) mrdave has given a specific example and the answer is "yes," with the earlier, vaguer example the answer was "probably not."

  • I still dont really get the bees system and how it is related to the running app. Is bees always present on the aleph? I guess there is only one app running on the aleph at any given time - not several apps. How does bees fit in? Perhaps you can describe this in relation to SuperCollider scsynth/sclang which I know (and like very much). You drew an analogy earlier to SC.

  • Yes - When can we get a look at Bees?

    Even some screenshots would be really cool :)

  • @zebra thanks man

    its not really critical for me to know since the monome is gauranteed to be compatible

    once i get mine i'll experiment with more controllers (the adapter i found seems to translate wii data to HID which should work fine)

  • ok. first, here is my initial long response to this thread, where i tried to explain bees:

    but to clarify: aleph will ship with a number of applications. most of these are "standalones" - they will probably use a single DSP module and have a pretty specific functionality - even if it is rather versatile. (for example i've extending the delay/looper app to use a grid interface for cutting within loops, and i will shortly extend it to load audio samples into the loop buffers. i'm extending the drum synth to respond to MIDI in a couple different modes (as a sequence editor or as a direct source of notes.))

    switching these applications is done offline, in the bootloader. you flash the app from sdcard - this takes about 30 seconds - and then the aleph behaves that way until you flash it again.

    bees is an application, but it is much more flexible than the others. you've used SC, so the analogy is something like: the "standalones" are entire applications wrapped in a class, and an instance of that class created in Main, and the whole SC structure wrapped in an application bundle. "bees" in this analogy is sort of like sclang itself; well ok its not that powerful, it is more like an idiosyncratic 3rd-party layer like the crucial Instr family or JITLib or something. blech, analogies.

    anyways bees can do the work of many different "standalones," at the necessary cost of overhead in runtime computation and in executable size. but the benefit is that it can swap functionalities, including DSP, in mid-performance. it takes about 1 second to swap DSPs and essentially no time to swap a whole set of control routings and DSP parameter values.

    we're not really sure what will be the most effective strategies for e.g. touring or performing vs. sound design and studio experimentation, bees vs. standalones. i expect different people will have different comfort levels.

    all i can say is that i've done computer-based performance for a long time, from laptops to a rack-mounted, screenless mac mini, osx, linux, max, SC, aulab, jack. and i am so, so sick of that piece of the equation being the one that inevitably causes the most anxiety and dismay, from the moment of setup. (will my startup script work? will it pick the right soundcard? will it find the controller? is it done booting yet? arg, someone unplugged the Mini rack... etc) both approaches in aleph induce far more confidence and peace of mind, for me anyways. (plus, it is tiny and encased in steel.)

    we will try and demonstrate bees in a video soon; i understand that its effectiveness and usability is a critical point, but it is inherently difficult to demonstrate an entire patching system. the source code and manuals will make it more clear; we will be publishing these as soon as possible and probably keep our videos more like little performance films that are more about making something that sounds good, and shows performance workflow rather than editing/development workflow.

  • great!

    as a footnote

    some of the critics who are unsure whether aleph will be well supported should merely look at how responsive brian + ezra have been while answering our questions ;)

  • well here's a valid point: i'm answering questions when i should be finishing bees ;)

    but sure, spending an hour a day on pertinent Q's is a fine investment

  • one of my tasks this week is to scrub this thread and put it into a new "addition" to the details page.

    plenty to do without understanding c, my friends.

  • i'm a bit puzzled by that particular question being repeated around the web because it was pretty clear from day one:

    "do i need to be a programmer to use it? no. even without programming the device is highly modifiable."

    you've even offered to codesign solutions for hardware if they arent supported yet...kinda baffling that anyone would still be worried

  • new proto parts came in today. custom mixed matte powder coat.

    i should've been more clear that the video and initial photos are all preliminary prototypes. finished unit will be highly exact.

    900 x 672 - 177K
  • even better (i wondered when i read the description as off white)

    also lovin the triangles for i/o

  • ^^ Those look very nice!
    Audio i/o jacks are right to left, interesting!

  • well, the numbering is actually normal when you view it from the top. the photo orientation doesn't make much sense given the panel goes on the back!

  • bonus if we can bait some extra anti-semitic trolls.. cause you know i love that

  • "bonus if we can bait some extra anti-semitic trolls.. cause you know i love that"

    i refuse to buy an aleph because i fear it will turn me into a jew!
    ( i just happen to have troll in my name! and jumped in to satisfy ezra's wishes... too soon? where'd everybody go? something i said?...)

  • Okay, then, so there's a distinction between standalone and bees apps. To me it sounds as if bees apps may have several different DSP modules running at the same time and these modules may be changed with a 1 sec operation. Akin to Synths in SC(?) but of course Synths in SC are replaced instantly. So as a developer I can implement a DSP module, say a lowpass filter, boot up the aleph and route different DSP modules in a graph with my filter as one module. Am I dreaming here?

    Sorry if these are dumb questions. It's just a bit vague given the website info.

  • My dream was based on this quote: "[bees] can swap out the running DSP modules in real-ish time".

  • Well I guess my "dream" above is impossible to implement on aleph. I guess the DSP graph - so to speak - has to be fixed during compilation.

  • @raja "... i also thought gli was referring to others on the web"

    i was

    not trying to dwell on the negative but merely made a comment...i could care less what anyone else thinks about it really, this thing is literally perfect for ME

    @jah it may not be

    i'd wait for a definitive answer on that...or the video thats surely in the works demonstrating dsp app toggling

  • @jah: i apologize that i've had trouble explaining these particulars. let me try again:

    there are control apps and dsp apps. bees is a control app. typically a control app will be tailored for a particular dsp app (such as the looper which uses a delay/sampling dsp app.) bees can load and re-load different dsp apps quickly.

    but only one at a time. but this isn't a big deal, really. dsp apps will often have a ton of functionality packed into one app-- for example, the delay/sampling app can also mix audio inputs to arbitrary nodes, has several filters, and various ways of routing feedback (and much more, ezra has the specifics). so your "dream" of routing may be pretty real. the synth module is very versatile, for example.

  • Yeah, to be honest, I thought that was the case. Bees to swap out monolithic DSP apps. And, it isnt such a big deal. As long as building blocks for DSP are provided in order to build DSP apps. No worries.

  • DSP graphs are indeed fixed (as yet, and in a sense) at compilation, but they can be dense.

    for example, echo/loop module used in vid has hundreds of parameters defining potentially useful mix points / routings.


    , for each pair of channels

    write/erase level controls for each phasor or "tape head"

    and pretty direct control of indexing if you need

    or if you dont need

    and filter params and other stuff of course.

    so anyways each of these modules tries to be complete and flexible low-level instrument firmware. it turns the aleph box into a mixer/preamp, plus some kind of (maybe very mutable) effects/instruments/weirdness. we have made, and are making a bunch of these firmwares [i will call these "modules."] there is also a decent and growing collection of building-blocks for making modules, and by necessity some scripting has already gone into it so i think we can sooner or later get to compiling them from a high-level graph specification. ultimately maybe we can get Faust/gen~ . but for now it is c programming (and/or ASM) on the blackfin. (1st level of customization)

    designing the controller application is simply about how to initially configure these parameters and map them to input. this is a customization of the firmware into a playable instrument. requires some straightforward c programming; i expect lots of people will want to perform minor or major tweaks/mods/inventions. (2nd level of customization)

    of course the application must do more complex things like store/recall banks of parameters to sdcard, draw to the screen etc. we've written a lot of clean boilerplate for this kind of stuff in the existing apps (or shared by them), and must still polish boilerplate into a proper library/API along with the low-level peripheral control (e.g. being a USB host); of course we will share this library and API as soon as it makes the most sense to do so (soon!)

    so: bees is a very complex application. it can reboot the DSP while the controller is running, swapping modules, and allows runtime "instrument-building" by managing the values and connectivity of the large set of parameters above, with a modular collection of objects to process them in conjunction with UI changes. these networks are ultimately flat graphs (like the max patcher up there,) are managed on sdcard, can be edited directly in the aleph box (with, yes, menus) and of course editing with host-computer gui is possible too. (3rd level of customization, no programming required)

    we also, certainly, hope that people will create more ways to use the dsp
    (like: (there could be a truly "modular" module, (which restructured the DSP graph with function pointers/offsets, and very small opcodes ( ))))

    and of course to use the controller too; bees is what i will prefer to use on the aleph, i think, but to each his own!

    but i think this will get us all started playing for sure...

    ok guys seriously i'm off for a while -ez

  • Oh Bees isn't done yet! Please ignore us :)

    But seriously - excited to see documentation.