aleph.

  • i do think it'd be a great thing to see people selling/publishing little hardware kits that took advantage of the ii port. once the protocol is wrapped up i'm hoping there will be aleph-independent ii devices that people can use.

  • @dimi3 , why the vitriol? Brian and I, the makers of aleph, will never attempt to charge users for firmware. That would be insane.

    But to answer the question: no, we will not legally prevent people from doing whatever they want with their hardware, including attempting to develop paid software, however crazy such a plans seems. Monome is not apple or Nintendo and the aleph doesnt ship with a EULA.

    As far as the licensing of our own code, it will certainly be free for noncommercial use and were still on the fence about commercial use. I'd be curious to hear from any open source devs about their thoughts on GPL vs MIT etc. But maybe on a new thread as this one's getting too long to read on my phone.

  • ah, to clarify, yes, monome will never sell aleph firmwares. that is crazy.

  • memories... that old thread was super wacky... and I definitely helped with the flame war.

    Personally I am really interested in trying to write a faust -> aleph compiler... for more info on faust check out http://faust.grame.fr/

    This kind of approach would allow people to run a vast amount of dsp code written by academics and scientists on the device.

    @zebra I've worked on a project where they offered both gpl and mit and allowed users to pick the license they wanted to use.

    The idea of custom hardware is super exciting to me, I foresee some group buys in the future to make cool custom new devices rather than cheap clones!

  • @thealphanerd group buy is an awesome idea for developers

    @karaokaze raja you crack me up man ;)

  • oooh, that faust project/idea sounds really great!

  • @karaokaze i'm imagining an experimental novel using your years of forum posts...

  • @thealphanerd - i echo dadek's comment, faust compiler for aleph is a great idea

  • @thealphanerd - certainly faust support is on the table. i've mentioned this in the thread. faust is brilliant. but it assumes a floating-point architecture so that is a hurdle. looking forward to a talk someday with the guys at CCRMA who maintain it, the addition of a fixed-point layer to their architecture descriptions would be cool for many reasons.

    cool, i didn't know dual-licensing was an option

  • Inane pedantry. Aren't the device and host slots labelled the wrong way round? Or more likely I've got confused.

  • i want to put my 2c on the commercial-firmware debate a little clearer.

    monome sells hardware to two users, A and B. A makes some software and offers to sell it. B says fuck yeah, your software is awesome, i would love to give you $5.

    monome has no legal or, IMO, ethical right to prevent this commercial relationship from happening. if we wanted to we would have to force everyone who buys an aleph to sign a contract saying they will only ever run free software on it. this is obviously fucked up, right?

    none of this means that we think selling closed binaries for aleph would be cool. it would not be very cool. i would publicly mock the person trying to do this and i don't think they would profit by it. and depending on our final choice of firmware licensing, if their binary incorporates our source code without attribution, it would be illegal (not that anyone would ever know.)

    but the perspective @kotdotnot articulates is relevant. embedded DSP programming is skilled and time-consuming labor and i see nothing wrong with someone who's making useful software being compensated through donations. a donation system is only as good as the generosity of users.

    i don't want to name names yet but there are some extremely accomplished people who will be contributing code for the aleph when we get more units made. i would very much like to see these people appreciated for their efforts, and monetary appreciation is unambiguously welcome.

    anyways we can cross that bridge when we get there.

    all that said, i don't think making good-sounding synths/reverbs/whatever is really all that arcane or difficult in this day and age, with all the educational resources and freely-licensed code that is available. in any case, i know how to do a couple of things, and i happen to have all these friends who are way smarter than me, so i think it will work out just fine.

  • @karaokaze ++1 for the comte de lautreamont...'only a few may savor the bitter fruit without danger'...

  • one of my favourites too

  • @zebra I agree with your last post. Donations are a good way and paid tools through you guys with a cert. Would be a great protection. The following, which I wrote before reading this last article:

    This is not an easy black and white Q&A, and sorry if I sound black... I can could and have argued but side of the topic.

    I think, as excited soon to be user, and since the device hasn't even shipped, I am stuck on the term firmware. Also, I have spent a lot of time with the OP-1 and Elektron devices. These two things make me bock at charging. I don't mean to be bitter. A well designed and built piece of software is certainly worth money, to someone. @tehn said it, support... But if the user base is small and neat things come out sure I probably buy it.

    To return a question, if there is low level coding done, a pay for amazing reverb tool, one installs it and the DSP bricks, would you warranty it?

    Firmware upgrade which make some portion of the system work better, seems a bit strange to pay for. You refactor you code so latency goes down more bandwidth and less overhead for tools, that takes a while and thinking. As a programmer that is a great cost to you, but it is sort of unfair to charge users for that. Now to add totally new functionality depends, but Teenage Engineering and Elektron spoiled me...

  • @dimi i already said we wouldn't be charging for firmwares. this seems to be your concern, i'd let it go.

    what we're talking about is third parties developing for the aleph and charging. ie, if teenage engineering made an aleph firmware, and charged for it, what our position is on this. of course they can charge for it.

    but the stuff we (monome) makes, will be free.

  • @tehn I was completely confused, and the comment was to explain my "vitriol" state, and when doing so, I miss read the first line as a question and I totally read it backwards. I am not sure why, but I seem to always be half getting posts correct meaning. Must be my ADD and ESL shining through!

    Glad we all agree.

  • @tehn @zebra we getting close to a "bees" preview? aside from all the custom app development... I'm excited to see the "out of box" power that the building blocks Ez has been working on is going to provide... with no additional coding required. ...maybe I'm just lazy. :)

  • @tehn is % developing the editor?

    also, what are the advantages of having a "browser based" system?


    @mrdave1981 i'm wondering the same + prepared to be pleasantly surprised

  • eta 2 weeks to bees vid.

    our goal is to have flexibility (building blocks) without programming. the focus on programming has been overemphasized.

    advantage to the browser based system is operating system independence. tentatively portable sunsets is working on the editor. likely more people will be involved. also the editor will be slightly behind the ship date, we're aiming to do it right, and we're looking to have a fully-capable editor inside the unit itself.

  • "operating system independence"
    i thought so and consider it to be a wise choice

    thanks for clarification

  • @zevbra

    Faust is actually a project out of Gramme, not ccrma. Althought there are a lot of cheerleaders / contributors at ccrma. The best person to talk to about it would be Yann Orley. While the faust compiler is assuming that the compiled path is a floating point system, you would be surprised how many of their algorithms rely on integer arithmetic. This is actually the reason they were having trouble with their Faust -> Web audio compiler.

    Overall I think it would be a really interesting challenge.

  • Sure, I know it didn't come from Stanford, but here we are in California. Anyways thanks for the contact.

    The problem with interesting challenges is that there are an infinite number of them. It would also be cool to port peter blasser's shlisp opcodes, or make our own language.

    I just don't have time to do these things as the groundwork is already an interesting challenge. I am still learning the nuances of blackfin ASM and working on our basic DSP pallette. I did spend a decent amount of time with the Faust sources, and there are a lot of difficulties there actually. It would not be trivial to make it fast.

    But I think I will be able to provide help for any ambitious porting projects anyone wants to take on, maybe as a school thing...

  • Any time frame for the release of some initial documentation? For instance, Bees syntax?
    Is the plan to finish a core set of docs before releasing anything? or will stuff start trickling in?

    I suppose the more stuff that lives on github might be best for community collab in regards to Aleph? I often wonder what the grid/arc app landscape might have looked like if from the very beginning things were able to be managed with something like GIT.

  • a shlisp port would be so sick

    even if @zebra doesnt...i hope somebody will tackle that

  • Yeah, one of the most exciting things about Aleph for me is integration with shnth. I'm trying to imagine what a shlisp port to Aleph would look like though, and it kinda doesn't make sense to port shlisp itself, how would you build shnth patches on Aleph? I see something more along the lines of a patch browser so you could store patches on SD and upload them from Aleph to shnth. But maybe I'm not thinking big enough and there are some more exciting possibilities there.

    Maybe some new shlisp operators that would be Aleph specific? But I guess bees would just support shnth directly at some point so you can assign any gesture on shnth to anything else. Squishable samplers!!!

    [and shnth and 64 are like perfect buddies, even form factor wise...]

  • honestly there's a lot of work that needs to go into documentation at this point. it'd be counterproductive (and kill a lot of time) releasing anything early. three weeks at the earliest for initial documentation.

    the first production parts have arrived (nothing too exciting, but something), and all of the purchase orders are out. pcb's and physical stuff getting made. everything is slated for mid-late november delivery, but my most rational self knows that something will get delayed and we'll be shipping first week of december. i'll make another post about this somewhere.

  • no, that just means i've requested that the pcb, assembly, and metal manufacturers all "go" and make the parts-- a promise that we'll pay them.

    we still have about 40 of the 100 units unsold for this batch.

  • @gli I saw on Modulargrid you have some small racks that you are building out for possible use with the Aleph. what types of goals are you looking to address? o'jones would be great for analysis of CV signals... gieskes jumped out as an interesting addition.

    I like the way you are going...

  • @mrdave1981 thank you

    modulargrid has been an invaluable resource for me. after ordering aleph i spent a few days brainstorming control schemes with items i already had. none of my gear had cv ins or outs

    once i found a small case, my first goal was to get a few modules that would mesh with aleph's abilities. i was primarily looking for things that offer control / observation of the audio & cv waves produced by aleph (and the rest of my setup).

    it is not built for visuals, but while bored i've spent the past month figuring out ways to use aleph as a hybrid av hub...which led me to gijs and his wide range of unique synths & fx

    so aleph and euro will be intertwined for varied intuitive control, observation of waves, and creating (or warping) visuals




  • @gli that sounds very intriguing as I am also thinking about ways to best integrate aleph with my modular. Just went to modular grid but could not find your racks with a quick search. Any pointers? Would love to have a look for inspiration. Thanks!

  • @myecholalia i didnt expect anyone to notice my page and am, admittedly, a complete noob

    you can probably get better direction/ideas/advice from guys like mapmap, mudlogger, oootini, a scanner darkly or the myriad other guys with modular experience and knowledge

    since you asked politely i will share: http://modulargrid.net/e/racks/view/52380
    the no-drums are imaginary, i have everything else installed and tested

    after trying this stuff with the aleph i will determine how best to fill the remaining 16hp

  • @tehn/zebra

    Have you guys discussed the subject of MIDI/CV -- CV/MIDI conversion much? I could be completely wrong but if that's fairly trivial programming wise, it seems like a super useful function that would be used often as part of an aleph program. Apologies if this has already been discussed.

  • Not an expert by any means but I'd be happy to help with any modular questions. We should probably start a separate thread for that though? We can discuss interesting setups to use with Aleph and then talk about different ways to integrate it once it arrives.

    I would say that having a specific purpose in mind for it will help, especially with a smaller setup. Part of the "problem" is that Aleph is so open ended, so it's hard to think what would compliment it best.

    I'd say if I was building something small and specifically for use with Aleph I'd go with one of the following:
    - sound processing that would compliment Aleph, filters, tubes (Metasonix etc)
    - a monosynth (lots of cool oscillators in Euro)
    - a drum synth, using Aleph as a sequencer, and should be easy to create an app that would do plocks on top of sequencer, MachineDrum style
    - alternative controller, touch plates, joysticks etc or interesting modulation sources
    - sampler on mushrooms, something built around Tyme Sefari or Phonogene.

  • question: are the cv inputs and outputs capable of accepting/receiving long lasting dc voltages? LFOs, wiggling dc offseted signals and the like?

    if not, then I guess you would want to consider these in a system to complement aleph.

  • cv takes dc certainly.

    i'm sure we'll be looking into 1v/oct cv operations, re: midi-cv. big list!

  • Out of curiosity... anyone know if Aleph will be compatible with all monome models (64, 128, 256)? Both videos have highlighted a 64 so I thought I'd check. Would be nice if bees allowed for grid size configuration.

  • @mrdave1981 the details page indicates that compatibility with "monome devices" is a priority

    but a video with the other models would be nice...


    also i wonder how the built-in encoders compare to the feel/function of arcs (led feedback aside)

  • aleph will work with all monome devices.

    the encoders feel super nice. they're different to the arc encoders but that's probably more to do with the much smaller diameter silicon knobs. the oled does pretty well at giving feedback for what the knobs are doing but there's definitely not the direct led feedback of an arc.

    presently working on ways for the arcs to integrate with the aleph as well!

  • @galapagoose cool! I imagine assigning extra Aleph param encoders to an Arc would be a pretty obvious use case?

  • it would be cool to see some vocal processing thru aleph + arc



  • I'm still not ready to order mine (totaled my car in a collision, have to buy a new one and my insurance is about to skyrocket), but the plan once I get there is vocal processing thru aleph + soundplane.

  • @GTZ sorry to hear about the accident + glad youre ok...i grazed a deer a few weeks ago but the damage was minimal



  • @gli to you or the deer? :)

  • @oootini lol . remarkably both :)

    i saw him
    he saw me
    and we both hurriedly applied the brakes

    if it were an old cartoon
    stars wouldve circled our heads as we stumbled away from each other


    (missing deer has been a daily occurrence for years cause my house is tucked away in a pocket of woods. thru sheer luck and cautious driving i'd somehow never clipped one until now)

    i felt bad for him tho...maybe he collapsed after making it back into the forest :(