• boy I'd love to be hoping on board this train. maybe I'll save up and catch the next one.

  • could an .sfz player be implemented?
    or some other multi sample playback device.
    so using a version/type of polygome wired into a multi sampled instrument all inside aleph. eliminating a hardware sampler or other computer playback from the performance.

    i get a 'simpler' would be fairly easy, but something a bit more robust that could handle more samples, round robins etc..

  • certainly it could!

    being quite honest though: i doubt i will personally implement this. there are just too many things to be done, and it's not "up my alley" as a musician.

    we'll have simple support for loading samples into aleph RAM, monolithically with region markers or as a concatenation of files.

    the .sfz format is pretty complex but it represents a well-understood feature set; should be straightforward for an interested developer to implement their "dream sampler," and we'll be on hand to help that happen.

  • here's the .sfz format:

    the list of opcodes implies the list of features to be expected in a full multisampling environment.

    if anyone wants to write, or point me towards, a clean implementation of these features, on any platform (but especially in c / c++) it would go a long ways towards getting them on the aleph!

    the same goes for many other application ideas...

    soon, very soon, we'll release the APIs and start a thread (or something) dedicated to discussing new application ideas in greater depth.

  • Until we receive our hardware, will the dev tools have a simulator?

  • i answered this to the best of my ability above. a full simulator would not, IMO, be a good use of development time.

    there is a sort of emulation layer for DSP that uses portaudio and OSC and provides fixed-point math and datatypes, allowing line-for-line development of audio modules on linux that can then be compiled for the aleph.

    all the tools are gcc-based, making this much easier.

    control logic can usually be developed and tested in an abstract way.

  • liblo is great for hooking up c code to external control (SC or max GUI):

    for testing control logic modules

  • thanks will have a look.

  • @zebra can you go into the software framework for developing? Is there a development sandbox?

    Not sure what is really in store for users.

    I feel the .sfz is a file structure with relationship to functions.

    I get the gcc stuff and I see that as great. But what I am wondering is what is the whole software end going to look like?

    I was sort of under the impression there would be a sandbox of sorts and for the gutsy there is lower level DSP hacking.

    do you see people writing DSP synth apps?

  • @dimi3: we need some time to get this stuff together. it'd be bad form to release half-documented material that will only lead to more confusion.

    yes, people will/can absolutely write their own DSP in addition to control-rate code.

  • @tehn sorry not trying to push the wrong way. I just am such a curious monkey... and also happy to be helpful how ever possible.

  • Any progress on a new Vid??

  • good to know i'm not the only one who keeps checking back...

  • it's coming along! CV is working great. my decade-old usb gamepad died, waiting for a new one to arrive tomorrow. picking up trent at the airport wednesday so we may get delayed, though i'd really like to post it up quick.

    also working on a huge update to the text.

    also working on bees to make a nice demo for y'all to see


  • I'm personally super stoked for the i2c stuffs

  • Just placed my order! WHOOO

  • bored at work and just found this quote from ez on cdm:

    "...this really is designed to be an instrument. it is less intended to replace your laptop as a central sound processor, than to allow the types of processing and the depth/flexibility of control currently only available on laptops, to be available in other setups as well. as a touring musician who uses acoustic instruments with idiosyncratic processing, i have wanted something like this for a long time - a small rugged box with builtin preamps and lots of I/O, that turns on and instantly starts doing what i have told it to do. we are putting every possible effort into making it easily adaptable to many specific purposes within that general use-case..."

  • it had been implied before by brian and ezra, but i find it particularly encouraging/exciting that the aleph emerged directly from their performance needs

  • I just had a thought,

    I'm guessing at this point none of the audio IN's have phantom power? I know there is a gain switch for mic vs line level. Is there a stand alone phantom power box that anyone here can recommend?

  • ^
    I was wondering about that too. I'm assuming that because they're 1/4" jacks (again i'm assuming that they're TS not TRS) that there's no phanthom power and they're line/instrument not mic jacks.
    Balanced, phanthom powered mic pres would be great, but i'm guessing there's no room inside aleph for all that?

    edit: so there is a gain switch for mic level? Cool! So you clould plug a dynamic mic in. That's good to know!

  • inputs and outputs are unbalanced TRS (ring = ground).

    gain, yes. i forget the exact ratios but it is plenty for any pickup or dynamic mic.

    phantom power, no (sorry.)

    audio latency: 1 sample in our DSP modules. this architecture allows unusual level of interaction between analog and digital (e.g. analog saturation in IIR filter loop.) could write code for buffered audio where preferred by algorithm (e.g. streaming from media.)

    controller latency: more variable... applications can specify.

    1khz is default control rate, will increase it if possible.

    much faster rates are feasible if the application is very singleminded.

    note that CV inputs are to the controller, CV outputs are from the DSP.
    for hi-res capture of e.g. waveforms from euro synth, use audio input with attentuation.

  • Cool about the TRS inputs and mic gain!

  • I just wanted to mention, I know that a communication protocol for the Madrona Labs Soundplane was mentioned to be in the works, but I'm so excited by the possibility of using it with the aleph that I just wanted to say I'd be willing to help in whatever way I can to help manifest it. I don't have any programming chops, but maybe I could learn? Or tehn, if there's any other way I might be able to help with that, just let me know.

    Also, I'm curious about the plan of documenting Trent's progress with Aleph programming. I'm also totally inexperienced, but I want to learn to create with the aleph.

    Maybe we could expand the documentation idea into a small group of early adopters who want to contribute to Aleph's growth, but lack the prior knowledge to do so independently? I don't know if that would be useful, but I would really enjoy getting my hands dirty right from the get-go. Basically what i'm saying is, if there's any way for me to be more involved, past just contributing on the forum and trying things out on my own, i'm at a place right now where I could actually do it.

  • so... an example of a module in the modular environment that is bees, would take the input of a footpedal to be used as a tap tempo. and could be used in any and all applications by simply adding/connecting said module to your bees patch or whatever you call it. yes?

  • @yorke:
    I'm very excited about getting my hands dirty too — the plan for my documentation of learning to code with aleph will likely be in the form of some lean blog posting arrangement. i've been talking with brian over the past few days getting my head around how the whole ecosystem works so perhaps i'll get the first post done in the near future. i guess in this way i can share my not-so-official ramblings about what the thing can do and such.

    once the api is ready for jamming i'll get straight to the coding, but i'll try and make sure there's sufficient back-story about bees & the dsp programs before we jump in too far.

    i believe modules are broken down even more simply. tap tempo would be an 'operator' module - that is it takes an input ('taps' patched from a footswitch), and turns those triggers into a time value ('tempo') which is then patched to your desired dsp parameter (eg. delay time).

    this will all be much clearer when bees is ready for a video showing and perhaps some graphics can be drawn up to demonstrate.

  • I always wanted to use a "tap tempo" on a filter cutoff

  • damn I have some surplus cash I was going to spend on a ciat lonbarde plumbutter but the aleph kind of has me dancing around in circles about its open ended nature

    I know I won't pull the trigger without some more info though

    I just love the programming paradigm of the shbobo shnth and even though the aleph is certainly programmed in a differently I think they are of the same ilk. Anything modulating anything a monster of swirling possibilities

  • @wednes pull the trigger!

    curious to see what you'd make with one

  • what scares me is textual programming

    I tried it before fish came out for the shnth and I could wrap my head around that as it just kind of made sense to me.

    then fish came and that just made everything so much easier

    I have also tried processing a long time ago and it didn't quite click
    much more recently I played around with arduino for a little bit and I think I may have been on the cusp of some basic understanding but I moved on

    I need to read through the info that is available but since you can use a usb jack to dongle your way to MIDI is this also possible for DMX?

    controlling lights with something like this would be pretty interesting

    I am caught in the net which I thought I swam free from already

  • "I am caught in the net which I thought I swam free from already"

    ha! profound words & exactly how i feel about the modular world

    regarding fish
    i *think* i recall mention of a similar graphical interface-based program for aleph but i dont think its going to be ready at launch

    beyond that, i'm curious how much can be done with just the unit itself via OLED

  • awesome

  • I second gli,

    I had to watch it twice to catch on to everything that was happening. Life interacting with aleph, and out to CV then some manipulation of audio in from the Roland Synth.

    What kind of case/rack are you using for your modular in the vid? I've been needing to solve that problem for a long time now and that looks interesting.

  • @MCDELTAT - looks like Pittsburgh Modular Cell 90 case.

  • @scanner
    Thanks so much! That was almost as if a deity had called for this! It's only $199 @analoguehaven which is a lot cheaper than Doepfer's cases! I only have 3 modules right now and don't plan to be expanding absolutely right now because I have lot's of other things to pay for. SO this is great, buy one now, if I need to expand, one or two more later...

    Thanks. My modules which are currently being used in a cardboard box will thank you.

  • guys

    based on the scale (compared to aleph and the gs64)
    it actually might be a cell 48

    just got one of them and a few modules

    i had talked myself out eurorack until i found that case

  • @MCDELTAT - just make sure to check the maximum depth. I almost bought one just to realize one of my modules wouldn't fit, thankfully was able to cancel the purchase. Another option is a Tip Top Happy Ending Kit, slightly cheaper but the Cell is enclosed.

    Oh, and cardboard box cases rock :)

  • @a_scanner_darkly + the power consumption...i'm a bit pissed i cant squeeze two lzx modules next to my others even tho i can afford the width :(

  • oh crust you guys this stuff isn't as expensive as I thought. Why did I click that link

    I know I'll still go with ciat lonbarde/ maybe aleph but eurorack stuff isn't too bad