there's a delta bubbling

  • oooh, just seen this appear in the aleph github via @zebra - exciting! :) - multi destination encoders here we come !


    +static const char* op_enc_instring = "MIN\0 MAX\0 STEP\0 VAL\0 ";
    +static const char* op_enc_outstring = "VAL\0 DELTA\0 ";

  • please create something beautiful with this, duncan :-)
    i am definitely planning to use one or more of you scenes at a live give early november. something new and crazy would be nice, although i have more than enough from your toolkit to play around with.
    personally, still not doing aleph patching myself as i am waiting/hoping for the visual editor soon.
    thanks for sharing all of your great work so far!

  • interesting...i never really look at github since i dont grasp much

    looks like a few months ago this was posted in the monome_arc op code

    static const char* op_marc_instring = "FOCUS\0 ";
    static const char* op_marc_outstring = "NUM\0 DELTA\0 "

  • just to add on to what @myecholalia said and to extend it a bit to a lament/rant:
    good to see that some things are kind of happening just when I get closer to selling my alpeh, ... Last major bee update has been in June, I think.
    Now there is a lot of noise about the modules but not much happening with the aleph aside from a few guys who deliver really great patches and also tutorials.
    To dig in myself, I'd really hoped for the visual editor, also the programming tutorials would still be interesting... I'd love to contribute but at the moment I do not know where to start.

  • sure a visual editor would help, but just print the op list, grab a pen and paper and get patching :)

    ps multi destination encoders are VERY welcome

  • Looking at all the bug fixes on the git thread lately I'm glad I didn't try to manual patch with this last version. I'm also waiting for the visual editor!
    Till then I have the euro modules for instant monome action without the weird hangs or bugs.

  • @alph, et al

    i'm sorry, we thought we would have outside help making a visual editor for BEES patches. it's a lot of work to do this. now i am doing it myself. this cuts into my time for maintain the bees and DSP codebases and providing standalones or other templates for more people to get into working on the aleph C code.

    to give you an idea of how the dev workload has been spread, here are the contribution stats since release ('catfact' is me)
    https://github.com/tehn/aleph/graphs/contributors

    i had to take a break for a while this summer/fall to work on making a living and other things. i'll continue to add things to aleph for the foreseeable future. i'm deeply invested in it as a device for my own musical use. but you have to understand that most new request for changes or additions to the existing software, or for new things like a host-based GUI, pushes other things down the list. things that still only exist in my head. this basically means more DSP modules, and radically imroved performance/features/interfaces for existing modules.

    brian, trent and i are currently working hard on getting BEES into what we consider a working 'beta' state, with a good degree of reliably and all the features we promised*. at the same time we are trying to work on more development documentation, because it is absolutely imperative to have more contributors if the aleph environment is to fulfill its potential.

    the upcoming bees 0.6.0 release will have some new operators for HID and serial control, some requested tweaks to existing operators, lots of minor UI tweaks, and some performance improvements. after this i will personally stop looking at bees (maybe forever, since i only intended it as a "proof of concept") and move on down my list, starting with releasing other control-side apps and making more progress on the editor.

    thanks for your understanding

    - ezra b

    * edit: well, nearly all the features. USB hub support on avr32 proved to be incredibly difficult. LUFA still doesn't have it so we're in good company there. i'm still convinced i could figure it, given enough time... ha ;)

  • from my perspective I'm with @analogue01 in that i'm perfectly happy programming bees from the screen without a visual interface (i have a fat notebook of scene sketches) and much more interested in -
    " this basically means more DSP modules, and radically improved performance/features/interfaces for existing modules." which would be sad to see pushed down the list for the sake of connecting lines on my computer screen :)

  • well, i've heard both opinions quite a bit.

    it seems clear that a friendlier way to edit patches on the computer would make a lot of people happy.

    so i will try and get together a very simple way to do this. it won't be dragging and drawing like max, but should make the patching process go a lot faster. maybe it can be fancified by interested parties in future.

  • thanks for your tireless work ezra!
    cant wait for the updates in 0.6.0 and all the future control apps

    i know that some of the ideas (beyond bees) have been discussed in the past but i cant recall if anybody asked this

    1. will onboard patching be the same or will we make connections in a different manner?
    2. is the editor you're working on bees-centric or will it be capable of use with any aleph apps?

  • working on an editor for bees patches (.scn files and .json equivalents).

    it will not be too far from the menu system, but will show a lot more stuff at once and be clickable.

    other apps will still need to be written in C; hoping to finish up the demo tonight. :D ~0)|

    i promise to make more DSP modules soon, i also care more about this than any other aspect of the system right now.

  • thanks for your tireless work ezra! i patiently await what's coming :)

    as for a visual editor - it would definitely speed up the process and i mostly look forward to it so i can patch when the aleph isn't around, but not having it isn't really a roadblock for working with bees

  • (delighted emoji)

  • Sounds cool Ezra. Always looking forward to what you build and add to the Aleph.

    I wish in an ideal world Monome would hire a UX/GUI programmer. That's just such a specific set of skills separate of programming DSP. I'm in the camp of...I'm to old to stare at the tiny screens anymore than absolutely necessary.

  • yes, i wish we *could* as well!

  • I'm really looking forward to the bug fixes, DSP improvements and documentation! less looking forward to a laptop GUI but I'm sure that will be cool too. when the dev how-to's are complete I also look forward to adding at least some sort of useful contribution to the Aleph codebase, to complement the awesome work of Ezra, Brian, Trent et al.

  • I'll take whatever updates you add - I could see that the visual patching aspect could be a lot of work without any new functionality.

    Quick question on the planned features for 0.6.0 - would a basic Arc operator be included / possible with the HID and serial updates? I could see this having a pretty good coding effort to awesomeness ratio, but perhaps is not as high on everyone else's list...

  • @miketodd nope...arc ops are high on want list too

    i'm waiting on the dev tutorials and thats my # 1 priority unless somebody (monome team?) beats me to it.

    it might be difficult but i'll give it a shot

  • but i agree, i cant wait till @zebra has time to focus on what HE wanted most including the spectral/analysis modules

  • re: arc

    there are several layers of relevant code:

    1) driver layer
    ( aleph/avr32_lib/src/monome.h , .c )
    this includes routines for exchanging data with arc.
    it also posts a connection event to the app when a device is plugged,
    and this event data includes the device type.
    so, this part is done, as far as i can tell.


    2) bees monome device management layer.
    ( aleph/apps/bees/src/net_monome.c , .h )
    ( aleph/apps/bees/src/handlers.c )
    this needs to be extended very slightly.
    it has a default loopback connection for arcs,
    which i'm pretty sure is tested and works,
    but it's a little too dumb to differentiate between device types.
    (on connection / op focus.)
    i just added some FIXME notes to the relevant sources.
    it's not a hard task.


    3) bees operators.
    there is not an arc operator.

    i haven't done the relevant work in 2) and 3) because i don't have an arc to test with.

    i really don't think it's difficult.

    i wold be happy to blindly add the stuff and have someone else test it, but probably better for brian to do it if he has the time.

  • yeah i might be out of my depth on this

    if you bulldoze thru i could test it but might be best to just wait a bit more until tehn gets to it

  • i'm doing it now

  • you = amazing @zebra

    will test this weekend