aleph: feature requests

  • Don't have any at the moment, but It seemed to me like this thread was needed so that other threads can stay on topic.

  • pasting from other thread:

    1) add hub support to USB host stack

    2) extend the sort of "monome daemon" layer in bees to know about multiple devices.

  • and would hub support include multiple midi devices as well?

  • ∞+1) Lazers!

  • yep that would be a prerequisite unless you use a midi merge device

  • i don't have an aleph. i'm really interested however.

    could aleph possibly run some of the wizard mutable instruments braids oscillator voices? that would be amaze.

    https://github.com/pichenettes/eurorack/tree/master/braids

    http://mutable-instruments.net/modules/braids/specifications

    code is all open source, running on an arm processor.

  • yes, that is doable though it represents a fair amount of work.

  • No doubt :)

  • alt + encoders for octave steps?!

  • Was just staring at my Arc 2, and got to wondering if it might be useful to have an operator for Arcs that could basically just extend the Aleph's encoders to ENC4-6 or ENC4-8

  • @Test2 - that's an interesting idea. you can already do this with a couple operators in PLAY mode, but are you thinking it would be useful in EDIT mode too? i'm pretty much always modulating the hz parameters on waves but perhaps you have a different use case.

    i can see the same kind of idea working well though especially applied to CV outs for 1V increments and other such things. please elaborate how you'd like to see it implemented, and then we can see if ezra thinks is possible! haha..

  • I´m thinking play mode and pitch cv first of all, but edit mode too (sometime the line is blurred…) or just switching to a faster or finer parameter mode.

  • todays song:


    (just kidding)

    knob sensitivitiy:
    so, there are the coarse/fine knobs on inputs page. right now these are simply "accelerated / unaccelerated." but it could easily be a customized behavior. each param type has a custom increment function and hz param types are linear in pitch domain. alt+val could multiply the coarse/fine controls by 3072/256 for octave/semitone.

    arc operators: on their way, i believe... really hoping for someone to attack that hub support thing so i don't have to.

  • i'm guessing there will be common arrangements of operators (composite operators, i guess) that will crop up across scenes - is there any way we would add a feature to create an operator that wraps a common pattern and allows this to be re-used and shared...without having to write code? so the facility to save and recall composite operators

  • @knecht
    i get the feeling this is something that will exist in the online editor but seems awfully difficult to communicate on the device itself. it's nice to be able to see the whole network in a pretty flat way when you're navigating a small oled w/ encoders i think.

    i'm super into the idea though — a lot of the new tutorial that's been posted would make sense in this 'composite operator' context.

  • alt+val, is that to be understood as using a held down key will modify encoder behavior?

  • could not make my arc4 with push buttons work with aleph(the leds flashed ones). are arcs generally not supported yet or is it just the push button version?

  • not yet supported - there should be a simple operator for the arcs finished quite soon.

  • great, thanks.

  • arc support is forthcoming but it's not quite the top of the list, it'll be a few weeks but expect many other additions to keep you busy.

  • thanks brian, the future looks mighty bright.

  • ^ you gotta wear shades.

  • split4, list12 (for twelve tone scales)

    is there a difference between ADD and SUB, seems like the B parameter can be both a pos or neg number?!

  • twelve tone scales? i've been using list8 to build traditional 7tone western scales, but also been exploring 8tones and different intonations.

    of course it is possible to use 2 list8s to do up to 16, but would be a little simpler with a list8.

    agreed that ADD and SUB are pretty much identical. i guess it's more just from a conceptual standpoint that it's nice to have both.

  • this is a sort of silly thing to point out, but if you didn't have SUB you would need an extra multiply to take the difference of two positive values. (like, maybe two adjacent outputs of HISTORY, to track deviations...)

  • hahaha of course! it makes a whole lot more sense when you think about sending it messages to the B input rather than just setting it to a given value...

  • @dadek , yes that's what it means. for example, ALT+ENC0 on the INPUTS page is currently used to select a different preset. hold down ALT and turn ENC0 to see preset name (plus contents for visible inputs), release ALT to perform a preset recall + selection.

  • preset tutorial on the way. i used this a bunch tonight and it's super powerful and fun!!

  • @galapagoose yeah, 12 was maybe a little to specific, but longer lists yes!

  • dynamic/linked list operator

  • is it worth saying that I would LOVE a version of Parc on the Aleph? it's become such a core tool in my writing at the moment.
    Still waiting for the second batch so haven't had a chance to get my hands dirty yet, but looking at the tutorials and current grid support is seems that making Parc in bees would be an almighty task! so an operator of sorts would be a beautiful thing... (especially thinking about how it could send out CV and other parameter control to modules)

  • agreed, i'd like to explore some parc-like monome patching on the aleph.

  • encoder 'listen input' to sync the encoder position to the current value; for instance a step value in a list.

    floating point arithmetic

  • I'd really like an FM synth module. I'd like to build it myself though I'm in the "not-a-programmer" camp of Aleph users - a total beginner in that area (at least, at the moment) - so I'd need a whole mess of help to do it. If someone with the expertise would like to build it, then that would be really great...

  • 'waves' is an fm synth module. It's labelled pm for phase modulation but it is the same thing.

  • Thanks for clearing that up, Ezra. I was reading about "Waves" ("FM modulation is implemented as phase modulation") and thinking about FM and wasn't quite sure about how it all hangs together. When I get my Aleph and put the module through its paces, I'll get a clearer idea of things.

  • I think encoder some kind of automapping would be useful for simple applications.

    I don't know how "floating point arithmetic" would  apply to bees network, which operates on signed 16-bit values. Of course developers are free to use float math calls, though they are slow in avr32.

    I did think that a "ratio" would be convenient, just combining a mul and div.

  • @5StarNomad :
    i guess i should further clarify and correct myself: PM and FM are not exactly the same thing under all circumstances. PM effectively highpass-filters the modulating input, as far as perceivable change goes. in some cases this is a "good" thing (when you want things to stay "in tune") and sometimes it might not allow the effect you want (a very slow, rhythmic pitch change perhaps.)

    changing the PM input (modulator contributes to current phase of carrier) into FM input (modulator contributes to instantaneous frequency of carrier) is actually a pretty simple hack to aleph/dsp/osc.c , and might make a good early exercise in synth programming on the aleph. amplitude modulation would be similarly simple to add.

    we will have more synthesis algorithms developed and ported soon. the timeframe of this depends on how many people start working on it! :D

  • Thanks, Ezra for that clarification. I like the idea of an early exercise in synth programming and more synthesis algorithms. I'm very much a beginner at any kind of programming right now and one of my many uses of Aleph is to learn that side of things and realise my ideas for synths etc Changing the PM input into FM input, as you describe, is definitely on my todo list (a list I'm sure is amazingly large for you!)

  • not sure where to post this

    currently trying to wrap my head around an app for rotary looping
    i think it should be possible with lines but i'm still brainstorming how i want the interface to work

  • @gli: Some background or a reference to what rotatry looping is may help spark some discussion

  • @eos thought of the idea after seeing the arc

    i wanted an app that was based on samples and allowed for intuitive control of loops...similar to the way "inner loops" work in MLR but with encoders rather than buttons







  • (edit) op lpf/hpf, op mixer, op wavplayer, op cv-out, op audio in/out...

  • those are DSP components, and are built into the modules. the operator network works on control rate only, ~1ms.

    for example, both modules expose parameters for cv-out value and slew time. lines has fully-routable input and output and so can function as a mixer. (waves is getting it momentarily, i'm in the midst of a heavy optimization pass on it - also more modulation options and hopefully more voices.) both have multi-mode and arbitrarily mixable state variable filters (lp/hp/band/notch.)

    filling audio RAM from sdcard is totally doable, there is some architecture in place for modules to declare fillable buffers to the controller for use as wavetables, sample manipulation source, etc. but i am waiting for more help on completing that.

    putting audio signals directly into the control network is neither feasible nor meaningful. however, there is a mechanism in place for BEES to poll the DSP for parameter values, which could be used for feeding back e.g. input amplitude envelope, or zero-crossing count, into the control net.

  • I have some understanding about the architecture, I'm just thinking aloud here, what about an op that is running dsp in the background? as an example from the user perspective I could add an op called LPF which has an input and output, cutoff mod input, fb input and so on, so visually I have an op but in reality some of its functions are DSP, would that be possible?! bees feels like a modular system already, it's just a few modules from being complete! I would be fine if some connections between the DSP and BEES are not allowed, and you can always use the physical i/o too! I think a more open architecture would make it easier to create cool stuff.

  • ah ok, i get what you're saying! it's a good idea, i'm not sure how easy it would be do accomodate without major changes.

    so to paraphrase, if i understand: you would have operators whose inputs and outputs represent bus points in the DSP module. when a connection is made, the operator would kind of go behind the scenes and make the appropriate parameter change.

    a couple issues with this:

    - it would require that all modules that support it have these same parameters laid out in the same location in the param list. this is probably a good idea anyways though!

    - more problematic: the BEES network is structured rather simply. inputs and ouputs really do represent memory locations where values are sent and received. all the logic that manages connections simply handles them as such. operators are not "aware" of what they connect with. such "awareness" could be added with lots of new logic and glue.

    in other words, the action of "making a connection" would have to execute some logic rather than simply change an index in a routing matrix, and has to assume some things about the structure of the running DSP param list.

    - this could all get real hairy when you think of the relevant parameters and connections coming under preset control.

    [ i really think the preset system is actually what makes the bees+dsp structure powerful and unique, its worth getting into that layer of stuff and trying to think of of patch structure in those terms! so a "mixer setting" can be a preset that affects only mix/routing parameters. ]

    -------

    in a bigger sense, of course it is good to think about different ways to approach the DSP+control architecture. there's no reason it has to be this way; DSP could be fully modular, and the controller could send a graph definition + control changes, more like SuperCollider; or the controller could even compile graphs into bytecode and send that.

    but this is all a lot of work down the road, and quickly becomes a totally different project rather than a feature-extension of BEES and the current modules. i am certainly interested in these things though!

  • also as part of optimization, currently thinking of different/better ways to handle routing. running a whole bunch of arbitrary mix points is expensive. having on/off "patch cables" that are summed, would be much more efficient.

  • also @Test2 , looking earlier in the thread, i don't know how a dynamic / LL op would work.

    the main limitations of operators:
    - each has a fixed number of ins and outs
    - they can send and receive only signed 16-bit integers (though these could be interpreted with a different radix if you want to get weird.)
    - each has a fixed amount of memory to work with.

    within those limitations, i'm quite open to suggestions! you could have a dynamic list that was limited to a given number of elements, and was maybe kind of clunky to work with (because editing commands are just integers send to various inputs.)

  • how about swapping of ops? (apologies if i missed an existing issue in the queue) for instance, I have a whole patch put together but at some point I realize I don't want a TOG I want an ACCUM and it's sandwiched in the middle of 40 ops.