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
|
|
||||||
| |
|||||||
|
Tich
Kent: 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... M
station:
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
|
|
||||||
| |
|||||||
| |
|
|
|
|
|
|
|