There have been a few concerns expressed recently about SCS becoming 'bloatware', ie becoming software that's bloated by heaps of functionality that's useless to most users, and that the more bloated the software becomes then the more susceptible it is to hidden bugs. I think it's time to address these concerns.
I wrote the first version of SCS back in the early 1990's after running sound effects for several theatre productions using cassette tapes (yes, cassette tapes!) After spending hours cueing up tapes for productions with 40-odd sound cues (= 40-odd tapes); having tapes wrecked in the machine just when you play the cue; and having no easy way to quickly replay cues during tech runs, I decided there must be a way to run these cues from a computer. So SCS was born to meet a need, and that is essentially the reason for it's success today and is the key factor in deciding what new features to include or not include.
The consumer market is always looking for something better than they've had before. I have a customer who lives about an hour's drive from where I live, and we have met several times to discuss requirements. This customer uses SCS with band gigs (very interesting application for SCS) and he tells me that the venues (pubs, clubs, etc) are always wanting bigger and brighter shows. So it is important to be aware of what the needs are and to identify and evaluate what can be added to SCS to meet these needs, and also to try to keep a step ahead.
Theatre patrons are also expecting more, and there's nothing wrong with that. As technicians, we should always strive to improve what we present, and by doing so we enhance the whole production. This doesn't have to mean more noise. A few months ago I attended the opening night of a production where SCS was being used, and during the interval chatted to a reporter I know. She asked me if SCS was being used for the show but before I could answer she commented that there weren't many sound effects in this show. Since I was much more aware of sound I knew that there were, in fact, many sound effects. It is a commendation on the sound design for the show that an 'average patron' was not consciously aware of the sound effects - they just subtly added the right atmosphere as and when required.
SCS is used in many different environments and some of them have requirements slightly different to others. SCS is used in amateur theatres with minimal equipment and is also used in large national and international productions with multiple sound desks and back-up systems. As well as theatre productions, I'm aware of SCS being used in schools, universities, colleges, churches, bands, dance companies, theme parks, sports events, seminars, cruise ships, etc. And that's just based on the usage I know about.
So there's on ongoing need to provide SCS functionality that meets and surpasses the expectations of all types of user. It is, of course, very important that new functionality is well tested, and I have been privileged to receive excellent support from alpha and beta testers for major releases. A few bugs may still get thru, but I trust I have been able to fix these in good time. Some new functionality incurs performance overheads, but with computers and associated hardware becoming faster and installed memory increasing in capacity with every new machine, these performance overheads usually become insignificant.
The above does not present a definitive guide as to whether or not a particular feature request will be included in SCS - I don't have a formula or points system that comes up with a 'yes' or 'no' answer. It basically comes down to (a) how much interest is shown in the request, (b) how useful the feature appears to be, and (c) how much work is involved in adding the feature. Also, if a feature request has the potential to attract a new group of users then that is also a good reason to add the feature.
Hope this helps explain the development path for SCS.
Functionality vs Bloatware
-
Mike Daniell
- Site Admin
- Posts: 3629
- Joined: Sun Jul 24, 2005 8:58 am
- Location: Brisbane, Queensland, Australia. TZ:GMT+10
- Contact:
Re: Functionality vs Bloatware
If I may, I'd like to add my support to Mike and his efforts. I've been using SCS for a few years now and I've always been impressed with the new features and the rate at which he has added them as well as the speed with which he is able to address bugs. Every time he has announced new features I've been worried that others might express concern that the software was becoming too bloated. It has always been my view (within reason of course,) that you have to allow and accept a certain degree of "bloat overhead" to allow for flexibility you won't know you need until you need it.
A good example in my case was the ability to specify a certain number of loops in a cue. If I knew how many loops I needed, I would just build it into the original cue and that would be the end of it. However, on my current show I suddenly find the feature indispensable for a big cue at the end.
Despite, the program having grown over the past few years I've found my (aging) computer's ability to run the program, and the speed with which I can program my shows remarkable compared to SCS' much bigger and much more expensive cousins. I think it's important for us all to remember that loyalty to his growing customer base means loyalty to all his customers. If the features he's added don't currently inhibit your usage of SCS, why worry about what might happen in the future. If the time comes that something is added or changed that negatively impacts your usage, I have no doubt that Mike will be more than happy to listen to and try to address your concerns. He's created an easy to use, powerful product for a very particular market at a price point that makes it an option to many users who might otherwise still be stuck in the dark ages with CD's or minidiscs on all but their biggest shows.
Just my unrequested 2 cents.
Matthew T. Lebe
-Freelance Audio, NYC
A good example in my case was the ability to specify a certain number of loops in a cue. If I knew how many loops I needed, I would just build it into the original cue and that would be the end of it. However, on my current show I suddenly find the feature indispensable for a big cue at the end.
Despite, the program having grown over the past few years I've found my (aging) computer's ability to run the program, and the speed with which I can program my shows remarkable compared to SCS' much bigger and much more expensive cousins. I think it's important for us all to remember that loyalty to his growing customer base means loyalty to all his customers. If the features he's added don't currently inhibit your usage of SCS, why worry about what might happen in the future. If the time comes that something is added or changed that negatively impacts your usage, I have no doubt that Mike will be more than happy to listen to and try to address your concerns. He's created an easy to use, powerful product for a very particular market at a price point that makes it an option to many users who might otherwise still be stuck in the dark ages with CD's or minidiscs on all but their biggest shows.
Just my unrequested 2 cents.
Matthew T. Lebe
-Freelance Audio, NYC
-
Bruce Richardson
- Posts: 22
- Joined: Wed Jan 21, 2009 7:43 am
Re: Functionality vs Bloatware
Hello Mike and fellow designers,
I have recently licensed SCS and begun using it. I viewed this thread with great interest.
For me, the deciding factor in moving to SCS was an email conversation I had with Mike. I spoke with him about a specific UI idea, the expansion of the waveform readout to accommodate much more shaping.
It was his response that made me realize I'd found a new "home." Rather than answer back something like "Why would you need that?" or "That's the job of editing software," he had a different response. He said (paraphrasing), "You know, there are some other requests for similar function that might all be accommodated by some UI work there. Why don't you let me think about it and see if this could solve several things at once?"
To me, that is the sign of an open and mature approach to software writing...not saying yes to every idea that comes along, but similarly, always being on the lookout for solutions to design problems.
I am a user who will always be looking for enhancements. Not because I'm feature-crazy, or painting up my shows like a ten-dollar crack whore, but because I'm a composer and designer, and integrating original music to action --seamlessly-- often requires literally doing a realtime mix of the music along with the design. Before software playback, the idea of actually SCORING a play was nearly impossible. You could write some scene music and hope for the best, but given the variables of live performance, it was difficult to justify the means required to reach an acceptable end. But by composing slip-points as part of the score, and creating multitrack mixes that can actually dovetail together imperceptibly, it is possible for me to score a scene almost exactly as I would do it for a film. And I am always looking for more enhancements to that process, in order to be able to achieve a higher end result.
Sometimes that end result isn't adding more "stuff" to the show, but rather, to add more subtlety, so that the end result is more perfectly organic to the overall production.
All of this is to say that the great variability of end uses that Mike mentioned is a big factor in the function vs. bloat debate. I've been at this long enough to bite my tongue when I'm tempted to ask, "Why would anyone want that?" Because it's likely that if the feature is there, I will find a creative use for it somewhere down the line...
I have recently licensed SCS and begun using it. I viewed this thread with great interest.
For me, the deciding factor in moving to SCS was an email conversation I had with Mike. I spoke with him about a specific UI idea, the expansion of the waveform readout to accommodate much more shaping.
It was his response that made me realize I'd found a new "home." Rather than answer back something like "Why would you need that?" or "That's the job of editing software," he had a different response. He said (paraphrasing), "You know, there are some other requests for similar function that might all be accommodated by some UI work there. Why don't you let me think about it and see if this could solve several things at once?"
To me, that is the sign of an open and mature approach to software writing...not saying yes to every idea that comes along, but similarly, always being on the lookout for solutions to design problems.
I am a user who will always be looking for enhancements. Not because I'm feature-crazy, or painting up my shows like a ten-dollar crack whore, but because I'm a composer and designer, and integrating original music to action --seamlessly-- often requires literally doing a realtime mix of the music along with the design. Before software playback, the idea of actually SCORING a play was nearly impossible. You could write some scene music and hope for the best, but given the variables of live performance, it was difficult to justify the means required to reach an acceptable end. But by composing slip-points as part of the score, and creating multitrack mixes that can actually dovetail together imperceptibly, it is possible for me to score a scene almost exactly as I would do it for a film. And I am always looking for more enhancements to that process, in order to be able to achieve a higher end result.
Sometimes that end result isn't adding more "stuff" to the show, but rather, to add more subtlety, so that the end result is more perfectly organic to the overall production.
All of this is to say that the great variability of end uses that Mike mentioned is a big factor in the function vs. bloat debate. I've been at this long enough to bite my tongue when I'm tempted to ask, "Why would anyone want that?" Because it's likely that if the feature is there, I will find a creative use for it somewhere down the line...