Aleph - new ZONE operator?

Monome
1

Hello Aleph users,

After working a bit with Grains, I stumbled again into one really annoying thing, which I almost forgot after being used to it a bit too much I must say: the GRID object is really not functional, as it takes the 128 (or 64) as a whole with no ability to separate parts, it has no feedback from the Aleph (meaning it sends info but doesn’t receive any), its MONO feature doesn’t really work (it is very much possible to lit several buttons at the same time), etc.

Therefore I have been dreaming of an object that would be called ZONE, which would allow this:
for instance, I am putting a fader from row 0 to 0 (it is horizontal), and from column 0 to 6. There can only be one button lit at a time there, but it won’t have any impact on the rest of the grid. Eventually I can also make the button behave like a fader, meaning the value goes from A to B with a certain duration, if need be (would be nice to interrupt the fade by removing the finger from the target button at any time, by the way). Then I can place a single button at coordinates 0/15 (row 0 to 0, col 15 to 15), and finally a whole zone for the rest (row 1 to 7, column 0 to 15).

So far I tend to use GRID/TOG with a value of 1, and GRID/MONO with a value of 0, then I have to press a button to unlit it before pressing another one otherwise I get lost very fast. Not very musical, if you see what I mean.

Anyway I can’t make that object myself, which is why I decided to create that thread - in case some of you guys would be interested. In my idea there would be 7 inputs, for something like:
ZONE/Focus (0 or 1)
ZONE/RowMin (0 to 7)
ZONE/RowMax (0 to 7)
ZONE/ColMin (0 to 15)
ZONE/ColMax (0 to 15)
ZONE/Fade (0 or 1)
ZONE/Duration (0 to 16, for instance)

And one output only:
ZONE/NUM (defined by the size of the zone/fader/button, with the idea that the count goes from upper left to lower right)

Also, if the resources appear to be crucial (and they usually are on the Aleph), there could be a specific object for buttons:

BUTTON, with 3 inputs: ROW (0 to 7), COL (0 to 15) and TOG (0 or 1), plus one output: VAL (0 or 1).

And of course, it would be nice if there was some feedback, meaning the buttons could be lit from the Aleph. Then one could easily create a fader from this by using the FADE operator (then we could remove 2 inputs on the Zone object?)

Another suggestion: make the buttons on a GRID have a specific number each, from 0 to 127. With feedback from the Aleph it will become much easier to make interesting scenes.

Let me know what you think, and if anybody is interested in helping with this. Any other suggestion appreciated, thanks for reading!

2

Hmm so my own grid is a brand new toy - unfortunately got ripped off buying a second hand kit with some major issues so trying to fix that up has eaten up most of my hacking time this week. Luckily I have access to excellent soldering station & tools at work so looks as if the grid is eventually gonna be ok even though the original owner did their level best to wreck the pcb…

Anyway sitting down with the aleph briefly this evening I saw you appear to be correct the grid op as it stands appears to display state of previous button presses on the LEDs, not arbitrary bees values. Would be awesome to open up the behaviour a bit more.

Here @zebra suggests (amongst other things) refactoring grid:


I’ll tackle the bare grid operator as described there tomorrow evening or Saturday. That seems to be a manageable weekend hack, and should allow decent patch-matrix control with a clever bees-patch.

Your suggestion to offload zone-ing into the op is interesting though! Having said that I’d be tempted to go for something more like:

Inputs:

Zone/RowMin (0-15)
Zone/RowMax (0-15)
Zone/ColMin (0-15)
Zone/ColMax (0-15)
Zone/Row (0-15)
Zone/Col (0-15)
Zone/LEDState (0-15)

Outputs
Zone/Row (0-15)
Zone/Col (0-15)
Zone/ButtonState (0-1)

3

Nice! Still, I don’t really get the point of having as inputs Zone/RowMin, Zone/RowMax AND Zone/Row… Same with the Zone/Col part, doesn’t that just make two inputs too much?
Also Zone/Focus would present the advantage of letting the user switch zone with presets, for instance… although it is probably a luxury, considering the size it would take in a Bees patch.
Then I can see now that the fade part would just be super easy as we have the objects for it already. Same with blinking, etc. so the rest is fine with me, an dthe addition of the LEDState is of course VERY welcome!

