Of course, maintaining a manual is not my favorite cup of joy either. Once 
the manual is under control, I will be devoting most of my time to 
composing.

I don't have strong feelings one way or the other about whether there is one 
manual or two, but parts of the 4.23 manual about links, about the manual 
itself, about installing, and so on are obsolete and could be replaced by 
the csound 5 stuff.

I'm kind of hoping csound 4.23 will go away pretty soon and be replaced by 
csound 5, which is the version that I depend on for composing.

By the way, I have adopted your suggestion about breaking out the API 
reference and that is now an optional target in the SCons build for Csound 
5. It is currently a PDF since I could only figure out how to get some 
necessary introductory stuff into the manual automatically with LaTeX. That 
too could be changed (the HTML API docs are better).

----- Original Message ----- 
From: "steven yi" 
To: 
Sent: Thursday, February 03, 2005 12:12 AM
Subject: Re: [Cs-dev] Updates


> Hi Michael,
>
> I was taking a look at the two manuals and was wondering why we need to 
> split the two manuals between version 4 and 5.  I think if we can keep the 
> sections separate as well as mark opcodes and features as being "Since 
> Csound 5", users will not be confused.  On the other hand, I can see 
> already there will be a need to have more and more duplicated files 
> between the 4 and 5 branch that differ only slightly, just to handle how 
> the entities resolve and how things are organized.  I think as long as we 
> mark what is 5 and what is not, put the csound5 information in it's own 
> section (pretty much as you have with the csound5 sections), that things 
> will be much easier to keep up to date.  Although I have been spending 
> time with the documentation system and trying to get things going smoothly 
> with that, it's not exactly the most enjoyable work for me, especially as 
> I have plenty to work on with blue documentation and blue itself.  The 
> prospect of having to manage the differences between the two manuals is 
> not exactly that appealing to me and I think that making a single version 
> manual would be the most ideal for me.
>
> For an example of what I'm thinking, see:
>
> http://docbook.org/tdg/en/html/docbook.html
>
> Notice how on that page in the reference section there are standout "V4.0" 
> and "V4.2" images that denote tags that are only available in newer 
> versions.  I think the same type of standout graphic would be appropriate.
> Let me know what you think of this proposal.
> Thanks,
> steven
>
>
> Michael Gogins wrote:
>
>>
>> Third, I have updated the manual module in CVS with a new makefile and 
>> sources for a Csound 5 docbook manual. The Csound 5 manual reuses sources 
>> from the Csound 4.23 manual wherever possible. However, it has new 
>> introductory materal, new installation and compilation instructions, a 
>> users guide, and new material on extending Csound. All sources for the 
>> Csound 5 version should into into the manual/csound5 directory. All 
>> opcodes peculiar to Csound 5 should go into the manual/csound5/opcodes 
>> directory. Opcodes common to both versions of Csound should go in the 
>> usual place.
>>
>>> From now on, it would be appreciated if those who contribute code to 
>>> Csound
>>
>> 5 update the Csound 5 manual, or add to it, to document their work.
>>
>> Also, the Csound 5 manual has reference entries for the Loris opcodes, 
>> the vst4cs VST plugin opcodes, my version of the fluid opcodes (but not 
>> Steven Yi's version), and the Python opcodes.
>>
>> Again, thanks to Steven Yi for getting me a toolchain I can use.
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, if you don't feel too strongly about it one way or another, then I 
think I'll go ahead and do this:

-push the csound5 documentation into the regular manual
-reoganize the csound5 info to be the primary info, reorganize any info 
that should be there for csound4 to  the the side so that it's there but 
it's shown to be on its way out (having it accessible is important, so 
I'm not looking to get rid of it, just pushing to the side, so to speak)

As for the API docs, that's great!  I think with how things are moving 
the past week, the documentation becomes obsolete very quickly, so I 
think it's nicer to have it easy to build with the sources. 

Thanks for the Doxygen and Csound5 docs!
steven

Michael Gogins wrote:

> Of course, maintaining a manual is not my favorite cup of joy either. 
> Once the manual is under control, I will be devoting most of my time 
> to composing.
>
> I don't have strong feelings one way or the other about whether there 
> is one manual or two, but parts of the 4.23 manual about links, about 
> the manual itself, about installing, and so on are obsolete and could 
> be replaced by the csound 5 stuff.
>
> I'm kind of hoping csound 4.23 will go away pretty soon and be 
> replaced by csound 5, which is the version that I depend on for 
> composing.
>
> By the way, I have adopted your suggestion about breaking out the API 
> reference and that is now an optional target in the SCons build for 
> Csound 5. It is currently a PDF since I could only figure out how to 
> get some necessary introductory stuff into the manual automatically 
> with LaTeX. That too could be changed (the HTML API docs are better).




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net