electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » Developers' Corner
Some good programming and quality control Advice
Post new topic   Reply to topic Moderators: DrJustice
Page 1 of 1 [2 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
State Machine
Janitor
Janitor


Joined: Apr 17, 2006
Posts: 2809
Location: New York
Audio files: 24

PostPosted: Tue Dec 11, 2012 8:20 am    Post subject: Some good programming and quality control Advice
Subject description: A Shuttle Failure Averted
Reply with quote  Mark this post and the followings unread

********************************************
I thought this was good information. Although our software we develop for our DIY electronic music instruments may contain bugs that lurk within, if a bug shows does show up may not cause death, it would certainly mean the difference between a great live performance OR a musical disaster ! Laughing

********************************************

Taken from: The Embedded Muse
Issue Number 232, December 10, 2012
Copyright 2012 The Ganssle Group
A Shuttle Failure Averted


The second Space Shuttle launch in 1981 was delayed by a month when a fuel spill loosened a number of its tiles. The crew booked simulator time in Houston to practice a number of scenarios, including a "Transatlantic Abort”, where the vehicle can neither make orbit nor can return to the launch site. Suddenly, all four main Shuttle computers (in the simulator) crashed. Part of the abort scenario requires fuel dumps to lighten the spacecraft. It was during the second of these dumps that the crash occurred.

After a couple of days of analysis, programmers discovered that the fuel management module, which had done one dump and successfully exited, when recalled for the second fuel dump, restarted thinking that this was it's first incarnation. Counters in the code had not been properly reinitialized, though, causing what was essentially a computed GOTO to branch out of the code, into a random section of memory.
A simple fix took care of the problem. More interesting, though, was the realization that this same sort of bug had appeared in different modules before. The programmers were committed to producing only the best code, so decided to see if they could come up with a systematic way to eliminate these generic sorts of bugs in the future.

They developed a list of seven questions that had a high probability of isolating similar problems. A different group of programmers then applied these questions to the bad fuel dumping module (to see if they would indeed pick up the known problem), as well as other modules.
The questions detected every one of the bugs. 17 additional, previously unknown, problems surfaced!

This is software engineering at its best. Instead of quickly fixing the bug and moving on - as most of us do - the development team transformed the defect into an opportunity to improve the code
Back to top
View user's profile Send private message Send e-mail
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Tue Dec 11, 2012 9:22 am    Post subject: Reply with quote  Mark this post and the followings unread

Wow, very interesting and pertinent here because as you said, there's nothing worse than being on stage with an audience watching as your DIY synthesizer or effect farts and dies.

From the standpoint of a musical device, I believe in "over" testing. As I develop code and before it is completed, I run tests, proof of concept if you will, because often what I do is an incremental building process and often if not always, one piece of code depends on others working correctly. I write code (usually in C) to simulate the process idea and often work out problems at that stage.

Unit testing is important and I always try to over stress the device code, such as blasting high bandwidth MIDI data at it as well as unexpected and malformed data, just to see whether the code will tolerate it and recover when good data is presented afterward.

I will also leave the unit powered up for days at a time quiescently and then send more test data (MIDI) to see that it still functions correctly after sitting idle for many hours.

Final testing includes an attempt to create a piece of difficult music which I eventually use as a demo mainly to show off the instrument's features, but that demo has been played over and over during the recording process to ensure it sounds exactly as I intended.

Finally, I will try to find MIDI files of complex classical music to fire at it in case subconsciously I have written the demo to conform to a "be nice to it" paradigm. Given that the composer was not me, that can't happen. I am not satisfied until I've remediated every glitch that my ears can hear.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: DrJustice
Page 1 of 1 [2 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Developers' Corner
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use