yes, I think it looks very good from my perspective, thanks a lot for this.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 15 Nov 2019, at 11:24, Francois PINOT  wrote:
> 
> Hello John, Victor and Steven,
> 
> I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
> 
> csound
>    |____csound
>    |____plugins
>    |         |____py
>    |____manual
>    |____...
> 
> The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
> 
> If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
> 
> François

Question: What is the csound/csound folder?  Usually one has to use
installed headers because of float-version.h being updated when
installing.

On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini  wrote:
>
> yes, I think it looks very good from my perspective, thanks a lot for this.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 15 Nov 2019, at 11:24, Francois PINOT  wrote:
> >
> > Hello John, Victor and Steven,
> >
> > I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
> >
> > csound
> >    |____csound
> >    |____plugins
> >    |         |____py
> >    |____manual
> >    |____...
> >
> > The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
> >
> > If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
> >
> > François
>

I'm not sure I understand why plugins would need to have access to
Csound source?  I would imagine they would only need headers and no
linking required back to csound. Also, the above makes it sound like
float-version.h is generated into the current build folder.  I think
I'm not seeing how this works.

Also, is the csound/csound a git submodule?

It might be good to coordinate with Eduardo's plugin repo too:

https://github.com/csound-plugins/csound-plugins


On Fri, Nov 15, 2019 at 10:52 AM Francois PINOT  wrote:
>
> The first csound is github.com/csound. The second one is the csound repo within github.com/csound. For example, in the CMakeLists.txt of the plugins repo we'll find something like this:
>
> if(APPLE)
>     string(REGEX REPLACE "([^;]+)(;|$)" "include/\\1\\2" csheaders "${csheaders}")
>     file(GLOB H_headers "${CMAKE_CURRENT_SOURCE_DIR}/../csound/H/*.h")
>     set(libcsound_SRCS "${libcsound_SRCS};${csheaders};${H_headers};${CMAKE_CURRENT_BINARY_DIR}/include/float-version.h")
> endif()
>
> which allow us to reference the original CMake organisation
>
> François
>
> Le ven. 15 nov. 2019 à 16:45, Steven Yi  a écrit :
>>
>> Question: What is the csound/csound folder?  Usually one has to use
>> installed headers because of float-version.h being updated when
>> installing.
>>
>> On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini  wrote:
>> >
>> > yes, I think it looks very good from my perspective, thanks a lot for this.
>> > ========================
>> > Prof. Victor Lazzarini
>> > Maynooth University
>> > Ireland
>> >
>> > > On 15 Nov 2019, at 11:24, Francois PINOT  wrote:
>> > >
>> > > Hello John, Victor and Steven,
>> > >
>> > > I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
>> > >
>> > > csound
>> > >    |____csound
>> > >    |____plugins
>> > >    |         |____py
>> > >    |____manual
>> > >    |____...
>> > >
>> > > The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
>> > >
>> > > If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
>> > >
>> > > François
>> >

I did not look at this but two things seem 
important:

1) plugins don't link to Csound, they should only need the public headers and exported
functions from CSOUND.

2) Repos should FINDCsound() to locate a Csound installation for building. We provide
this in the source code and repos such as csound-pd use it

