Thanks Jim,

Quote:
It took me awhile, at least maybe a year, to adjust my way of working to the way RealBand operates enough that the program would operate without crashing too often. But, it still crashes more often than I would like.

This is the reality with much software. All programmers know programs should ideally never abort. The program should anticipate everything that comes at it and deal with it (example: popups when the user makes an error). It is a tall order and generally only very mature programs are this advanced. Ones with big money behind them like banking software or brokerage software.


Quote:
I constantly had to think about what I was doing when a crash happened, what could I do to adjust so it wouldn't happen again, test and see if my adjustment works. I discovered a couple of weak spots in how the program operates and try to avoid them.


Yes. Always. With BIAB I had a macro doing some things to control it. BIAB would bomb and I would need to do a factory reset. I changed my macro to make it better for me and much to my surprise the macro change fixed the BIAB bombing. I have no idea why and no time to go back and figure it out.

Quote:
Save, save, save! You can't save too often. The more often you save the less often you crash!

Every now and then use save as and save the project under a new name. If, or when, your project crashes, close the program, open the program and open the last project name that worked. You've lost whatever you did from the time of the last save as to the time the crash happened but ... you didn't completely lose the project!


This did not work for me. It should but something deeper was going on. I documented a procedure to do my mixes. About 8 major steps. At the end of each step I would save (it was part of the instructions). I would name the step after the song name. Returning the file did not fix an abort. I think bad data was getting saved. So for example I would close down the program, do the standard RB reset when prompted, return the file and it would immediately abort again. I think I even tried shutting down windows once and I got the same result. In other words it created the problem and it was a long time before its ugly head finally surfaced. Now that was very annoying.


Quote:
If you use a feature like the gain or volume nodes you need to use extra care. In addition to the saves and save as you need to take steps specific to the feature like clean-up nodes, don't move any node up, down, left or right too much. In other words, don't create a node unless you need it and when you do create one, create it where you need it.

Yes, I am not surprised this feature would introduce bugs. Audacity seems to have it down pat. RB is better in that it gives you a number to reset to but in a way that isn't that important. Audacity is so fast at zooming in and out I just eye ball it and hear it (have to do that anyways). But getting back to the aborts it the program auto saved the info from the abort and asked the user to leave the machine on overnight while it uploaded the dump to PGmusic also telling them they would eventually get back to them when the fix was in place this would give users a lot of confidence. The program needs a detailed log of what it is doing upload as well as the user info for the problem is fixed emailing. I think it would need a central switch that can be used to turn the log writes off once they feel the bug is fixed. It I remember correctly Multicharts did the reverse. They built this into their programs anticipating potential problems and only if the bugs showed would they turn the log on. They would turn it on for sections of the program. However they did not have a (when fixed notification system).

Quote:
So, the program is temperamental. I wish it wasn't but it is. Learn what sets it off and minimize those things. Everyone has to decide for themselves if the benefits outweigh the effort required. For me, it does.

True. I never had any aborts when creating acid loops. I put one in my BIAB backing tracks on one song. I will rarely use it.

If cleaning up nodes is something that helps prevent the bugs this probably can be automated. The programmers are in a much better position to know when to do this and why. That should be blatantly obvious but may be it is only obvious to me because I am a programmer. The irony is if they put this in they probably can fix the issue and it may not be needed. Can't say for sure but I give it pretty high odds. After all they wrote the routine to clean it up didn't they. Who knows. Maybe this is why Audacity works so well in this way. Maybe every time you place a volume node it calls a clean up routine.




Last edited by bowlesj; 05/03/19 03:57 AM.
John Bowles
My playing in my 20s:
https://www.reverbnation.com/johnbowles