bees tutorials (jan 30: modulation sources)

  • hello folks! i've been working on a series of tutorials to guide a learning process with the aleph. a few have been posted so far and there are many more to come. mostly focussed around the creation of new scenes and getting to know the operators available in a bees network.

    if you have any feedback please let me know what works (and doesn't work) for you, and i'll do my best to take it on board. for now though here's the list:

    0: getting started (modifying params, changing modes)

    1: making a network (adding ops, making connections, saving your scene)

    2: a simple synth (aleph-waves, envelopes, frequency control)

    3: connecting a controller (MIDI keys / monome grid)

    4: modulation building blocks (LFOs, sample and hold, randomness)

    we're working on a number of simple but very useful scenes to share but hope that these tutorials help you on the way to creating your own useful scenes.

  • thanks

  • Hiya, I know I can edit docs - but wanted to check here 1st. In tut2

    connect the SPLIT’s OUTPUTs to the amp PARAMs:

    select 013.SPLIT/OUT1 (ENC0), point to 084.amp0 (ENC3), double-press CONN (SW2).
    select 013.SPLIT/OUT2 (ENC0), point to 083.amp0 (ENC3), double-press CONN (SW2).

    Should this be 083.amp1 for the second parameter?

  • yes well spotted! feel free to fix it, or i'll jump in there shortly.

    it's definitely not the easiest way to represent the data flow (w/ numbers i mean), so i've been drawing some flow diagrams today to better explain the next patches. seems like it could be a good way to explain patches at the moment before the online editor is finished.

  • Cool..edited!

    I was actually thinking to myself as I went through these tuts that if I were to create something even remotely complicated, I would almost definitely have to use some sort of visual flow charting to be able to "visualize" a bees patch but I'm sure like anything else, things will get more and more familiar and intuitive. Is the "online editor" a web app for building bees scenes?

  • the tutorials have been very informative thus far. enjoyable to follow.

    repeating steps & processes is necessary and extremely beneficial.

    it's been helpful to remind myself that while editing INPUTS---ENC1 is a fine control while ENC3 is a coarse control.

  • Where is Bees v0.0.0? I see v0.1.0 and up.

    edit: nevermind use newer versions of bees

  • are the following operators TBD - they're not in the 'proposed' list (the names i've made up):

    MIDIOUT - send MIDI note events to a USB connected device
    DAC - send control output from the CV output jacks
    LED - illuminate monome led
    ARC - receive knob data from a monome arc
    ARCLED - illuminate arc led

    only just completed first tutorial so this question is probably a little premature: how are ENC and SW associated with specific encoders and keys/foot-switches? i'm guessing as you add one of each of these types then the next available one is used, reading left to right as you view the top plate.

    people might find pic below useful (edit cheat sheet):

    working on a template so that you can draw scenes visually - this doesn't generate code!

    [edit - cheat sheet corrected]

    960 x 720 - 28K
  • @c1t1zen: v0.0.0 shipped on the sdcards. I'm guessing zebra wanted to start "officially" in the repository with 0.0.1

  • @knecht
    there are a number of operators that obviously need to be created. while they are pretty key for a number of use cases, ezra is mostly focussed on getting the existing functionality working as flawlessly as possible first.

    regarding the specifics:
    DAC outputs are controlled by the blackfin for a number of reasons, including speed & ability to add smoothing to params without choking up bees. you can send values directly to the DAC already in both waves & lines with the dac0 - dac3 and change slew times with dacSlew0 - dacSlew3. this also infers that there won't be a DAC operator.

    regarding your proposed LED & ARC operators, i believe it will be much more likely to build self-contained button & led combination operators. for example a 'polygome' operator could be made which sends deals with the led handling internally, and provides input values to control it's operation. building a similarly complex SCENE in bees would get very messy so it will make more sense to create these more complex operators.

    finally on switches / encoders, these operators are automatically initialised in the network when you create a new scene. they will be listed as:
    000.ENC: encoder0
    001.ENC: encoder1
    002.ENC: encoder2
    003.ENC: encoder3
    004.SW: key0
    005.SW: key1
    006.SW: key2
    007.SW: key3
    008.SW: footswitch0
    009.SW: footswitch1

    we've spoken about changing 008+9 to say 008.FS to indicate a footswitch, but it's an ugly hack codewise as they are functionally identical (in the same class).

  • i thought the adc0-adc3 and dac0-dac3 in the bfin modules refers to the 4 audio inputs and outputs respectively? actually it has to because otherwise i wouldn't have been able to get the lines module to work ;-)

    knecht is referring to the 4 cv outputs on top. the 4 cv inputs already have an op called ADC.

    also, i guess this is an indication that the naming is confusing. for someone who has been living in firmware land, adc and dac are probably pretty natural nomenclature but i think something like cv_in1-4, cv_out1-4, audio_in1-4, audio_out1-4 would be clearer. And this numbering scheme matches the screen print on the aleph.

  • "we've spoken about changing 008+9 to say 008.FS to indicate a footswitch, but it's an ugly hack codewise as they are functionally identical (in the same class)."

    IMO, this is a poor reason to veto a UI improvement. unless you just mean this is the reason why it hasn't happened yet? ;-)

  • thanks for the reference @knecht.

    i'm also curious about MIDIOUT as my biggest interest in aleph is to enable grid and arc use with hardware minus computer.

  • +1 MIDIOUT grid sequencer/arpeggiator.

  • apologies for my vagueness above. i was also referring to the CV outputs, but i wrote the param names ambiguously. i was referring to:
    which are the CV output jacks on the top of the device. i agree that it is ambiguous to then have the routing nodes marked with 'adc0_dac0' where that 'dac0' actually refers to the first audio output channel.

    (an aside: you can see a full description of each modules i/o here:

    i thought ADC as an operator was sufficiently clear (as it's the only converter attached to bees) but you are correct that i only assume that due to knowing a lot about the architecture. the CV is generally more confusing as the inputs are handled with an operator, but the outputs with a module. would renaming the op to 'CVIN' and the outs to eg. 'cv_out0' be clear enough? trying to avoid underscores in the OP names as it blurs the line between op & module.

    agreed re: switch naming. the 'FS' idea was mine but brian & ezra didn't think it was much of an 'improvement' per se. i'll add it to the list of 'things to discuss'!

    as always - thanks for the feedback!

  • anyway - we're way off topic.
    is there already a 'feature request' thread? would love to know more of your thoughts on the tutorials!

  • oops! this was the tutorial thread! my mistake -- there are just so many aleph threads haha.

    the tutorials 0-2 are godsend btw. in tutorial 3, i have to admit that my eyes glazed over when i saw how much work was required to implement the monome patch. still its a great example but for me it really drives home the need for the ability to save/recall/share sub-patches (not sure what to call them since 'modules' is already taken). that or a more comprehensive GRID operator. all in good time though.

  • Just because it has a 1/4" socket doesn't mean we have to use a 'foot' switch with it right? I like the fact it's just labelled as a switch, keeps the interaction possibilities more open in my head

    (although of course I'm saying this as someone who's waiting on the second Aleph everything is still just a possibility for me :) )

  • @duncan_speakman: good point! i guess i just want some kind of differentiation. there is just so much to remember already. perhaps JSW for Jack Switch?

  • personally i was more confused by the KEYS being referred to as SW

    and, like @duncan_speakman, i'm really curious what else can be plugged in the footswitches...

  • @galapagoose working my way thru the tutes and just amazed at how deep BEES is

    i honestly thought it would be simpler: generic, interchangeable scenes which could be slapped onto any module

    but this far exceeds my imagination

  • @galapagoose - thanks for the feedback.

    i've done your first tutorial - this was good thanks - more to do this evening.

    i think it would be beneficial to have some dedicated threads locked to the top of the forum, or somewhere obvious, for posting on various aspects of aleph - like 'feature request', 'application ideas', 'bugs', etc.

    mentioned this before but it would probably be good to coordinate the developer effort in some way to maximise efficiency - i'm sure there's a lot of potential for reuse within the code.

    can't wait to play again this evening :)

  • @kotdotnot
    yes - the tutorials are a bit complex to do seemingly 'simple' things. in many ways these will become easier as new operators are added. but mostly the tutorials so far are to try and explain how operators work, and describe the workflow of making a scene. unfortunately i think that's led me into some complexity for complexities sake.

    agreed - i have an issue with KEY and SW referring to the same thing. it seems brian has used KEY everywhere, and ezra SW.. will put this on the list to reword in the documentation (most likely all to SW).

    bees certainly is deep, but also the functional blocks are quite simple. in most of the tutorials so far, a lot of operators are used for level-shifting & splitting outputs. i'm hoping we can streamline those processes so they take far less time to build the networks.

    feel free to start an 'aleph: feature request' post. honestly i don't think it needs a sticky as it will hover near the top of the list with new requests.

    regarding developer effort i'm not sure what you mean: coordinate through a forum thread? at the moment i think the group of people actively developing is no more than a handful – it makes sense to me to keep the github issue tracker as the organising location as particular issues / feature requests can be delegated to contributors through that system. am i missing your point?

  • I got through tutorials 0+1 last night and really enjoyed tweaking the sequencer for a few hours after and hopefully recorded some presets. heh, haven't tested reloading them yet today.
    Tutorial 2, I must have screwed up. Was the final sound a drone? I felt let down after the cool sequencer toot. I'm going to redo it before moving on.
    Thanks again for these, The idea of Networking all these features was opening my mind to some cool ideas. I think I do need to draw out the layout like a schematic.

  • i know it will take time...but the more i understand about bees, the more excited i am for the visual editor thats in the works

    it will help my feeble brain keep better track of connections and relationships in these networks (plus i'll be able to cook things up w/o aleph on hand)

  • @galapagoose

    yes - i'm probably getting carried away - i was imagining multiple people working on developing the same operators, scenes and modules - but i guess that's not very likely in the early days of the aleph. the github is absolutely the right focal point for the developer effort and we'll be able to contribute there once we're up to speed.

    will your tutorials be covering module development in the future? i guess ezra and tehn have written the first modules. are there any good resources (books, web) that you can recommend for programming dsps for audio processing? found this earlier - 'the audio programming book' by boulanger and lazzarini - anyone looked at it?

  • i think the first dozen or so tutes will all be focussed on working with the in-built features of bees & ezra's modules. the capabilities of both of these elements will continue to rapidly expand so more and more will be possible as time goes by.

    eventually i'll definitely be covering some 'code-based' tutorials, first starting with making a bees operator, and then perhaps covering making a module (though the latter might be better covered by someone like ezra). at the moment we're focussed on teaching people to use bees as the great majority of users will only have the capability to use the aleph in that capacity.

    obviously we're very excited to have more developers on board to work on bees & modules though, so if that's you please get in touch with ezra (and brian) more directly via irc / email / github.

    i'm super excited about the visual editor too. it will allow ideas to be expressed much more succinctly, and hopefully some kind of 'copy & paste' functionality will follow too for re-useable functional elements.

  • re: grid functionality, agreed that it is intense to make a grid based patch using bees along. i plan on making macro grid-operators, ie. grid-flin, grid-polygome, grid-step, grid-life etc. that accept position/metro/etc and output sensible values. this way tempo/etc can be patched in bees, outputs can be routed to cv or synthesis or whatever.

  • i've plugged my guitar into input 1 (mono jack plug into aleph socket) - gain set high. i'm running through tutorial 1. as far as first connection with switch output set to max. with key 0 released sound in left earphone, with key 0 pressed in right - is this correct? i was expecting muted in both and then on full in both?

    [edit] listening on headphones

  • panic over - output 1 left, output 2 right - headphone picks up off both output 1 and output 2, in the next step of the tute with addition of split - i get audio from both earpieces...was worried for a while that input was stereo and i'd shorted it...

  • are there recommended bees-module-scene versions fro the tutorials?
    have been having success using the recommendations for each individual scene, so wondering.

  • after completing tutorial 3 connecting my qunexus crashes the aleph - this requires aleph to be re-flashed. is qunexus sending some data to the aleph that it can't handle or am i doing something dumb?

    also never appear to be able to scroll to last scene added - if i had one and added a second then can't scroll to second. when third added can't scroll to third but can scroll to first two, etc..

  • i often get weird behavior in the 'scene' directory. when scrolling names disappear, get out of order and characters jumble... in the 'preset' directory at times as well.

  • there's some redrawing issues in teh scenes page that is in the issues list.

    attaching the qunexus crashes the aleph just by being plugged in? what happens when you try to turn it back on and why the need to reflash?

  • yes aleph unresponsive, need to pull power cable. when restarted freezes when loading default scene. have to turn on with mode switch depressed and then reload bees

  • when it freezes at 'loading default scene', hold SW2 while booting.
    this will force bees to 'first run' and re-initialise itself.
    you shouldn't need to reflash bees.

    the bees application is write-protected during run-time so it can't corrupt itself.

  • ok i've completed the first 3 tutorials and while i get the logic of making connections in bees to be pretty straightforward i'm finding the actual implementation to be quite confusing. for example assigning SW3 to act as a volume mute via the MUL operator makes complete sense. however accomplishing this by changing the value of 007.SW/TOG is unintuitive as it requires a couple of extra steps of mental translation ("oh, SW3 is in fact the 7th control after the first 4 encoders which start at number zero followed by the four keys which are called switches here thus the label SW and also start from 0, that makes seven!"). perhaps this will become more intuitive in time but as of now it would seem preferable to refer to the hardware controls more, to change the toggle value of switch 3, you would go to 'SW3/TOG'.. the same for the other controls and parameters. I'm curious whether other folks are struggling with these mappings and if so if might not make sense to adjust the naming scheme to be more descriptive?

  • i think you've got some good points here. i've just been trying to unify all the KEY/SW confusion so everything is just referred to by 'SW' now on the wiki (but unfortunately not so on the documentation that shipped).

    there's definitely challenges in making a logical numbering / reference scheme and for certain there's room to improve. thanks for the critical feedback, and more of the same is appreciated.

  • @meatus yes the scheme of using it is a bit confusing. It sometimes take me a minute to realize ENC3 is really the fourth encoder and so on. The 0-3 scheme was goofing me up more than the labeling within Bees.
    SW makes sense for switch...people with the first batch are going to be using this forum I suspect so I wouldn't worry about wording on the sheet you mailed out with it. Change it on the next batch.
    What is the Footswitch labeled in Bees?

  • @galapgoose - will try SW2 while booting.

    however qunexus is locking the aleph - has anyone else tried plugging one of these in? i'm pretty sure that the qunexus sends out some data when you connect it to something, as i've had issues connecting to my pc where i have to run the qunexus editor software with and without the device connected before it works...maybe i've got a dodgy qunexus or possibly there's a bug in the qunexus firmware? will contact mcmillan again - but would appreciate it if someone with an aleph and qunexus could try seeing if things work ok.

  • @knecht i can test qunexus functionality

    what module + scene were you using? i assume waves with a new scene for cv? or were you trying out midi?

    lemme know so we can pinpoint whether the q is the problem

  • @c1t1zen: footswitches are currently 008.SW and 009.SW

    re: qnexus - is it a class-compliant MIDI device or does it need it's own driver? if it's the later someone will need to make an aleph driver for it. perhaps it uses an FTDI chip? if so perhaps that's crashing the code looking for a grid?

  • @galapagoose

    from the keith mcmillen web site: "QuNexus is class compliant and works natively with any system that supports MIDI. Mac OS, Windows, Linux, iOS, and Android* with no software drivers required. "

    are you saying that even if it's class compliant but if it's using an FTDI chip then it may be confusing the aleph? why should that be significant and is there anything that can be done to overcome this? i wondered whether, despite the class compliancy, the qunexus was sending some data to the aleph when the usb cable is plugged in and this data was confusing the aleph.

    @gli - i completed galapagoose's tutorial 3 and on completion plugged in the qunexus - the qunexus performed its initialization light show and then the aleph was unresponsive. thanks for your help.

    [edit] will check versions of bees and modules i was using and post shortly...

    [edit2] aleph-bees-0.3.2-dbg (for some reason the non-versioned bees file was the debug version), aleph-waves-0.2.0, aleph-lines-0.1.0

  • good to know it's class compliant - shouldn't be any issues getting it to work.

    i don't know how things work internally regarding plugging in a USB device, but thought their might be some kind of code that was expecting a monome device (due to the ftdi stamp) and got stuck. that's a wild guess though. it's just as likely the qnexus doesn't use ftdi.

    is this behaviour reproducable? ie. reboot the aleph and plug it in. does it freeze straight away every time?

  • curious that the qunexus causes a crash. we tested an op-1 in midi mode along with a few other midi devices that are "class compliant" and they worked fine. must look into it.

    ftdi doesn't relate to midi compliance.

  • @galapagoose

    when i tried this last night it repeatedly froze as soon as the qunexus was plugged in - i'll try again later

  • Ohh nice! I like the 'hide' feature of input parameters. I assume that excludes the output data from streaming to the screen? I must've missed that before.

  • @galapagoose: in tutorial2:

    "The simple equation that we’ll use is to multiply the amplitude from SW0 by the state of SW3. if oscillator1 is on (SW3 = 1), then the amplitude will pass as normal. if oscillator1 is off (SW3 = 0) then the amplitude will always equal 0. first we’ll change the routing to send the amp1 PARAM through the MUL:

    Navigate to OUTPUTS (ENC2), select 013.SPLIT/OUT2 (ENC0), point to 014.MUL/A (ENC3), double-press CONN (SW2).

    Then send MUL to the amplitude PARAM:"

    I think the step of using 'DISC' to disconnect the previously set routing may be missing here. Either that or I'm missing something.

    Also, I have not been able to implement the final part of the tutorial where SW3 acts as a toggle to mute one of the oscillators.

  • regarding your first question:
    you don't need to disconnect a routing before changing it to a new value. just turn ENC3 to select the destination and press 'CONN' again. if you change your mind and don't want to alter the routing just scroll away from the param (ENC0) and it will remain at it's previous location.

    2nd q: i'll have a look at that today. obviously the tutorials have been written with whatever was the current version at the time so i'll go through and make any updates / changes required today. will try and get another tutorial written today as well!

  • ahhhh ... the aleph cv is beautiful !

  • those of you yet to try tutorial 3 may find the following diagram useful. note that i created the grid operator in the wrong order; if you follow galapagoose's instructions then 22, 19, 20 & 21 on the diagram should be numbered 19, 20, 21 & 22. the red line is a connection that gets rerouted following the basic grid setup. everything below ENC0 on the diagram is added in the second part of the grid setup in the tutorial, apart from op 13. orange = op which represents an aleph i/o control, green represents a module param, red is for numbers and blue for all other operators. question - why couldn't GRID/VAL have been directly connected to 29.SUB/A? can't see what THRESH is achieving...minor point...

    1101 x 896 - 41K