I adapted the cmake scripts of my own plugins to build within the tree 
of the new plugins repo living here https://github.com/csound/plugins

Everything seems to build correctly in linux, macOS and windows. What is 
confusing about this repository is that the plugins there are still 
present in the main tree. How are these two projects suppose to interact?

What about documentation?

Anyway, I can send a PR with the new plugins to have everything under 
one tree.

best

I think the idea is this where things will be once things are moved
out from CS7 and it's in preparation stage now.

Documentation is a good question: suggestions?  Seems like it would be
best to keep the docs within each opcode's subdirectory, but have a
build stage that compiles an aggregate doc for the plugins by
traversing the directories.  It'd be easy then to copy a module
(folder) for others to get going.

PR sounds good, I imagine this will take some iterations to work out
what's missing and what needs to be changed to get it to work for
everyone.

On Wed, Dec 18, 2019 at 7:35 AM Eduardo Moguillansky
 wrote:
>
> I adapted the cmake scripts of my own plugins to build within the tree
> of the new plugins repo living here https://github.com/csound/plugins
>
> Everything seems to build correctly in linux, macOS and windows. What is
> confusing about this repository is that the plugins there are still
> present in the main tree. How are these two projects suppose to interact?
>
> What about documentation?
>
> Anyway, I can send a PR with the new plugins to have everything under
> one tree.
>
> best
>

On 19.12.19 18:06, Steven Yi wrote:
> I think the idea is this where things will be once things are moved
> out from CS7 and it's in preparation stage now.

It would be possible to make these two projects coexist by excluding the 
duplicate plugins from building (editing them out in the CMakeLists 
file). Like that we could move on with making this the "official" 
plugins project, see how the documentation can be integrated with the 
rest of csound, etc.


> Documentation is a good question: suggestions?  Seems like it would be
> best to keep the docs within each opcode's subdirectory, but have a
> build stage that compiles an aggregate doc for the plugins by
> traversing the directories.  It'd be easy then to copy a module
> (folder) for others to get going.

There was some discussion about documentation systems. There is no 
shortage of those. The question to answer is how any documentation could 
be integrated with the main docs. My suggestion would be first to see if 
a conversion of the current docbook manual to something more maleable 
can be achieved with as little manual work as possible.

Another question which needs to be resolved is about dependencies.

>
> PR sounds good, I imagine this will take some iterations to work out
> what's missing and what needs to be changed to get it to work for
> everyone.
>
> On Wed, Dec 18, 2019 at 7:35 AM Eduardo Moguillansky
>  wrote:
>> I adapted the cmake scripts of my own plugins to build within the tree
>> of the new plugins repo living here https://github.com/csound/plugins
>>
>> Everything seems to build correctly in linux, macOS and windows. What is
>> confusing about this repository is that the plugins there are still
>> present in the main tree. How are these two projects suppose to interact?
>>
>> What about documentation?
>>
>> Anyway, I can send a PR with the new plugins to have everything under
>> one tree.
>>
>> best
>>

Disabling some modules makes sense to me.  Could have multiple
top-level build files or single build file with options for choosing
"build all" or "build CS6 compatible" or something along those lines.

For integration with main docs, I'm not sure that's necessary.  We
could have a "plugins" documentation that lives with the plugins and
just have some URL links between the two projects.

One option that might be curious is to use Github pages.  We can make
the repo be a Jekyll website and use markdown for documentation and a
top-level page that traverses the other pages. Might need some work to
organize the repository structure to keep the pages to the side, but
it would be pretty easy for contributions once setup I think.


On Thu, Dec 19, 2019 at 3:05 PM Eduardo Moguillansky
 wrote:
