Hi all,
I'm writing simple sounds (for use as samples in another app) from
the command line on an olpc, and I am having a few serious problems.
The biggest one is that rendering to .wav ALWAYS makes the file sound very
very different than playing the .csd file through csound.
This has been happening consistently for the 1 month or so I've been
experimenting with Csound.

The other problem I'm having is using 0dbfs = 1 in the header of my
orchestra, as the reference manual suggests I should. This gives me
unlistenable, clipping high volume regardless of amplitude, and reducing
the value of 0dbfs, or reducing the amplitudes in my score, literally
makes my sounds fall apart - oscillators sound like they're going out of
tune with each other, etc.
Where should I start tinkering here? I am generally not having buffer
issues, so I don't know where else to look.
Thanks in advance,
Greg

You are using 0dBFS=1, and calling ampdb(40) (i.e. "plus 40dB"), with an 
lfo amp of 900. What do you intend the output level level to be?

Try calling ampdb(-10), and an lfo amp of 1.

The 0dBFS enables you to dictate what your amplitude numbers mean in 
relation to digital peak. With 0dBFS = 1, your code needs to generate 
~all~ amplitude levels < 1. Could be a lot less, according to need, but 
certainly not more.


Richard Dobson


Greg Schroeder wrote:
> Hi all,
> I'm writing simple sounds (for use as samples in another app) from
> the command line on an olpc, and I am having a few serious problems.
> The biggest one is that rendering to .wav ALWAYS makes the file sound very
> very different than playing the .csd file through csound.
> This has been happening consistently for the 1 month or so I've been
> experimenting with Csound.
> 
> The other problem I'm having is using 0dbfs = 1 in the header of my
> orchestra, as the reference manual suggests I should. This gives me
> unlistenable, clipping high volume regardless of amplitude, and reducing
> the value of 0dbfs, or reducing the amplitudes in my score, literally
> makes my sounds fall apart - oscillators sound like they're going out of
> tune with each other, etc.
> Where should I start tinkering here? I am generally not having buffer
> issues, so I don't know where else to look.
> Thanks in advance,
> Greg
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Yes, that's MUCH better. Thank you!
And that seems to have fixed the differences between playing .csd files
and their .wav files.
:)
Sweet.
Greg

On Tue, 10 Feb 2009, Richard Dobson wrote:

> You are using 0dBFS=1, and calling ampdb(40) (i.e. "plus 40dB"), with an lfo
> amp of 900. What do you intend the output level level to be?
>
> Try calling ampdb(-10), and an lfo amp of 1.
>
> The 0dBFS enables you to dictate what your amplitude numbers mean in relation
> to digital peak. With 0dBFS = 1, your code needs to generate ~all~ amplitude
> levels < 1. Could be a lot less, according to need, but certainly not more.
>
>
> Richard Dobson
>
>
> Greg Schroeder wrote:
> > Hi all,
> > I'm writing simple sounds (for use as samples in another app) from
> > the command line on an olpc, and I am having a few serious problems.
> > The biggest one is that rendering to .wav ALWAYS makes the file sound very
> > very different than playing the .csd file through csound.
> > This has been happening consistently for the 1 month or so I've been
> > experimenting with Csound.
> >
> > The other problem I'm having is using 0dbfs = 1 in the header of my
> > orchestra, as the reference manual suggests I should. This gives me
> > unlistenable, clipping high volume regardless of amplitude, and reducing
> > the value of 0dbfs, or reducing the amplitudes in my score, literally
> > makes my sounds fall apart - oscillators sound like they're going out of
> > tune with each other, etc.
> > Where should I start tinkering here? I am generally not having buffer
> > issues, so I don't know where else to look.
> > Thanks in advance,
> > Greg
> > 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"
>

Hi Greg,

Do you have any suggestions for the manual to help other users avoid
this problem?

Cheers,
Andrés

On Tue, Feb 10, 2009 at 7:43 AM, Greg Schroeder  wrote:
> Yes, that's MUCH better. Thank you!
> And that seems to have fixed the differences between playing .csd files
> and their .wav files.
> :)
> Sweet.
> Greg
>
> On Tue, 10 Feb 2009, Richard Dobson wrote:
>
>> You are using 0dBFS=1, and calling ampdb(40) (i.e. "plus 40dB"), with an lfo
>> amp of 900. What do you intend the output level level to be?
>>
>> Try calling ampdb(-10), and an lfo amp of 1.
>>
>> The 0dBFS enables you to dictate what your amplitude numbers mean in relation
>> to digital peak. With 0dBFS = 1, your code needs to generate ~all~ amplitude
>> levels < 1. Could be a lot less, according to need, but certainly not more.
>>
>>
>> Richard Dobson
>>
>>
>> Greg Schroeder wrote:
>> > Hi all,
>> > I'm writing simple sounds (for use as samples in another app) from
>> > the command line on an olpc, and I am having a few serious problems.
>> > The biggest one is that rendering to .wav ALWAYS makes the file sound very
>> > very different than playing the .csd file through csound.
>> > This has been happening consistently for the 1 month or so I've been
>> > experimenting with Csound.
>> >
>> > The other problem I'm having is using 0dbfs = 1 in the header of my
>> > orchestra, as the reference manual suggests I should. This gives me
>> > unlistenable, clipping high volume regardless of amplitude, and reducing
>> > the value of 0dbfs, or reducing the amplitudes in my score, literally
>> > makes my sounds fall apart - oscillators sound like they're going out of
>> > tune with each other, etc.
>> > Where should I start tinkering here? I am generally not having buffer
>> > issues, so I don't know where else to look.
>> > Thanks in advance,
>> > Greg
>> > 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"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 


Andrés

Greg Schroeder wrote:
..
> Mr. (Dr.?) Dobson's response makes it sound as if it were common sense 
> to expect a gigantic output at 40 db. However, Dr. Boulanger's 
> tutorials, for example, regularly give db values > 60 (I just spotted an 
> 85 in the beginner tutorial on GENs) with no explanation for the changes 
> in value between the examples, and no defined 0dbfs. Vercoe just uses 
> raw amplitude.


This is very possibly an issue for documentation, though it is not so 
easy to see where it might go.  The original version of Csound had no 
0dBFS mechanism, and (in being based on an explicit 32767 range for 
amplitude) used the ampdb opcode such that a value of 90-odd gave 
digital peak, and a value of 40 was naturally somewhat quieter.

This however is not in accordance with conventions in the audio 
industry, which defines digital peak as 0dB and all lower levels 
therefore are indicated with a negative dB value. So, for example, -6dB 
maps to an amplitude of 0.5 (approx). I introduced the ambdbfs and 
dbfsamp  pair of opcodes to address this anomaly, and they are 
recommended for all new orchestras. However the original amp/db opcodes 
cannot be removed, as so many orchestras depend on it; and as Victor 
recently pointed out, they can still be useful for other tasks, as they 
just perform a standard log10 calculation.

I later added the 0dBFS opcode as a more generalised solution, given 
that we needed  much more scope for reading and writing soundfiles of 
any sample size, so that the old 32767 default was increasingly 
meaningless (and indeed confusing). Arguably an amplitude scale of +-1.0 
is more logical these days (all plugin formats use that for example, as 
does SAOL); but you can in fact use any value you like for 0dBFS. With 
0dBFS = 1, the old and new amp/db opcodes do the same thing. But just 
adding it to an old-style orchestra without adjusting explicit level 
values is bound to create problems such as you have encountered

