I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.

1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.

2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.

3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,

Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.

My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.

What do you think? Do you have a better idea?

Regards,

Mike

-----------------------------------------------------

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

Mike,

these are good contributions, but I think they are better suited to be kept as third-party packages which you can maintain in your own repository.

The plugins repository is not really meant for this. Particularly as we do not have a maintainer. It will increase the complexity of upkeep and making release packages.

However, if any of the opcodes below have no dependencies, then you could considef adding it to the Csound repository and it will be maintained there.

The basic principles at the moment are:

1) have dependencies: keep them as a third-party library.

2) no dependencies: either keep them

as a third-party library or contribute them to the Csound repository. In that case, if it's in C, add it as builtin linkage, otherwise add it as a plugin.

Of course if we can find someone committed to maintain the plugins repository on a long-term basis, producing release packages etc, then they can decide on other rules for expanding the repository.

For the moment, I am against any new code being added to the plugins repository that has not originated in the Csound sources.

It had been hard work putting this into

shape and it is in a fragile state as it is.

best regards

Prof. Victor Lazzarini

Maynooth University

Ireland

On 31 Aug 2021, at 17:09, Michael Gogins <michael.gogins@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.

1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.

2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.

3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,

Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.

My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.

What do you think? Do you have a better idea?

Regards,

Mike

-----------------------------------------------------

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

Mike,

these are good contributions, but I think they are better suited to be kept as third-party packages which you can maintain in your own repository.

The plugins repository is not really meant for this. Particularly as we do not have a maintainer. It will increase the complexity of upkeep and making release packages.

However, if any of the opcodes below have no dependencies, then you could considef adding it to the Csound repository and it will be maintained there.

The basic principles at the moment are:

1) have dependencies: keep them as a third-party library.

2) no dependencies: either keep them

as a third-party library or contribute them to the Csound repository. In that case, if it's in C, add it as builtin linkage, otherwise add it as a plugin.

Of course if we can find someone committed to maintain the plugins repository on a long-term basis, producing release packages etc, then they can decide on other rules for expanding the repository.

For the moment, I am against any new code being added to the plugins repository that has not originated in the Csound sources.

It had been hard work putting this into

shape and it is in a fragile state as it is.

best regards

Prof. Victor Lazzarini

Maynooth University

Ireland

On 31 Aug 2021, at 17:09, Michael Gogins <michael.gogins@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.

1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.

2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.

3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,

Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.

My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.

What do you think? Do you have a better idea?

Regards,

Mike

-----------------------------------------------------

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

As currently built, the opcodes I was planning to contribute have external dependencies.

However, it would be pretty easy to get rid of the CMask external dependency for the cmask opcodes just by importing the source code from the cmask repository into the Csound repository. The license should not be an issue, it is compatible with LGPLv2.1. The code is straightforward C++.

Regards,

Mike

-----------------------------------------------------

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

On Tue, Aug 31, 2021 at 2:15 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Mike,

these are good contributions, but I think they are better suited to be kept as third-party packages which you can maintain in your own repository.

The plugins repository is not really meant for this. Particularly as we do not have a maintainer. It will increase the complexity of upkeep and making release packages.

However, if any of the opcodes below have no dependencies, then you could considef adding it to the Csound repository and it will be maintained there.

The basic principles at the moment are:

1) have dependencies: keep them as a third-party library.

2) no dependencies: either keep them

as a third-party library or contribute them to the Csound repository. In that case, if it's in C, add it as builtin linkage, otherwise add it as a plugin.

Of course if we can find someone committed to maintain the plugins repository on a long-term basis, producing release packages etc, then they can decide on other rules for expanding the repository.

For the moment, I am against any new code being added to the plugins repository that has not originated in the Csound sources.

It had been hard work putting this into

shape and it is in a fragile state as it is.

best regards

Prof. Victor Lazzarini

Maynooth University

Ireland

On 31 Aug 2021, at 17:09, Michael Gogins <michael.gogins@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.

1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.

2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.

3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,

Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.

My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.

What do you think? Do you have a better idea?

Regards,

Mike

-----------------------------------------------------

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

I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.

1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.

2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.

3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,

Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.

My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.

What do you think? Do you have a better idea?

Regards,

Mike

-----------------------------------------------------

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

About cmask, people might be interested in this: https://github.com/fggp/gmask. It's a port of the cmask program to the Go programming language with binaries cross-compiled for the main platforms. And here is a golang library offering the cmask possibilities to go programs.

Regards

