The answer is the list. Where does one learn this? I searched for the
term bug at the big three obvious places:

The Canonical Csound Reference Manual (index.html)
http://csound.sourceforge.net/ (including the faq page)
http://www.csounds.com/ (all main pages)

None of them turn up any information about how or where to submit bugs.

Want to know the only place I've been able to find out where I should
send bug reports?  Read the bottom of this email. That's right, the
only place I found where it says you should report bugs to the list is
at the footer of the list. Consider the implications. Imagine how many
bugs never get caught because of this GLARING hole in our bug net.

What can be done to improve this?

Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

How about your noisepages blog and a couple places in the online  
copies of EAST v. 1 and 2 to start?

No offense intended, a lot of things you wrote were my "now what?"  
experience with csound. They showed up in searches and were about  
appropriate when I got bored with the material in Doc Boulanger's  
t00ts - i.e. hitting stride with users starting to make instruments  
that could really go wrong and it not be a simple typo, or goofy crap  
like using loscil for the first time.
That sounds like who we really need to report more bugs, right?

Greg

On Feb 24, 2010, at 5:38 AM, Jacob Joaquin wrote:

> The answer is the list. Where does one learn this? I searched for the
> term bug at the big three obvious places:
>
> The Canonical Csound Reference Manual (index.html)
> http://csound.sourceforge.net/ (including the faq page)
> http://www.csounds.com/ (all main pages)
>
> None of them turn up any information about how or where to submit  
> bugs.
>
> Want to know the only place I've been able to find out where I should
> send bug reports?  Read the bottom of this email. That's right, the
> only place I found where it says you should report bugs to the list is
> at the footer of the list. Consider the implications. Imagine how many
> bugs never get caught because of this GLARING hole in our bug net.
>
> What can be done to improve this?
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

There could be a button in the help menu of Qutecsound, also Csound itself
could print a link whenever it crashes, or a link in the man pages. However,
if the invitation to report bugs is too loud then users might get tempted to
report everything when something doesn't work, and that's clearly something
the developers wouldn't want.



Jacob Joaquin wrote:
> 
> The answer is the list. Where does one learn this? I searched for the
> term bug at the big three obvious places:
> 
> The Canonical Csound Reference Manual (index.html)
> http://csound.sourceforge.net/ (including the faq page)
> http://www.csounds.com/ (all main pages)
> 
> None of them turn up any information about how or where to submit bugs.
> 
> Want to know the only place I've been able to find out where I should
> send bug reports?  Read the bottom of this email. That's right, the
> only place I found where it says you should report bugs to the list is
> at the footer of the list. Consider the implications. Imagine how many
> bugs never get caught because of this GLARING hole in our bug net.
> 
> What can be done to improve this?
> 
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

> How about your noisepages blog and a couple places in the online copies of
> EAST v. 1 and 2 to start?
>
> No offense intended, a lot of things you wrote were my "now what?"
> experience with csound. They showed up in searches and were about
> appropriate when I got bored with the material in Doc Boulanger's t00ts -
> i.e. hitting stride with users starting to make instruments that could
> really go wrong and it not be a simple typo, or goofy crap like using loscil
> for the first time.
> That sounds like who we really need to report more bugs, right?

No offense taken. And I actually think there is a lot of truth to what
you are saying.

You bring up another interesting point. There does seem to be this
lack of guidance through the existing material. One where does start?
Then what? And then what?  More or less, there could be a guide or
guides that present a logical progression of tutorials, which may
include comments to help fill in the gaps in-between.

Best,
Jake

Great suggestion.

In addition to on the list....

There should be info in the manual:
- on where and how to report bugs (like include the .csd)
- on where and how to post suggestions (for opcodes or features)
(maybe something at cSounds.com to host them)

And, there should be buttons/links/menus in QuteCsound that take you  
to the bugPage and the FeatureRequest Page
- at either SourceForge or cSounds.com or both.

Dr. B.

On Feb 23, 2010, at 4:08 PM, moleculeColony wrote:

>
> There could be a button in the help menu of Qutecsound, also Csound  
> itself
> could print a link whenever it crashes, or a link in the man pages.  
> However,
> if the invitation to report bugs is too loud then users might get  
> tempted to
> report everything when something doesn't work, and that's clearly  
> something
> the developers wouldn't want.
>
>
>
> Jacob Joaquin wrote:
>>
>> The answer is the list. Where does one learn this? I searched for the
>> term bug at the big three obvious places:
>>
>> The Canonical Csound Reference Manual (index.html)
>> http://csound.sourceforge.net/ (including the faq page)
>> http://www.csounds.com/ (all main pages)
>>
>> None of them turn up any information about how or where to submit  
>> bugs.
>>
>> Want to know the only place I've been able to find out where I should
>> send bug reports?  Read the bottom of this email. That's right, the
>> only place I found where it says you should report bugs to the list  
>> is
>> at the footer of the list. Consider the implications. Imagine how  
>> many
>> bugs never get caught because of this GLARING hole in our bug net.
>>
>> What can be done to improve this?
>>
>> Best,
>> Jake
>> --
>> The Csound Blog - http://csound.noisepages.com/
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
> -- 
> View this message in context: http://old.nabble.com/Where-does-one-go-to-report-bugs--tp27710093p27710535.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I'm using Haskell, and they have quite a funny compiler message on certain
errors:

ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.4 for x86_64-unknown-linux):
        charType: '\167'

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