You have hit the eternal Csound problem of changes and additions of 
opcodes (that in various ways encourage new ways of thinking), while 
retaining all the old ones for backwards compatibility. One solution may 
be a general "compatibility" section in the manual somewhere, that 
collates all these changes - there is a number of opcodes still in the 
system that have been substituted by newer enhanced (or even corrected) 
ones.

Amplitude unfortunately is a subject affected variously by a number of 
these recent changes, such that it can indeed be a problem to use some 
old and some new together, especially when exploring some of the 
examples in the Csound book which follow the original "canonical" opcode 
usage.

Richard Dobson

I'm not sure my comments are directly related to the ampdb issue as  
much as to the manual in general. I was recently doing some less-than- 
usual table reading tasks and I found I couldn't understand the manual  
entry, principally because they were couched in quasi-musical language  
rather than describing what the opcode actually did. I also can across  
quite a lot of 'loose' language - 'note' being used for 'pitch',  
'pitch' for 'frequency' etc. I'm sure y'all get the drift. I would  
like to see a project where the manual underwent a parallel revision/ 
development path to that of the code. It is a big task however and  
best achieved over time, wording for entries even discussed via a wiki  
or something. One advantage of such a process would be an increase in  
the general knowledge of opcodes, etc.
BTW, what happened to the 'display of a random opcode' on the home page?

D.

On 11/02/2009, at 8:48 PM, Richard Dobson wrote:

> Greg Schroeder wrote:
> ..
>> Mr. (Dr.?) Dobson's response makes it sound as if it were common  
>> sense to expect a gigantic output at 40 db. However, Dr.  
>> Boulanger's tutorials, for example, regularly give db values > 60  
>> (I just spotted an 85 in the beginner tutorial on GENs) with no  
>> explanation for the changes in value between the examples, and no  
>> defined 0dbfs. Vercoe just uses raw amplitude.
>
>
> This is very possibly an issue for documentation, though it is not  
> so easy to see where it might go.  The original version of Csound  
> had no 0dBFS mechanism, and (in being based on an explicit 32767  
> range for amplitude) used the ampdb opcode such that a value of 90- 
> odd gave digital peak, and a value of 40 was naturally somewhat  
> quieter.
>
> This however is not in accordance with conventions in the audio  
> industry, which defines digital peak as 0dB and all lower levels  
> therefore are indicated with a negative dB value. So, for example,  
> -6dB maps to an amplitude of 0.5 (approx). I introduced the ambdbfs  
> and dbfsamp  pair of opcodes to address this anomaly, and they are  
> recommended for all new orchestras. However the original amp/db  
> opcodes cannot be removed, as so many orchestras depend on it; and  
> as Victor recently pointed out, they can still be useful for other  
> tasks, as they just perform a standard log10 calculation.
>
> I later added the 0dBFS opcode as a more generalised solution, given  
> that we needed  much more scope for reading and writing soundfiles  
> of any sample size, so that the old 32767 default was increasingly  
> meaningless (and indeed confusing). Arguably an amplitude scale of  
> +-1.0 is more logical these days (all plugin formats use that for  
> example, as does SAOL); but you can in fact use any value you like  
> for 0dBFS. With 0dBFS = 1, the old and new amp/db opcodes do the  
> same thing. But just adding it to an old-style orchestra without  
> adjusting explicit level values is bound to create problems such as  
> you have encountered
>
> You have hit the eternal Csound problem of changes and additions of  
> opcodes (that in various ways encourage new ways of thinking), while  
> retaining all the old ones for backwards compatibility. One solution  
> may be a general "compatibility" section in the manual somewhere,  
> that collates all these changes - there is a number of opcodes still  
> in the system that have been substituted by newer enhanced (or even  
> corrected) ones.
>
> Amplitude unfortunately is a subject affected variously by a number  
> of these recent changes, such that it can indeed be a problem to use  
> some old and some new together, especially when exploring some of  
> the examples in the Csound book which follow the original  
> "canonical" opcode usage.
>
> Richard Dobson
>
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg
- MARCS Auditory Laboratories: marcs.uws.edu.au

Hi,

The manual can always use help. It is huge and some entries even date
back to the original 1980s documentation. The best way to help is by
actually submitting ideas and contributing directly. It would be great
if you can post suggestions and actual wordings for a particular page.
It is very helpful to edit the xml files directly, but if you want to
contribute just plain text that is also extremely helpful. If you want
to organize a project, that would also be great, but it may be harder
to do this than to contribute little by little. For terminology issues
where note is used when pitch should be used, there's no need to
consult, but for deeper issues like the recent types vs. rate vs.
signal discussion, the list can give very interesting ideas.

Cheers,
Andrés

On Wed, Feb 11, 2009 at 6:47 AM, DavidW  wrote:
> I'm not sure my comments are directly related to the ampdb issue as much as
> to the manual in general. I was recently doing some less-than-usual table
> reading tasks and I found I couldn't understand the manual entry,
> principally because they were couched in quasi-musical language rather than
> describing what the opcode actually did. I also can across quite a lot of
> 'loose' language - 'note' being used for 'pitch', 'pitch' for 'frequency'
> etc. I'm sure y'all get the drift. I would like to see a project where the
> manual underwent a parallel revision/development path to that of the code.
> It is a big task however and best achieved over time, wording for entries
> even discussed via a wiki or something. One advantage of such a process
> would be an increase in the general knowledge of opcodes, etc.
> BTW, what happened to the 'display of a random opcode' on the home page?
>
> D.
>
> On 11/02/2009, at 8:48 PM, Richard Dobson wrote:
>
>> Greg Schroeder wrote:
>> ..
>>>
>>> Mr. (Dr.?) Dobson's response makes it sound as if it were common sense to
>>> expect a gigantic output at 40 db. However, Dr. Boulanger's tutorials, for
>>> example, regularly give db values > 60 (I just spotted an 85 in the beginner
>>> tutorial on GENs) with no explanation for the changes in value between the
>>> examples, and no defined 0dbfs. Vercoe just uses raw amplitude.
>>
>>
>> This is very possibly an issue for documentation, though it is not so easy
>> to see where it might go.  The original version of Csound had no 0dBFS
>> mechanism, and (in being based on an explicit 32767 range for amplitude)
>> used the ampdb opcode such that a value of 90-odd gave digital peak, and a
>> value of 40 was naturally somewhat quieter.
>>
>> This however is not in accordance with conventions in the audio industry,
>> which defines digital peak as 0dB and all lower levels therefore are
>> indicated with a negative dB value. So, for example, -6dB maps to an
>> amplitude of 0.5 (approx). I introduced the ambdbfs and dbfsamp  pair of
>> opcodes to address this anomaly, and they are recommended for all new
>> orchestras. However the original amp/db opcodes cannot be removed, as so
>> many orchestras depend on it; and as Victor recently pointed out, they can
>> still be useful for other tasks, as they just perform a standard log10
>> calculation.
>>
>> I later added the 0dBFS opcode as a more generalised solution, given that
>> we needed  much more scope for reading and writing soundfiles of any sample
>> size, so that the old 32767 default was increasingly meaningless (and indeed
>> confusing). Arguably an amplitude scale of +-1.0 is more logical these days
>> (all plugin formats use that for example, as does SAOL); but you can in fact
>> use any value you like for 0dBFS. With 0dBFS = 1, the old and new amp/db
>> opcodes do the same thing. But just adding it to an old-style orchestra
>> without adjusting explicit level values is bound to create problems such as
>> you have encountered
>>
>> You have hit the eternal Csound problem of changes and additions of
>> opcodes (that in various ways encourage new ways of thinking), while
>> retaining all the old ones for backwards compatibility. One solution may be
>> a general "compatibility" section in the manual somewhere, that collates all
>> these changes - there is a number of opcodes still in the system that have
>> been substituted by newer enhanced (or even corrected) ones.
>>
>> Amplitude unfortunately is a subject affected variously by a number of
>> these recent changes, such that it can indeed be a problem to use some old
>> and some new together, especially when exploring some of the examples in the
>> Csound book which follow the original "canonical" opcode usage.
>>
>> Richard Dobson
>>
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:       www.avatar.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
> Australian research affiliations:
> - Capital Markets Cooperative Research Centre: www.cmcrc.com
> - Sonic Communications Research Group:  creative.canberra.edu.au/scrg
> - MARCS Auditory Laboratories: marcs.uws.edu.au
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 