>
> On 19.12.19 18:06, Steven Yi wrote:
> > I think the idea is this where things will be once things are moved
> > out from CS7 and it's in preparation stage now.
>
> It would be possible to make these two projects coexist by excluding the
> duplicate plugins from building (editing them out in the CMakeLists
> file). Like that we could move on with making this the "official"
> plugins project, see how the documentation can be integrated with the
> rest of csound, etc.
>
>
> > Documentation is a good question: suggestions?  Seems like it would be
> > best to keep the docs within each opcode's subdirectory, but have a
> > build stage that compiles an aggregate doc for the plugins by
> > traversing the directories.  It'd be easy then to copy a module
> > (folder) for others to get going.
>
> There was some discussion about documentation systems. There is no
> shortage of those. The question to answer is how any documentation could
> be integrated with the main docs. My suggestion would be first to see if
> a conversion of the current docbook manual to something more maleable
> can be achieved with as little manual work as possible.
>
> Another question which needs to be resolved is about dependencies.
>
> >
> > PR sounds good, I imagine this will take some iterations to work out
> > what's missing and what needs to be changed to get it to work for
> > everyone.
> >
> > On Wed, Dec 18, 2019 at 7:35 AM Eduardo Moguillansky
> >  wrote:
> >> I adapted the cmake scripts of my own plugins to build within the tree
> >> of the new plugins repo living here https://github.com/csound/plugins
> >>
> >> Everything seems to build correctly in linux, macOS and windows. What is
> >> confusing about this repository is that the plugins there are still
> >> present in the main tree. How are these two projects suppose to interact?
> >>
> >> What about documentation?
> >>
> >> Anyway, I can send a PR with the new plugins to have everything under
> >> one tree.
> >>
> >> best
> >>

I think the documentation suggestion to use markdown is sensible. You
can do the markdown in the same format as the Csound Reference Manual.
If each plugin is one subdirectory each can have one README.md that
serves as the reference manual page.

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Thu, Dec 19, 2019 at 3:21 PM Steven Yi  wrote:
>
> Disabling some modules makes sense to me.  Could have multiple
> top-level build files or single build file with options for choosing
> "build all" or "build CS6 compatible" or something along those lines.
>
> For integration with main docs, I'm not sure that's necessary.  We
> could have a "plugins" documentation that lives with the plugins and
> just have some URL links between the two projects.
>
> One option that might be curious is to use Github pages.  We can make
> the repo be a Jekyll website and use markdown for documentation and a
> top-level page that traverses the other pages. Might need some work to
> organize the repository structure to keep the pages to the side, but
> it would be pretty easy for contributions once setup I think.
>
>
> On Thu, Dec 19, 2019 at 3:05 PM Eduardo Moguillansky
>  wrote:
> >
> > On 19.12.19 18:06, Steven Yi wrote:
> > > I think the idea is this where things will be once things are moved
> > > out from CS7 and it's in preparation stage now.
> >
> > It would be possible to make these two projects coexist by excluding the
> > duplicate plugins from building (editing them out in the CMakeLists
> > file). Like that we could move on with making this the "official"
> > plugins project, see how the documentation can be integrated with the
> > rest of csound, etc.
> >
> >
> > > Documentation is a good question: suggestions?  Seems like it would be
> > > best to keep the docs within each opcode's subdirectory, but have a
> > > build stage that compiles an aggregate doc for the plugins by
> > > traversing the directories.  It'd be easy then to copy a module
> > > (folder) for others to get going.
> >
> > There was some discussion about documentation systems. There is no
> > shortage of those. The question to answer is how any documentation could
> > be integrated with the main docs. My suggestion would be first to see if
> > a conversion of the current docbook manual to something more maleable
> > can be achieved with as little manual work as possible.
> >
> > Another question which needs to be resolved is about dependencies.
> >
> > >
> > > PR sounds good, I imagine this will take some iterations to work out
> > > what's missing and what needs to be changed to get it to work for
> > > everyone.
> > >
> > > On Wed, Dec 18, 2019 at 7:35 AM Eduardo Moguillansky
> > >  wrote:
> > >> I adapted the cmake scripts of my own plugins to build within the tree
> > >> of the new plugins repo living here https://github.com/csound/plugins
> > >>
> > >> Everything seems to build correctly in linux, macOS and windows. What is
> > >> confusing about this repository is that the plugins there are still
> > >> present in the main tree. How are these two projects suppose to interact?
> > >>
> > >> What about documentation?
> > >>
> > >> Anyway, I can send a PR with the new plugins to have everything under
> > >> one tree.
> > >>
> > >> best
> > >>

I have a question about how to manage dependencies in the plugin
repository. What should we do to manage dependencies that have to be
built from source code?

Jon Christopher Nelson created a VST effect plugin based on Cabbage
and Csound called MVerb, which implements a very high quality reverb
using a mesh of filtered delay lines.