François

Le mar. 31 août 2021 à 18:09, Michael Gogins <michael.gogins@gmail.com> a écrit :

I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.

1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.

2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.

3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,

Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.

My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.

What do you think? Do you have a better idea?

Regards,

Mike

-----------------------------------------------------

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

So here’s my thoughts about this

1) as it involves a complete set of third-party files, with a different licence (even though compatible with the current license we use),
it may not be suitable for addition to the Csound code. Even though it does not have external dependencies, we are still dependent on
other code that may need to be maintained, which is different from a set of opcodes wholly written by the contributor.

2) it is then a question of whether it suits the plugins library, as it is a lower risk project. In principle, while the issue raised in 1)
does not go away, it may be less of a problem here. The problem continues to be that we are adding code to a project that does not
yet have any long-term maintainer, and if for some reason this code fails to work in one way or the other, there is no one committed
to follow it up and getting things fixed, as well as preparing releases etc for it.

3) and so we ask why does it need to be placed there, when it can be maintained by yourself in your repository, as Rory quite rightly
noted in his comments.

It would be interesting to hear opinions from other contributors.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 1 Sep 2021, at 00:27, Michael Gogins <michael.gogins@gmail.com> wrote:
>
> As currently built, the opcodes I was planning to contribute have external dependencies.
>
> However, it would be pretty easy to get rid of the CMask external dependency for the cmask opcodes just by importing the source code from the cmask repository into the Csound repository. The license should not be an issue, it is compatible with LGPLv2.1. The code is straightforward C++.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Aug 31, 2021 at 2:15 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
> Mike,
>
> these are good contributions, but I think they are better suited to be kept as third-party packages which you can maintain in your own repository.
>
> The plugins repository is not really meant for this. Particularly as we do not have a maintainer. It will increase the complexity of upkeep and making release packages.
>
> However, if any of the opcodes below have no dependencies, then you could considef adding it to the Csound repository and it will be maintained there.
>
> The basic principles at the moment are:
>
> 1) have dependencies: keep them as a third-party library.
>
> 2) no dependencies: either keep them
> as a third-party library or contribute them to the Csound repository. In that case, if it's in C, add it as builtin linkage, otherwise add it as a plugin.
>
> Of course if we can find someone committed to maintain the plugins repository on a long-term basis, producing release packages etc, then they can decide on other rules for expanding the repository.
>
> For the moment, I am against any new code being added to the plugins repository that has not originated in the Csound sources.
> It had been hard work putting this into
> shape and it is in a fragile state as it is.
>
> best regards
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 31 Aug 2021, at 17:09, Michael Gogins <michael.gogins@gmail.com> wrote:
>>
>> 
>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.
>>
>> 1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.
>>
>> 2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.
>>
>> 3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,
>>
>> Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.
>>
>> My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.
>>
>> What do you think? Do you have a better idea?
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com

Hi Mike, is the any way would you be willing to maintain the repo and manage future releases for Windows and MacOS? 

On Wed 1 Sep 2021, 12:27 a.m. Michael Gogins, <michael.gogins@gmail.com> wrote:

As currently built, the opcodes I was planning to contribute have external dependencies.

However, it would be pretty easy to get rid of the CMask external dependency for the cmask opcodes just by importing the source code from the cmask repository into the Csound repository. The license should not be an issue, it is compatible with LGPLv2.1. The code is straightforward C++.

Regards,

Mike

-----------------------------------------------------

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

On Tue, Aug 31, 2021 at 2:15 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Mike,

these are good contributions, but I think they are better suited to be kept as third-party packages which you can maintain in your own repository.

The plugins repository is not really meant for this. Particularly as we do not have a maintainer. It will increase the complexity of upkeep and making release packages.

However, if any of the opcodes below have no dependencies, then you could considef adding it to the Csound repository and it will be maintained there.

The basic principles at the moment are:

1) have dependencies: keep them as a third-party library.

2) no dependencies: either keep them

as a third-party library or contribute them to the Csound repository. In that case, if it's in C, add it as builtin linkage, otherwise add it as a plugin.

Of course if we can find someone committed to maintain the plugins repository on a long-term basis, producing release packages etc, then they can decide on other rules for expanding the repository.

For the moment, I am against any new code being added to the plugins repository that has not originated in the Csound sources.

It had been hard work putting this into

shape and it is in a fragile state as it is.

best regards

Prof. Victor Lazzarini

Maynooth University

Ireland