Andrés

I think that it would be a good idea for Csound 6 to reorganize section II
of the manual ("Opcodes Overview") so that the currently recommended opcodes
in each section are presented first and older unrecommended, confusing, or
broken opcodes be placed in a "deprecated" section further down in each
section or on an entirely different page.  Perhaps even a page with a table
of "unrecommended" opcodes and a "use instead" recommendation.  Heck, why
not stick a note on the reference pages for each of those opcodes saying the
same thing.

At the same time, we could move many of the obsolete or "unrecommended"
opcodes into a compatibility plugin that would perhaps not be loaded by
default.

One of these days, I will set up the tool chain for the manual on my
computer and get to work ...

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

Richard Dobson wrote on 2/11/09 4:48 AM:

> You have hit the eternal Csound problem of changes and additions of
> opcodes (that in various ways encourage new ways of thinking), while
> retaining all the old ones for backwards compatibility. One solution may
> be a general "compatibility" section in the manual somewhere, that
> collates all these changes - there is a number of opcodes still in the
> system that have been substituted by newer enhanced (or even corrected)
> ones.

I'm all for Anthony's ideas here.  One thing is that I think currently
"deprecated" shows up at end of an opcode reference; it might be worth
placing notes on top of page if we can get that going.

On Wed, Feb 11, 2009 at 12:53 PM, Anthony Kozar
 wrote:
> I think that it would be a good idea for Csound 6 to reorganize section II
> of the manual ("Opcodes Overview") so that the currently recommended opcodes
> in each section are presented first and older unrecommended, confusing, or
> broken opcodes be placed in a "deprecated" section further down in each
> section or on an entirely different page.  Perhaps even a page with a table
> of "unrecommended" opcodes and a "use instead" recommendation.  Heck, why
> not stick a note on the reference pages for each of those opcodes saying the
> same thing.
>
> At the same time, we could move many of the obsolete or "unrecommended"
> opcodes into a compatibility plugin that would perhaps not be loaded by
> default.
>
> One of these days, I will set up the tool chain for the manual on my
> computer and get to work ...
>
> Anthony Kozar
> mailing-lists-1001 AT anthonykozar DOT net
> http://anthonykozar.net/
>
> Richard Dobson wrote on 2/11/09 4:48 AM:
>
>> You have hit the eternal Csound problem of changes and additions of
>> opcodes (that in various ways encourage new ways of thinking), while
>> retaining all the old ones for backwards compatibility. One solution may
>> be a general "compatibility" section in the manual somewhere, that
>> collates all these changes - there is a number of opcodes still in the
>> system that have been substituted by newer enhanced (or even corrected)
>> ones.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Thanks for your reply, Andrès,
I'm happy to help incrementally, as I'm sure many are. I do not know  
how to "actually submit ideas and contributing directly" in a way that  
gives me confidence that the contribution will not just disappear into  
the dev. list archives. This is not to cast _any_ aspersions on those  
who hack the sources, which, in the case of the manuals, are somewhat  
convoluted. There really needs to be tagging system to which one can  
contribute, or access to the sources when one asks. To have one's  
request for this ignored on more than one occasion just means one puts  
one's energy elsewhere.
There is more than one long-existing open-source project of which I  
have experience,  that's still-huge-potential is hampered by the  
development infrastructure being outstripped by the enthusiasm of  
dedicated individuals who 'just want to get on with it.' csound is not  
the worst in this regard, though it does have some of the symptoms.

ciao4now,
David

On 12/02/2009, at 12:36 AM, Andres Cabrera wrote:

> Hi,
>
> The manual can always use help. It is huge and some entries even date
> back to the original 1980s documentation. The best way to help is by
> actually submitting ideas and contributing directly. It would be great
> if you can post suggestions and actual wordings for a particular page.
> It is very helpful to edit the xml files directly, but if you want to
> contribute just plain text that is also extremely helpful. If you want
> to organize a project, that would also be great, but it may be harder
> to do this than to contribute little by little. For terminology issues
> where note is used when pitch should be used, there's no need to
> consult, but for deeper issues like the recent types vs. rate vs.
> signal discussion, the list can give very interesting ideas.
>
> Cheers,
> Andrés
>
> On Wed, Feb 11, 2009 at 6:47 AM, DavidW  wrote:
>> I'm not sure my comments are directly related to the ampdb issue as  
>> much as
>> to the manual in general. I was recently doing some less-than-usual  
>> table
>> reading tasks and I found I couldn't understand the manual entry,
>> principally because they were couched in quasi-musical language  
>> rather than
>> describing what the opcode actually did. I also can across quite a  
>> lot of
>> 'loose' language - 'note' being used for 'pitch', 'pitch' for  
>> 'frequency'
>> etc. I'm sure y'all get the drift. I would like to see a project  
>> where the
>> manual underwent a parallel revision/development path to that of  
>> the code.
>> It is a big task however and best achieved over time, wording for  
>> entries
>> even discussed via a wiki or something. One advantage of such a  
>> process
>> would be an increase in the general knowledge of opcodes, etc.
>> BTW, what happened to the 'display of a random opcode' on the home  
>> page?
>>
>> D.
>>
>> On 11/02/2009, at 8:48 PM, Richard Dobson wrote:
>>
>>> Greg Schroeder wrote:
>>> ..
>>>>
>>>> Mr. (Dr.?) Dobson's response makes it sound as if it were common  
>>>> sense to
>>>> expect a gigantic output at 40 db. However, Dr. Boulanger's  
>>>> tutorials, for
>>>> example, regularly give db values > 60 (I just spotted an 85 in  
>>>> the beginner
>>>> tutorial on GENs) with no explanation for the changes in value  
>>>> between the
>>>> examples, and no defined 0dbfs. Vercoe just uses raw amplitude.
>>>
>>>
>>> This is very possibly an issue for documentation, though it is not  
>>> so easy
>>> to see where it might go.  The original version of Csound had no  
>>> 0dBFS
>>> mechanism, and (in being based on an explicit 32767 range for  
>>> amplitude)
>>> used the ampdb opcode such that a value of 90-odd gave digital  
>>> peak, and a
>>> value of 40 was naturally somewhat quieter.
>>>
>>> This however is not in accordance with conventions in the audio  
>>> industry,
>>> which defines digital peak as 0dB and all lower levels therefore are
>>> indicated with a negative dB value. So, for example, -6dB maps to an
>>> amplitude of 0.5 (approx). I introduced the ambdbfs and dbfsamp   
>>> pair of
>>> opcodes to address this anomaly, and they are recommended for all  
>>> new
>>> orchestras. However the original amp/db opcodes cannot be removed,  
>>> as so
>>> many orchestras depend on it; and as Victor recently pointed out,  
>>> they can
>>> still be useful for other tasks, as they just perform a standard  
>>> log10
>>> calculation.
>>>
>>> I later added the 0dBFS opcode as a more generalised solution,  
>>> given that
>>> we needed  much more scope for reading and writing soundfiles of  
>>> any sample
>>> size, so that the old 32767 default was increasingly meaningless  
>>> (and indeed
>>> confusing). Arguably an amplitude scale of +-1.0 is more logical  
>>> these days
>>> (all plugin formats use that for example, as does SAOL); but you  
>>> can in fact
>>> use any value you like for 0dBFS. With 0dBFS = 1, the old and new  
>>> amp/db
>>> opcodes do the same thing. But just adding it to an old-style  
>>> orchestra
>>> without adjusting explicit level values is bound to create  
>>> problems such as
>>> you have encountered
>>>
>>> You have hit the eternal Csound problem of changes and additions of
>>> opcodes (that in various ways encourage new ways of thinking), while
>>> retaining all the old ones for backwards compatibility. One  
>>> solution may be
>>> a general "compatibility" section in the manual somewhere, that  
>>> collates all
>>> these changes - there is a number of opcodes still in the system  
>>> that have
>>> been substituted by newer enhanced (or even corrected) ones.
>>>
>>> Amplitude unfortunately is a subject affected variously by a  
>>> number of
>>> these recent changes, such that it can indeed be a problem to use  
>>> some old
>>> and some new together, especially when exploring some of the  
>>> examples in the
>>> Csound book which follow the original "canonical" opcode usage.
>>>
>>> Richard Dobson

