aleph.

  • @jah
    that might be because the ad1989 is brand new? i don't know that soundcard manufacturers often publish their components in any case; they have no obligation to do so.

    actually i doubt its even theoretically possible to use the aleph as a soundcard. its USB device port is connected to the controller, not to the DSP, and it has actually a third processor, a tiny 8-bit guy, that turns the USB into a virtual serial port in the same way as FTDI but without the need to use their shitty drivers that will crash your mac.

    anyways its just not designed to stream audio over the USB in a synchronous, class-compliant manner. could use the USB for asynchronous audio transfers though.

  • x[n+1] = 1 - y[n] + |x[n]|
    y[n+1] = x[n]

  • So audio processed internally with single sample delays? ? It seems a lot of software falls apart doing feedback otherwise? I'm not sure if that's the only consideration. I'm still trying to figure this stuff out. I was looking into an eventide box for exploring feedback and delays, but potentially this could be the feedback and delay box of my dreams. :)

    Can you write programs on the Aleph itself? I'd be all about a physical, kinesthetic programing language that I can literally jack into.

    If not? Will we be able to run programs in a virtual environment on our computers even if slowly/poorly? This would be the ultimate "demo". :)

    Not trying to be a hard case, but I use supercollider and whip up sketches for arduino on a breadboard for jacking into the modular. The price is right and it works, but it's only really suitable for the studio.

    I'm not 100% sure I want to learn another or a "real" language. Is the main advantage of the Aleph robust, dedicated, low latency hardware? Don't get me wrong that's no mean feat and I do appreciate the advantages that offers. There's just the concern of how long it'll take to get comfortable with a language to make it transparent enough to get on with making music.

    I mean for me, supercollider is pretty easy (still learning/always learning, but yeah), iteration makes sense to me. Max is fun, but I still feel like I'm tinkering. Reaktor is too clunky and tedious at the higher levels and baffling at the lower levels. Too many layers. "Real" programing I've tried doesn't feel like it rewards playing around and I never stick with it.

  • Heard about this from the Mutable Instruments forum...

    @tehn I really like the idea of a Eurorack based version of this especially if it could make it more affordable.

    I also wanted to echo the folks who mentioned how cool this is to detach from the computer...as a former 40h and 64 owner, reliance on the laptop to play or perform kept me from really, really getting into my monomes. Not a criticism so much as just a personal observation.

    Do you guys have other minds working on software? I could see some of the folks in the digital modular world embracing this! pichenettes/Olivier at mutable Instruments would seem like a good fit as someone else in the open source camp who is doing awesome stuff integrating digital brains into the modular world.

    Anyway, I am stoked to see this come together!

  • Congrats guys! It really is impressive and forward thinking (per usual) :)

  • @zebra writes:
    "the problem with an open architecture and a small team: too many possibilities to choose!"

    Yeah... Have you considered running a component video feed through aleph's i/o ports? There isn't enough memory for something like "64 (video) fingers", but you could probably do some crazy effects processing...

    so... this, in motion, with tactile controls:
    http://atrainatdusk.blogspot.com/2013/08/sonification-study-less-process-more.html

  • i think with video you run into timing / samplerate problems if you want to preserve RGB information. those frequencies are in the megahertz.

    stuff like the LZX modular video synths, which are totally awesome, mainly differ from audio processors in that they need more specialized timing circuits. getting a special xtal to clock the microprocessor at some harmonic of the video frequency. stuff like that.

    but yeah, i mean you can put video on an audiocassette and get some weird ghostly version of the alpha channel at least. try it out!

  • @hazyvariable
    good suggestion! yes i would love to get more coders involved because, well, my wrists hurt ;)

    the plan at the moment is to make more applications for non-programmers and to polish the codebase for programmers, before shipping. once the thing is in some hands there will be more opportunities for collaboration etc

  • @jonah
    whoa those are some thoughts. well i can't stress enough that the point here is not to make a new development environment, rather it is to make a nice instrument that is also open to development. we are designing for functionality and enjoyment/ease of use, not for ease of programming per se. but of course we want to make programming as easy as possible.

    i feel like i'm running out of general things to say. it starts to sound like vaporware since there is not a lot of actual stuff to look at yet, and of course it is not vaporware, it is a real thing that works and is awesome but is hard to articulate due to extreme mutability.

    i would like to keep answering specific technical questions if yall have them at this early stage.

  • i just posted this on muffwiggler, thought i would share here since it may be informative:

    ////
    Paranormal Patroler wrote:

    I'd be really interested to listen to its sound producing capabilities in a clear demo then. Sound design is a big factor for me

    I was sold on the Snthn for that reason alone
    ////

    point well taken! honestly it is just early times in the public life of this object, and we are super small. i have been developing different sound engines and stuff, but doing sound design and making videos is a large job in itself.

    for an example and as an excercise, let me describe the drum synth engine you see in the video:


    4 voices

    each voice has a noise source and a state variable filter.

    the noise source is itself somewhat modulatable between very pure white noise and varoius weird chaotic orbits.

    the state variable filter has arbitrary mix of lowpass, highpass, band, and notch outputs.

    at full resonance the SVF is a sine wave with amplitude compensation.

    corner frequency, resonance, and output amplitude each have a separate ADSR envelope that can be enabled or disabled.

    each envelope has arbitrary on, off, and sustain levels, so it can be inverted, and of course arbitrary durations / slew coefficients per section.

    each envelope can be in triggered (one-shot) mode or in gated (sustain) mode.

    the SVF can be routed before or after the ampltiude evelope. so for example you can hit a very resonant filter with a short pulse and let it ring.

    noise source can be mixed with or replaced by audio input from any channel.

    so all told, that is a lot of parameters and a lot of sound design and a lot of possibilities.


    the "looper" app in the video, where i'm playing viola, is actually a similarly huge and multipurpose buffer-manipulation and filterbank engine with aribtrary control over read and write head position, erase level, write level, routing to/from each input/output/delayline/filter.


    so, these things require interfaces to be very useful. rather than designing a "perfect" interface for editing hundreds of audio parameters, we have decoupled the control side from the synthesis side and made tools to code your own interface, use a menu system on the unit to patch things together, edit via serial stream or filesystem, or just use the interfaces that we've made for our own use. we'll spend the next two months making stuff that we enjoy and polishing the customization channels.

    so, this is a very geeky kind of approach. its not for everyone but i'm selfishly very glad for its existence as a musician.

    sorry for the long post!

    ez

  • Any chance of a look inside the case a the wiring?


    Thanks!

    -AG

  • i'll do some take-apart photos next week as i'm building another hand-soldered prototype (as shown in the video).

    the video and photos show our existing but not-final unit, by the way. hence some small irregularities. we'll post new shiny photos when all the parts are together.

  • I can't wait to get this, looking forward to learning c. Honestly, I thought aleph would be more when I watch the video and Brian and Ezra talk about the dsp and processors and that this really has an endless amount of possibilities, like an mlr typ arpeggio that can load to monome and you can "freak" em. Or unique step sequencers not only for drums, but some of the awesome filters and efx. The possibilities are really mind boggling. I'll have my monome, aleph and a MacBook on top of a mountain here in Alaska making music, thanks monome crew.

  • The image on top looks to be an oyster farm in Cancale France. looks like low tide.

    I'm so happy for this device, I can't wait to hook up a monome and play synths without having to start up a laptop.

    People should hold off making crazy suggestions till the dang thing is released. It'll be epic. I hope the community gets behind coding for it like what the Monome spurned. I know I want to design some ideas already. :)
    Thanks Brian, Kelli and Ezra!

  • spurned, or spawned?

  • still don't understand what it is, what it does or how it does it but well done and i hope people part with their hard earned.

  • oops ment spawned, haha

  • Been doing dealings all day selling my current modular so I can get a nice table top skiff eurorack to play along with the Aleph.

    Bugbrand to eurorack.

    That's how devoted I am. :P

  • the demo video makes me wish i could play the cello -- that, or have a couple of pet cellists to collaborate with from time to time.

  • Im curious how open it is to upgrades in the future. If more memory or a better processor becomes available in a year or two at a cost effective price point, will the aleph be able to be upgraded, or will we have to wait for aleph 2.0?

  • That's a really good question @Yorke

  • the more you post the more excited I get, if ezra's feedback to questions is indicative of the support you're offering then that's impressive - you've obviously put a lot of thought and effort into the dev environment, tools and tutorials as well as the hardware...will you be releasing some of these software related things in advance of the hardware so that we can begin to think about writing our own applications? I already have a couple of ideas that i'd like to start working on.

  • Woohoo, I'm in! How soon before we get to sniff the APIs? I want to know how unrealistic my foolish dreams are.

    Also, thanks for making this!

  • "I want to know how unrealistic my foolish dreams are."

    <-- Best sentence I've read all week.

  • i felt it was important to add this to the aleph-detail page, repeating it here:

    under the heading "why not just use a laptop"

    all of this said, the aleph is absolutely not a laptop replacement. it’s not fit to run full ableton-style dj sets (the screen/interface is less than ideal for this), run tons of simultaneous plugins (laptops remain more powerful in terms of computation), or serve as a super-multi-tasker (it will be good at doing only a few things at once, whereas it’s no trouble for a laptop to also record to disk, run visuals, and check e-mail during a live set.)

    we’ll continue posting videos and clarifying best intended uses.

  • very good news about the drum synth

    is tehn basically running a sequencer with his grid + tweaking the filters via aleph encoder?

  • "elaborate mappings can be created without writing code by way of an easy menu driven environment and a thorough preset system."

    so is there a sort of 'OSC Learn' to accomplish this?

  • Please use high enough power supply voltage to allow analog input/output level to be high enough for direct patching into a modular... @tehn

  • the CV in + outs say that they are 3.5mm how would I get this to work with something like my Moog gear which uses 1/4" ins + outs for the CV, just curious and ashamed if I should have known better for asking such an idiotic question

    Thanks to the non hating informative people!!

  • You get 1/4 to 1/8 TS cables, I think thats the thing you need:
    http://www.musiconmypc.co.uk/hosa-cmp-310-mono-cable-3-5-mm-ts-to-1-4-in-ts-10-ft-3m
    (Maybe not a 10ft one though)

    If you're comfortable soldering up your own cables it'd be a pretty straighforward job to buy the different size jacks and make your own to the required lengths.

  • my mind is really buzzing right now with ideas

    and its crazy to think of what will be made in the future that might change and extend its capabilities

    not only from e / b / and other talented folks within the monome community
    but the brains behind madrona and ciatlonbarde/shbobo

  • @zebra + tehn: Trying to get a leg up my dev environment.

    I've got an instance of Ubuntu with build-essential installed which lets me compile C and C++. What else?

  • This is probably going to sound silly, and has probably been addressed here already. I haven't made it quite through the whole thread yet.

    I'm seriously considering an Aleph, as the idea of a central hub for my various noise making apparatus sounds very interesting, especially that i can make my grid an integral part of that.

    Given that, I'm a bit iffy on the little oled menu window. One of the things i like most about the grid and arc are their ergonomics. A small menu driven device seems to fly in the face of that given that the gui of most any laptop these days is so easy to use and easily navigable. Yes, i understand i can plug my laptop in too, but part of the idea of the Aleph seems to be to be able to lose the laptop.

    I guess i'm just thinking out loud here, and i do have somewhat of a hatred for menu windows, so i admit to being biased. Is anyone else who dislikes menu windows considering an Aleph? I'd be interested in hearing some thoughts on this, thanks!

  • I think it depends how you use the screen, look at the OP-1, it's a far cry from the old 2x16 character LCD displays of ages ago.

  • True, and the OP-1 is also one i've had my eye on. I guess i'm a bit used to the displays of apps like party van and others.

  • @blungo2

    i'm not fond of menus on lcd/led screens either

    however, i see them as no more intrusive, annoying, unnecessary than the UI of max/msp patches or the GUI of a DAW or an au/vst plugin

    from what i can gather aleph does not rely heavily on the OLED anyway (i could be wrong)
    the power is in the control objects you attach to it

    (and it seems like there are many ways to sidestep the screen if you are willing to tweak the code at a deeper level)

  • I doubt i have the ability to tweak the code, but your answer if what i was hoping for. That the control objects are of more importance.

  • @emergencyofstate :
    the only other thing you need is the avr32-gcc toolchain (for control side development) and the bfin-elf-gcc toolchain (for DSP development.) both are freely available from Atmel and Analog Devices respectively. oh, you need the atmel headers too, this is a separate install for some reason.

    relatedly: we still need to do some work on the APIs. we'll be releasing the software well in advance of shipping the units though, this will include all our source code as well as a pre-built development image so you don't actually have to fiddle around with installing toolchains if you don't want to.

    regarding component upgrades: not too likely.

    regarding alternative configurations:
    we started working on this thing years ago, so inevitably by this time we have thoughts about other ways to do it. ideas of a DSP-only version and CV-only version have come up; especially the former. it would bring the price down. but don't hold your breath, lets get this one out first... i'll also point out again that the CV out/in are there for other things besides controlling modular synths. like adding potentiometers / expression pedals

    regarding CV formats:
    converting banana <-> 1/8" <-> 1/4" is pretty trivial! its just cables. we went with 1/8" because it is small and the most widespread. there is also the small advantage of not having to worry about sharing a ground with the modular. but this is no reason to e.g. sell all your bugbrand stuff! all my modules have banana jacks too ;)

    regarding the screen:
    you need the screen to know what is going on. it doesn't have to be connected to a menu system. for example the looper app in the video just shows the value of last touched parameter in various units, and states like record/play/overdub. its hard to capture in video but the screen is very nice, fast and sharp. its small but not distressingly low-res (128 x 64px), but so is the aleph itself (7 x 4.5"). i think we will be seeing some cool lookin stuff on it.

    bees has a completely self-contained editing system based on menus, and no-one would claim that this is an optimal way to edit complex patches, but it its very important to have that capability when needed. i'm not a big lover of menus myself but they are a necessary evil. like many things, there are good and bad ways to design them. i like menu systems to be relatively flat and non-modal and i think this one is pretty nice.

    as i mentioned somewhere above, you will also be able to edit / control patches from your computer via the aleph's usb-device port. we'll have some help developing nice front-end GUI editors while brian and i continue to focus on extending the firmware possibilities.

  • @bartaug:
    interfacing with modulars is a cool feature but not a core use-case really, as far as the audio i/o is concerned. so the audio levels are standard "professional" line-level (max at +/- 1.5v peak, or so.) the CV ins and outs are 0-10v suitable for direct use in most modular systems.

  • oh, a question came up some time about actually replacing the cv jacks on the panel. this seems hard, brian has done a beautiful job designing the mechanical layout and it is tight (so to speak)

    there is an idea floating around about a panel-mount version. some challenges there but some advantages - lower cost without a power system, etc. the i/o would probably be on a separate panel section in this case and would be more customizable.

    but again, first things first! we will get the first batch out there and then we can all think together about where to go next

  • great having both of you chiming in here and great to see the whole ting starting to open up.

    couple of quick questions which i appologize if I skimmed over earlier in the thread:

    * can effects on audio inputs be run simultaneously with sound generators?
    * is there mapping for stereo/mono on the inputs and outputs.
    * am i correct in assuming it doesn't do any sound via usb?
    * patching for it would be a host language or max patches?

    exciting work here guys, with a ton of possibilities running through my little head.

  • i'd never heard of i2c so i've been reading about it this evening

    now i'm trying to figure out how connect a Wii controller to the aleph port


    this is going to be pretty nuts

  • polygome for aleph! I don't think I could resist that.

  • @zebra

    I completely agree with your thoughts the transparency of C. I need a reason to learn more of it. Perhaps Aleph would be a good hardware platform to give that a shot.

    I have some programs (mostly numerical simulations) that I would like to explore for audio production. A sandbox for the Aleph programming environment would do wonders for development. I can see myself not wanting to pull it out as soon as I want to test a new program. It would also make it possible for users that dont own an Aleph themselves to contribute to the community.

    As a general comment on the whole banana jack idea: It takes 20 minutes to make a nana->minijack convertor and stick that into your modular system. The time and money involved with designing an Aleph version with nanas instead of minijacks probably makes no sense in that context. Even if you dont want to make the converter yourself, there are plenty of devices that perform that function.

  • * can effects on audio inputs be run simultaneously with sound generators?

    only one audio program can be run at a time. that said, the program could be designed to do quite a number of things given processing power is allocated optimally.

    * is there mapping for stereo/mono on the inputs and outputs.

    the mapping system in bees will have operators for accommodating dual (stereo) control schemes, though again it depends on what parameters are made available at the audio level (which will typically be very many)

    * am i correct in assuming it doesn't do any sound via usb?

    correct, audio over usb is not supported and was not our goal-- it would've required more hardware and programming to conform to usb audio standards.

    * patching for it would be a host language or max patches?

    patching is via a menu system, but we'll also implement some sort of external editor (the file format is readable, like xml). so it's not a "language" as it's simply a dataset. max patches, no.

    polygome, yes.

  • To design a controller to work easily with the aleph, what would be the best approach? I'm thinking specifically of the stribe, (http://soundwidgets.com/stribe/) which is based on Arduino. It's 8 touchstrip sensors with lots of LED illumination. I'd want to be able to send the sensor values to aleph for CV outs or MIDI or synth params and meanwhile control the LEDs on the stribe (1024 of them). The original stribe communicated with the computer via Max. One approach was to do everything from Max, e.g. all the logic of which LEDs to light up, sensor-taming, etc, was in Max patches. The other approach was to make the controller smarter, e.g. more features in the firmware for sensor-taming, LED control modes. There were advantages and disadvantages to each approach. I'm working on a new stribe design and Aleph could be the perfect host. Would it be better to still rely on stribe's microcontroller to run the stribe's LEDs and read the sensors, or could I use the aleph's resources for some of this?

  • echoing ultra's question, what's the general communication between devices? osc messages filtered through the laptop host or are there direct calls which can be made to the device.