On 31 Aug 2021, at 17:09, Michael Gogins <michael.gogins@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.

1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.

2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.

3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,

Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.

My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.

What do you think? Do you have a better idea?

Regards,

Mike

-----------------------------------------------------

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

I agree with victor that plugins should be hosted by the maintainer.
Setting CI integration for multiple platforms, which is something that
the csound/plugins repository still does not have, is incredibly tedious
and time-intensive, the complexity of this task being exponentially
related to the number of dependencies, where each new library might
itself have dependencies with obscure incantations needed when building
remotely.

 From my perspective, the best way to aggregate/distribute plugins is to
follow projects like deken, where plugin maintainers can upload binaries
while each author is responsible for building and testing such binaries.

regards,
Eduardo

On 01.09.21 09:59, Victor Lazzarini wrote:
> So here’s my thoughts about this
>
> 1) as it involves a complete set of third-party files, with a different licence (even though compatible with the current license we use),
> it may not be suitable for addition to the Csound code. Even though it does not have external dependencies, we are still dependent on
> other code that may need to be maintained, which is different from a set of opcodes wholly written by the contributor.
>
> 2) it is then a question of whether it suits the plugins library, as it is a lower risk project. In principle, while the issue raised in 1)
> does not go away, it may be less of a problem here. The problem continues to be that we are adding code to a project that does not
> yet have any long-term maintainer, and if for some reason this code fails to work in one way or the other, there is no one committed
> to follow it up and getting things fixed, as well as preparing releases etc for it.
>
> 3) and so we ask why does it need to be placed there, when it can be maintained by yourself in your repository, as Rory quite rightly
> noted in his comments.
>
> It would be interesting to hear opinions from other contributors.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 1 Sep 2021, at 00:27, Michael Gogins <michael.gogins@gmail.com> wrote:
>>
>> As currently built, the opcodes I was planning to contribute have external dependencies.
>>
>> However, it would be pretty easy to get rid of the CMask external dependency for the cmask opcodes just by importing the source code from the cmask repository into the Csound repository. The license should not be an issue, it is compatible with LGPLv2.1. The code is straightforward C++.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Aug 31, 2021 at 2:15 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>> Mike,
>>
>> these are good contributions, but I think they are better suited to be kept as third-party packages which you can maintain in your own repository.
>>
>> The plugins repository is not really meant for this. Particularly as we do not have a maintainer. It will increase the complexity of upkeep and making release packages.
>>
>> However, if any of the opcodes below have no dependencies, then you could considef adding it to the Csound repository and it will be maintained there.
>>
>> The basic principles at the moment are:
>>
>> 1) have dependencies: keep them as a third-party library.
>>
>> 2) no dependencies: either keep them
>> as a third-party library or contribute them to the Csound repository. In that case, if it's in C, add it as builtin linkage, otherwise add it as a plugin.
>>
>> Of course if we can find someone committed to maintain the plugins repository on a long-term basis, producing release packages etc, then they can decide on other rules for expanding the repository.
>>
>> For the moment, I am against any new code being added to the plugins repository that has not originated in the Csound sources.
>> It had been hard work putting this into
>> shape and it is in a fragile state as it is.
>>
>> best regards
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>>> On 31 Aug 2021, at 17:09, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>
>>> 
>>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>> I am planning to contribute the following plugin opcode libraries to https://github.com/csound/plugins, and probably more in the future. These have external dependencies.
>>>
>>> 1. CMask opcodes, depends on https://github.com/gogins/cmask. This provides all the facilities of Andre Bartetzki's CMask program as Csound opcodes.
>>>
>>> 2. MVerb opcode, depends on https://github.com/LancePutnam/Gamma. This provides a C++ implementation of Jon Christopher Nelson's Cabbage VST plugin for Jon Dattoro's reverb algorithm, as a Csound opcode.
>>>
>>> 3. musicxml opcodes, depends on https://github.com/grame-cncm/libmusicxml. These opcodes translate either a MusicXML text file, or a string containing MusicXML text, into a Csound score and schedules that score during performance. This enables Csound, given a suitable orchestra, to render scores exported from notation software such as MuseScore directly,
>>>
>>> Obviously, dependencies in the form of "system packages" don't need much beyond a CMake "find" facility. But these dependencies don't exist as system packages, and must be built from sources.
>>>
>>> My current thinking is to create a common plugins/dependencies directory, and put all the source code dependencies of all the plugins in that directory, as Git submodules.
>>>
>>> What do you think? Do you have a better idea?
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com