Indicating deprecation should be at the top of the entry - near the  
name. I'd vote against moving things out of alphabetical order into  
some sort of deprecation hierarchy: If you want to look up a feature,  
want you want is access to the info as simply as possible, without  
having to wonder where it might be located.
D.
On 12/02/2009, at 7:57 AM, Steven Yi wrote:

> I'm all for Anthony's ideas here.  One thing is that I think currently
> "deprecated" shows up at end of an opcode reference; it might be worth
> placing notes on top of page if we can get that going.
>
> On Wed, Feb 11, 2009 at 12:53 PM, Anthony Kozar
>  wrote:
>> I think that it would be a good idea for Csound 6 to reorganize  
>> section II
>> of the manual ("Opcodes Overview") so that the currently  
>> recommended opcodes
>> in each section are presented first and older unrecommended,  
>> confusing, or
>> broken opcodes be placed in a "deprecated" section further down in  
>> each
>> section or on an entirely different page.  Perhaps even a page with  
>> a table
>> of "unrecommended" opcodes and a "use instead" recommendation.   
>> Heck, why
>> not stick a note on the reference pages for each of those opcodes  
>> saying the
>> same thing.
>>
>> At the same time, we could move many of the obsolete or  
>> "unrecommended"
>> opcodes into a compatibility plugin that would perhaps not be  
>> loaded by
>> default.
>>
>> One of these days, I will set up the tool chain for the manual on my
>> computer and get to work ...
>>
>> Anthony Kozar
>> mailing-lists-1001 AT anthonykozar DOT net
>> http://anthonykozar.net/
>>
>> Richard Dobson wrote on 2/11/09 4:48 AM:
>>
>>> You have hit the eternal Csound problem of changes and additions of
>>> opcodes (that in various ways encourage new ways of thinking), while
>>> retaining all the old ones for backwards compatibility. One  
>>> solution may
>>> be a general "compatibility" section in the manual somewhere, that
>>> collates all these changes - there is a number of opcodes still in  
>>> the
>>> system that have been substituted by newer enhanced (or even  
>>> corrected)
>>> ones.

I think what confused you is that you were actually changing the
amplitude scale, when it was not really clear you were actually doing
so. Since older references and many opcode examples use the older
system, this is a big confusion, which makes me think: An easy and
very interesting way to help with this is to review the examples and
post versions using 0dbfs=1 to the list, this way while you learn a
lot about Csound, you get to help out clarifying the manual.

Volunteers?

Cheers,
Andrés

On Wed, Feb 11, 2009 at 12:58 AM, Greg Schroeder  wrote:
> I don't think this is the manual's business.
> If anything, a discussion in some of the hodgepodge of documentation around
> Csound about what contributes to loudness would be nice. For example, I had
> no idea my lfo was making my instrument louder. I figured it had to be
> oscillating much faster than it was - isn't incapacity to oscillate enough
> to generate/modify a pitch or increase loudness what makes it an lfo? Isn't
> it just another oscillator otherwise?
> My confusion that might be useful to documentation is the disparity between
> the tutorials (Boulanger's and Vercoe's, for example) and the manual.
> Mr. (Dr.?) Dobson's response makes it sound as if it were common sense to
> expect a gigantic output at 40 db. However, Dr. Boulanger's tutorials, for
> example, regularly give db values > 60 (I just spotted an 85 in the beginner
> tutorial on GENs) with no explanation for the changes in value between the
> examples, and no defined 0dbfs. Vercoe just uses raw amplitude.
> I just want my freakin' .csd files to sound the same when I run them through
> csound as they do when I save them to .wav, theory be darned.
> Looking through the reference manual, it looked like setting 0dbfs = 1 might
> help.
> It might have, but it also made any instrument I generated a howling,
> screeching, really, really loud mess.
> That's where I was when I sent the initial email.
> Greg
>
>
> On Wed, Feb 11, 2009 at 1:58 AM, Andres Cabrera 
> wrote:
>>
>> Hi Greg,
>>
>> Do you have any suggestions for the manual to help other users avoid
>> this problem?
>>
>> Cheers,
>> Andrés
>>
>> On Tue, Feb 10, 2009 at 7:43 AM, Greg Schroeder 
>> wrote:
>> > Yes, that's MUCH better. Thank you!
>> > And that seems to have fixed the differences between playing .csd files
>> > and their .wav files.
>> > :)
>> > Sweet.
>> > Greg
>> >
>> > On Tue, 10 Feb 2009, Richard Dobson wrote:
>> >
>> >> You are using 0dBFS=1, and calling ampdb(40) (i.e. "plus 40dB"), with
>> >> an lfo
>> >> amp of 900. What do you intend the output level level to be?
>> >>
>> >> Try calling ampdb(-10), and an lfo amp of 1.
>> >>
>> >> The 0dBFS enables you to dictate what your amplitude numbers mean in
>> >> relation
>> >> to digital peak. With 0dBFS = 1, your code needs to generate ~all~
>> >> amplitude
>> >> levels < 1. Could be a lot less, according to need, but certainly not
>> >> more.
>> >>
>> >>
>> >> Richard Dobson
>> >>
>> >>
>> >> Greg Schroeder wrote:
>> >> > Hi all,
>> >> > I'm writing simple sounds (for use as samples in another app) from
>> >> > the command line on an olpc, and I am having a few serious problems.
>> >> > The biggest one is that rendering to .wav ALWAYS makes the file sound
>> >> > very
>> >> > very different than playing the .csd file through csound.
>> >> > This has been happening consistently for the 1 month or so I've been
>> >> > experimenting with Csound.
>> >> >
>> >> > The other problem I'm having is using 0dbfs = 1 in the header of my
>> >> > orchestra, as the reference manual suggests I should. This gives me
>> >> > unlistenable, clipping high volume regardless of amplitude, and
>> >> > reducing
>> >> > the value of 0dbfs, or reducing the amplitudes in my score, literally
>> >> > makes my sounds fall apart - oscillators sound like they're going out
>> >> > of
>> >> > tune with each other, etc.
>> >> > Where should I start tinkering here? I am generally not having buffer
>> >> > issues, so I don't know where else to look.
>> >> > Thanks in advance,
>> >> > Greg
>> >> > 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"
>> >>
>> >
>> >
>> > Send bugs reports to this list.
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>