I would also think that having these means they will be have separate installation and release packages.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 15 Nov 2019, at 16:07, Steven Yi  wrote:
> I'm not sure I understand why plugins would need to have access to
> Csound source?  I would imagine they would only need headers and no
> linking required back to csound. Also, the above makes it sound like
> float-version.h is generated into the current build folder.  I think
> I'm not seeing how this works.
> 
> Also, is the csound/csound a git submodule?
> 
> It might be good to coordinate with Eduardo's plugin repo too:
> 
> https://github.com/csound-plugins/csound-plugins
> 
> 
>> On Fri, Nov 15, 2019 at 10:52 AM Francois PINOT  wrote:
>> 
>> The first csound is github.com/csound. The second one is the csound repo within github.com/csound. For example, in the CMakeLists.txt of the plugins repo we'll find something like this:
>> 
>> if(APPLE)
>>    string(REGEX REPLACE "([^;]+)(;|$)" "include/\\1\\2" csheaders "${csheaders}")
>>    file(GLOB H_headers "${CMAKE_CURRENT_SOURCE_DIR}/../csound/H/*.h")
>>    set(libcsound_SRCS "${libcsound_SRCS};${csheaders};${H_headers};${CMAKE_CURRENT_BINARY_DIR}/include/float-version.h")
>> endif()
>> 
>> which allow us to reference the original CMake organisation
>> 
>> François
>> 
>>> Le ven. 15 nov. 2019 à 16:45, Steven Yi  a écrit :
>>> 
>>> Question: What is the csound/csound folder?  Usually one has to use
>>> installed headers because of float-version.h being updated when
>>> installing.
>>> 
>>>> On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini  wrote:
>>>> 
>>>> yes, I think it looks very good from my perspective, thanks a lot for this.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 15 Nov 2019, at 11:24, Francois PINOT  wrote:
>>>>> 
>>>>> Hello John, Victor and Steven,
>>>>> 
>>>>> I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
>>>>> 
>>>>> csound
>>>>>   |____csound
>>>>>   |____plugins
>>>>>   |         |____py
>>>>>   |____manual
>>>>>   |____...
>>>>> 
>>>>> The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
>>>>> 
>>>>> If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
>>>>> 
>>>>> François
>>>> 

Yes, I like the idea of a plugin repo too under csound on Github.

On Fri, Nov 15, 2019 at 3:08 PM Victor Lazzarini  wrote:
>
> Have a look at the CMakeLists.txt in csound-pd, it used FINDCsound.
>
> I like the idea of the repos under the Csound
> project
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On 15 Nov 2019, at 19:21, Francoi PINOT je
>  wrote:
>
> I did it this way because I'm not a CMake guru and it was the easiest way for me to derive quickly my CMakeLists.txt files from the csound repo, because my purpose was mainly to port the py opcodes to Python3. The link to Eduardo's plugings repo is inspiring. So I will rework my CMakeLists.txt files in the sense exposed in your answers.
>
> The question is then, should we have a plugins repo in github.com/csound, including the "historical plugins" that have been inside Csound until now? If yes, then I'll push my plugins repo when it is ready with the correct CMakeFiles.txt
>
> François
>
> Le ven. 15 nov. 2019 à 18:31, Victor Lazzarini  a écrit :
>>
>> I did not look at this but two things seem
>> important:
>>
>> 1) plugins don't link to Csound, they should only need the public headers and exported
>> functions from CSOUND.
>>
>> 2) Repos should FINDCsound() to locate a Csound installation for building. We provide
>> this in the source code and repos such as csound-pd use it
>>
>> I would also think that having these means they will be have separate installation and release packages.
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> > On 15 Nov 2019, at 16:07, Steven Yi  wrote:
>> > I'm not sure I understand why plugins would need to have access to
>> > Csound source?  I would imagine they would only need headers and no
>> > linking required back to csound. Also, the above makes it sound like
>> > float-version.h is generated into the current build folder.  I think
>> > I'm not seeing how this works.
>> >
>> > Also, is the csound/csound a git submodule?
>> >
>> > It might be good to coordinate with Eduardo's plugin repo too:
>> >
>> > https://github.com/csound-plugins/csound-plugins
>> >
>> >
>> >> On Fri, Nov 15, 2019 at 10:52 AM Francois PINOT  wrote:
>> >>
>> >> The first csound is github.com/csound. The second one is the csound repo within github.com/csound. For example, in the CMakeLists.txt of the plugins repo we'll find something like this:
>> >>
>> >> if(APPLE)
>> >>    string(REGEX REPLACE "([^;]+)(;|$)" "include/\\1\\2" csheaders "${csheaders}")
>> >>    file(GLOB H_headers "${CMAKE_CURRENT_SOURCE_DIR}/../csound/H/*.h")
>> >>    set(libcsound_SRCS "${libcsound_SRCS};${csheaders};${H_headers};${CMAKE_CURRENT_BINARY_DIR}/include/float-version.h")
>> >> endif()
>> >>
>> >> which allow us to reference the original CMake organisation
>> >>
>> >> François
>> >>
>> >>> Le ven. 15 nov. 2019 à 16:45, Steven Yi  a écrit :
>> >>>
>> >>> Question: What is the csound/csound folder?  Usually one has to use
>> >>> installed headers because of float-version.h being updated when
>> >>> installing.
>> >>>
>> >>>> On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini  wrote:
>> >>>>
>> >>>> yes, I think it looks very good from my perspective, thanks a lot for this.
>> >>>> ========================
>> >>>> Prof. Victor Lazzarini
>> >>>> Maynooth University
>> >>>> Ireland
>> >>>>
>> >>>>> On 15 Nov 2019, at 11:24, Francois PINOT  wrote:
>> >>>>>
>> >>>>> Hello John, Victor and Steven,
>> >>>>>
>> >>>>> I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
>> >>>>>
>> >>>>> csound
>> >>>>>   |____csound
>> >>>>>   |____plugins
>> >>>>>   |         |____py
>> >>>>>   |____manual
>> >>>>>   |____...
>> >>>>>
>> >>>>> The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
>> >>>>>
>> >>>>> If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
>> >>>>>
>> >>>>> François
>> >>>>

