#52

yikes! It’s a big change - found myself getting pretty mangled when attempted something similar (though admittedly more ambitious). I guess since you actually wrote all the menus & stuff maybe that makes it a somewhat more manageable task!

Did you make any headway on this in last week or so? If so, I could attempt to merge with my changes. If not, should be fairly quick to reproduce this using beekeep/linux I guess, so I might try that instead of ‘fixing’ any of the data structures…

1 Like
#53

That would be fantastic. I did the show by the way, although I had to fix my failing presets a couple of times… Apart from that the whole experience with the Aleph, the arbitrary insert/delete operators function, the real inclusion of the Grid and the new operators is already a bliss, and MUCH more enjoyable than ever before!

#54

ach, i’ve been travelling, there has been progress but not enough to share yet.

thing is, i’m using the aleph to perform every night; it’s a litle scary to be doing deep surgery and reflashing the firmware right before a show (which is usually when i have time.)

but yeah, it’s not really that scary to me to make the necessary changes to menus, etc. what i’m doing is just making the offset between op input indices, and parameter indices, a fixed constant. avoiding lots of unpleasantness when adding operators. the downside is slightly weirder logic in the menus but it;s a good trade.

but it’s really bothering me that the code linked above isn’t doing it’s job though… can’t figure it out.

#55

@zebra, @Yann_Coppier - think this should do it!!!

that passes a minimal test case for the bug - let me know if it plays up when patching more complex scenes…

1 Like
#56

Will try it tomorrow, thanks!

#57

It shouldn’t have worked at all above 16! investigating the bounds checking now - if you want to use large numbers in mem1D in a future release you will have to modify the declaration of MEM_1D_DATA_LENGTH & break scene compatibility… https://github.com/boqs/aleph/issues/2


Not gonna do this right now, purely so we can converge on a stable scene format sooner rather than later…

@Yann_Coppier could you describe the bug more either in this thread or on the github issue? I’m not familiar enough with step to know when it is/isn’t broken - learning all the features of white whale & kria was already a decent amount of work!

#58

It shouldn’t have worked at all above 16!

Interesting… and weird, because it does work. Only thing is, as I wrote the values are not saved correctly.

you will have to modify the declaration of MEM_1D_DATA_LENGTH

I’ll try that in order to see how things work out this way, thanks.

could you describe the bug more either in this thread

Sure. When saved and reloaded, none of the 4 lower lines on the 128 get lit. They actually work more or less correctly, but you have to activate them manually (by lighting them all up once, then shutting them down again) before you get to see them. Then the 4 upper lines show the right movements and positions, but with all the buttons before the starting one lit until you also manually shut them. Difficult to explain in a better way, maybe a video would help? Anyway it is mostly visual bugs so far.

Also, while we are here am I the only one who noticed that the RANDOM operator seems to use some weird seed? For instance, if I want to use it between min 0 and max 15, all the results oscillate between 4 values (1, 2, 13 and 14 if I remember correctly). Pretty annoying in most of the scenes where I use it, but maybe it is just me…?

#59

yes there was an incredibly dumb typo in bounds check - fixed now on boqs/dev.

don’t try it directly on the skektek branch - behaviour could be unpredictable. The bug that’s allowing you to write above index 15 could easily lead to overwriting even the data inside other operators!!! If you want to quickly expand the mem1d limit on skektek nonrelease snapshot - you could copy the whole of mem1d & mem2d (both .c & .h) from boqs/dev into your working copy, then mess with _DATA_LENGTH.

Quick code inspection - easiest way to do this is to directly pickle the led buffer, which would be a scene-breaking change… I’ll dig a bit more, see if I can write a function to ‘refresh’ the LEDs from the rest of the op state…

#60

i’m looking at it know… it’s a simple LCPRNG, i think the parameters are copied from a noise generator on aleph. i’d say the seed, params and algo are OK - not crypto-quality but fine for (most) music purposes

