Visual feedback

  • Hello guys,

    I have just been building a nice scene that takes advantage of the BARS operator. It does give some great visual feedback to what's going on, and then it led me to two questions:
    1/ could it be possible to have more than 4 lines appearing on the screen? 8 would be great, for instance. Or to have a choice with the number, for instance?
    2/ while using BARS I noticed the BIGNUM only flashes. It can still be used, but it is clearly competing with BARS. I just thought it'd be great to have both at the same time, as BARS kills any other visual.

    I know I know, everybody has a lot on their hands. But hopefully I'll finish this first scene very soon and will send it so you can test it and see why it would be so cool. I also have a lot of videos to upload from concerts I played with the Aleph, and it'll come soon.
    All the best to you all, this forum is a blessing.
    Yann

  • anxious to see this. thanks for the heads up. i have not tried to use that as i am still learning my way around the UI.

  • Thanks companyofquail. I am getting ready now with the scene, and will film myself using it this weekend hopefully before posting it. Quite chaotic for the moment but I am slowly getting there. Some things have been very annoying though: the BIGNUM operators disappear each time I reload a scene, even though I am using an operator to re-enable them each time I touch a knob - had to dedicate a button to make them appear, which is quite useless as I want them sytematically in here.

    Same thing with the MIDI CC operators, the CC number gets back to 0 each time I reload a scene... I found a parade to that one by including it in the presets, but still it is annoying and might end up NOT using the MIDI ribbon I wanted to use here because of that: too complicated if you want to make sure it works every time you set it up. Worse with my external Kurzweil triple arpeggiator, which I planned on using with the Aleph: as I can't get to send any MIDI note out (see another thread) it has become useless for now.

    Ah yes, another one: once I start working with the presets somehow the menu disappears on the Preset page, and never comes back until I shut the Aleph and boot it again. The buttons still function, but the menu doesn't appear. Anybody has had this issue so far?

    I wonder if I missed some points, but anyway... The scene is getting somehow really cool though, and also quite funny to use - you'll see!

    Will send it next week : )

  • Nice! Thanks for the update. Interested to see this.

  • there's some sorting out to be done with the display operators-- combinations of multiple ops could be implemented a little cleaner regarding refreshing.

    8 bars, not a bad idea.

    looking forward to seeing the results!

  • i will look into the midi note out.

  • Great Brian, thanks. Actually the other thing that will be needed the most is to be able to use a delta function with the knobs, so it becomes possible to modify their function by pressing a button for instance, without loosing the original value in the meantime... The patch is out now, I am creating a new post for it.

  • Oh damn, who cares about a new post, here it is:
    http://monome.org/docs/aleph:bees:sharing:slidrone
    Still a bit messy but I'll be cleaning the patch very soon. Some functions to add, along with the grid. It's mostly ready but I need some time to do it. Hope you enjoy it, any feedback is welcome!

  • Splendid. This is going straight into my live setup.

  • Thanks man, nice to hear. I have used it already for live purposes and it worked incredibly well I must say. Working on a new improved version right now!

  • By the way if you have any remarks on how to improve the patch please share, I am already quite far from the original version but could always make it better. Thanks in advance.

    Here are my ideas:
    - SW0 switches from osc0 & osc1, to osc0 alone, or osc1 alone (a delta function within the encoders would make it soooo much perfect there),
    - SW1 is changing the resolution of each encoder,
    - SW2 is switching from phase mod & wave mod, to phase mod alone, or wave mod alone,
    - SW3 still keeps the Slide/Freeze function plus will change the behavior of ENC3,
    - ENC0 is modifying wave0 & wave 1, or wave 0 alone, or wave 1 alone (SW0),
    - ENC1 is modifying wave mod & phase mod, or wave mod alone, or phase mod alone (SW2),
    and can also work on 01 & 10, or 01 alone, or 10 alone (SW0),
    - ENC2 is modifying cut0 & cut1, or cut0 alone, or cut1 alone (SW0),
    - ENC3 modifies the acceleration/slow down/reverse of osc0 &osc1, or osc0 alone, or osc1 alone (SW0) in Slide mode (SW3). It modifies tune0 & tune1, or tune 0 alone, or tune1 alone (SW0) in Freeze mode,
    - The grid should be used to add some changeable upper and lower limits to the two sliding oscillators (although I am thinking of using my ribbon for that), and add some different LFOs for the movements. First only one at a time, and hopefully soon some combinations (what about saw down, and each time the OSC reaches the lower limit it goes to a random point and goes into saw up on a very short and fast scale?). Here it would make sense to be able to reflect the BARS operator on the grid, wouldn't it?
    - Also, I haven't used the pedals yet and although I thought of them to change the filter resonance I now am considering this: using a pedal for the Slide/Freeze function, and keeping SW3 for 3 different resonances. How about that? I'll still have one pedal left, which could be used for the LFOs so I'd keep the grid only for the upper and lower limits in Slide mode, which could become a regular pitch in Freeze mode (it'll have to modify the BARS placement then).

    Any other idea?

    Seems to me that this makes much more sense. The whole point is to make it into a reasonable patch, and I am making rather extensive use of the presets for that - such a great feature! I am getting used to working with them, and although it tends to make a written patch messy on the paper, it becomes insanely efficient once put into the Aleph!
    Also, even if it could easily become messy, the corresponding preset names will appear briefly each time you press a switch, so you should always know where you are. By the way, they always appear twice (on Switch on, then on Switch off). Any idea on how to make it only once, although it's no big deal?

    I am finally also cleaning the patch A LOT. Way better now, and I have found a way to deal with the BIGNUM enable function which is satisfying for the moment. I'll send some videos soon.

  • hmmm I just reached a limit with 71 operators and an ok-working-but-still-messy patch. The Aleph won't take anymore apparently, so I looked at my programmation and it seems I can at least save 12 operators (I'll start by removing most useless BIGNUMs and rely more on the BARS and my ears), maybe more. I wasn't expecting this but it's somehow cool.

    One question though for Brian or Ezra, do presets consume a lot of memory as well or is it safe to say that using them extensively will save memory? Also, I suppose some operators consume more than others, as I could add a last SPLIT although the Aleph wouldn't accept a SPLIT4, is that right?

  • i think the restriction is actually on the number of input & output nodes, rather than the number of operators themselves – hence LIST16 uses a lot more memory space than LIST2.

    the main cause of the limitation is actually because of the preset system – every single input value/param & output routing is remembered within all 32 presets (just mostly inactive). so the best way to add functionality to a complex patch is with extensive preset use – the memory requirement is all inherently there, and the cpu overhead is tiny to use them.

    i think the reasoning behind this is to encourage the preset system to be seen as a dedicated input layer and quite integral to a performance system, rather than just a 'state-saver' tacked on.

  • Thanks a lot for these explanations, I'll sure keep this in mind from now on.
    Edit - I indeed have made a new test version, topped at 61 operators and can still add 20 simple ones at least. Now I can hopefully go for some extra LFO and those lower/upper limits on the grid... well, if I can manage of course!

  • very curious about grid functionality. I have a 256 and would love to use it.

    I have been enjoying the freeze function a lot. I tend to slide for just an instant and go back to freeze. The results are drastic but amazing. It allows me to start a whole new sequence/track by just changing some percussion loops. Will certainly test that out live next month.

    don't hold back on sharing your updates as it seems you've caught the bug and are even cleaning everything up.

    once again, thanks!

  • Well thanks, glad to hear you enjoy it! I must say I have been pretty amazed at how sweet the Aleph sounds live - I'll send a video tomorrow. Also, I'll test the new version for a while before bringing it out here again, but it seems like I'll be able to implement all of the functions I described earlier. Last step: how to bring in the grid with only 3 operators (only the first 4 rows though)! I now only have to put up some extra LFO in there, and once I am done I'll clean up again to remove some of the less useful functions and - who knows - add some sequencing on the lower rows.

  • Or preset recall?

  • So I ran into a funny problem: using the GRID with a ROUTE operator, in which the rows will give the "TO" and the columns will give the "VAL", I found out that no matter what you do the columns will come first (because they are placed before the rows) and will fuck up the results once each time you change row. Then I found that a DELAY with time=1 on the columns is enough to set everything in order. Nice!

    And RdF: good idea, the scene will become clearer. Thanks.