-- 


Andrés

Hi David,

On Wed, Feb 11, 2009 at 4:30 PM, DavidW  wrote:
> Thanks for your reply, Andrès,
> I'm happy to help incrementally, as I'm sure many are. I do not know how to
> "actually submit ideas and contributing directly" in a way that gives me
> confidence that the contribution will not just disappear into the dev. list
> archives. This is not to cast _any_ aspersions on those who hack the
> sources, which, in the case of the manuals, are somewhat convoluted. There
> really needs to be tagging system to which one can contribute, or access to
> the sources when one asks. To have one's request for this ignored on more
> than one occasion just means one puts one's energy elsewhere.

Yes the manual sources are Docbook-xml which requires (how to put it
mildly?) an affinity with hand editing XML =). I try to add all
contributions which are put on the list, particularly when they
involve just simple copy-pasting (Some may slip through when time is
short, but if you pester me, it will get in). Your contribution will
not likely rot in the archives. Permission to edit the sources is
usually granted by John when he is asked, particularly for the manual.
Not much bureaucracy here...

> There is more than one long-existing open-source project of which I have
> experience,  that's still-huge-potential is hampered by the development
> infrastructure being outstripped by the enthusiasm of dedicated individuals
> who 'just want to get on with it.' csound is not the worst in this regard,
> though it does have some of the symptoms.
>

I think the manual doesn't suffer from this, since no one is going to
argue whether to use the chapter tag or the section tag for a
particular text =)

Cheers,
Andrés

On 12/02/2009, at 9:42 AM, Andres Cabrera wrote:

> Hi David,
>
> On Wed, Feb 11, 2009 at 4:30 PM, DavidW  wrote:
>> Thanks for your reply, Andrès,
>> I'm happy to help incrementally, as I'm sure many are. I do not  
>> know how to
>> "actually submit ideas and contributing directly" in a way that  
>> gives me
>> confidence that the contribution will not just disappear into the  
>> dev. list
>> archives. This is not to cast _any_ aspersions on those who hack the
>> sources, which, in the case of the manuals, are somewhat  
>> convoluted. There
>> really needs to be tagging system to which one can contribute, or  
>> access to
>> the sources when one asks. To have one's request for this ignored  
>> on more
>> than one occasion just means one puts one's energy elsewhere.
>
> Yes the manual sources are Docbook-xml which requires (how to put it
> mildly?) an affinity with hand editing XML =).
> I try to add all
> contributions which are put on the list, particularly when they
> involve just simple copy-pasting (Some may slip through when time is
> short, but if you pester me, it will get in). '
Bonjour Andrès !
Surely you not see the issue here? "I will try", .. "some may slip" ..  
"pester me"
are all indications of an inefficient system (from a contriibutor's  
POV).
And what happens if you can't get to it? What is the contingency plan?

> Your contribution will
> not likely rot in the archives. Permission to edit the sources is
> usually granted by John when he is asked, particularly for the manual.
> Not much bureaucracy here...
I'm glad you inserted "usually"  what does one have to do when a  
request and a follow-up is not even graced with a reply?
(The OLPC project is even worse - don't get me started on that one!)
The point is my identity is not defined by whether or not some  
bureaucracy deigns to allow me to contribute or not - if I didn't care  
about the projects I wouldn't even be spending time writing this.
Project management has to evolve with a project and successful open  
source does not result from diminished project management.
I want to take pride in contribution to quality work - not have it  
shuffled into a hopeful  bit bucket.
Again, please understand - this is not personal - far from it - I  
really appreciate your contribution - as I do of others.

I think I've made my point. I won't bag on about it.

D.

>> There is more than one long-existing open-source project of which I  
>> have
>> experience,  that's still-huge-potential is hampered by the  
>> development
>> infrastructure being outstripped by the enthusiasm of dedicated  
>> individuals
>> who 'just want to get on with it.' csound is not the worst in this  
>> regard,
>> though it does have some of the symptoms.
>>
>
> I think the manual doesn't suffer from this, since no one is going to
> argue whether to use the chapter tag or the section tag for a
> particular text =)
>
As you can see from the above - I beg to differ - IMO the whole csound  
project does.

> Cheers,
> Andrés

Hi Greg,

On Wed, Feb 11, 2009 at 8:24 PM, Greg Schroeder  wrote:
> Could we please get some tutorials that indicate these changes?
> I'd make them myself if I were even remotely qualified to do anything except
> ask questions. But I'm not.
> I understand "steep learning curve," but seriously - this makes going
> through the best/most-current beginner materials I've found (Boulanger's
> t00ts) sort of frustrating. ("Here's how to make some basic instruments and
> scores. Sike! We changed the language to fit standards developed for outside
> reasons and you couldn't have known how to start following those standards
> unless you were in contact with the project's contributors or understood
> sound synthesis to begin with, even though these changes happened some time
> ago!")
> Could someone edit them to indicate the changes - i.e. indicate 0dbfs
> and insert appropriate amplitude values?
> It _is_ the preferred way to write an orchestra, right?
>

I think you are misunderstanding. Things haven't changed, but a new
better way to do things was added. Older files will still work as
expected, but you will break them if you add 0dbfs=1 and don't change
all the amplitude values in your csd file. If you don't place a 0dbfs
line, the older ~32000 default will be used, and the file will work as
before. I've been adding the recommendation to use 0dbfs = 1 in the
manual because it makes working with amplitudes easier, more intuitive
and in line with other software like pd and supercollider.

> A good first step for all of this re: the manual (I know nothing about the
> politics of changing manuals) is include something like Richard's
> explanation of 0 vs. 32,000 as digital peak from earlier in this discussion
> in the manual, note the ongoing change and the resulting current,
> temporary inconsistencies in the manual, along with 0dbfs' "preferred"
> status and some brief practical advice on adapting the older code in the
> examples to current standards.
> Then, edit the manual and remove the note when the examples are updated.
> That would have made my last 2-3 weeks much more pleasant.
> I'd love to help with this - is docbook xml that bad?
>

It is =) (This is the file for the oscil page:
http://csound.cvs.sourceforge.net/viewvc/csound/manual/opcodes/oscil.xml?revision=1.13&view=markup
 ). However the examples, in the examples directory:

