Weird problem getting stuck in edit mode.

  • I've actually had this problem from day one. I thought it was my fault for mucking around with things, but i've been noticing it happening even after a fresh format of the the sd card an reinstall of Bees.

    I just tried to load Gridgrain and it happened again. I couldn't get out of edit mode or power down. I had to unplug the power.

    Any ideas? Thanks.

  • it's probably this much-discussed bug with timer management, which we've just fixed. sporadic hangs with metro enable/disable/delete.

    bees-0.5.1 is being posted right now, and i'll post a compatible version of duncan's scene shortly and hopefully the crash will go away.

    sorry about that

  • Thanks! It just happened again when i tried to load Skitter. It hung up on "waiting for module init"

    Is the link to the new version on the main Bees page? I didn't see it last time i looked.

  • oh... maybe something else then. what else does it say? does it say that it found "aleph-lines.ldr" ? you've been using skitter and lines successfully before? are you trying to use different versions (of bees or lines) from latest master zip (bees 0.4.3, lines 0.1.2) ?

    here is a link to that version on github. it should work with duncan's scene. (given that, as noted, using an enabled METRO in a scene can cause crashes):

    brian will be posting a new public release link shortly... there is now a permalink to the latest version, as updated on front page of aleph docs:

    sorry i kind of have to run, won't be online this evening... but we will sort you out in short order.

  • I can't remember, just that it was hung up on the init line. Everything seemed to be loading fine until then.
    Yes, i was using Skitter and doing the waves tutorials earlier.
    Just using the versions of Bees that came with the Aleph, or rather was up on the page.

    No worries, thanks for the help! I'm going to work on other stuff tonight. Probably won't get back to the Aleph until wed. or thur. if i finish the album i'm working on...

  • Did you restart with a blank slate? hold SW2 while restarting.
    I've only seen init errors if the Bees is the wrong version for the scene or files are in he wrong folders on the SD card.

  • Yes, but i'll try again tonight, thanks!

  • Dang. Just successfully (it thought anyhow) upraded to the new Bees, but when i started up again (I had been using Skitter), it hung up on "waiting for module init" again. At least this time i can power down the Aleph.

  • you mean you did the update, (replacing *all* the directories on sdcard with contents of, flashing new bees .hex), used skitter successfully, and now it suddenly doesn't work anymore? that would be confounding.

    or do you mean it doesn't work since you flashed the new bees? in that case i'd double-check that all the components got updated. the easiest way (i think) is to just reformat the card and copy the new app/ , mod/ and data/ folders in their entirety.

  • The second, i've reformatted the SD card a couple times, rebooted a couple times, etc. and had Flashed the new Bees when i wrote the post about hanging up again on module init.
    Now it's working again.
    I'm wondering if some of the problems are related to powering it from the battery I have.
    Using Skitter from the wall-wart again and it seems to be working fine.

  • jeez, ok, you are using a battery, that's new information.

    yeah the DSP could be starved for current or something, and not booting at all, or booting slow. if this is actually happening it is not good for the hardware. i would want to test it carefully and see that all the supply and logic reference pins in the system are at sane levels.

  • I wasn't, just got it a few days ago. It should have plenty of power,, but maybe i should refrain from using it for now.

  • it has a charge controller...? who knows what it is doing. at the very least check the current draw with a meter for wall wart vs battery.

  • My meter isn't here. I'll just not use it until i know it's ok.

  • I dunno, something is still very weird. I was using Stepwaves (no battery) and when I restarted it, nothing sounded right. Tried to switch to other scenes, but everything was weird. I couldn't power down. I'll reformat the SD card and try again, but this is frustrating.
    I'm sure i haven't done anything too wrong this time.

  • Just reformatted the card, reinstalled the new Bees. It's hanging up on module init again.
    I suspect there's something wrong with my aleph.
    I'll contact you guys to see if i can send it back for a check up.

  • have you tried holding SW2 (third switch from left) when powering up?

  • Yes, that's my standard procedure. Can i send it back and have you check it out?

  • Sorry to hear you're having so many issues. I wonder if your card has the three folders in the root? When writing the Bees to flash is was random grayscale, you didn't have any repeat patterns...I've seen that on bad copied Bees. When I had a flakey reader.
    I'd also suggest different SD Cards and a few different (newer the better) card readers.

  • Citizen, thanks so much for all your help! I sent the aleph back. Hopefully Brian and crew can sus it out. It's been problematic from day one.
    My reader is new, if the card is shit, maybe they should include a better one.
    I've had nothing but frustration with everything monome. I think it's just not for everybody.
    Thanks again for your help and advice!

  • I just had a really bad hang up with Mode button not working. I had used the Stepwaves app on a 256 and unplugged it. I came back after work and at start up it had CV 0-3 all at 0.0000. I couldn't get the mode button to work (edit/play or load Bees) and even the blank slate SW2 was also not working at start up. I swapped cards and it hung at loading init part. I swapped to the old card and held the mode button down again and it caught this time...weird.

  • if you swap to an old card and run it with the new bees firmware, it is guaranteed to hang on module init. bees won't find the .dsc files it needs to talk to the module, and the startup "handshake" between the two processors has changed, so the module won't cooperate.

    the button thing is weird. of course, we haven't changed anything on that level. mode button pin detection at startup actually happens in the bootloader (which jumps to the app code if the button is up.) we couldn't change that even if we wanted to; the bootloader flash region is protected by physical fuse bit settings as well as by software.

    anyways, keep letting me know. of course we have been incrementally testing each change to bees firmware over the last month+, on the units we have available; that means many, many cycles of flashing and rebooting, and many hours of uptime. but if there are hardware inconsistencies exposed by changes to the timing and structure of software, we will need help finding them.

    blungo, i'm sorry to hear that, and i'm sorry we can't seem to offer you better support. (doing my best!) of course nobody should use tools/devices that only frustrate them, that's not the point at all.

  • You described it right, I tried an older Bees SD Card hoping the Mode button would somehow catch. Maybe because I powered down with a 256 and restarted with no grid?

  • i really can't think of anything that could affect that except a physically sticky switch... or something wrong with the debounce circuit. that seems unlikely, but it's true that all the keys share a schmitt-trigger IC (SN74AHCT14D) , so if you see more responsiveness issues with different keys i guess that's worth considering.

    anyways just keep an eye on it and maybe best to send email to directly if you see a consistent key problem.

    sorry, my brain is stumbling, been a long day.

  • Zebra, i appreciate your help as well! At this point though, i feel like i'm going to keep banging my head against the wall. I must have formatted my card reinstalled Bees 20 times or so. It shouldn't have to be like this. If there is a problem with my particular device i'd like to know about it.

    Also, in almost all of my hang ups neither the Mode button or power switch worked. I would have to unplug the power to shut the unit down.

  • If it's hung up then no you won't be able to use any buttons and you have to pull the cord. Best to restart in a blank scene on restart.
    If you read the long SD card thread you'll see you probably don't need to keep reformatting your card.

  • ok, i'm going to restate here, for the benefit of anyone following, that re-flashing the bees application code will pretty much never fix anything, as noted here and elsewhere. it is just a waste of time and we have never recommended it.

    the *only* time it could matter is if you flashed a corrupted .hex file. the bootloader will probably complain vigorously on the screen when you attempt to do this; at the least it will look very weird.

    if you have problems, ask us, of course. we will certainly respond. but equally importantly, take the time to read what we have written. this is a general plea!

    sometimes, actually, one does need reformat a card. for example, a recently posted zipfile contained some hidden files generated by Mavericks. (i guess.) i found that when i unzip an archive containing these files directly onto an sdcard in linux, the card is instantly corrupted. (some cards, anyways. the "bad" ones?) this is a weird thing that i was lucky to figure out, but doing so involved lots of frustration and some very methodical experiments. oviously, it is also not related to the aleph, per se! but it is typical of the headaches one encounters, messing around with computers and sd cards all day. (for the record, i removed the hidden files from the archive, re-uploaded it, and informed the rest of the team to watch out for this. and now i'm mentiong it here.)

    but yeah, formatting your card is also not recommended as a general troubleshooting step. it's very unlikely to fix any crash conditions.

    again for the general benefit: aleph firmware is obviously in very active development, and sometimes there are crashes. certainly we try and spot crash conditions and fix them (i fixed a lot of them in the new release. seriously.) so i like to hear about crashes, and i like to hear as much detail as possible. (by the way, i've begged and begged for debug build output, and i never see it. so i fire up the debug build myself, and try and replicate crash conditions from the descriptions, which might be very clear or very vague. this is pretty ineffective, but maybe just the way its gonna be. )

    and when bees crashes, buttons become unresponsive, including the power button. this doesn't mean anything is broken. (except our software, duh.) this totally unresponsive behavior in itself is undesirable and unnecessary, and it should be changed, and that's tricky. i've discussed the the details at length, (which mostly feels like i'm typing into an echo chamber, but there has also been valuable input with other people on here), on the git issues list and on the forum. here's the main issue report on app-stall behavior including some of my conclusions with what is and isn't possible with the hardware watchdog timer:

    ok i guess i am ranting and rambling now. see you later, good luck, best wishes, sorry.

  • btw, i totally understand that getting debug output is a pain in the ass, and all one wants to do after a crash is go back to whatever you were doing, not reflash the unit and whatever. of course i have no real complaint about this.

    but if someone seriously wants to contribute to diagnosing crashes it is the absolute best way, so it bears repeating!

  • was that my zip file? I'm so sick of mavericks ... think i'm going to be going try downgrading

  • nah, it was an attachment from the releases page. i only found this because i decided to try very literally following the steps described on the "update" page, and boom it broke. (those aren't the steps i would normally use, or recommend. but i'm not a mac user, so my experience isn't typical.) maybe this has happened to people before.

  • i've updated the update page.

    yes, this was/is typical file management behavior for non-command-line using mac users.

  • Just a quick fyi: flashing to bees 5.2 a couple of nights ago using a brand new SD card silenced my unit. None of the waves scenes produced any sound. During flashing the display showed random level gray scale blocks (not sure if this is an expected behaviour).

    Troubleshooting today, and before reading @zebra's note above that reflashing is not likely to resolve many issues, I did reflash (oops) and now things seem to be working. Perhaps this was only a coincidence?

    -- edit --
    Just found that loading skitter from this caused my unit to hang. I was able to recreate this hang.

    After unplugging/replugging the power, powering on with sw2 pressed, loading this then loading skitter but not connecting my grid, skitter loaded fine. Hoping this is useful.

  • @HalfLife, thanks!

    the grayscale blocks during update are showing the actual bytes being written. they should look pretty dense and random. if there are repeating patterns or blank regions it's probably a corrupted .hex file (and the bootloader will probably be complaining.)

    i guess i should amend my note: it's always possible that a firmware update failed to complete (because of lost power, sd card got unseated, something like that.) in this rare case, you will likely end up with a) an unbootable unit, or b) the pre-update firmware, but probably with weird problems. (so it's a good idea to watch and note the version of bees reported at startup, after an update.)

    so yeah, if you just flashed and it seems completely bricked, or it's showing the old version, try flashing again. if it seems to flash ok and launches, but you run into some random problem at some point, then reflashing is not the answer.

    BTW: the reason we use .hex is that this file format includes built-in checksums after each data entry. so if a .hex file is corrupted the checksum will fail, and the bootloader will inform you on the screen. (there are a couple pathological cases that will escape the check, like if you totally remove the sdcard before writing, or if the .hex file is all zeros IIRC.)

    anyways... if the bootloader finishes updating without visible issues, restarts into the new bees version, doesn't hang but doesn't make sound, then i dunno. most likely it didn't find aleph-waves.ldr and/or aleph-waves.dsc. in the former case, the INPUTS page will show weird values for all DSP parameters instead of the normal defaults (probably all zeros); in the latter case, the DSP parameters won't show up in the INPUTS page at all; both cases will probably produce silence or bus noise.

    it's really important to remember that the bees application isn't actually responsible for making sound. aleph-waves.ldr and aleph-lines.ldr are the programs that do that, running on the DSP slave processor. there is one big change in 0.5.2 regarding how the processors communicate, which is that the controller reads the parameter descriptors from a .dsc file, instead of querying the DSP processor after launcing a module.

    this means that if you are updating bees from 0.4.x to 0.5.x you *must* also replace the old .ldr files with the new ones from the release .zip, and add the respective .dsc files. this is why we suggest just starting from a blank card. (i know you said you did this, i'm just restating it.)

    FWIW: i can't reproduce [this->skitter] issue, starting from scratch with the release .zip on either of my test units. i've tried various combinations:
    1) clean boot, load 'this', load 'skitter'
    2) clean boot, load 'skitter'
    3) use 'skitter' as default, clean boot, hard shutdown, boot with default
    4) boot into 'this' as default, load skitter

    at all times i'm leaving a grid controller plugged (series gs64), and haven't had any problems. (oh, except the nasty bootup noise from unitialized audio buffer in lines-0.2.1, which has been noted, and which i'm working on fixing.)

    so... i dunno? is there something else i should be trying? any other system messages that you've noticed in the failure case?

  • People might be having problems because of the new github download causing something unexpected. Can one of you developers post a known clean zip on this site again?

  • Thanks for additional info @zebra. With the exception of my first attempt, flashing to 5.2 was quite uneventful - no power outs, no SD card ejects. I did have see a "corrupted hex" warning the first time I tried flashing. This turned out to be the harbinger of death of the supplied SD card. I made my second attempt using a new Sony card and everything looked fine.

    Based on what you've explained, maybe my issues are grid related. FWIW I'm using one of the first run 256s (s/n 250-something). Interestingly since disconnecting it I've had no problems. I'll experiment with unplugging the grid before loading scenes.

    Thanks for your help Ezra. Aleph is a fascinating new platform and, I hope I speak for everyone here, we appreciate the incredibly hard work you have done to bring it to life.

  • I found plugging in a grid after a scene loads to be pretty solid. just takes a second to initialize.

  • @c1t1zen i've downloaded the .zip like 10 times. you think hosting it on a different server would change anyone's experience?

  • maybe there is something up with init/query on mext protocol devices. i'm afraid i can't personally attend to this though cause i don't have one.

  • I'd be happy to assist with debugging by providing additional info. Let me know if, and how, I can help.

  • Just tossing in ideas since I noticed so many people with Bees 0.5.2 issues. That was one thing that changed on this release and I also noticed a weird decompress issue a few times on my side. I ended up using a third party unzipper.
    So far I'm liking 0.5...The step app is killer with a grid.

  • Ok, point taken.... Well I probably would have gone with a .img file containing the raw disk image. (This is how ras.pi and beagleboard firmware is distributed, for example.)

    Then again, the last thing I would want is for someone to blow away their boot disk using 'sudo dd of' trying to update their aleph...

  • @halflife @zebra I also had the 'no sound from waves' issue this morning (after a few days of using 0.5.2 without issue). Couple of restarts and then sound came back after tweaking some of the input settings (i can't remember which ones, sorry)
    Then it happened again but this time it was after I put the sd card in my computer to copy a scene 'from' the card. When I looked at modules list it was just garbled text. Reformatted the card, put the clean 0.5.2 files back on and all seems to be fine again (apart from the default scene writing, see 0.5.2 thread)
    Could it be something in the mavericks os that is playing silly buggers?
    If this is likely could someone maybe suggest the best method for taking moving files on/off the card on mavericks? Is using the command line less prone to error?