If desired I can move the csound-plugins repo to the csound project.

Eduardo

On 15.11.19 21:22, Steven Yi wrote:
> Yes, I like the idea of a plugin repo too under csound on Github.
>
> On Fri, Nov 15, 2019 at 3:08 PM Victor Lazzarini  wrote:
>> Have a look at the CMakeLists.txt in csound-pd, it used FINDCsound.
>>
>> I like the idea of the repos under the Csound
>> project
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> On 15 Nov 2019, at 19:21, Francoi PINOT je
>>  wrote:
>>
>> I did it this way because I'm not a CMake guru and it was the easiest way for me to derive quickly my CMakeLists.txt files from the csound repo, because my purpose was mainly to port the py opcodes to Python3. The link to Eduardo's plugings repo is inspiring. So I will rework my CMakeLists.txt files in the sense exposed in your answers.
>>
>> The question is then, should we have a plugins repo in github.com/csound, including the "historical plugins" that have been inside Csound until now? If yes, then I'll push my plugins repo when it is ready with the correct CMakeFiles.txt
>>
>> François
>>
>> Le ven. 15 nov. 2019 à 18:31, Victor Lazzarini  a écrit :
>>> I did not look at this but two things seem
>>> important:
>>>
>>> 1) plugins don't link to Csound, they should only need the public headers and exported
>>> functions from CSOUND.
>>>
>>> 2) Repos should FINDCsound() to locate a Csound installation for building. We provide
>>> this in the source code and repos such as csound-pd use it
>>>
>>> I would also think that having these means they will be have separate installation and release packages.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>>> On 15 Nov 2019, at 16:07, Steven Yi  wrote:
>>>> I'm not sure I understand why plugins would need to have access to
>>>> Csound source?  I would imagine they would only need headers and no
>>>> linking required back to csound. Also, the above makes it sound like
>>>> float-version.h is generated into the current build folder.  I think
>>>> I'm not seeing how this works.
>>>>
>>>> Also, is the csound/csound a git submodule?
>>>>
>>>> It might be good to coordinate with Eduardo's plugin repo too:
>>>>
>>>> https://github.com/csound-plugins/csound-plugins
>>>>
>>>>
>>>>> On Fri, Nov 15, 2019 at 10:52 AM Francois PINOT  wrote:
>>>>>
>>>>> The first csound is github.com/csound. The second one is the csound repo within github.com/csound. For example, in the CMakeLists.txt of the plugins repo we'll find something like this:
>>>>>
>>>>> if(APPLE)
>>>>>     string(REGEX REPLACE "([^;]+)(;|$)" "include/\\1\\2" csheaders "${csheaders}")
>>>>>     file(GLOB H_headers "${CMAKE_CURRENT_SOURCE_DIR}/../csound/H/*.h")
>>>>>     set(libcsound_SRCS "${libcsound_SRCS};${csheaders};${H_headers};${CMAKE_CURRENT_BINARY_DIR}/include/float-version.h")
>>>>> endif()
>>>>>
>>>>> which allow us to reference the original CMake organisation
>>>>>
>>>>> François
>>>>>
>>>>>> Le ven. 15 nov. 2019 à 16:45, Steven Yi  a écrit :
>>>>>>
>>>>>> Question: What is the csound/csound folder?  Usually one has to use
>>>>>> installed headers because of float-version.h being updated when
>>>>>> installing.
>>>>>>
>>>>>>> On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini  wrote:
>>>>>>>
>>>>>>> yes, I think it looks very good from my perspective, thanks a lot for this.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>>
>>>>>>>> On 15 Nov 2019, at 11:24, Francois PINOT  wrote:
>>>>>>>>
>>>>>>>> Hello John, Victor and Steven,
>>>>>>>>
>>>>>>>> I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
>>>>>>>>
>>>>>>>> csound
>>>>>>>>    |____csound
>>>>>>>>    |____plugins
>>>>>>>>    |         |____py
>>>>>>>>    |____manual
>>>>>>>>    |____...
>>>>>>>>
>>>>>>>> The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
>>>>>>>>
>>>>>>>> If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
>>>>>>>>
>>>>>>>> François