http://csound.cvs.sourceforge.net/viewvc/csound/manual/examples/

are ordinary csd files. These are the ones anyone can help with even
if they are only starting with Csound.

Cheers,
Andrés

> Greg
>
> On Thu, Feb 12, 2009 at 8:18 AM, DavidW  wrote:
>>
>> On 12/02/2009, at 9:42 AM, Andres Cabrera wrote:
>>
>>> Hi David,
>>>
>>> On Wed, Feb 11, 2009 at 4:30 PM, DavidW  wrote:
>>>>
>>>> Thanks for your reply, Andrès,
>>>> I'm happy to help incrementally, as I'm sure many are. I do not know how
>>>> to
>>>> "actually submit ideas and contributing directly" in a way that gives me
>>>> confidence that the contribution will not just disappear into the dev.
>>>> list
>>>> archives. This is not to cast _any_ aspersions on those who hack the
>>>> sources, which, in the case of the manuals, are somewhat convoluted.
>>>> There
>>>> really needs to be tagging system to which one can contribute, or access
>>>> to
>>>> the sources when one asks. To have one's request for this ignored on
>>>> more
>>>> than one occasion just means one puts one's energy elsewhere.
>>>
>>> Yes the manual sources are Docbook-xml which requires (how to put it
>>> mildly?) an affinity with hand editing XML =).
>>> I try to add all
>>> contributions which are put on the list, particularly when they
>>> involve just simple copy-pasting (Some may slip through when time is
>>> short, but if you pester me, it will get in). '
>>
>> Bonjour Andrès !
>> Surely you not see the issue here? "I will try", .. "some may slip" ..
>> "pester me"
>> are all indications of an inefficient system (from a contriibutor's POV).
>> And what happens if you can't get to it? What is the contingency plan?
>>
>>> Your contribution will
>>> not likely rot in the archives. Permission to edit the sources is
>>> usually granted by John when he is asked, particularly for the manual.
>>> Not much bureaucracy here...
>>
>> I'm glad you inserted "usually"  what does one have to do when a request
>> and a follow-up is not even graced with a reply?
>> (The OLPC project is even worse - don't get me started on that one!)
>> The point is my identity is not defined by whether or not some bureaucracy
>> deigns to allow me to contribute or not - if I didn't care about the
>> projects I wouldn't even be spending time writing this.
>> Project management has to evolve with a project and successful open source
>> does not result from diminished project management.
>> I want to take pride in contribution to quality work - not have it
>> shuffled into a hopeful  bit bucket.
>> Again, please understand - this is not personal - far from it - I really
>> appreciate your contribution - as I do of others.
>>
>> I think I've made my point. I won't bag on about it.
>>
>> D.
>>
>>>> There is more than one long-existing open-source project of which I have
>>>> experience,  that's still-huge-potential is hampered by the development
>>>> infrastructure being outstripped by the enthusiasm of dedicated
>>>> individuals
>>>> who 'just want to get on with it.' csound is not the worst in this
>>>> regard,
>>>> though it does have some of the symptoms.
>>>>
>>>
>>> I think the manual doesn't suffer from this, since no one is going to
>>> argue whether to use the chapter tag or the section tag for a
>>> particular text =)
>>>
>> As you can see from the above - I beg to differ - IMO the whole csound
>> project does.
>>
>>> Cheers,
>>> Andrés
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>



-- 


Andrés

I'd love to help, Andres!

I've also found my problem.
Leaving out the orchestra header = two very different sets of sounds  
in the .csd and the .wav files.
Thought I read that could be implied.
Guess not . . .
Thank you all for your patience and guidance.

Greg

On Feb 12, 2009, at 11:12 PM, Andres Cabrera wrote:

> Hi Greg,
>
> On Wed, Feb 11, 2009 at 8:24 PM, Greg Schroeder  
>  wrote:
>> Could we please get some tutorials that indicate these changes?
>> I'd make them myself if I were even remotely qualified to do  
>> anything except
>> ask questions. But I'm not.
>> I understand "steep learning curve," but seriously - this makes going
>> through the best/most-current beginner materials I've found  
>> (Boulanger's
>> t00ts) sort of frustrating. ("Here's how to make some basic  
>> instruments and
>> scores. Sike! We changed the language to fit standards developed  
>> for outside
>> reasons and you couldn't have known how to start following those  
>> standards
>> unless you were in contact with the project's contributors or  
>> understood
>> sound synthesis to begin with, even though these changes happened  
>> some time
>> ago!")
>> Could someone edit them to indicate the changes - i.e. indicate 0dbfs
>> and insert appropriate amplitude values?
>> It _is_ the preferred way to write an orchestra, right?
>>
>
> I think you are misunderstanding. Things haven't changed, but a new
> better way to do things was added. Older files will still work as
> expected, but you will break them if you add 0dbfs=1 and don't change
> all the amplitude values in your csd file. If you don't place a 0dbfs
> line, the older ~32000 default will be used, and the file will work as
> before. I've been adding the recommendation to use 0dbfs = 1 in the
> manual because it makes working with amplitudes easier, more intuitive
> and in line with other software like pd and supercollider.
>
>> A good first step for all of this re: the manual (I know nothing  
>> about the
>> politics of changing manuals) is include something like Richard's
>> explanation of 0 vs. 32,000 as digital peak from earlier in this  
>> discussion
>> in the manual, note the ongoing change and the resulting current,
>> temporary inconsistencies in the manual, along with 0dbfs'  
>> "preferred"
>> status and some brief practical advice on adapting the older code  
>> in the
>> examples to current standards.
>> Then, edit the manual and remove the note when the examples are  
>> updated.
>> That would have made my last 2-3 weeks much more pleasant.
>> I'd love to help with this - is docbook xml that bad?
>>
>
> It is =) (This is the file for the oscil page:
> http://csound.cvs.sourceforge.net/viewvc/csound/manual/opcodes/ 
> oscil.xml?revision=1.13&view=markup
>  ). However the examples, in the examples directory:
>
> http://csound.cvs.sourceforge.net/viewvc/csound/manual/examples/
>
> are ordinary csd files. These are the ones anyone can help with even
> if they are only starting with Csound.
>
> Cheers,
> Andrés
>
>> Greg
>>
>> On Thu, Feb 12, 2009 at 8:18 AM, DavidW  wrote:
>>>
>>> On 12/02/2009, at 9:42 AM, Andres Cabrera wrote:
>>>
>>>> Hi David,
>>>>
>>>> On Wed, Feb 11, 2009 at 4:30 PM, DavidW  wrote:
>>>>>
>>>>> Thanks for your reply, Andrès,
>>>>> I'm happy to help incrementally, as I'm sure many are. I do not  
>>>>> know how
>>>>> to
>>>>> "actually submit ideas and contributing directly" in a way that  
>>>>> gives me
>>>>> confidence that the contribution will not just disappear into  
>>>>> the dev.
>>>>> list
>>>>> archives. This is not to cast _any_ aspersions on those who  
>>>>> hack the
>>>>> sources, which, in the case of the manuals, are somewhat  
>>>>> convoluted.
>>>>> There
>>>>> really needs to be tagging system to which one can contribute,  
>>>>> or access
>>>>> to
>>>>> the sources when one asks. To have one's request for this  
>>>>> ignored on
>>>>> more
>>>>> than one occasion just means one puts one's energy elsewhere.
>>>>
>>>> Yes the manual sources are Docbook-xml which requires (how to  
>>>> put it
>>>> mildly?) an affinity with hand editing XML =).
>>>> I try to add all
>>>> contributions which are put on the list, particularly when they
>>>> involve just simple copy-pasting (Some may slip through when  
>>>> time is
>>>> short, but if you pester me, it will get in). '
>>>
>>> Bonjour Andrès !
>>> Surely you not see the issue here? "I will try", .. "some may  
>>> slip" ..
>>> "pester me"
>>> are all indications of an inefficient system (from a  
>>> contriibutor's POV).
>>> And what happens if you can't get to it? What is the contingency  
>>> plan?
>>>
>>>> Your contribution will
>>>> not likely rot in the archives. Permission to edit the sources is
>>>> usually granted by John when he is asked, particularly for the  
>>>> manual.
>>>> Not much bureaucracy here...
>>>
>>> I'm glad you inserted "usually"  what does one have to do when a  
>>> request
>>> and a follow-up is not even graced with a reply?
>>> (The OLPC project is even worse - don't get me started on that one!)
>>> The point is my identity is not defined by whether or not some  
>>> bureaucracy
>>> deigns to allow me to contribute or not - if I didn't care about the
>>> projects I wouldn't even be spending time writing this.
>>> Project management has to evolve with a project and successful  
>>> open source
>>> does not result from diminished project management.
>>> I want to take pride in contribution to quality work - not have it
>>> shuffled into a hopeful  bit bucket.
>>> Again, please understand - this is not personal - far from it - I  
>>> really
>>> appreciate your contribution - as I do of others.
>>>
>>> I think I've made my point. I won't bag on about it.
>>>
>>> D.
>>>
>>>>> There is more than one long-existing open-source project of  
>>>>> which I have
>>>>> experience,  that's still-huge-potential is hampered by the  
>>>>> development
>>>>> infrastructure being outstripped by the enthusiasm of dedicated
>>>>> individuals
>>>>> who 'just want to get on with it.' csound is not the worst in this
>>>>> regard,
>>>>> though it does have some of the symptoms.
>>>>>
>>>>
>>>> I think the manual doesn't suffer from this, since no one is  
>>>> going to
>>>> argue whether to use the chapter tag or the section tag for a
>>>> particular text =)
>>>>
>>> As you can see from the above - I beg to differ - IMO the whole  
>>> csound
>>> project does.
>>>
>>>> Cheers,
>>>> Andrés
>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>
>
>
> -- 
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

DavidW wrote on 2/11/09 6:18 PM:

> On 12/02/2009, at 9:42 AM, Andres Cabrera wrote:

>> I try to add all
>> contributions which are put on the list, particularly when they
>> involve just simple copy-pasting (Some may slip through when time is
>> short, but if you pester me, it will get in). '

> Bonjour Andrès !
> Surely you not see the issue here? "I will try", .. "some may slip" ..
> "pester me" are all indications of an inefficient system (from a
> contriibutor's  POV). And what happens if you can't get to it? What is the
> contingency plan?

There is no contingency plan unless you want to count "you can do it
yourself."  Given how few people *consistently* make contributions to Csound
development (including editing the manual), I think that this situation is
understandable.  There are plenty of tasks that simply do not have anyone
"assigned" to them.  And there are far too few dedicated developers to deal
with everything.

I use the phrase "I will try" most of the time when responding to Csound
support requests because, frankly, my time for working on Csound is limited
and there are usually twenty other things on my list ahead of that request.
I wish that there was enough time to do everything, but Csound is not the
only project that I work on, and even if it were, I doubt that there would
be time for everything.

Of course, the most efficient way for people to contribute is to actually
become a Csound developer, manual editor, etc.  Obviously, it is more work
if the 6 or 7 "core" developers have to personally figure out what to do
with contributions that are not their own.

>> Your contribution will
>> not likely rot in the archives. Permission to edit the sources is
>> usually granted by John when he is asked, particularly for the manual.
>> Not much bureaucracy here...
> I'm glad you inserted "usually"  what does one have to do when a
> request and a follow-up is not even graced with a reply?

Where did you put your request?  In the middle of a list email on some
random topic?  If you email John directly with an appropriate subject line,
I believe he will respond to you fairly quickly.

> Project management has to evolve with a project and successful open
> source does not result from diminished project management.
> I want to take pride in contribution to quality work - not have it
> shuffled into a hopeful  bit bucket.

There was talk long ago of using the Sourceforge Tracker system for managing
bug reports, but most people still just post to the list and some developers
prefer to use their inboxes to manage requests.

If you want to take charge and organize a better way of doing things, then
by all means.  BUT, you will have to ensure that any new issue tracking
system meets the needs of the current developers.  Developers should be able
to receive email notices of new issues.  And ideally, developers should not
have to do a lot of clicking in a web interface to respond to issues or to
change their status (eg. to "fixed").  If the system had a way for
developers to modify issues via email or if the emails had links that when
followed actually changed the status, that might work.  I don't know if such
a system exists though.

> Again, please understand - this is not personal - far from it - I
> really appreciate your contribution - as I do of others.
> 
> I think I've made my point. I won't bag on about it.

Thanks.  I hope I've made my point too.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

Thanks Anthony, Andrès for your views.
I'm not really in the mood to stay on this merry-go-round, so I'll say  
my piece and be done with it.
I'd like to focus on the process; the individual players are  
incidental. That is, this issue is not about either of you, or me, or  
John or whomever.  It is about the roles we play. It is about the  
responsiveness of a project to new ideas; fresh blood; its communities  
of users, of contributors, of developers.  The responsiveness, or  
otherwise, is one indication of where to put one's energy. Because  
these tools are processes, the ability to contribute is essential;  
argue a case if necessary, yes, and bend to the common will, unless it  
is really vital, yes, but contribute. A project that is open to such  
contribution, is a healthy project and it attracts new users who add  
to its vitality. There are _other_ computer sound projects like that.  
A project that isn't open, unless you've been privy to some secret  
handshake, is ossifying, prey to its own portentousness, is difficult  
to approach etc.
Is any of that really revelatory? I've led and contributed to  
development teams, started organisations etc, and I know it is not.
So I see my own circumstance as a test case. It is not about ego or  
feeling unwanted - honestly I'm more resilient that that. I've been  
around - this isn't some freshman's semester project for me.
But let's be clear about the facts. When I came back to see how the  
csound project was getting along a couple of years ago, I saw that it  
had developed somewhat since I signed a NDA with Barry regarding the  
'chip'  version. And those developments were good; enhanced  
considerably by John's rework and the move to an API library version.  
I did observe that there were not a lot of active developers, as  
Anthony reminds us, and I thought that if I was going to use and  
recommend csound, it was the right thing to do to offer to contribute  
- at that time to take some of the pressure off Victor in the python/ 
SConstruct build area, as that is something about which I have some  
real experience.
So I  _did_ write to John, personally,  off the list(s), over a year  
ago, as advised, explaining what  I thought I could contribute and  
asking for the relevant permissions to do so. At the time I thought,  
how strange, given the size and longevity of this project, that  there  
was only one gatekeeper, but hey, perhaps there had been problems in  
the past of which I was not aware. That email didn't bounce, and I did  
not receive a reply. So I waited, thinking, well if there's only one  
gatekeeper, perhaps he's busy.
Silence. So I started to ask again via various posts, when I came  
across problems/solutions, how one might contribute. I was told to  
write to John or just post to the list and one of the ordained will  
deal with it, if they're not too busy etc etc as discussed earlier.  
Well, writing to John hadn't worked previously and if he read the  
lists, as there was evidence that he did, then the appropriate thing  
would have been for him, or Richard, to ask for an explanation, or  
just do it! I thought it unlikely that it was my BO that was the  
problem,  so what was it?
At that time I was asked by Richard,  to contribute to OLPC, to which  
I responded by taking the time find out about the project and then  
wrote and submitted a proposal. Result? The same: silence. Now of  
course these two projects are only peripherally connected, through  
csound, but it would take a team of horses to drag me back to that  
project now. I simply don't have time to work with such  
'creative' (read shambolically nepotistic) organisations (I use the  
term loosely). Look at the websites - they are a dog's breakfast! For  
what it's worth, I now think of such an organisation as serving  
principally a 'clique' of 'providers' whose clients are but fodder to  
support the continued take on the largesse of an gullible public.
But I digress... Except for the dog's breakfast....Where have I  
experienced that recently? Oh yes,  the home directory of the csound  
sources! Another shamble, which I, and others have also written about  
on list. Do any csound developers ever compile other projects from  
sources? Do they seriously think that their cleanliness  is  an  
accident;, that perhaps csound is too complicated to be factored, or  
because it is just-so-big-and-wonderful (to misquote Monty Python)  
that it shouldn't  be made easy to compile, lest the blessed by  
worshipped less? I mean, it's not like XML or docbooks formats require  
all that much brain-power.
So, I resigned myself to making suggestions via the dev-list,  
including for the manual, and hoping I'd catch when/if they'd been  
responded to if/when they were. Then I came across a manual entry that  
jumbled up 'frequency' and 'pitch' or whatever it was -  
'amplitude'/'loudness'? - there are lots of them! The most effective  
solution would have been to quickly log in and make the change - an  
aside that would have taken a couple of minutes at most and it would  
have been permanently fixed. I didn't have the permissions to do that,  
so the other option was to compose a change, write to the dev list  
explaining the need for the change, offer my suggestion etc etc  etc  
and hope it was dealt with.  Well, life's too short, so I just mumbled  
into my beard and moved on. Results. 1. The manual entry stays in  
error and continues to be confusing for those less able to handle such  
noise, especially beginners, than I, and  2. I become more  
dissatisfied with working like that and, in a last ditch attempt to  
try to get some organisational change by writing  a long and probably  
boring post to this list.
Now one of the difficulties of nagging like this is that it builds a  
false expectation that, given access, I will start to make a big  
contribution, like take responsibility for a whole area of the  
project, or something. Well, I won't, at least not at the moment, and  
the desire is fading fast. All I want to do is to fix things that,  
when I find them, need fixing, that I'm competent to fix; no fuss, no  
bother, and move on. Some people will read this as a personal gripe.  
More reasoned souls will understand that I write, not out of desire to  
build an empire, or just to be a pest, but because I care about the  
project. Can I be clearer or more reasonable than that? It took months  
and months of waiting 'till Victor was able to make a build that could  
be used on an incredibly common platform: the latest  Intel OSX +  
python > 2.4. So I'm starting to work w. csound again, and the  
question I ask myself is, do I continue or just get jacked with having  
to walk on nails, genuflect or whatever it takes to gain the  
gatekeeper's attention enough for him to flick the switch?
The good thing for those long-suffering enough to have read thus far,  
is that you won't hear from me, unsolicited, on the topic again.

-David

On 15/02/2009, at 5:21 AM, Anthony Kozar wrote:

> DavidW wrote on 2/11/09 6:18 PM:
>
>> On 12/02/2009, at 9:42 AM, Andres Cabrera wrote:
>
>>> I try to add all
>>> contributions which are put on the list, particularly when they
>>> involve just simple copy-pasting (Some may slip through when time is
>>> short, but if you pester me, it will get in). '
>
>> Bonjour Andrès !
>> Surely you not see the issue here? "I will try", .. "some may  
>> slip" ..
>> "pester me" are all indications of an inefficient system (from a
>> contriibutor's  POV). And what happens if you can't get to it? What  
>> is the
>> contingency plan?
>
> There is no contingency plan unless you want to count "you can do it
> yourself."  Given how few people *consistently* make contributions  
> to Csound
> development (including editing the manual), I think that this  
> situation is
> understandable.  There are plenty of tasks that simply do not have  
> anyone
> "assigned" to them.  And there are far too few dedicated developers  
> to deal
> with everything.
> I use the phrase "I will try" most of the time when responding to  
> Csound
> support requests because, frankly, my time for working on Csound is  
> limited
> and there are usually twenty other things on my list ahead of that  
> request.
> I wish that there was enough time to do everything, but Csound is  
> not the
> only project that I work on, and even if it were, I doubt that there  
> would
> be time for everything..
> Of course, the most efficient way for people to contribute is to  
> actually
> become a Csound developer, manual editor, etc.  Obviously, it is  
> more work
> if the 6 or 7 "core" developers have to personally figure out what  
> to do
> with contributions that are not their own.
>>> Your contribution will
>>> not likely rot in the archives. Permission to edit the sources is
>>> usually granted by John when he is asked, particularly for the  
>>> manual.
>>> Not much bureaucracy here...
>> I'm glad you inserted "usually"  what does one have to do when a
>> request and a follow-up is not even graced with a reply?
>
> Where did you put your request?  In the middle of a list email on some
> random topic?  If you email John directly with an appropriate  
> subject line,
> I believe he will respond to you fairly quickly.
>

>> Project management has to evolve with a project and successful open
>> source does not result from diminished project management.
>> I want to take pride in contribution to quality work - not have it
>> shuffled into a hopeful  bit bucket.
>
> There was talk long ago of using the Sourceforge Tracker system for  
> managing
> bug reports, but most people still just post to the list and some  
> developers
> prefer to use their inboxes to manage requests.
>
> If you want to take charge and organize a better way of doing  
> things, then
> by all means.  BUT, you will have to ensure that any new issue  
> tracking
> system meets the needs of the current developers.  Developers should  
> be able
> to receive email notices of new issues.  And ideally, developers  
> should not
> have to do a lot of clicking in a web interface to respond to issues  
> or to
> change their status (eg. to "fixed").  If the system had a way for
> developers to modify issues via email or if the emails had links  
> that when
> followed actually changed the status, that might work.  I don't know  
> if such
> a system exists though.
>
>> Again, please understand - this is not personal - far from it - I
>> really appreciate your contribution - as I do of others.
>>
>> I think I've made my point. I won't bag on about it.
>
> Thanks.  I hope I've made my point too.
>
> Anthony Kozar
> mailing-lists-1001 AT anthonykozar DOT net
> http://anthonykozar.net/
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg