#21

EDIT: it just seems like deleting SCREEN can create strange behaviour on the OUTPUT page, like a SPLIT with only one output, an operator without outputs that suddenly has two, etc.

Anyway so far I tried with IS and DIV for instance, adding some SPLIT operators to see if something weird happened again but all seems well. Will let you know if I see something more, just tell me what you need to test and I’ll do what I can to help: this feature will definitely make my life simpler in the end!

One thing though: once arbitrary OP deletion is working, will it be complicated to insert operators as well? Not that it is as much needed, but it could help to make some clean programming. Then again, not such a big deal compared to what you are doing right now!

#22

Got the same thing somehow with BARS8: deleting actually seems to work fine, but if I bring a new instance of BARS8 afterwards then it messes up with the outputs and stops working, without freezing the Aleph though. I’ll stop testing for tonight, hope this is still useful.

#23

I reproduced the bug you described and see the symptoms clearly. Thanks again for the testing

granted arbitrary insertion would be nice but probably nearly as much work again as the deletion - probably with it’s own set of corner cases and bugs.

As stated before the underlying model is slightly dysfunctional, which is what makes the deletion feature so tough to add. I would put totally refactoring the network on a higher priority than arbitrary op insertion…

#24

yes bars8 is one of the other ops that are expected probably still broken. here’s the full list again:

  • bars (almost definitely still broken but same fix for screen should work)
  • bars8 (almost definitely still broken but same fix for screen should work)
  • bignum (almost definitely still broken but same fix for screen should work)
  • mout_cc
  • mout_note

Would appreciate a quick test of mout_cc & mout_note if possible?

Serial is now working after arbitrary op delete (but with the confused outputs after op delete)

#25

Totally agreed about op insertion. Then I just tried MIDI_CC. So far same thing: the deletion is correct but the Output page shows weird things. The result, as far as I tested it, is still correct in Performance mode though. Also, I noticed after reinserting it that MIDICC/VAL had disappeared from the Inputs page, and had appeared in the Outputs twice… Maybe that’ll give you a hint to what’s happening there. Going to bed now, exciting to hear what tomorrow will bring!

#26

ok pretty sure now I have a handle on the problem and trying a fix…
…
…
and think it’s fixed now hurrah! code’s pushed to the feature branch - now just need to fix memory management issues with the remaining screen-drawing ops…
UPDATE: ok all good now I fixed bars, bars8, bignum.

Have reason to believe now there may be issues with op_metro, op_delay & op_ww - these all use the polled-timer-callbacks which get upset when you ‘squash-out’ an existing op…

#27

OK good news I think! So just after getting the screen operators back up and running I realised it is in fact impossible to fix metro & timer in the same way! D’oh!

I tried making a fundamental change to the way operators are allocated, using malloc/free instead of the compacting pool memory scheme we had before. This was a suggestion that had been floating around but not actually tried. Within an hour the thing was back up and running with the arbitrary op deletion and without any modification to the operator code! Hurrah!

I used a cheeky trick to try and reduce memory fragmentation problems so I am pretty confident we can test, then merge this change, since there are no more crazy moving memory shenanigans leaving landmines all over the place. @zebra do you think the 128 byte allocation anti-fragmentation hack will do the trick?

@Yann_Coppier and/or @glia are you able to test a bit? Anyone else able to pitch in with that? Here’s the code https://github.com/rick-monster/aleph/tree/net-use-malloc. I would like to clean up my new grid goodies like the mem1d operators and produce a binary beta version for people to play around with…
…
umm hold up no wait there’s still a problem - bees comes up cleanly on first run but when loading from a scene the net comes up unresponsive for whatever dumb reason & I can’t even trigger bfin params from an encoder…
EDIT:
I can’t seem to reproduce any bugs now with latest head - that’s good, right!? @Yann_Coppier if you can spare some time again to help debug please note it’s a different branch name from the one you were testing yesterday (the branch named arbitrary-op-deletion is now abandoned and the one you want is net-use-malloc)

#28

yeah i think we would need the 2 chunk sizes ( [see note] ( https://github.com/rick-monster/aleph/commit/cfe39aa0546331cb34dd4164d6ddb675b8854417#diff-3e21c99a03f2f615e68f22f97bdea1f9R371 ) )

[ moved to GH ]

#29

I’ll work on it later today, sounds great!

#30

Prototype of the small_op memory management scheme supporting only one chunk size for now. Want to get some testing done first on the current HEAD of net-use-malloc branch, make sure no bugs introduced by that change, then graft this new thing on…

I kind of would like to see arbitrary op insertion now as well. The arbitrary op deletion is apparently not so mind-bending when you fix the underlying memory model and the code doesn’t look too bad in the end (fixing underlying data structures was just a pipe dream apparently).

1 Like
#31

[quote=“rick_monster, post:27, topic:2578”]
@Yann_Coppier and/or @glia are you able to test a bit? Anyone else able to pitch in with that? Here’s the code https://github.com/rick-monster/aleph/tree/net-use-malloc. I would like to clean up my new grid goodies like the mem1d operators and produce a binary beta version for people to play around with…
[/quote]sorry for the lack of help

I’m tied up with another project tonight and cant reflash my aleph until tomorrow

#32

No problem - grateful when people can help but don’t necessarily expect everyone to drop everything and spend their weekend testing my buggy code…

Bit cheeky really but I’m struggling to make enough time every week to keep aleph software moving forward - working in a team like this is a great way to keep up the momentum!

2 Likes
#33

So far it seems good to me. Haven’t had so much time though and I really need to sleep now, so I’ll do some more tomorrow… but it looks promising!

#34

is this still the latest zip?

do i need to build this or will it load directly onto the machine?

#35

To help with the testing, this is the branch which enables arbitrary op deletion (and I will try to update that branch with arbitrary op insertion too before the weekend):

https://github.com/rick-monster/aleph/tree/net-use-malloc.

Any help testing the snot out of that thing would be very much appreciated. Though I have been using a version of bees with the arbitrary op deletion feature and also the new grid ops. All seems fine woohoo!

Won’t be releasing any binary build of bees for testers. In order to help test it should be a case of:

  • checkout the branch to be tested using git
  • build it
  • load it using bootloader
  • test
  • bug report (hopefully not…)
#36

http://monome.org/docs/aleph/dev/ says

To build Bees, run ‘make’ in aleph/apps/bees. This produces aleph-bees-x.y.z-dbg.hex by default. ‘make R=1’ produces a release build, aleph-bees-x.y.z.hex (you must also run a ‘make clean’ if switching between debug and release.)

To build a module, run ‘make deploy’ in e.g. aleph/modules/lines. This produces lines.ldr, a blackfin executable, as well as lines.dsc, the parameter descriptor file. ‘make’ alone just builds the .ldr, which is fine if you aren’t making changes to the parameter descriptors.

this is what I want? right?

#37

The first part - yes, definitely.

1 Like
#38

right! The part that’s not explained there is how to check out the right branch from my github, in order to be building the right version of the code. If it’s not clear how that works just ask…

#39

Just revamped the memory management again & pushed to this branch https://github.com/rick-monster/aleph/tree/net-use-malloc. Way too late to start testing on the device. Anyone awake and fancy testing the latest version for me? It uses two pools of memory for big_ops and small_ops to avoid fragmentation issues…

#40

Unfortunately won’t be able to test anything before tomorrow night, too much work right now. But will do!