That would require that we agree on how plugins are to be documented. Should they be integrated in the manual? Should we use the documentation system already implemented within this repo (which uses mkdocs to generate the docs)?

That would be nice Eduardo. Thanks.

François

Le ven. 15 nov. 2019 à 22:17, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> a écrit :

If desired I can move the csound-plugins repo to the csound project.

Eduardo

On 15.11.19 21:22, Steven Yi wrote:
> Yes, I like the idea of a plugin repo too under csound on Github.
>
> On Fri, Nov 15, 2019 at 3:08 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>> Have a look at the CMakeLists.txt in csound-pd, it used FINDCsound.
>>
>> I like the idea of the repos under the Csound
>> project
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> On 15 Nov 2019, at 19:21, Francoi PINOT je
>> <fggpinot@gmail.com> wrote:
>>
>> I did it this way because I'm not a CMake guru and it was the easiest way for me to derive quickly my CMakeLists.txt files from the csound repo, because my purpose was mainly to port the py opcodes to Python3. The link to Eduardo's plugings repo is inspiring. So I will rework my CMakeLists.txt files in the sense exposed in your answers.
>>
>> The question is then, should we have a plugins repo in github.com/csound, including the "historical plugins" that have been inside Csound until now? If yes, then I'll push my plugins repo when it is ready with the correct CMakeFiles.txt
>>
>> François
>>
>> Le ven. 15 nov. 2019 à 18:31, Victor Lazzarini <Victor.Lazzarini@mu.ie> a écrit :
>>> I did not look at this but two things seem
>>> important:
>>>
>>> 1) plugins don't link to Csound, they should only need the public headers and exported
>>> functions from CSOUND.
>>>
>>> 2) Repos should FINDCsound() to locate a Csound installation for building. We provide
>>> this in the source code and repos such as csound-pd use it
>>>
>>> I would also think that having these means they will be have separate installation and release packages.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>>> On 15 Nov 2019, at 16:07, Steven Yi <stevenyi@gmail.com> wrote:
>>>> I'm not sure I understand why plugins would need to have access to
>>>> Csound source?  I would imagine they would only need headers and no
>>>> linking required back to csound. Also, the above makes it sound like
>>>> float-version.h is generated into the current build folder.  I think
>>>> I'm not seeing how this works.
>>>>
>>>> Also, is the csound/csound a git submodule?
>>>>
>>>> It might be good to coordinate with Eduardo's plugin repo too:
>>>>
>>>> https://github.com/csound-plugins/csound-plugins
>>>>
>>>>
>>>>> On Fri, Nov 15, 2019 at 10:52 AM Francois PINOT <fggpinot@gmail.com> wrote:
>>>>>
>>>>> The first csound is github.com/csound. The second one is the csound repo within github.com/csound. For example, in the CMakeLists.txt of the plugins repo we'll find something like this:
>>>>>
>>>>> if(APPLE)
>>>>>     string(REGEX REPLACE "([^;]+)(;|$)" "include/\\1\\2" csheaders "${csheaders}")
>>>>>     file(GLOB H_headers "${CMAKE_CURRENT_SOURCE_DIR}/../csound/H/*.h")
>>>>>     set(libcsound_SRCS "${libcsound_SRCS};${csheaders};${H_headers};${CMAKE_CURRENT_BINARY_DIR}/include/float-version.h")
>>>>> endif()
>>>>>
>>>>> which allow us to reference the original CMake organisation
>>>>>
>>>>> François
>>>>>
>>>>>> Le ven. 15 nov. 2019 à 16:45, Steven Yi <stevenyi@gmail.com> a écrit :
>>>>>>
>>>>>> Question: What is the csound/csound folder?  Usually one has to use
>>>>>> installed headers because of float-version.h being updated when
>>>>>> installing.
>>>>>>
>>>>>>> On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>>>
>>>>>>> yes, I think it looks very good from my perspective, thanks a lot for this.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>>
>>>>>>>> On 15 Nov 2019, at 11:24, Francois PINOT <fggpinot@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hello John, Victor and Steven,
>>>>>>>>
>>>>>>>> I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
>>>>>>>>
>>>>>>>> csound
>>>>>>>>    |____csound
>>>>>>>>    |____plugins
>>>>>>>>    |         |____py
>>>>>>>>    |____manual
>>>>>>>>    |____...
>>>>>>>>
>>>>>>>> The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
>>>>>>>>
>>>>>>>> If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
>>>>>>>>
>>>>>>>> François