I have now succeeded in porting Nelson's plugin to a C++ plugin
opcode, and I would like to host this and other plugins I may create
in the plugin repository.

However, in order to implement MVerb, I have used Lance Putnam's Gamma
library for audio signal processing in C++. This library is not a
system package, and it does not have a CMake build system. I had to
use the included Makefile and I had to change the build options to
include -fPIC.

I suggest that in the plugins repository, for source code level
dependencies such as Gamma, there be a Git submodule (if the
dependency is hosted in a Git repository) in a "dependencies"
subdirectory of the plugins repository, and that the CMakeLIsts.txt
for the plugin that uses that source level dependency include some
means of building that dependency, without necessarily using a CMake
"find" macro.

What do you think?


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Fri, Jan 3, 2020 at 10:12 AM Michael Gogins  wrote:
>
> I think the documentation suggestion to use markdown is sensible. You
> can do the markdown in the same format as the Csound Reference Manual.
> If each plugin is one subdirectory each can have one README.md that
> serves as the reference manual page.
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Thu, Dec 19, 2019 at 3:21 PM Steven Yi  wrote:
> >
> > Disabling some modules makes sense to me.  Could have multiple
> > top-level build files or single build file with options for choosing
> > "build all" or "build CS6 compatible" or something along those lines.
> >
> > For integration with main docs, I'm not sure that's necessary.  We
> > could have a "plugins" documentation that lives with the plugins and
> > just have some URL links between the two projects.
> >
> > One option that might be curious is to use Github pages.  We can make
> > the repo be a Jekyll website and use markdown for documentation and a
> > top-level page that traverses the other pages. Might need some work to
> > organize the repository structure to keep the pages to the side, but
> > it would be pretty easy for contributions once setup I think.
> >
> >
> > On Thu, Dec 19, 2019 at 3:05 PM Eduardo Moguillansky
> >  wrote:
> > >
> > > On 19.12.19 18:06, Steven Yi wrote:
> > > > I think the idea is this where things will be once things are moved
> > > > out from CS7 and it's in preparation stage now.
> > >
> > > It would be possible to make these two projects coexist by excluding the
> > > duplicate plugins from building (editing them out in the CMakeLists
> > > file). Like that we could move on with making this the "official"
> > > plugins project, see how the documentation can be integrated with the
> > > rest of csound, etc.
> > >
> > >
> > > > Documentation is a good question: suggestions?  Seems like it would be
> > > > best to keep the docs within each opcode's subdirectory, but have a
> > > > build stage that compiles an aggregate doc for the plugins by
> > > > traversing the directories.  It'd be easy then to copy a module
> > > > (folder) for others to get going.
> > >
> > > There was some discussion about documentation systems. There is no
> > > shortage of those. The question to answer is how any documentation could
> > > be integrated with the main docs. My suggestion would be first to see if
> > > a conversion of the current docbook manual to something more maleable
> > > can be achieved with as little manual work as possible.
> > >
> > > Another question which needs to be resolved is about dependencies.
> > >
> > > >
> > > > PR sounds good, I imagine this will take some iterations to work out
> > > > what's missing and what needs to be changed to get it to work for
> > > > everyone.
> > > >
> > > > On Wed, Dec 18, 2019 at 7:35 AM Eduardo Moguillansky
> > > >  wrote:
> > > >> I adapted the cmake scripts of my own plugins to build within the tree
> > > >> of the new plugins repo living here https://github.com/csound/plugins
> > > >>
> > > >> Everything seems to build correctly in linux, macOS and windows. What is
> > > >> confusing about this repository is that the plugins there are still
> > > >> present in the main tree. How are these two projects suppose to interact?
> > > >>
> > > >> What about documentation?
> > > >>
> > > >> Anyway, I can send a PR with the new plugins to have everything under
> > > >> one tree.
> > > >>
> > > >> best
> > > >>