Now about the Outputs, my idea of giving defined numbers to buttons depending on the size of the zone has a lot to do with the maximum possible patch size in any Aleph scene: the limit depends on the total number of inputs and outputs in the operators you are using… So I’d say one less is always cool. Also, on a whole grid you could make a 128-steps sequence super fast this way, just using a single Metro and an Accum instead of finding whatever system to go to the beginning of the next line. Just trying to simplify it, although it might only make sense to me. Still, what you are describing suits me fine anyway!

4

the idea is to have rowmin,rowmax,colmin,colmax as the delimiters for a particular zone in the grid, whereas row & col are the coords within zone, then LEDstate bangs set the brightness of LED indexed at row,col (in zone coords). Going to ignore focus for now - can’t visualise the whole thing at the moment better just get something cooking maybe I tear it all to bits later - some of the discussion of eurorack module ports is going over my head & this is kind of tied to that in some sense…

5

I get it - and it sounds fine, really!

6

ok so with the following new bees ops:

  • iter (bangs a value n times, outputting n, then val each time, and finally bangs done)
  • mem2D (allows to write/read/toggle location in a 2D memory)
  • mem1D (allows to write/read/toggle location in a 1D memory)

plus a rewrite of both grid & life ops it is possible to implement the following patches:

  • patch-matrix one-per-row
  • patch-matrix one-per-col
  • 7x16 2D step sequencer (7-sound percussion sequencing) as patch
  • 7x16 1D step sequencer (7-pitch monophonic sequencing) as patch
  • 7x16 2D step sequencer based on life grid (steps run async to life grid, reading cols on life grid)
  • Block-fill & flash 2D regions on grid

I think the patches would be a bit neater/better with the addition of another op, called numbang (number-bang)

you input any number, it outputs a rising-edge-bang (1 on first output), input number on second output, another rising-edge-bang (1 on third output).

Without this operator I find myself using split & random to express the idea ‘whenever a number comes in, send 1 on output A followed by the number on output B’ - hardly intuitive! The other option would be to add a separate trigger output to to the memory elements, which I don’t like…

EDIT:

Pushing this further, I realised the patches mentioned above were not quite right. I add the mem0D operator (read/write/toggle just a number), then make extensive use of split4 to control the trigger-order of event-sequences. Still exploring bees patching techniques with visually fun examples such as a fancier 8x16 step-sequencer with ‘wiper’ animation.

1 Like
7

This sounds great, but could a one-per-row patch-matrix superimpose on a Grid object? Or will we have to necessarily use, for instance, 8 or 16 operators to fill up a 128 (depending if we go horizontal or vertical)? Also, I have been thinking of a kind of Uzi object (as found in Max) for quite a while, so I am very much positive here. Let me know if you want me to do some testing, anytime!

8

hmm I never used max - looks like my ‘invention’ of ITER op fills the same function as uzi. Feel free to grab the code off my feature branch here, compile & try out. but back up your precious scenes first - as it stands scene compatibility with the ‘old’ grid/life ops is broken. Usual paranoid disclaimer/caveats about as-yet-untested code definitely applies here!

Kind of waiting to hear what the other developers think about taking bees in this direction before expending more effort…

EDIT:
Also can only use one simultaneous instance of mem1D/mem2D/life. Not sure whether possible to allocate at instantiation time with malloc - haven’t tried yet…

9

I will actually try this, sorry for the late reaction. I can see ITER there, as well as MEM0D, MEM1D and MEM2D. Sounds like fun, talk soon…

1 Like
10

yeah i noticed them yesterday

need to rewrap my head around what they do as i was only half paying attention before (since i didnt have a grid)

11

Hello there!

Soooo I have tried the whole, and some things I got and some I didn’t get…
Therefore I have a few questions, hope you can address them!

1/ ITER works fine. I realized that in order to have it send its bangs you just need to send its value again. No question here really, I think it’ll be useful.