If there is general consent, I will see how I can transfer the repo to the csound project. To be procise, this does not mean putting it inside the source tree. Plugins should have their own build system and should only depend on the include files being present.

Regarding documentation, I think that plugin manpages should not be integrated into the manual as long as it is in its current docbook format. I would propose to use the documentation system already in place (mkdocs). I can see how viable an automated conversion from the docbook to a markdown based manual would be.

I see here two different topics:

1) Having a plugin repository under Csound  in github, which seems to find agreement from a majority of devs

2) Reorganization of the manual, which is still under discussion in the community.

For now, I created a plugins repository with the Python 3.x version of the py opcodes so that people can test them. This is a first step. Do you want me to put a link to your csound-plugins repo, which could be integrated when the community will find an agreement on the plugins documentation and the reorganization of the manual?

François

Le ven. 15 nov. 2019 à 23:34, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> a écrit :

That would require that we agree on how plugins are to be documented. Should they be integrated in the manual? Should we use the documentation system already implemented within this repo (which uses mkdocs to generate the docs)?

On 15.11.19 23:06, Francois PINOT wrote:

That would be nice Eduardo. Thanks.

François

Le ven. 15 nov. 2019 à 22:17, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> a écrit :

If desired I can move the csound-plugins repo to the csound project.

Eduardo

