thetechnobear

basically, if you enter something incorrectly in codebox, you can crash max... 

and worst still, every time you load the patch max will either crash again (or hang)

and example of this previously was a bit of a cut n' paste error on my part

yeah, the repeated x< ... meant it was an infinite loop, but syntactically correct.

(though most C++ compilers would at least warn of this... so at certain compile levels fail to compile)

but there is no protection for this in rnbo/max.

basically, what happens is it compiles fine, and then appears to create a stack overflow (my assumption), which kills max.

whats a bit odd though, is even when I had audio off, relaunch/loading this patch would again kill max.

... though this is kind of is not the point.

I think what we need, is for max to recognise the codebox is crashing max...

so that when we reload, the rnbo object is temporarily completely disabled.

(thus allowing us to fix and also save/recover our work!)

currently, the only solution I found was to edit the max patch directly and edit out the code, 

though annoyingly it has \r\n formatting in it, so you have to then edit this out to recover your work.

I get that its a programming error, but in a prototyping tool (as I view RNBO/Max is),

you need to be able to get away with mistakes, and not have the tool crash n' burn ;)

EDIT: just found out what my last crash n' burn was caused by....

allowing an out of bound on an FixedSampleArray.

max crashing, and hanging every time patch was loaded.

having to edit max patch, remove code from it manually.

reformatting the code in an editor to remove all the escaping

fortunately, in this case.. Id saved the RNBO patch recently, 

otherwise, I guess we might potentially lose work when max crashes?

basically, if you enter something incorrectly in codebox, you can crash max... 
and worst still, every time you load the patch max will either crash again (or hang) 

I ended up with 
```
for(var x=0;x<x< d;x++)  {
```

yeah, the repeated x< ... meant it was an infinite loop, but syntactically correct.
(though most C++ compilers would at least warn of this... so at certain compile levels fail to compile)

whats a bit odd though, is even when I had audio off, relaunch/loading this patch would again kill max.
... though this is kind of is not the point.

I think what we need, is for max to recognise the codebox is crashing max...
so that when we reload, the rnbo object is temporarily completely disabled.
(thus allowing us to fix and also save/recover our work!)
 
currently, the only solution I found was to edit the max patch directly and edit out the code, 
though annoyingly it has \r\n formatting in it, so you have to then edit this out to recover your work.

I get that its a programming error, but in a prototyping tool (as I view RNBO/Max is),
you need to be able to get away with mistakes, and not have the tool crash n' burn ;) 

EDIT: just found out what my last crash n' burn was caused by....
allowing an out of bound on an FixedSampleArray.
again, sure, a programming error... 
but the consequences : 
max crashing, and hanging every time patch was loaded.
having to edit max patch, remove code from it manually.
reformatting the code in an editor to remove all the escaping
re-check code to find issue...
fix issue
then reinsert back into rnbo patch...

fortunately, in this case.. Id saved the RNBO patch recently, 
otherwise, I guess we might potentially lose work when max crashes?

I've now had this a few times...
basically, if you enter something incorrectly in codebox, you can crash max... 

codebox~-crash-hardimpossible-to-recover

Yes I agree there are still some flaws and bug in RNBO.

I made the observation that even if the audio engine in max is off audio seems to be still processed inside RNBO. That would explain your crash when DSP was off.

Max crashed when changing a parameter in RNBO. Like in your case, the patch would not open anymore. It turned out that a connected attrui was causing the crash. I also had to manually edit the patcher file.

Yes I agree there are still some flaws and bug in  RNBO.
 I made the observation that even if the audio engine in max is off audio seems to be still processed inside RNBO. That would explain your crash when DSP was off.

I had another/ similar issue   recently: 
Max crashed when changing a parameter in RNBO. Like in your case, the patch would not open anymore.  It turned out that a connected attrui was causing the crash. I also had to manually edit the patcher file.

codebox~ - crash - hard/impossible to recover.