While playing with the SCREEN operator I noticed three bugs:
1/ If I set an encoder with a negative value and send it to X, the values below 0 are wrapped to the right of the screen. Nothing like this when X is set above 127 though, and not problem of this kind on the Y axis.
2/ When Y is set to 0 (or below, which should be the same), movements on the X axis will not show, as if we were below 0 when I’d expect Y to be locked at 0. At 127, no problem.
3/ I made a visual “granular” patch, meaning I create a cloud around my X and Y coordinates. Same issues as above, except at some point when I put Y to 0 (or below, as there is a cloud around) the screen will freeze and I’ll have to unplug the Aleph. At 63, again no problem, and no problem of this kind on the X axis.
In all cases there are some issues there, I also tried to put limits myself in my programmation (which is stupid as they are included in the object, right) but that’s adding a lot of objects and I will eventually get to freeze anyway. Brian, Ezra or someone else, any idea where that might come from?
Nobody? I’ll post a small video of the scene I am working on (the granular patch, which is not granulating audio here but could, if adapted to the Lines module), so you get an idea of what I am talking about. It is looking great and is very cool to play with, except it will always freeze when you get close to Y=0.
So here is my “granular” synthetic patch.
In here you can see the problems: I am making a visual cloud (the brightness of the dots defines the filtering, but I don’t think it can be seen or heard this way), which is here translated into notes, very simple. When I go to the left edge the grains are appearing to the right when they shouldn’t, and when I go to the top everything freezes. Sorry about the bad quality, my camera was out of battery and I didn’t have any time to redo it… Still, I guess it’s enough to understand the issue
i absolutely believe you that there are bugs in SCREEN
the op was really quickly thrown in there on impulse and you are probably the first person to really put it to use. (lovely stuff by the way.)
and indeed, it seems to be missing a lower bounds check. the upper bound is clamped:
so, add the lower bounds version to clamp that too. or to make it wrap in both directions add, e.g.
while (x > OP_SCREEN_X_MAX) { x -= (OP_SCREEN_X_MAX+1); }
while (x < 0) { x += (OP_SCREEN_X_MAX+1); }
i’m not so sure about the freeze. if it’s only when one of the coordinates goes <0 then i’d just fix that. it looks like it would have totally unpredictable outcomes with negative input.
i think this op was tossed together at some far-distant point when the op inputs were unipolar.
I corrected it following your indications Ezra, and it seems to work perfectly now - no bugs so far. Where should I put the new op_screen.c and op_screen.h so they can be included in a future release?
In all cases thank you very much for your precious indications!
this can be a confusing process though if you’re new to git and/or github. i’d recommend getting comfortable with it if you want to make changes in the future; otherwise for this one simple change i can just add it.
i’m curious: did you go with clamping or wrapping? what do you think is more useful?
I went for clamping, much more interesting visually. Also, it makes more sense sound-wise. And if it’s ok with you Ezra, I would appreciate your help on this one. How do we do it? By the way I have made other operator modifications, like Route16 and Bars8 as well (pretty nice, this last one, as it is separated in two times 4 smaller bars, so that you can still have two Bignum on top without covering it) and wouldn’t mind sharing them if other people are interested as well.