On 15.11.19 21:22, Steven Yi wrote:
> Yes, I like the idea of a plugin repo too under csound on Github.
>
> On Fri, Nov 15, 2019 at 3:08 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>> Have a look at the CMakeLists.txt in csound-pd, it used FINDCsound.
>>
>> I like the idea of the repos under the Csound
>> project
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> On 15 Nov 2019, at 19:21, Francoi PINOT je
>> <fggpinot@gmail.com> wrote:
>>
>> I did it this way because I'm not a CMake guru and it was the easiest way for me to derive quickly my CMakeLists.txt files from the csound repo, because my purpose was mainly to port the py opcodes to Python3. The link to Eduardo's plugings repo is inspiring. So I will rework my CMakeLists.txt files in the sense exposed in your answers.
>>
>> The question is then, should we have a plugins repo in github.com/csound, including the "historical plugins" that have been inside Csound until now? If yes, then I'll push my plugins repo when it is ready with the correct CMakeFiles.txt
>>
>> François
>>
>> Le ven. 15 nov. 2019 à 18:31, Victor Lazzarini <Victor.Lazzarini@mu.ie> a écrit :
>>> I did not look at this but two things seem
>>> important:
>>>
>>> 1) plugins don't link to Csound, they should only need the public headers and exported
>>> functions from CSOUND.
>>>
>>> 2) Repos should FINDCsound() to locate a Csound installation for building. We provide
>>> this in the source code and repos such as csound-pd use it
>>>
>>> I would also think that having these means they will be have separate installation and release packages.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>>> On 15 Nov 2019, at 16:07, Steven Yi <stevenyi@gmail.com> wrote:
>>>> I'm not sure I understand why plugins would need to have access to
>>>> Csound source?  I would imagine they would only need headers and no
>>>> linking required back to csound. Also, the above makes it sound like
>>>> float-version.h is generated into the current build folder.  I think
>>>> I'm not seeing how this works.
>>>>
>>>> Also, is the csound/csound a git submodule?
>>>>
>>>> It might be good to coordinate with Eduardo's plugin repo too:
>>>>
>>>> https://github.com/csound-plugins/csound-plugins
>>>>
>>>>
>>>>> On Fri, Nov 15, 2019 at 10:52 AM Francois PINOT <fggpinot@gmail.com> wrote:
>>>>>
>>>>> The first csound is github.com/csound. The second one is the csound repo within github.com/csound. For example, in the CMakeLists.txt of the plugins repo we'll find something like this:
>>>>>
>>>>> if(APPLE)
>>>>>     string(REGEX REPLACE "([^;]+)(;|$)" "include/\\1\\2" csheaders "${csheaders}")
>>>>>     file(GLOB H_headers "${CMAKE_CURRENT_SOURCE_DIR}/../csound/H/*.h")
>>>>>     set(libcsound_SRCS "${libcsound_SRCS};${csheaders};${H_headers};${CMAKE_CURRENT_BINARY_DIR}/include/float-version.h")
>>>>> endif()
>>>>>
>>>>> which allow us to reference the original CMake organisation
>>>>>
>>>>> François
>>>>>
>>>>>> Le ven. 15 nov. 2019 à 16:45, Steven Yi <stevenyi@gmail.com> a écrit :
>>>>>>
>>>>>> Question: What is the csound/csound folder?  Usually one has to use
>>>>>> installed headers because of float-version.h being updated when
>>>>>> installing.
>>>>>>
>>>>>>> On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>>>
>>>>>>> yes, I think it looks very good from my perspective, thanks a lot for this.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>>
>>>>>>>> On 15 Nov 2019, at 11:24, Francois PINOT <fggpinot@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hello John, Victor and Steven,
>>>>>>>>
>>>>>>>> I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
>>>>>>>>
>>>>>>>> csound
>>>>>>>>    |____csound
>>>>>>>>    |____plugins
>>>>>>>>    |         |____py
>>>>>>>>    |____manual
>>>>>>>>    |____...
>>>>>>>>
>>>>>>>> The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
>>>>>>>>
>>>>>>>> If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
>>>>>>>>
>>>>>>>> François

Do you have developer access? If not, I can add you, just give me your user name.