I think we need an editor (person) to look after these things, think it through, and provide a
set of rules. Otherwise we’ll quickly descend into chaos.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 6 Jan 2020, at 15:56, Rory Walsh  wrote:
> 
> Good question. Currently each plugin library is in a dedicated folder. This seems clean to me. If any plugin lib needs extra deps, then would it be Ok for each plugin to have its own deps folder rather than a 'global' deps folder, which I fear will get cluttered with all sorts of 3rd party frameworks over time?  
> 
> On Mon, 6 Jan 2020 at 14:37, Michael Gogins  wrote:
> I have a question about how to manage dependencies in the plugin
> repository. What should we do to manage dependencies that have to be
> built from source code?
> 
> Jon Christopher Nelson created a VST effect plugin based on Cabbage
> and Csound called MVerb, which implements a very high quality reverb
> using a mesh of filtered delay lines.
> 
> I have now succeeded in porting Nelson's plugin to a C++ plugin
> opcode, and I would like to host this and other plugins I may create
> in the plugin repository.
> 
> However, in order to implement MVerb, I have used Lance Putnam's Gamma
> library for audio signal processing in C++. This library is not a
> system package, and it does not have a CMake build system. I had to
> use the included Makefile and I had to change the build options to
> include -fPIC.
> 
> I suggest that in the plugins repository, for source code level
> dependencies such as Gamma, there be a Git submodule (if the
> dependency is hosted in a Git repository) in a "dependencies"
> subdirectory of the plugins repository, and that the CMakeLIsts.txt
> for the plugin that uses that source level dependency include some
> means of building that dependency, without necessarily using a CMake
> "find" macro.
> 
> What do you think?
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> On Fri, Jan 3, 2020 at 10:12 AM Michael Gogins  wrote:
> >
> > I think the documentation suggestion to use markdown is sensible. You
> > can do the markdown in the same format as the Csound Reference Manual.
> > If each plugin is one subdirectory each can have one README.md that
> > serves as the reference manual page.
> >
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> > On Thu, Dec 19, 2019 at 3:21 PM Steven Yi  wrote:
> > >
> > > Disabling some modules makes sense to me.  Could have multiple
> > > top-level build files or single build file with options for choosing
> > > "build all" or "build CS6 compatible" or something along those lines.
> > >
> > > For integration with main docs, I'm not sure that's necessary.  We
> > > could have a "plugins" documentation that lives with the plugins and
> > > just have some URL links between the two projects.
> > >
> > > One option that might be curious is to use Github pages.  We can make
> > > the repo be a Jekyll website and use markdown for documentation and a
> > > top-level page that traverses the other pages. Might need some work to
> > > organize the repository structure to keep the pages to the side, but
> > > it would be pretty easy for contributions once setup I think.
> > >
> > >
> > > On Thu, Dec 19, 2019 at 3:05 PM Eduardo Moguillansky
> > >  wrote:
> > > >
> > > > On 19.12.19 18:06, Steven Yi wrote:
> > > > > I think the idea is this where things will be once things are moved
> > > > > out from CS7 and it's in preparation stage now.
> > > >
> > > > It would be possible to make these two projects coexist by excluding the
> > > > duplicate plugins from building (editing them out in the CMakeLists
> > > > file). Like that we could move on with making this the "official"
> > > > plugins project, see how the documentation can be integrated with the
> > > > rest of csound, etc.
> > > >
> > > >
> > > > > Documentation is a good question: suggestions?  Seems like it would be
> > > > > best to keep the docs within each opcode's subdirectory, but have a
> > > > > build stage that compiles an aggregate doc for the plugins by
> > > > > traversing the directories.  It'd be easy then to copy a module
> > > > > (folder) for others to get going.
> > > >
> > > > There was some discussion about documentation systems. There is no
> > > > shortage of those. The question to answer is how any documentation could
> > > > be integrated with the main docs. My suggestion would be first to see if
> > > > a conversion of the current docbook manual to something more maleable
> > > > can be achieved with as little manual work as possible.
> > > >
> > > > Another question which needs to be resolved is about dependencies.
> > > >
> > > > >
> > > > > PR sounds good, I imagine this will take some iterations to work out
> > > > > what's missing and what needs to be changed to get it to work for
> > > > > everyone.
> > > > >
> > > > > On Wed, Dec 18, 2019 at 7:35 AM Eduardo Moguillansky
> > > > >  wrote:
> > > > >> I adapted the cmake scripts of my own plugins to build within the tree
> > > > >> of the new plugins repo living here https://github.com/csound/plugins
> > > > >>
> > > > >> Everything seems to build correctly in linux, macOS and windows. What is
> > > > >> confusing about this repository is that the plugins there are still
> > > > >> present in the main tree. How are these two projects suppose to interact?
> > > > >>
> > > > >> What about documentation?
> > > > >>
> > > > >> Anyway, I can send a PR with the new plugins to have everything under
> > > > >> one tree.
> > > > >>
> > > > >> 