2/ Your version of GRID is definitely interesting, but also a bit confusing for me yet. I understand I need to use MEM0D, MEM1D or MEM2D to make it work correctly, right? Anyway without those I have X and Y, to place any coordinates (they should definitely be limited to 0-15 and 0-7 then), a Value and then ON (0 or 1) as Inputs. Fine, although there is no other way to clear a button (or an entire grid) than to go on each coordinate and give them a Value of 0, or an ON=0 signal. Right? And with ON=0, if I set a Value of 15 I can still lit a button, which is a bit confusing as to why we should need the ON feature at all. Then as Outputs I have X, Y and BUT (for button, which gives a value of 0 or 1, no Toggle possibility). These give the Aleph the coordinates pressed on the Grid, which is great.

3/ Then comes the MEM operators, and that’s where I am not totally sure:
If I use MEM0D to lit a button using a TOG operator along with the GRID, then I can toggle on/off that button. If I move to any other button then I get this annoying thing which works once out of two, but I suppose it’s not the point. Right? For the rest (MEM1D and MEM2D) I get really confused, I can see they work the same as MEM0D with just one coordinate or two added and I do understand I am supposed to send some of the GRID outputs in those and then send them back to the GRID to some extent (I can draw an exclusive line on the GRID like this with MEM1D, but that’s it). Could you explain a bit more about how you would use it, with maybe just one example?

Finally as one remark, I now understand that if I am correct you can only use one instance of MEM0D, MEM1D or MEM2D at a time, which means the rest of the GRID becomes useless… that also is not so clear at this stage.

Oh and by the way - what is PARAM?

Anyway this does look very promising, and I would really like to try and use it soon!
All the best,

12

ok so now I found a way to use MEM2D, like this:

GRID/X -> MEM2D/X
GRID/Y -> MEM2D/Y
GRID/BUT -> SPLIT
SPLIT/X -> MEM2D/TOG
SPLIT/Y -> MEM2D/READ
MEM2D/X -> GRID/X
MEM2D/Y -> GRID/Y
MEM2D/VAL -> GRID/ON

This way I get a pretty reliable Grid with a toggle on each button, which I can manipulate from the grid itself or from the Aleph (although when I do so the grid fails at following fast movements). Still, that is quite limited so far so I am curious about how you see the whole thing!

Last edit for now: when I send coordinates from the Aleph into MEM2D/X I noticed the buttons in column 0 never lights up, for some reason. Any idea why?

13

So hopefully I’ve addressed all the tricky questions about the new ops below. But also bear in mind I do think this stuff is only useful if we have the arbitrary op deletion. That requires addressing the memory management issues (see my other posts on major bees overhaul) My head was exploding after a day or two with these new primitives and no arbitrary op deletion (not in a mind-blown way just in ‘a bored of unpicking everything for the zillionth time’ way)

umm no I would’ve expected that to work - would have to make some test on the device…

It does nothing useful ‘out of the box’ - I think you realised already that it’s just lights and buttons…

It enables querying module parameters - there’s an analysis-only module on my dev branch (maybe got merged to main aleph repo) that detects pitch & envelopes to demonstrate how this operator can be used to query the blackfin from bees…

you can combine two iter operators to clear a zone on the grid - row iter bangs column iter, which bangs the grid lights.

just a shortcut because brightness=15 is the most commonly useful setting… right!?

correct - that’s a bug not a feature - needs some malloc magic or something. I just used global variables for prototyping then pull-requested the change hoping to stimulate this kind of detailed discussion & get a sense if other people like this direction for bees. Memory fragmentation & other issues associated with this kind of allocation led me towards a very ambitious & as-yet-unfinished bees refactor.

Not so! For example I had patches that built a step sequencer in left half of grid with new primitives, whilst running life in right half of the grid. But yes point taken the MEM operators shouldn’t be using global variables it’s just for prototyping and trying out this new way to do things…

14

ok that all makes sense. Now I managed to make the buttons from a single line on the Grid lit up when I press them (using MEM1D), with 5 operators. I then tried to do the same with one single button lit at all times on a single line, but that took me 11 operators… and I still have a buggy feature (the buttons can still be toggled off in some way). I guess it’s all about finding the right procedure, as simple as possible. Then I also tried to limit the size of my line, with two THRESH operators, but added to the rest it became way too complicated for the simple thing I wanted to achieve: one specific segment in the Grid with one and only button lit at all times.