That's the simplest way to make this move.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 15 Nov 2019, at 21:17, Eduardo Moguillansky  wrote:
> 
> If desired I can move the csound-plugins repo to the csound project.
> 
> Eduardo
> 
>> On 15.11.19 21:22, Steven Yi wrote:
>> Yes, I like the idea of a plugin repo too under csound on Github.
>> 
>>> On Fri, Nov 15, 2019 at 3:08 PM Victor Lazzarini  wrote:
>>> Have a look at the CMakeLists.txt in csound-pd, it used FINDCsound.
>>> 
>>> I like the idea of the repos under the Csound
>>> project
>>> 
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>> 
>>> On 15 Nov 2019, at 19:21, Francoi PINOT je
>>>  wrote:
>>> 
>>> I did it this way because I'm not a CMake guru and it was the easiest way for me to derive quickly my CMakeLists.txt files from the csound repo, because my purpose was mainly to port the py opcodes to Python3. The link to Eduardo's plugings repo is inspiring. So I will rework my CMakeLists.txt files in the sense exposed in your answers.
>>> 
>>> The question is then, should we have a plugins repo in github.com/csound, including the "historical plugins" that have been inside Csound until now? If yes, then I'll push my plugins repo when it is ready with the correct CMakeFiles.txt
>>> 
>>> François
>>> 
>>>> Le ven. 15 nov. 2019 à 18:31, Victor Lazzarini  a écrit :
>>>> I did not look at this but two things seem
>>>> important:
>>>> 
>>>> 1) plugins don't link to Csound, they should only need the public headers and exported
>>>> functions from CSOUND.
>>>> 
>>>> 2) Repos should FINDCsound() to locate a Csound installation for building. We provide
>>>> this in the source code and repos such as csound-pd use it
>>>> 
>>>> I would also think that having these means they will be have separate installation and release packages.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 15 Nov 2019, at 16:07, Steven Yi  wrote:
>>>>> I'm not sure I understand why plugins would need to have access to
>>>>> Csound source?  I would imagine they would only need headers and no
>>>>> linking required back to csound. Also, the above makes it sound like
>>>>> float-version.h is generated into the current build folder.  I think
>>>>> I'm not seeing how this works.
>>>>> 
>>>>> Also, is the csound/csound a git submodule?
>>>>> 
>>>>> It might be good to coordinate with Eduardo's plugin repo too:
>>>>> 
>>>>> https://github.com/csound-plugins/csound-plugins
>>>>> 
>>>>> 
>>>>>> On Fri, Nov 15, 2019 at 10:52 AM Francois PINOT  wrote:
>>>>>> 
>>>>>> The first csound is github.com/csound. The second one is the csound repo within github.com/csound. For example, in the CMakeLists.txt of the plugins repo we'll find something like this:
>>>>>> 
>>>>>> if(APPLE)
>>>>>>    string(REGEX REPLACE "([^;]+)(;|$)" "include/\\1\\2" csheaders "${csheaders}")
>>>>>>    file(GLOB H_headers "${CMAKE_CURRENT_SOURCE_DIR}/../csound/H/*.h")
>>>>>>    set(libcsound_SRCS "${libcsound_SRCS};${csheaders};${H_headers};${CMAKE_CURRENT_BINARY_DIR}/include/float-version.h")
>>>>>> endif()
>>>>>> 
>>>>>> which allow us to reference the original CMake organisation
>>>>>> 
>>>>>> François
>>>>>> 
>>>>>>> Le ven. 15 nov. 2019 à 16:45, Steven Yi  a écrit :
>>>>>>> 
>>>>>>> Question: What is the csound/csound folder?  Usually one has to use
>>>>>>> installed headers because of float-version.h being updated when
>>>>>>> installing.
>>>>>>> 
>>>>>>>> On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> yes, I think it looks very good from my perspective, thanks a lot for this.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>> 
>>>>>>>>> On 15 Nov 2019, at 11:24, Francois PINOT  wrote:
>>>>>>>>> 
>>>>>>>>> Hello John, Victor and Steven,
>>>>>>>>> 
>>>>>>>>> I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
>>>>>>>>> 
>>>>>>>>> csound
>>>>>>>>>   |____csound
>>>>>>>>>   |____plugins
>>>>>>>>>   |         |____py
>>>>>>>>>   |____manual
>>>>>>>>>   |____...
>>>>>>>>> 
>>>>>>>>> The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
>>>>>>>>> 
>>>>>>>>> If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
>>>>>>>>> 
>>>>>>>>> François

If there is general consent, I will see how I can transfer the repo to the csound project. To be procise, this does not mean putting it inside the source tree. Plugins should have their own build system and should only depend on the include files being present.

Regarding documentation, I think that plugin manpages should not be integrated into the manual as long as it is in its current docbook format. I would propose to use the documentation system already in place (mkdocs). I can see how viable an automated conversion from the docbook to a markdown based manual would be.

On 16.11.19 11:03, Francois PINOT wrote:

I see here two different topics:

1) Having a plugin repository under Csound  in github, which seems to find agreement from a majority of devs

2) Reorganization of the manual, which is still under discussion in the community.

For now, I created a plugins repository with the Python 3.x version of the py opcodes so that people can test them. This is a first step. Do you want me to put a link to your csound-plugins repo, which could be integrated when the community will find an agreement on the plugins documentation and the reorganization of the manual?

François

Le ven. 15 nov. 2019 à 23:34, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> a écrit :

That would require that we agree on how plugins are to be documented. Should they be integrated in the manual? Should we use the documentation system already implemented within this repo (which uses mkdocs to generate the docs)?

On 15.11.19 23:06, Francois PINOT wrote:

That would be nice Eduardo. Thanks.

François

Le ven. 15 nov. 2019 à 22:17, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> a écrit :

If desired I can move the csound-plugins repo to the csound project.

Eduardo