...I guess the developers are more interested in certain bugs than in
others, so maybe it's a good idea to make the csound program react
differently to different sorts of error.




csounder wrote:
> 
> Great suggestion.
> 
> In addition to on the list....
> 
> There should be info in the manual:
> - on where and how to report bugs (like include the .csd)
> - on where and how to post suggestions (for opcodes or features)
> (maybe something at cSounds.com to host them)
> 
> And, there should be buttons/links/menus in QuteCsound that take you  
> to the bugPage and the FeatureRequest Page
> - at either SourceForge or cSounds.com or both.
> 
> Dr. B.
> 
> On Feb 23, 2010, at 4:08 PM, moleculeColony wrote:
> 
>>
>> There could be a button in the help menu of Qutecsound, also Csound  
>> itself
>> could print a link whenever it crashes, or a link in the man pages.  
>> However,
>> if the invitation to report bugs is too loud then users might get  
>> tempted to
>> report everything when something doesn't work, and that's clearly  
>> something
>> the developers wouldn't want.
>>
>>
>>
>> Jacob Joaquin wrote:
>>>
>>> The answer is the list. Where does one learn this? I searched for the
>>> term bug at the big three obvious places:
>>>
>>> The Canonical Csound Reference Manual (index.html)
>>> http://csound.sourceforge.net/ (including the faq page)
>>> http://www.csounds.com/ (all main pages)
>>>
>>> None of them turn up any information about how or where to submit  
>>> bugs.
>>>
>>> Want to know the only place I've been able to find out where I should
>>> send bug reports?  Read the bottom of this email. That's right, the
>>> only place I found where it says you should report bugs to the list  
>>> is
>>> at the footer of the list. Consider the implications. Imagine how  
>>> many
>>> bugs never get caught because of this GLARING hole in our bug net.
>>>
>>> What can be done to improve this?
>>>
>>> Best,
>>> Jake
>>> --
>>> The Csound Blog - http://csound.noisepages.com/
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>>
>>
>> -- 
>> View this message in context:
>> http://old.nabble.com/Where-does-one-go-to-report-bugs--tp27710093p27710535.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

I've thought about this before. The output from Csound errors don't
make much sense to non programmers, i.e., undefined variables and what
not. It wouldn't be tricky to modify these, one could even turn on a
verbose error messaging system for beginners so instead of getting

"error:  input arg 'a2' used before defined, line 21:"

Csound might spit out:

"Csound came across 'a2' on line 21 and got confused. Csound has never
seen this variable before which means that you have not  defined it in
the preceding lines of code. Please be nice and define a2 or Csound
will come and bit-crunch you into tiny little pieces...."

All joking aside though I do think the error messages could be more
user friendly. This idea could be taken further whereby each error is
explained in context in an aid to teach people where they have gone
wrong in their code, i.e., explain in lay man's terms what the problem
is.

Rory.


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I don't know about others, but when I started to learn Csound some 5 years
ago, there was no "alternative" (now "canonical") Reference Manual, so I
only had the then official one, and there were only a few tutorial pages at
the end. Them I read first, and afterwards I went through all the opcodes
one by one, trying them out in small self-made programs. (Without FLTK,
which only later became my friend for tweaking parameters in real-time.)

It took me some three or four weeks (full-time, as these was during
holidays), and in the end I had some quite broad overview over all the
opcodes. The most fascinating thing was that I didn't know anything about
sound processing before that, so all the material in the manual was an
introduction into concepts of additive or subtractive synthesis, etc., as
well. Thanks, Csound, for that, and I still believe that the educational
value of this program is one of its greatest virtues.

Don't know if more tutorials really is what we need, as you only have a
certain amount of your lifetime to spend on reading, and the material
presented for you to read should be as minimized as possible. So probably
some reordering and tightening of the existing manual (which I think is very
good already) is enough to give both the beginner and the expert everything
they need.

Order is important here. The beginner tends to start reading from the
beginning, and the first thing he encounters which he doesn't understand
either makes him stop thinking about it till he understands, or it makes him
start skipping more and more that belongs to higher levels, so a good idea
would be to sort the manual in a way that the most important and most basic
things are at the beginning, and advanced tweaking options and complex
opcodes only come later.

This was good in earlier versions of the manual, but as Csound gets bigger
and bigger, nowadays I see too much information up front before you get
towards starting programming with oscil and noise.

Since I do not know programming in C, and since other people already started
offering their contribution into making Csound better at this point of
history, maybe I could lend a hand also and get incorporated into a group
that tries to lift our manual into the future.

Cheers,
Erich




Jacob Joaquin wrote:
> 
> You bring up another interesting point. There does seem to be this
> lack of guidance through the existing material. One where does start?
> Then what? And then what?  More or less, there could be a guide or
> guides that present a logical progression of tutorials, which may
> include comments to help fill in the gaps in-between.
> 
> Best,
> Jake
>