the problem is how the random output is mapped to an arbitrary range, this line:
[ https://github.com/monome/aleph/blob/dev/apps/bees/src/ops/op_random.c#L74 ]

it takes a modulo of the LCG output, so effectively uses the least-significant bits; only the last 4 bits in the case you describe. these bits by themselves are decidedly not random - the have obvious cycles as you’ve observed.

a better way would be to take as many bits as are needed starting with the highest.

a still better and more expensive way would be to cast the full output range to float, rescale to the requested range, and cast back to sint16.

the “best” way (in terms of getting a really random distribution) would be to just keep rerolling until you “happen” to get something in the range you requested. of course this won’t work for a realtime application!

oh, and maybe we should have a SEED input anyway… repeatable randomness!

(tagging @tehn just cause it looks like he authored this op. which is not to say that it wasn’t my mistake.)

thanks for pointing it out

#61

I was actually thinking about a SEED input, which would be very nice indeed. Thanks for the clear answer!

#62

this bugged me too last time I used RAND - quick hack using BEES/pd to debug - boom!


the obvious deficiency of the approach ezra described is that if you desire a range which is not a power of 2 & bitshift to the smallest power of 2 greater than that number, subsequent application of the modulo operator will tend to skew the distribution toward the lower end of the desired range.

Therefore I’m shifting the 32 bit number right by 25 - bitwidth(range) (as opposed to 32 - bitwidth(range)) before applying modulo. I think this will tend to reduce of skew by a factor of ~ 2^7 for most numbers.
(and there’s nothing special about 7 I picked it… randomly!)

added that feature - again pd/BEES helped me catch a dumb typo using gdb…

#63

I just tried to compile using the corrected STEP operator but got a bug in line 105. Will get back to it later, right now I have to try a lot of stuff. You are on a roll!

#64

Ok I might have made a mistake, but after compiling the Aleph freezes each time I trigger a RANDOM operator. Also, can’t see any SEED input there. What did I do wrong, I wonder?

#65

I just made new midi program change operator - now my behringer fcb1010 can talk to grains! Totally horrible FM guitar sounds & silly pitch-bend guitar pedal fun…

sounds like it didn’t work, could be any of a number of things depending on what codebase you’re starting from… I’ve lost track of what features from skektek & boqs have/haven’t been merged.

Working towards testing all my recent changes enough for a merge into monome/dev then I think it’s time for release 0.8.0 !!!

3 Likes
#66

Yes, you are most likely right! Also, I just tried to add one operator in the middle of a scene that uses two presets and still got an issue… but this time it is something like a mix of the two presets appearing, with the elements included in both presets appearing on top of each other. Anyway I’ll wait until 0.8.0 to say more unless you have a whole version I can compile and test now, mostly because I suspect my mashup to be quite a mess right now! Oh, and fantastic with the new op, I just saw it a few minutes ago!

#67

I’ve just raised a pull-request from the aleph boqs/dev branch into monome/dev. If you can manage to get a clean checkout of boqs/dev & test a bit from that, it’d be super-helpful towards the 0.8.0 release!

1 Like
#68

Ok, I had to download separately the libavr32 content, without which I couldn’t compile. Done now, will begin testing!

#69

hey yeah, did you get libavr32 from monome’s github or boqs? boqs aleph dev branch should be built against the boqs dev branch of libavr32:

alternatively you can do the git submodule song & dance:

git submodule init
git submodule update

those commands (when executed from a fresh checkout of boqs/aleph/dev) should grab the appropriate version of libavr32

1 Like
#70

Thanks, I now have incorporated this version.
Then my first test with RANDOM has shown a bug, as can be witnessed in this scene: Random_test1.scn (256.1 KB)

The tempo of the RANDOM triggers is fixed, and you get 3 BIGNUM on the screen.
ENC0 (0-15) is changing RAND/MIN (result on the upper left BIGNUM).
ENC2 (0-15) is changing RAND/MAX (result on the upper right BIGNUM).
The lower BIGNUM shows the results from RAND/VAL.

It seems to be working fine, except you can’t ever access the upper limit, so that if you choose MIN=0 and MAX=1 you will only get 0, for instance. And if you use MIN = MAX then the values triggered explode and go from 0 to 140 or something like that, although MIN and MAX are still equal on the INPUT page.

Some more to come soon!

#71

bug easily reproduced & fixed, posted to boqs/dev. Thanks!

2 Likes