I noticed that for most of this year, not really many important
changes are committed, other than those by me. In fact, for the
last few months, I did not see any updated files most of the time.
With this significantly reduced activity compared to previous years,
it is becoming very unlikely that Csound 5 can be released this
year. I am not criticizing anyone, but it would be useful to have
some development plan, since at this time I am basically the only
main developer of canonical Csound, but do not know what is left
to be done to have a final release. Also, I cannot really fix any
issues related to platforms I do not use.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am still at ICMC and will not be back to read the mail from the start of 
my holiday until Tuesday, and there are over 1600 of them already.  My 
target is to produce a cs5rc1 this month.  We need an installer for each 
platform, and documentation for ALL opcodes (I still think some are 
missing), but apart from the parser what remains to be done from the plan?

The only problem I have had is the loss on teh control opcode, but I will 
do something about that, using teh software bus, when I get back.  Also 
want to include SDFT into the pv streaming opcodes, but that is a matter 
of a few days.

On teh other hand I spent most of the summer trying to keep up with the 
changes, and maintain a buildable system.  From an earlier remark I expect 
that I will have all that chaos again wgen I return.

While I have been looking at CS, the laptop is not on the net, so there 
will be a re-sync problem

==John




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sep 8, 2005, at 6:41 AM, Istvan Varga wrote:

> I noticed that for most of this year, not really many important
> changes are committed, other than those by me. In fact, for the
> last few months, I did not see any updated files most of the time.
> With this significantly reduced activity compared to previous years,
> it is becoming very unlikely that Csound 5 can be released this
> year. I am not criticizing anyone, but it would be useful to have
> some development plan, since at this time I am basically the only
> main developer of canonical Csound, but do not know what is left
> to be done to have a final release.

My guess is that all other developers are struggling to catch up to 
your remarkable CVS commits; also it doesn't help that most other main 
Csound developers are also teachers which I'd imagine significantly 
cuts down on the time that one is able to spend developing Csound.

Imagine where Csound5 would be WITHOUT your contribution?? I shudder to 
think...

Here's a quote from one Csound Developer from the List archives (the 
original poster shall remain anonymous)

 >>> My set of fluidsynth opcodes is documented now in the canonical 
manual
 >>> along with the Python opcodes and the Loris opcodes.
 >>>
 >>> Sorry to keep throwing all these changes at you... with Istvan on
 >>> board I'm
 >>> getting a bit dizzy myself.

On Sep 8, 2005, at 9:21 AM, John ffitch wrote:

> We need an installer for each platform, and documentation for ALL 
> opcodes (I still think some are missing)

I have an XCode project for Csound5 on OSX... maybe inclusion of that 
to teh CVS would help facilitate users on OSX to be testing / 
developing for Csound. Hopefully more so than at present.

ATS documentation is missing but I'm working on some manual examples 
right now for them. Also I noticed a few opcodes missing documentation, 
most notably oscilv, printf, and printf_i

> Also want to include SDFT into the pv streaming opcodes, but that is a 
> matter
> of a few days.
>

Yes!! I can't wait to hear how that would sound.


-David

As I mentioned last week (I think), there were a number of issues that I
wanted to address.  But the pure chaos I have been experiencing this week --
starting a new job, trying to find a replacement car -- makes it clear that
I will probably not be able to make any significant contributions for
awhile.

I am sorry to have to back down from my stated intentions.  At this point, I
am not sure when I will even be able to finish the MacOS 9 adaptation of
Csound 5, much less be able to contribute the features I intended to the
canonical base.

Here are the things that were on my to do list if it helps anyone else.

Things to check/do before Csound 5 is released:

- Cscore
    - does it work?
    - does the API require changes?
    - change to allow loading cscore plugins

- line counting with macros, #includes, and \r\n not accurate