I would favor the idea of one directory per plugin library 
instead of having a folder per contributer. Regarding 
documentation / examples, I would propose that all plugin 
projects have at least following structure (or similar)

csound-plugins/
  foo/
    CMakeLists.txt
    README.md   <---- short description about the plugins defined here
    docs/
      opcode1.md
      opcode2.md
      ...
     examples/   <---- optional
       opcode1.csd
       opcode2.csd

How dependencies are handled, where they are placed, should be
left to the discretion of the developer, as long as they are
within the project directory. 
There should be one .md file for each opcode defined in the library,
and, optionally, an example file showing how the opcode is used. An 
example should be included within the .md file.

One question: if a certain dependency could/should be installed
through a package manager (apt-get, brew, etc), how should that be handled?

I think once some thought is given to getting it set up correctly, with a clear set of guidelines, we can avoid the need of a maintainer. That's why I was thinking each contributer would have their own self contained directory, that can't contaminate anyone elses projects. 

On Mon 6 Jan 2020, 17:04 Victor Lazzarini, <Victor.Lazzarini@mu.ie> wrote:

I think we need an editor (person) to look after these things, think it through, and provide a
set of rules. Otherwise we’ll quickly descend into chaos.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 6 Jan 2020, at 15:56, Rory Walsh <rorywalsh@EAR.IE> wrote:
>
> Good question. Currently each plugin library is in a dedicated folder. This seems clean to me. If any plugin lib needs extra deps, then would it be Ok for each plugin to have its own deps folder rather than a 'global' deps folder, which I fear will get cluttered with all sorts of 3rd party frameworks over time? 
>
> On Mon, 6 Jan 2020 at 14:37, Michael Gogins <michael.gogins@gmail.com> wrote:
> I have a question about how to manage dependencies in the plugin
> repository. What should we do to manage dependencies that have to be
> built from source code?
>
> Jon Christopher Nelson created a VST effect plugin based on Cabbage
> and Csound called MVerb, which implements a very high quality reverb
> using a mesh of filtered delay lines.
>
> I have now succeeded in porting Nelson's plugin to a C++ plugin
> opcode, and I would like to host this and other plugins I may create
> in the plugin repository.
>
> However, in order to implement MVerb, I have used Lance Putnam's Gamma
> library for audio signal processing in C++. This library is not a
> system package, and it does not have a CMake build system. I had to
> use the included Makefile and I had to change the build options to
> include -fPIC.
>
> I suggest that in the plugins repository, for source code level
> dependencies such as Gamma, there be a Git submodule (if the
> dependency is hosted in a Git repository) in a "dependencies"
> subdirectory of the plugins repository, and that the CMakeLIsts.txt
> for the plugin that uses that source level dependency include some
> means of building that dependency, without necessarily using a CMake
> "find" macro.
>
> What do you think?
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Fri, Jan 3, 2020 at 10:12 AM Michael Gogins <michael.gogins@gmail.com> wrote:
> >
> > I think the documentation suggestion to use markdown is sensible. You
> > can do the markdown in the same format as the Csound Reference Manual.
> > If each plugin is one subdirectory each can have one README.md that
> > serves as the reference manual page.
> >
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> > On Thu, Dec 19, 2019 at 3:21 PM Steven Yi <stevenyi@gmail.com> wrote:
> > >
> > > Disabling some modules makes sense to me.  Could have multiple
> > > top-level build files or single build file with options for choosing
> > > "build all" or "build CS6 compatible" or something along those lines.
> > >
> > > For integration with main docs, I'm not sure that's necessary.  We
> > > could have a "plugins" documentation that lives with the plugins and
> > > just have some URL links between the two projects.
> > >
> > > One option that might be curious is to use Github pages.  We can make
> > > the repo be a Jekyll website and use markdown for documentation and a
> > > top-level page that traverses the other pages. Might need some work to
> > > organize the repository structure to keep the pages to the side, but
> > > it would be pretty easy for contributions once setup I think.
> > >
> > >
> > > On Thu, Dec 19, 2019 at 3:05 PM Eduardo Moguillansky
> > > <eduardo.moguillansky@gmail.com> wrote:
> > > >
> > > > On 19.12.19 18:06, Steven Yi wrote:
> > > > > I think the idea is this where things will be once things are moved
> > > > > out from CS7 and it's in preparation stage now.
> > > >
> > > > It would be possible to make these two projects coexist by excluding the
> > > > duplicate plugins from building (editing them out in the CMakeLists
> > > > file). Like that we could move on with making this the "official"
> > > > plugins project, see how the documentation can be integrated with the
> > > > rest of csound, etc.
> > > >
> > > >
> > > > > Documentation is a good question: suggestions?  Seems like it would be
> > > > > best to keep the docs within each opcode's subdirectory, but have a
> > > > > build stage that compiles an aggregate doc for the plugins by
> > > > > traversing the directories.  It'd be easy then to copy a module
> > > > > (folder) for others to get going.
> > > >
> > > > There was some discussion about documentation systems. There is no
> > > > shortage of those. The question to answer is how any documentation could
> > > > be integrated with the main docs. My suggestion would be first to see if
> > > > a conversion of the current docbook manual to something more maleable
> > > > can be achieved with as little manual work as possible.
> > > >
> > > > Another question which needs to be resolved is about dependencies.
> > > >
> > > > >
> > > > > PR sounds good, I imagine this will take some iterations to work out
> > > > > what's missing and what needs to be changed to get it to work for
> > > > > everyone.
> > > > >
> > > > > On Wed, Dec 18, 2019 at 7:35 AM Eduardo Moguillansky
> > > > > <eduardo.moguillansky@gmail.com> wrote:
> > > > >> I adapted the cmake scripts of my own plugins to build within the tree
> > > > >> of the new plugins repo living here https://github.com/csound/plugins
> > > > >>
> > > > >> Everything seems to build correctly in linux, macOS and windows. What is
> > > > >> confusing about this repository is that the plugins there are still
> > > > >> present in the main tree. How are these two projects suppose to interact?
> > > > >>
> > > > >> What about documentation?
> > > > >>
> > > > >> Anyway, I can send a PR with the new plugins to have everything under
> > > > >> one tree.
> > > > >>
> > > > >> best
> > > > >>
> > > > >> Eduardo

