#1

Continuing the discussion from Monome modular firmware on aleph:

Awesome thanks a lot I will try to track down what is going on in that case when I have time with the device.

Just to reiterate off-topic stuff from the other thread this refers to testing for the following pull-request:

Aleph - new ZONE operator?
#2

ok thanks again @Yann_Coppier for spotting that one. Looking into the code it seems there is a reason that particular op would be expected to blow up - it stores pointers to the memory area which weā€™re shuffling around. Thereā€™s a comment in the source code there suggesting this will lead to problems! So gonna try & refactor that op to use alloc/free on init/de-init weā€™ll see if it that stops it blowing upā€¦

#3

I should add that I could reproduce the bug every single time, as soon as the operators were pointing at each other in the OUTPUT page. Then when I just create operators and randomly delete them, it seems like it works most of the time - although it has been freezing once or twice that way as well, but not in a way I could reproduce clearly.

#4

ok so thanks for the testing results @yann_coppier. Donā€™t worry for now providing any more information about bugs/weird behaviour resulting from this change - we canā€™t merge this change into bees sorry!

My conclusion now is that a much more brutal code refactor required in order to make this feature possible:


When that code emerges there will be plenty more testing to do but for now Iā€™m thinking first to shift my focus to help the guys merge modular with aleph codebaseā€¦

#5

Sounds wise. Happy to help anytime, thanks for trying this!

#6

umm yeah the wisdom of this refactoring is starting to seem debatable bffffffpfffghā€¦

#7

hey hey @Yann_Coppier or @glia are you with the device at the moment? Iā€™m at the office but on standby just in case the other guys here need software support. So itā€™s hacking time!!!

If someone sitting with their aleph can get on the case right this minute - I just pushed a commit to https://github.com/rick-monster/aleph/tree/arbitrary-op-deletion with an attempt to make arbitrary op deletion not blow up the screen operator. If someone can report back whether that fixed the crash on arbitrary op deletion of an operator below screen operator in netlist I can try to do the same with the other 6 buggy operatorsā€¦

#8

ack

just dozing off after a teletype session and had flashed prgm on aleph to test when i wake up

i gotta re read how to compile this and try in the morning (which will likely be too late for you)

#9

bah no donā€™t worry I think the fix wonā€™t work anyway - itā€™s a little more subtleā€¦
EDIT: no - think Iā€™ve got it licked. Home time now and time to test!!!

1 Like
#10

Great, Iā€™ll try later today :slight_smile:
Have you seen my post about the new GRID object by the way?
I made a scene for Grains that works perfectly, just would need a small fix on the operator (or another way of using it?) in order to make it efficient. I could make a series of empty scenes, just with different GRID configurations afterwards thenā€¦ and of course share.

#11

yes I was happy to see this different way of using bees with grid is not too strange! Anyway I have to finish the arbitrary op deletion (though am with the device now and thereā€™s still something wrong)ā€¦

#12

Not strange, but definitely not intuitive - Iā€™d be happy to contribute with a tutorial showing various ways of using it once it all works fineā€¦ been wanting this so badly for such a long time so again thanks! And as said before Iā€™ll be happily trying the op deletion later today.

#13

screen op is totally not working after the change to its memory management. I got a rush of enthusiasm/excitement for some reason but itā€™s going to be a struggle getting this feature finishedā€¦

UPDATE: working now to try and fix op_screenā€™s memory management so it plays nice with arbitrary op deletion - some kind of progress I think. Now I can delete the op under op_screen without blowing things up, but deleting op_screen crashes hard, even when itā€™s at top of stack. This oneā€™s a humdinger of a fiddly bug. I wonder if this has something to do with the fact that op_screen is special in that it has 0 outputsā€¦

1 Like
#14

[quote=ā€œrick_monster, post:13, topic:2578ā€]
screen is special in that it has 0 outputsā€¦
[/quote]can we change this without breaking the op?

#15

Hacking the ops themselves to cope with a bug in op removal code just spreads the rot further really - didnā€™t fancy that solutionā€¦

The hypothesis about 0 outputs turns out to be correct & Iā€™ve got a kludge in the op_removal code that seems to be working!!! So I can add/delete op_screen, or add op_screen on top of op_add, then delete op_add and everything keeps on trucking!!! Hurrrah!

kind of donā€™t care why the kludge is needed, since I view the whole underlying representation of bees net as somewhat dysfunctional. As long as the hacks to cope with the insanity donā€™t escape from the parts that would be re-written to restore order Iā€™m a happy camper. Anyone fancies testing code for me? So all ops should now work on latest arbitrary op deletion branch including screen but excluding:

  • bars
  • bars8
  • bignum
  • mout_cc
  • mout_note
  • serial
    Maybe even some of those might be fixed now (but thatā€™s wishful thinking really). If anyone can do some testing while I sleep that would be beyond awesome!!! (code not pushed yet)
    UPDATE code pushed to https://github.com/rick-monster/aleph/tree/arbitrary-op-deletion I force-pushed so local branches should be deleted then re-pulled to test the fixā€¦
#16

Iā€™ll do it. Not for serial, which I never used, but for all the others. Thanks for not letting go of that one!

#17

ok - op_serial is also kind of new and itā€™s depends on code I wrote in lisp for the test harness at the moment (though I should provide some C bindings too in order to hook an aleph into puredata or similar). Think I am only one that knows how to test that, besides itā€™s my own code!!

So did you get any results from testing? Otherwise Iā€™ll go at it a bit this morning, re-test screen, then give the other ops same treatmentā€¦

UPDATE: ok so now able to use arbitrary op deletion on scenes containing op_screen - I am a very happy bunny - now time to try the same treatment on the other misbehaving opsā€¦

#18

Got some serious bug with BIGNUM, but I was busy today and will work on it now. Iā€™ll report within an hour with some more information :slight_smile:

#19

ok so first thing: I can delete Screen without blocking Bees so far, unless I use another op such as Bignum. Then removing screen fucks it up. Still there is a bug here, and hereā€™s what I did to create it:

000.ENC/VAL (min 0, max 639) -> 012.DIV/A
002.ENC/VAL (min 0, max 1279) -> 013.DIV/A
012.DIV/VAL (B=10) -> 014.SCREEN/X
013.DIV/VAL (B=10) -> 015.Y/X
015.Y/A -> 014.SCREEN/Y
015.Y/B -> 016.MUL/A

Here the idea was to have some operator before and after SCREEN. It all worked, but when I removed SCREEN I got something left in my outputs, like:

015.Y/A
016.Y/A
016.Y/B -> 014.MUL/A

Problem is, OP 015 should be double (A and B) and there shouldnā€™t be any OP 016. Furthermore, if I add Screen again I will get this:

013.DIV/VAL -> 015.DIV/X
015.Y/A
016.SCREEN/
016.SCREEN/ROUT -> 014.MUL/A

Knowing SCREEN has no output, I would say we still have quite an issue.
I then deleted SCREEN, but without blocking anything it stayed in the output page.
Hope it helps, talk soon!

#20

the operators such as bignum still need a patch. So that was expected. The other bug though - garrrr that is annoying thereā€™s still something wrong. I donā€™t quite understand the bug report (all though the general idea is clear and think I can probably follow your steps to reproduce).

Is the same thing reproducible using some other operator in place of screen? For example an operator which has 1 or more outputs? BTW thanks for the testing - it is much appreciatedā€¦