| I'd love to help out with this.
That's what I enjoy doing the most.
It would help me learn csound much quicker.
A suggestion.
This needs to include backwards compatibility issues, yes?
So new Csound does not break old Orc/Sco, correct.
Use tried and true 'archive' compositions as part of the testing process.
They're quite wonderful and refreshing to hear again.
A question.
This came up before on the list.
Someone mentioned, "How do you validate the results if binary compare is not
an option?"
I ask, how would you know if something is only slightly broken, as in some
math somewhere is just 'a little bit off'?
Another suggestion that would help users immensely.
All opcodes (funtions, the whole bit) could each have useable and useful
example Orc/Sco's in the doc.
Before the flames start, this would be in the context of just enough to get
the idea across for users.
Where this would come in real handy for this "Csound QA Testing Team", white
box method of test where the opcode/function developer knows the range and
extent of what the code should do would write test code that also
demonstrates (and attempts to go beyond) the 'bounds' of said code.
What I see happening if it gets off the ground is two things, both
beneficial to the Csound community.
We as users/testers would have a bank of known good code to work from that
would allow the test team to put together the test scripts with less hassle
AND the users some know good code to get a better handle quicker what all
this stuff is for and about.
Details on request.
My day job is software/hardware test.
The main reason I have so little time in on Csound.
A warning.
Opening the door to Csound QA ...
There's no turning back.
It's a life-long commitment, but long overdue here...
Thanks Gabriel, for the suggestion....
-----Original Message-----
From: owner-csound-outgoing@maths.ex.ac.uk
[mailto:owner-csound-outgoing@maths.ex.ac.uk]On Behalf Of Gabriel
Maldonado
Sent: Friday, October 08, 1999 1:33 AM
To: Csound Mailing List
Subject: Csound Beta Tester Team
Dear Csound Community,
I propose to divide the huge work of testing ALL Csound, opcodes,
providing a simple, short and essential example for each one
(DirectCsound now gives a count of 727(!!!) opcodes including original
Perry Cook ToolKit, DS3d and EAX opcodes). This will hugely help the
developers to mantain the various versions, by batch testing all opcodes
(some old opcodes could be broken in newer versions). Those examples can
also be included in the manual. Unfortunately testing an opcode, can
sometime require more time than implement a new one.
So I'm searching many willing csounders in order to organize a division
of this hard work.
Any candidate can be included in the Team. We can divide the opcodes in
family groups or proceed alphabetically. Any idea?
P.S. I remember that an alphabetical list of all opcodes implemented in
a Csound version can be obtained by running Csound with the following
command line:
csound --opcodes.txt -z1
where the file "opcodes.txt" is the target text file containing the
list.
BtW: How many people is included in this list?
Thanks in advance
--
Gabriel Maldonado
http://web.tiscalinet.it/G-Maldonado |