Recent on Mstation: music: Vivian Girls, America's Cup, music: Too Young to Fall..., music: Pains of Being Pure At Heart, Berlin Lakes, music: Atarah Valentine, Travel - Copenhagen, House in the Desert
front page / music / software / games / hardware /wetware / guides / books / art / search / travel /rss / podcasts / contact us
I know you have plans for some new features someday. Would you like to outine them? Mention a timetable (heh heh)?
Time is always the main problem for home-based projects, especially once they get beyond the exciting first stage and into “actual” development.I work as a senior software engineer these days so when I get home the last thing I want to do is concentrate on software !! This means it is pretty impossible to propose any timetable but I guess the main developments would include:
* Revamping the DAP web-site (courtesy of my good lady whose is currently studying software development !!) - December 2001
* Finishing off unimplemented features (eg multi-band EQ) - early 2002
* Adding direct-to-disk support - late 2002
* Adding context sensitive help, tooltips, keyboard shortcuts - during 2002
What do you think of the future of open source development? Right now we are dependant on student programmers and enthusiasts mostly and this seems to work quite well except where the project is very big in which case there seems to be a big element of luck as to whether people will support the project or not. Do you think the current model is sustainable?
I think the model _is_ sustainable, up to a point. The main problem is with platform choice and support - the majority of students and academics, in my experience, are Unix oriented. This means (IMHO) that the majority of open-source/GPL/freeware projects are Unix-based. This is, of course, no bad thing in itself but once projects begin to take on a more commercial size or stature, unless they have the ability to move to Windows it can be difficult for them to progress much beyond “student project” status - DAP being a good (or is that bad) example of this :( For the record I don’t think Unix is better than Windows or vice-versa (they are just different) but unless projects have the ability to move successfully to Windows, which is without doubt the most common commercial desktop platform, they probably won’t be seen by industry to be of “commercial quality” - which simply means they are viewed asprojects rather than commercially useful software. You may be wondering why I think this is so important ? This is because, again in my opinion, unless software can be viewed as being commercially viable (whether sold or given away free) it won’t achieve the user base needed to ensure continued support and development and thus won’t achieve its fullpotential.
So, by removing the need for software to be sold to qualify as ‘commercially viable’, would you include programs like emacs or vi which must have huge user bases together with pretty good backup? For me programs like those are the ‘lucky’ ones that gathered some sort of critical mass necessary for continued intensive development.
Those two examples (emacs and vi) _are_ particularly “lucky”, but there are other factors in those cases. I think important factors are that you can work in both vi and emacs quite happily on both Unix and Windows - and thus they become your default editor for all edit operations, on all platforms. They are also text editors, almost certainly learned during academic study and never really “unlearned” - text editors being perhaps the most subjective software tools in the world. Personally I can’t use anything other than NEdit on Unix (used during university) and TextPad on Windows (where I can set all the shortcuts to work like NEdit). Academia is much to “blame” for such habits (and indeed for many anti-Microsoft feelings !!). Emacs and vi were also lucky enough to have no significant competition in the early Unix days and were distributed pretty much by default with most Unix flavours (and were infinitely more powerful than the default text editors that came with the operating system). This may be a reasonably common trait amongst successful open-source projects but it is very tricky to determine why certain projects gain momentum and others fall by the wayside.
Thanks very much Tich.
Richard "Tich" Kent is the developer of DAP. DAP is a comprehensive audio sample editing and processing suite. DAP currently supports AIFF, AIFF-C, WAV and RAW audio files, 8 or 16 bit resolution and 1, 2 or 4 channels of audio data. The package itself offers comprehensive editing, playback and recording facilities including full time stretch resampling, manual data editing and a reasonably complete DSP processing suite. DAP Homepage
As for how DAP started I essentially needed an honours project to complete in the fourth (and final) year of my Computer Science degree at Heriot Watt University (92 to 96). I initially picked one of the “preset” projects - a new GUI for Mathematica - but quickly realised I had absolutely no interest in this at all !! So I decided to try and come up with a project in a field I was actually interested in - digital audio and sampling. I’d been playing with synths and samplers since an early age (and am a classical pianist) but never really knew how they all worked so it seemed like a perfect idea for a project. That idea was to design and implement a comprehensive audio editing package for SGIworkstations, which had fantastic audio hardware but very limited and basic audio software (at the time).The completion of this project gave rise to the first version of DAP (SGIonly) which was pretty basic (eg mono operation only). It also gave me an excellent degree and won me the “Young Software Engineer of the Year 1996” award - the judges obviously liked it !!I then I had the summer off (after I completed my degree) to basically chill-out and relax before starting “proper” work. I spent this time adding multi-channel support to DAP and writing the first Linux port. I continued working reasonably heavily on DAP throughout my first job (until September1997) which saw it transform into today’s version of DAP. Sadly my work on DAP has since tailed off but I am considering an overhaul. I quite fancy trying a Java port as I’ve heard good things about the Java sound API, and I really (really) must implement direct-to-disk editing to let people work with larger audio files. One day...
In doing DAP as a degree project I wonder if you did the full software engineering thing of spelling out requirements and being properly organised with your code. Or was it more of a seat of the pants thing? If the former, do you think starting coders should spend more time on the tedious aspects as it leads to better code at the end? And if the latter, ...??
The former !! As DAP was indeed a university project we were “forced” to go through a proper set of software engineering stages - requirements gathering/analysis, software design and implementation/testing. Each of the three phases lasted an academic term. I have to admit this was probably the best engineered project I have ever worked on - that’s not to congratulate myself but instead highlight that in the “real world” (in my experience) actual “software engineering” is never performed so neatly and methodically. And I can state whole-heartedly that the more analysis and design you can do in the first instance the more pain you’ll save yourself later on. I may start to sound like an cynical oldie here but nearly all of the commercial projects I have been involved in have had ridiculously short analysis and design stages (due to marketing pressure requiring results and prototypes quickly) and this always leads to problematic, badly thought out code that in the end greatly reduces software quality. That’s not to say being able to code “by the seat ofyour pants” isn’t an invaluable skill but it’s never going to produce efficient and maintainable code :( Besides these days I find the design stage,producing all those pretty UML diagrams, much more fun than the hard slog of coding !!
Yes, that’s my experience too and quite often the project managers seem to come from non-coding backgrounds which doesn’t help. Anyway! Did you have any prior experience with DSP before you started or did you pick that up as you went along?
Before DAP I had no experience at all with DSP. I’d been using effects processors (and synths) for years but never really investigated the theory behind it all. Basically for DAP I had to learn the ins and outs of DSP as Iwent along. My main point of reference was a book called “Elements of ComputerMusic” by “F. Richard Moore”. This excellent book helped me out a great deal,especially for the resampling routines.
How did you formulate the specific functions that you eventually coded in?
My main aim for DAP was to code a “good” audio editing package for Unix. At the time I was using AudioMaster IV on my beloved Amiga for sample editing and the features available in this excellent editor, combined with the features available in decent PC based editors (Cool Edit and Gold Edit were popular atthe time) helped define the baseline features that should be available.After this I simply extended the requirements to include features that Ithought would be extremely useful (DSP effects, proper resampling, complete loop control, etc). For the DSP effects themselves I basically nabbed the majority of the effects definitions, albeit in simplified form, from my Sony HRMP5 effects processor (whose manual is still the only real guide to DAP’s many effects parameters !!) and the reverb algorithms from well documented ”standard” reverb routines.
Did you have any particular method with testing? ... Intuitive testing of features as they were written or something more rigourous?
tAs part of the dissertation work we had to do a test/evaluation phase but I didn’t use any particular methodology. Essentially the majority of testing was performed by myself during development, often with small command-line test programs to test specific features. I then carried out a “user evaluation” where I got ten of my colleagues to run through a set of tasks using DAP - they were timed for each task and asked to complete a questionnaire at the end.The real testing, however, was when I placed a free copy of DAP for download on the internet and emailed the appropriate (SGI-based) newsgroups. This lead to a good response from the SGI community including emails asking for more information, bug reports and suggestions for the future. This uncontrolled testing was highly successful, but of course only really works for relatively small free/shareware projects like DAP. Top of next column