What to do when the Organelle freezes?


#1

Hi,

What is the best/safest procedure for restarting the Organelle when it freezes? I’m stuck in Orac right now, and I’d rather not loose my settings by unplugging the PSU, but I can’t find any other way. The Organelle stopped responding completely.

BTW – isn’t it ironic it got stuck while in a Freezer module that currently says “Not Frozen” :wink:

Thanks in advance.

Cheers,
Lukasz


#2

if you have wifi enabled, then you can use ssh to log in remotely
or connect keyboard/mouse and monitor (to hdmi)

then use restart_mother.sh


#3

Thanks, mate. Would a mouse be enough? I’ve only had my Organelle less than a week, and I’m still trying to figure it out, so excuse my ignorance, if it’s obvious I’ll need a mouse AND a keyboard :wink:

Also, how bad is it to restart it by unplugging the power supply?

Cheers,
Lukasz


#4

This should not be something you need to do…

Doing in every once in a while will unlikely cause any issue , you just don’t want to get into a habit of it :).


#5

It happened again. I’ve got a keyboard connected, but when I type “restart_mother.sh” and press enter it says (on the tv screen): command not found. What am I missing? What shall I do?

Cheers,
Lukasz


#6

~/scripts/restart-mother.sh


#7

Is there a keyboard shortcut to the command line?
Sometimes desktop ui is also slow/unresponsive.


#8

I think the red exclamation mark (hand?) does the same? (not sure as I dont use this at all)

but if desktop UI is slow, sounds like cpu issue
if a patch uses a lot of CPU, not much left for UI… also using PD in graphics mode also consumes more CPU.
(though the buffer size is increased to help ease this )

if you find this happening alot with a particular patch when using the desktop, you could increase the audio buffer for it. (using pd-opts.txt)


something to be aware of here…
when the organelle “freezes”, usually what this means is PD has crashed,
the issue is, if the patch has taken over the encoder (which modern patches do all the time for menus etc),
then the issue is you cant get back to the main menu.
so whilst it feels like the organelle has crash/frozen it hasn’t really…its just you cant get back to the menu.

(restart-mother is just an easy way to take back control to the menu)

what would be ideal is if we could introduce some kind of ‘key combination’ that the patch launcher could always intercept, and take back control - but unfortunately, have kind of use up all key combos for patches :wink:


#9

So it’s a hyphen ("-"), not an underscore? :slight_smile:

I did type “~/scripts/restart_mother.sh”, then hit enter, but also got a “command not found” message.

I’m pretty sure I’m missing something obvious here (like using the command line…), so please – bear with me.

Cheers,
Lukasz


#10

yeah hyphen…

sorry, theres a bit of inconsistency with script names, some underscore, some hypen

AND Im lazy, I don’t type the full name, on the command line, if you hit TAB, it’ll ‘auto complete’ (and show options :slight_smile: ) … so full filenames dont tend to stick in my memory.

so I type, something like:

~/scripts/rest[TAB]

:slight_smile:


#11

I had this happen many times when messing around in orac.

I don’t always start wifi if I’m not expecting to use it (since it involves taking up one of the usb slots and I’m often using both with orac). And I don’t have a keyboard/monitor/mouse setup, so I have two questions.

What could the potential harmful cumulative effects be of just unplugging?

Despite

might there be some other way to implement a reset directly from the organelle?

As it is I’m afraid to try things in orac that might push the cpu, which is… okay, but a little bit sad to be scared to experiment freely :frowning:


#12

unlikely any really…
possible corruption of usb drive, or (less likely) sdcard.

sdcard you could just reformat, and put fresh image on it…
usb drive, (if used) you’d need backup of patches etc.

but unlikely since patches are not usually actively writing to disk/stick

so its only really risky if you do it all the time, rather than just occasionally.


#13

I do it all the time, pushing orac too hard with synth + fx. Not had any issues yet but backed up in case I do.

What about a long long (long) press of encoder for shutdown?


#14

Yes, I’d also like to be able to do it all the time and have a proper reset, as this would allow me to freely play with orac without any worry. I don’t get to back up as often as I’d like, so presently I’m avoiding this kind of experimentation.


#15

this already exists (after about 4 seconds) … but only if a patch doesn’t take over control.

I added it a while back, mainly as just a shortcut, if @oweno was happy we could make this always active,
and perhaps the hold time to really prevent accidents.

(note: you get the option to abort the shutdown by releasing the encoder so its fairly safe)


perhaps mid-term we really need to reserve a few ‘gestures’ for the OS, that was the problem with multi menu system - they took away the control from the OS, and handed them to the patch.


also Id say, its more important long term that patches don’t crash!

Orac does not crash due to cpu load … as far as i know there are a couple of crashes when using braids/elements and certain parameter combinations - Ive just not had time to resolve them yet.


backups thats also an interesting point, its why wanted data to be separated from patches, so that a user could easily backup presets/samples etc - without having to copy the whole patch directory.


#16

I’m aware of this! Really just suggesting the required hold time is extended and that it is applicable on all patches. 5 seconds… display message, hold for further 5 seconds to shutdown? Also, shutdown process is aborted if an organelle key press is detected.

I wouldn’t mind going through 10 seconds of waiting to avoid corruption on a freeze up. I do usually use the regular menu shortcut in normal use though anyway.


#17

Is this more a case of semantics? The organelle certainly does become unusable/frozen up if a user accidentally (or on purpose!) uses a combination of high draw modules in the orac patch. I understand the distinction, but I believe what people are describing as a crash is when they cannot use the menu of, hear or in any way operate the organelle due to cpu load. Brds module crashes occasionally for me but this usually resolves and brings me back to the main menu screen, like a reload.


#18

as with all tech, like it or not, specifics are important… since the fix or resolution is dependent on exactly whats going on , rather than what the user perceives is going on…

if it’s just heavy CPU load, then I would expect (with patience) eventually the patch will respond and return you to the main menu, and so eventually you’d be able to shutdown.
caveat : unfortunately, those pesky details rear their heads again here… somethings might use timers, which might screw up and things become a bit unpredictable - either making functionality, like menus, work intermittently or not at all.

in this case the shutdown shortcut may or may not work, due to those timing issues, as we have no way to get more priority to the mother executable, in fact its actually running at a lower priority than audio (which is what you normally want)

however, if the patch crashes (due to an external, or pd acting up) , then its a different thing entirely - the patch cannot return the control to mother executable.

I have actually talked with @oweno about a different solution for this, we could be periodically checking the patch is running and if we find its died, we could then ‘cease’ control, and return to the main menu.

likelyhood is , different people are describing both… this is why I use try to find out some specifics, rather than just the organelle has crashed or frozen - because from a technical standpoint this doesn’t actually tell us anything at all…


#19

Is there a way we can identify which case it is? I mean, after one hour of waiting for the Organelle to respond, I tend to think it froze :wink:

Cheers,
Lukasz


#20

connect a keyboard/monitor (or log in via ssh) and see if PD is still running :wink:

the thing is, it wont just start responding… you’d need to be actively trying to exit the patch etc.

more seriously,
a) I think we can do something to improve this e.g. “shutdown shortcut” could also kill pd/regain control… we just need (including C&G) what exactly the ‘kill switch’ is.
b) as I first said, its actually unlikely that powering off will corrupt your sd/usb.
c) priority really is to ‘fix patches’ , since patches dying is not good anyway.