On 15.11.19 21:22, Steven Yi wrote:
> Yes, I like the idea of a plugin repo too under csound on Github.
>
> On Fri, Nov 15, 2019 at 3:08 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>> Have a look at the CMakeLists.txt in csound-pd, it used FINDCsound.
>>
>> I like the idea of the repos under the Csound
>> project
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> On 15 Nov 2019, at 19:21, Francoi PINOT je
>> <fggpinot@gmail.com> wrote:
>>
>> I did it this way because I'm not a CMake guru and it was the easiest way for me to derive quickly my CMakeLists.txt files from the csound repo, because my purpose was mainly to port the py opcodes to Python3. The link to Eduardo's plugings repo is inspiring. So I will rework my CMakeLists.txt files in the sense exposed in your answers.
>>
>> The question is then, should we have a plugins repo in github.com/csound, including the "historical plugins" that have been inside Csound until now? If yes, then I'll push my plugins repo when it is ready with the correct CMakeFiles.txt
>>
>> François
>>
>> Le ven. 15 nov. 2019 à 18:31, Victor Lazzarini <Victor.Lazzarini@mu.ie> a écrit :
>>> I did not look at this but two things seem
>>> important:
>>>
>>> 1) plugins don't link to Csound, they should only need the public headers and exported
>>> functions from CSOUND.
>>>
>>> 2) Repos should FINDCsound() to locate a Csound installation for building. We provide
>>> this in the source code and repos such as csound-pd use it
>>>
>>> I would also think that having these means they will be have separate installation and release packages.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>>> On 15 Nov 2019, at 16:07, Steven Yi <stevenyi@gmail.com> wrote:
>>>> I'm not sure I understand why plugins would need to have access to
>>>> Csound source?  I would imagine they would only need headers and no
>>>> linking required back to csound. Also, the above makes it sound like
>>>> float-version.h is generated into the current build folder.  I think
>>>> I'm not seeing how this works.
>>>>
>>>> Also, is the csound/csound a git submodule?
>>>>
>>>> It might be good to coordinate with Eduardo's plugin repo too:
>>>>
>>>> https://github.com/csound-plugins/csound-plugins
>>>>
>>>>
>>>>> On Fri, Nov 15, 2019 at 10:52 AM Francois PINOT <fggpinot@gmail.com> wrote:
>>>>>
>>>>> The first csound is github.com/csound. The second one is the csound repo within github.com/csound. For example, in the CMakeLists.txt of the plugins repo we'll find something like this:
>>>>>
>>>>> if(APPLE)
>>>>>     string(REGEX REPLACE "([^;]+)(;|$)" "include/\\1\\2" csheaders "${csheaders}")
>>>>>     file(GLOB H_headers "${CMAKE_CURRENT_SOURCE_DIR}/../csound/H/*.h")
>>>>>     set(libcsound_SRCS "${libcsound_SRCS};${csheaders};${H_headers};${CMAKE_CURRENT_BINARY_DIR}/include/float-version.h")
>>>>> endif()
>>>>>
>>>>> which allow us to reference the original CMake organisation
>>>>>
>>>>> François
>>>>>
>>>>>> Le ven. 15 nov. 2019 à 16:45, Steven Yi <stevenyi@gmail.com> a écrit :
>>>>>>
>>>>>> Question: What is the csound/csound folder?  Usually one has to use
>>>>>> installed headers because of float-version.h being updated when
>>>>>> installing.
>>>>>>
>>>>>>> On Fri, Nov 15, 2019 at 7:17 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>>>
>>>>>>> yes, I think it looks very good from my perspective, thanks a lot for this.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>>
>>>>>>>> On 15 Nov 2019, at 11:24, Francois PINOT <fggpinot@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hello John, Victor and Steven,
>>>>>>>>
>>>>>>>> I just adapted successfully the py opcodes for Python3.x. After of suggestion from Victor, I made a plugin repository in my local csound repository with the following hierarchy:
>>>>>>>>
>>>>>>>> csound
>>>>>>>>    |____csound
>>>>>>>>    |____plugins
>>>>>>>>    |         |____py
>>>>>>>>    |____manual
>>>>>>>>    |____...
>>>>>>>>
>>>>>>>> The plugins and the py repos have their own CMakeList.txt files referencing the csound repo to keep the bells and whistle of the current build system. This plugins repo could be the first step toward building the plugins apart from the core csound repo.
>>>>>>>>
>>>>>>>> If you agree with this idea, I can push on github.com/csound this plugins repo so that people can already test the py opcodes with Python3 without interfering with the current csound6.14 release.
>>>>>>>>
>>>>>>>> François