up early to test - one little bug not initialising the mempools soon enough. That was easily fixed - now it looks good! Onward and upward to arbitrary operator insertion…
1 Like
ok think I have cracked the arbitrary op insertion feature. @Yann_Coppier, @glia (anyone else that’s lurking) if you’re at a loose end over the weekend I’d very much appreciate help testing it to root out any evil bugs. I’ve created a dedicated merge branch combining the new grid-focussed ops with the arbitrary op insertion/deletion branch (which necessitated memory management overhaul).
Appreciate it’s quite a change to some crucial bits of the bees backend for not very much in the way of new features, but (for me at least) only having access the top operator in the list was unbearable!
Anyway here’s the branch with all the new features:
https://github.com/rick-monster/aleph/tree/grid-refactor.merge.net-use-malloc
Hopefully nothing’s broken on there, but if there are problems, a bug report would be much appreciated…
1 Like
Great! -i have made a HIST2 and ROUTE2 operators as well, in order to make simple comparisons of input changes at low CPU cost. Would it make sense to include them as well? I should add I have used those extensively already, and they just work fine.
Kind of curious what @zebra & @tehn think of all these new ops (if they even have time to keep up with the developments!?). I guess there may be some concern about enabling more graphical programming of the device. I share the doubts whether it isn’t better to encourage even non-programmers to hack up useful compound objects in C rather than building kafka-esque bees patches (doing anything useful with the new ops is somewhat mind-bending).
Would be good to maintain a dialogue with the original authors and keep changes within the original vision, rather than forking at this stage. Just to reiterate, my life & grid break scene compatibility for existing users, but releasing the arbitrary insertion/deletion feature with old ops would mean people have the option to remove grid/life from existing scenes, then update to the new version before adding those back in. Of course the new grid op does little ‘out of the box’ which could be confusing for those that were happy with the limitied functionality of original op.
It’s little bother of course to maintain a branch which contains only one’s personal ops, rebasing that on main branch regularly. Totally happy to merge only the updates to memory & op management into bees mainline, (after more testing of course)
i’d say if there’s more than one person interested in an op, go ahead and merge it. these new ones aren’t necessarily outside the original vision-- it’s just that we all acknowledge the limits of the original vision. but it’s still pretty useful and can do some great things!
i’m embarassed to say that i have not really had time to try out these particular changes - haven’t been home much and usually don’t have a grid around.
but from the looks of it (grid_refactor branch and the [other thread] (Aleph - new ZONE operator?)), seems like a reasonable tradeoff, acquire some clunkiness in exchange for much greater flexibility. explicit 1d or 2d memory region is handy for lots of things. i would even consider using a specially named file to load data from the sdcard (text file with one hex value per line, or something)
as far as any “vision” of mine for bees, it mainly consists of the basic operator architecture and especially the preset system (which i still think is powerful and pretty unique.) i’m generally in favor of more modular functionality, but i don’t see a problem with having many operator classes - the only real limit is code size. usability of the op creation menu is also a concern; but the best way to make bees more generally usable would be to provide more sophisticaed patch editing methods (interactive and otherwise.)
anyways, yeah, i’d be in favor of merging upstream and bumping bees revision to 0.8, if the changes are deemed stable.
1 Like
For sure - have to admit I have been guilty of not exploring the musical possibilities of ‘vanilla’ bees/lines/waves enough. I remember @dspk alluding to the huge amount that can be squeezed out of the aleph with the original software and thinking hmmm, maybe I should stop tinkering at some point and spend at least a month or so working with what’s already there.
Still aleph remains more programming project for me than anything else - the disconnect with my own very conservative music-making couldn’t be wider really. I mostly play 50s music on guitar at the moment (or bass on whatever the heck people want me to play), mostly because I start crawling up the walls without regular gigs and those things at least pay for gas money…
Another reason I should spend more time as a user. Although the basic concept & obvious potential power is clear I haven’t explored at all. Hope the op insertion/deletion did not break preset system!
So everything points to now being a good time for me to feature-freeze & heavy test through musical use. Once more feature (just one more) that would be amazing though would be have the default scene fit on the onboard flash memory rather than always need sdcard.
Just to say I am still on it, just didn’t have much time from work these days!
Anyway the preset system is definitely the most powerful feature the Aleph has in my opinion, it is a game changer.
Also, and that is off topic but I spent an afternoon on Grains, and will post some music made with it very soon, using the new GRID and MEM operators.
I can report that arbitrary op insertion/deletion is a HUGE improvement to the menu-diving - after squashing several bugs with the new code, things are starting to look exceedingly promising on that front. Preset system should now be not borked by netlist reshuffling…
However I did see some likely weirdness/bug at some point (not dead sure there’s anything wrong just yet). Reproducible bug report on arbitrary deletion/insertion would be incredibly useful @Yann_Coppier you seem to have a knack for this!
Lost quite a bit of time Sunday failing to set up a whitewhale scene - hadn’t twigged that this op requires an alternating clock signal - I guess the high duration controls length of trigger signals on outputs?
Reading through the code away from the device today I spotted something that looked wrong and pushed this change (before putting two and two together on the trigger-pulsewidth thing…):
https://github.com/rick-monster/aleph/commit/ce158e7ffa60843f428c5ef91327b881201a4f07
Still looks right to me, even though t’was a basic misunderstanding lead me to that bit of the code…
Hello you all,
I am back on the Aleph after a few weeks’ break. Fantastic what I could do today, the arbitrary op insertion and deletion both have worked fine! It’s mostly a matter of getting used to it but this feature does help a LOT !! Only thing I might have found is that insertion and deletion seemed both to disturb some of the presets (and I used a lot there), meaning some elements from the OUTPUT page got removed and were replaced by numbers such as 105, for instance. I just had to set that right and save the corresponding presets, and everything worked fine afterwards. Still, I think it has happened to me beforehand, so I would like to check this a bit more before calling it an official bug. Finally I haven’t tested WW yet, but for the rest it is definitely a keeper.
I did build a rather big scene, and will try it out live tomorrow. More to come soon!
1 Like
I found the output preset bug too. Connections to dsp params in presets get scrambled on op create / delete…
update: hm, maybe not so easy. should have been addressed by these lines:
but, still seeing output->param assignments in presets get pushed around after adding operators.
i’m making some changes now to more cleanly separate DSP params from operator input values, which should avoid the need for all this nonsense in the first place.
2 Likes
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
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!
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.
@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
Will try it tomorrow, thanks!
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!
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…?
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…
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