- BUG: line continuation ('\') does not work with non-native line endings?

- merge fixes to CsoundAV ops from Cs4

- check for other Cs4 bug fixes not applied to Cs5

- check import/export utilities for analysis files

- what is the fate of Scot?

- check that command-line options in different "layers" are applied in a
  logical way

- MacOS 9 compatibility
    - port plugin loading from Cs4
    - finish reconciling diffs with Cs5 API
    
- API additions/modifications:
    - independent syntax checking for orch and score
      (host able to iterate over errors one at a time and get info about
      each error)
    - obtaining opcode list and opcode metadata (Cecilia et al. need this!)
    - setting a Cscore function
    - turning individual options on/off with API calls?
    - be able to print a list of installed plugins and what functionality
      each provides.  (This is critical for usability as I see it).

I should probably commit the Macintosh GUI code that I have right now before
something bad befalls my hard drive.  I have made modifications to Perf to
use the basic Csound 5 API and to link to it as a shared library.  Should
commit these since no one else has a copy ...

Anthony Kozar
anthonykozar@sbcglobal.net
http://akozar.spymac.net/



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> - line counting with macros, #includes, and \r\n not accurate

This one is actually quite difficult to fix, and probably needs
rewriting at least parts of the orchestra preprocessor (rdorchfile()),
and perhaps the score as well. However, as line numbers have never
been printed correctly since macros and include files were introduced,
perhaps this may just as well be done after Csound 5 is already
released, once someone actually takes the time to try fixing this
well known problem. Perhaps needless to say, any attempts at fixing
line numbers should not introduce real, serious bugs that actually
break orchestra code.

> - BUG: line continuation ('\') does not work with non-native line endings?

Is this sure ?

> - merge fixes to CsoundAV ops from Cs4
> 
> - check for other Cs4 bug fixes not applied to Cs5

Perhaps those people who made fixes to version 4 but not 5 (knowing
that the former will eventually be deprecated in favor of the latter)
should port their fixes now, rather than having others hunt for
every little and possibly undocumented change ?

> - check that command-line options in different "layers" are applied in a
>   logical way

The order of evaluating command line options is:

   1. $HOME/.csoundrc
   2. ./.csoundrc
   3. 
   4. command line

the last one has the highest precedence.

> - API additions/modifications:
>     - independent syntax checking for orch and score
>       (host able to iterate over errors one at a time and get info about
>       each error)
>     - obtaining opcode list and opcode metadata (Cecilia et al. need this!)

It is already possible to list the available opcodes with the types of
input and output arguments (however, you need to load an orchestra first
- even if a very simple one containing an empty instrument). Not sure
what you mean when referring to "metadata".

>     - setting a Cscore function
>     - turning individual options on/off with API calls?

It is possible for some of the more commonly used options, and in
fact the -+ style new options have an API that allows listing and
setting any such options and even registering new ones.
However, I am not sure if we should have an API function for every
single option (there are quite a few !). Also, if the host sets an
option before calling csoundCompile(), it may possibly be overridden
by any of the above mentioned sources of command line flags; on the
other hand, after csoundCompile() it is probably too late in most
cases to set a particular option with the API.
So you either need to use the existing method of creating an argv[]
list, or maybe an API function needs to be added that requests
.csoundrc and  to be ignored completely.

>     - be able to print a list of installed plugins and what functionality
>       each provides.  (This is critical for usability as I see it).

While currently there is no API function that lists the loaded plugins,
it should be easy to implement because there is a database of loaded
libraries (note that the directory part of the file names is not preserved).
Knowing the functionality of the plugins would require changes to the plugins
themselves to return "plugin type" information that should be stored in the
database.
I am not sure, however, if this is critical for usability, as so far no one
else asked for this functionality.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

...new parser.....

==John

(only joking)



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

If a new parser that is compatible with the existing orchestra language
can be integrated without breaking external code that uses the API, then
it can be added even after Csound 5 is already released and is no longer
beta. So, there is surely enough time to work on the parser, and it can
be added whenever it is done. Replacing the parser is unlikely to affect
the host API that is fairly high level, and does not depend on internal
structures of the parser at all. Plugin opcodes are a more likely problem
area, but as long as frequently used structures like TEXT (for all the
p->INOCOUNT and others) are preserved, opcodes should continue to work;
also, the API already has functions that allow opcodes to query information
about the number and type of arguments etc. without having to access
internal structures.

John ffitch wrote:

> ...new parser.....
> 
> ==John
> 
> (only joking)


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote:

> I have an XCode project for Csound5 on OSX... maybe inclusion of that to 
> teh CVS would help facilitate users on OSX to be testing / developing 
> for Csound. Hopefully more so than at present.

Does the project need to be updated and maintained whenever
SConstruct is changed ? Also, it seems the main problem with
building Csound 5 on OS X is often not the use of scons, but
rather compiling the FLTK library which is a separate package.

> ATS documentation is missing but I'm working on some manual examples 
> right now for them. Also I noticed a few opcodes missing documentation, 
> most notably oscilv, printf, and printf_i

oscilv is basically the same as oscil, but uses a floating point
phase accumulator, so it may allow for better pitch accuracy if
compiled with MYFLT=double. In fact it is a quite old opcode, it
just was not documented.

ar  oscilv xamp, xcps, ifn[, iphs]

Note: oscilv does not interpolate, and xcps must be >= 0 and < sr.

printf and printf_i do what you probably expect, these opcodes are
the Csound equivalent of printf():

     printf    Sformat, ktrig, xarg1[, xarg2[, ... ]]
     printf_i  Sformat, itrig, xarg1[, xarg2[, ... ]]

printf_i prints once at init time if itrig is greater than zero,
and the arguments may be of type i or S.
printf prints at control rate whenever ktrig is both greater than
zero and different from the previous value (after the initialization
of the note it is always considered different), allowing i-, k-, and
S-rate (string) arguments.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sep 9, 2005, at 5:00 AM, Istvan Varga wrote:

>> - API additions/modifications:
>>        - obtaining opcode list and opcode metadata (Cecilia et al. 
>> need this!)
>
> Not sure what you mean when referring to "metadata".
>

I believe in this case metadata refers to the idea of a graphical app 
being able to reference the OENTRY structure and print out what each 
opcodes args are in order for a front end to display a "shorthand 
manual".

Examples are found in MacCsound, WinXoundPro, and Cecilia.


-David



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

To be honest, i dropped to the sidelines [ if i wasn't already ]
because you were doing so much.
I think you have rewritten or made obsolete almost every contribution  
i have
made to canonical Csound.   So why would i bother?
I might as well just focus on my front-end work.

I also can't keep up with this dev list anymore...

-matt

On Sep 8, 2005, at 3:41 AM, Istvan Varga wrote:

> I noticed that for most of this year, not really many important
> changes are committed, other than those by me. In fact, for the
> last few months, I did not see any updated files most of the time.
> With this significantly reduced activity compared to previous years,
> it is becoming very unlikely that Csound 5 can be released this
> year. I am not criticizing anyone, but it would be useful to have
> some development plan, since at this time I am basically the only
> main developer of canonical Csound, but do not know what is left
> to be done to have a final release. Also, I cannot really fix any
> issues related to platforms I do not use.
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>



Matt;
________________________
           matt  ingalls
http://sonomatics.com



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net