I am sending the last scene I made. This is for line 2 of the 128 Grid, and it is a bit messy, sorry! gridsplit_1.scn (256.1 KB)
Hope it is useful, thanks for reading.

1 Like
15

I think there is some sublety to toggling - it’s possible you have to bang it with a non-zero number. Can’t remember exactly - kind of a shortcut that lets button-presses only register on push, not on release. Or maybe it’s the other way round (toggle will bang on zero).

I can’t remember exactly and not with the device right now so I can’t check. But iirc I found the existing bang-behaviour across the existing bees operators to be a little lacking in logical consistency. So I tweaked these new guys till it allowed me to create my test-scenes (which I haven’t released anywhere). You could dig into source code to find out more!

First order of business for bees should be arbitrary op deletion IMO. That is the only thing about BEES that I really dislike from usability point of view - internal representation of a net is more of a code quality issue and/or matter of personal taste (though I don’t see a way to display outputs on play screen without fundamental changes under the hood)…

The more I think about it, maybe it’s possible to fix bees’ memory management issues and achieve the arbitrary op deletion without totally breaking everything and turning into an unmanageable rewrite.

16

I do understand your concern about arbitrary deletion of operators. I have been working with paper ever since I found about this… I see it as a kind of meditation now, but I would be soooo happy if it got solved.

Anyway back to your operators: I have now found how to have one and only button per line constantly lit on a 128 grid, how to send to and receive from the Aleph, and even how to make a somehow split scene (equivalent to the small one I built for grains): for instance 8 lines with one and only button lit per line on 15 columns. The last column is let to toggle individual buttons. I used 15 operators on the whole and it works!!! This is really great, and although I should say it is not so intuitive (took me some time to figure it out) I have to say it really is great. Next step will be about the varibright features!

Again thanks for this one, things are moving and it is a pleasure.

EDIT: still one thing I see as a bug though: GRID is sending X and Y (which could be called COL and ROW, so we don’t get too confused with the SPLIT operators?) twice each time: once when you press, and a second time when you release each button. What’s the point? I mean, for the scenes I am trying to put up it just basically sends everything twice, and it forces me to put some CHANGE and TOG operators a bit everywhere, which uses a lot of resources… Is that something that could be fixed?

1 Like
17

[quote=“Yann_Coppier, post:16, topic:2510”]
arbitrary deletion of operators
[/quote]I meant to ask yesterday but forgot since I wanted to search the forum first

after searching I saw nothing that made it clear…what is the issue? is it a bug that prevents deletion? or something else?

18

I tried to implement this feature then @Yann_Coppier helped me discover that there are bugs with some of the key operators after my changes - see this thread on lines Aleph Testers Corner & this github issue.
https://github.com/tehn/aleph/issues/174

So what then happened was I got over-ambitious and took on way too big a refactor shortly before burning out & picking up an even crazier project - the picolisp interpreter. Well actually I made much better progress on picolisp - think I can test my first lisp program tonight - an etchasketch using encoder callbacks & screen-twiddling functions from last night.

EDIT: Picolisp etchasketch program kind of working now - next step hook picolisp up to the blackfin params - exciting!!!

Looking back at bees with a bit of emotional distance I think it will be possible to fix the 7 broken operators on my arbitrary-op-deletion branch:
https://github.com/rick-monster/aleph/tree/arbitrary-op-deletion
there must be some cheeky hack/workaround to get this working without picking the whole program to bits…

1 Like
19

Aso @yann_coppier if you are not already tired of all the testing, then I also made some changes on the grid-refactor branch. It would break scene compatibility with the last version but if it works correctly, now each instance of mem2d/mem1d/mem0d would have it’s own memory, and that should get stored in the scene memory. So you should get those patterns back after reboot. Could even add a mem3d operator so you can use presets to choose between 16 2D patterns that are stored…

I agree about the X/Y point - just changed that and pushed to my github. However I think transmitting button release message is a feature, not a bug! this is how the buttons on the aleph work, so it needs to be consistent…

20

Sure but why send release info on X AND Y AND BUT (so 3 times) ? The button part should be enough, right? And about the testing of course I will go for it, no problem - but once I get back from work !