That is what I have been doing in my own repository.

So, what I'm going to do, when I add MVerb to the main plugins
repository, is to make the Gamma repository a submodule of the MVerb
repository. I will create my own CMake build system for the Gamma
library. By the way, the Gamma library is statically linked with the
opcode shared library.

So, there's one additional fillip to cloning and building the main
plugins repository, and that is making sure that any submodules are
properly initialized. This however is easy to do recursively.

There are tradeoffs here. If everyone keeps all dependencies of their
plugins in their plugin directories, then it is possible, even likely,
that some of these dependencies will be duplicated between plugins.
But, that totally simplifies the actual build.

Actually there's another fillip, which is updating and upgrading
system dependencies for plugins. But, I'm content not to do anything
about that since using a script or something would be another thing to
maintain.

I do think it is best to have exactly one and only one plugin in each
subdirectory, although of course one plugin can contain multiple
opcodes.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Tue, Jan 7, 2020 at 5:41 AM Rory Walsh  wrote:
>
> If they don't have their own CMake build, can you not just build them as part of the CMake build you use for your own plugins?
>
> On Tue, 7 Jan 2020 at 01:52, Michael Gogins  wrote:
>>
>> My question was about dependencies that find_package won't find because they need to be built from source, and don't have their own CMake build.
>>
>> On Mon, Jan 6, 2020, 17:31 Stephen Kyne  wrote:
>>>
>>> Definitely a folder per opcode to keep it simple.
>>>
>>>
>>>
>>> Dependencies are handled differently for every platform. Clients should just look for dependencies in CMake via find_package() and consume them that way.
>>>
>>>
>>>
>>> There will have to be some other means (a script I guess) to download the dependency to the system through a platform specific way. I.e. apt on Debian/ubuntu, homebrew for OSX and VCPKG for windows.
>>>
>>>
>>>
>>> It could either be a master script in the root or some agreed upon script name in each folder that gets invoked before the CMake build.
>>>
>>>
>>>
>>> Everything else sounds reasonable. Just need to agree on the format to add a description, documentation and examples and maybe a registry file for the version number/meta data.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Stephen
>>>
>>>
>>>
>>> From: Eduardo Moguillansky
>>> Sent: Monday 6 January 2020 23:07
>>> To: CSOUND-DEV@LISTSERV.HEANET.IE
>>> Subject: Re: [Csnd-dev] Main plugins repository
>>>
>>>
>>>
>>> I would favor the idea of one directory per plugin library
>>>
>>> instead of having a folder per contributer. Regarding
>>>
>>> documentation / examples, I would propose that all plugin
>>>
>>> projects have at least following structure (or similar)
>>>
>>> csound-plugins/
>>>
>>>   foo/
>>>
>>>     CMakeLists.txt
>>>
>>>     README.md   <---- short description about the plugins defined here
>>>
>>>     docs/
>>>
>>>       opcode1.md
>>>
>>>       opcode2.md
>>>
>>>       ...
>>>
>>>      examples/   <---- optional
>>>
>>>        opcode1.csd
>>>
>>>        opcode2.csd
>>>
>>>
>>>
>>> How dependencies are handled, where they are placed, should be
>>>
>>> left to the discretion of the developer, as long as they are
>>>
>>> within the project directory.
>>>
>>> There should be one .md file for each opcode defined in the library,
>>>
>>> and, optionally, an example file showing how the opcode is used. An
>>>
>>> example should be included within the .md file.
>>>
>>>
>>>
>>> One question: if a certain dependency could/should be installed
>>>
>>> through a package manager (apt-get, brew, etc), how should that be handled?
>>>
>>> On 06.01.20 18:39, Rory Walsh wrote:
>>>
>>> I think once some thought is given to getting it set up correctly, with a clear set of guidelines, we can avoid the need of a maintainer. That's why I was thinking each contributer would have their own self contained directory, that can't contaminate anyone elses projects.
>>>
>>>
>>>
>>> On Mon 6 Jan 2020, 17:04 Victor Lazzarini,  wrote:
>>>
>>> I think we need an editor (person) to look after these things, think it through, and provide a
>>> set of rules. Otherwise we’ll quickly descend into chaos.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>> > On 6 Jan 2020, at 15:56, Rory Walsh  wrote:
>>> >
>>> > Good question. Currently each plugin library is in a dedicated folder. This seems clean to me. If any plugin lib needs extra deps, then would it be Ok for each plugin to have its own deps folder rather than a 'global' deps folder, which I fear will get cluttered with all sorts of 3rd party frameworks over time?
>>> >
>>> > On Mon, 6 Jan 2020 at 14:37, Michael Gogins  wrote:
>>> > I have a question about how to manage dependencies in the plugin
>>> > repository. What should we do to manage dependencies that have to be
>>> > built from source code?
>>> >
>>> > Jon Christopher Nelson created a VST effect plugin based on Cabbage
>>> > and Csound called MVerb, which implements a very high quality reverb
>>> > using a mesh of filtered delay lines.
>>> >
>>> > I have now succeeded in porting Nelson's plugin to a C++ plugin
>>> > opcode, and I would like to host this and other plugins I may create
>>> > in the plugin repository.
>>> >
>>> > However, in order to implement MVerb, I have used Lance Putnam's Gamma
>>> > library for audio signal processing in C++. This library is not a
>>> > system package, and it does not have a CMake build system. I had to
>>> > use the included Makefile and I had to change the build options to
>>> > include -fPIC.
>>> >
>>> > I suggest that in the plugins repository, for source code level
>>> > dependencies such as Gamma, there be a Git submodule (if the
>>> > dependency is hosted in a Git repository) in a "dependencies"
>>> > subdirectory of the plugins repository, and that the CMakeLIsts.txt
>>> > for the plugin that uses that source level dependency include some
>>> > means of building that dependency, without necessarily using a CMake
>>> > "find" macro.
>>> >
>>> > What do you think?
>>> >
>>> >
>>> > -----------------------------------------------------
>>> > Michael Gogins
>>> > Irreducible Productions
>>> > http://michaelgogins.tumblr.com
>>> > Michael dot Gogins at gmail dot com
>>> >
>>> > On Fri, Jan 3, 2020 at 10:12 AM Michael Gogins  wrote:
>>> > >
>>> > > I think the documentation suggestion to use markdown is sensible. You
>>> > > can do the markdown in the same format as the Csound Reference Manual.
>>> > > If each plugin is one subdirectory each can have one README.md that
>>> > > serves as the reference manual page.
>>> > >
>>> > > -----------------------------------------------------
>>> > > Michael Gogins
>>> > > Irreducible Productions
>>> > > http://michaelgogins.tumblr.com
>>> > > Michael dot Gogins at gmail dot com
>>> > >
>>> > > On Thu, Dec 19, 2019 at 3:21 PM Steven Yi  wrote:
>>> > > >
>>> > > > Disabling some modules makes sense to me.  Could have multiple
>>> > > > top-level build files or single build file with options for choosing
>>> > > > "build all" or "build CS6 compatible" or something along those lines.
>>> > > >
>>> > > > For integration with main docs, I'm not sure that's necessary.  We
>>> > > > could have a "plugins" documentation that lives with the plugins and
>>> > > > just have some URL links between the two projects.
>>> > > >
>>> > > > One option that might be curious is to use Github pages.  We can make
>>> > > > the repo be a Jekyll website and use markdown for documentation and a
>>> > > > top-level page that traverses the other pages. Might need some work to
>>> > > > organize the repository structure to keep the pages to the side, but
>>> > > > it would be pretty easy for contributions once setup I think.
>>> > > >
>>> > > >
>>> > > > On Thu, Dec 19, 2019 at 3:05 PM Eduardo Moguillansky
>>> > > >  wrote:
>>> > > > >
>>> > > > > On 19.12.19 18:06, Steven Yi wrote:
>>> > > > > > I think the idea is this where things will be once things are moved
>>> > > > > > out from CS7 and it's in preparation stage now.
>>> > > > >
>>> > > > > It would be possible to make these two projects coexist by excluding the
>>> > > > > duplicate plugins from building (editing them out in the CMakeLists
>>> > > > > file). Like that we could move on with making this the "official"
>>> > > > > plugins project, see how the documentation can be integrated with the
>>> > > > > rest of csound, etc.
>>> > > > >
>>> > > > >
>>> > > > > > Documentation is a good question: suggestions?  Seems like it would be
>>> > > > > > best to keep the docs within each opcode's subdirectory, but have a
>>> > > > > > build stage that compiles an aggregate doc for the plugins by
>>> > > > > > traversing the directories.  It'd be easy then to copy a module
>>> > > > > > (folder) for others to get going.
>>> > > > >
>>> > > > > There was some discussion about documentation systems. There is no
>>> > > > > shortage of those. The question to answer is how any documentation could
>>> > > > > be integrated with the main docs. My suggestion would be first to see if
>>> > > > > a conversion of the current docbook manual to something more maleable
>>> > > > > can be achieved with as little manual work as possible.
>>> > > > >
>>> > > > > Another question which needs to be resolved is about dependencies.
>>> > > > >
>>> > > > > >
>>> > > > > > PR sounds good, I imagine this will take some iterations to work out
>>> > > > > > what's missing and what needs to be changed to get it to work for
>>> > > > > > everyone.
>>> > > > > >
>>> > > > > > On Wed, Dec 18, 2019 at 7:35 AM Eduardo Moguillansky
>>> > > > > >  wrote:
>>> > > > > >> I adapted the cmake scripts of my own plugins to build within the tree
>>> > > > > >> of the new plugins repo living here https://github.com/csound/plugins
>>> > > > > >>
>>> > > > > >> Everything seems to build correctly in linux, macOS and windows. What is
>>> > > > > >> confusing about this repository is that the plugins there are still
>>> > > > > >> present in the main tree. How are these two projects suppose to interact?
>>> > > > > >>
>>> > > > > >> What about documentation?
>>> > > > > >>
>>> > > > > >> Anyway, I can send a PR with the new plugins to have everything under
>>> > > > > >> one tree.
>>> > > > > >>
>>> > > > > >> best
>>> > > > > >>
>>> > > > > >> Eduardo
>>>