There is some new work that I would like to contribute to core Csound.
This work depends on external source code.

I have completed a new opcode that brings CMask into Csound. This
depends on CMask source code. I obtained the permission of the author
to change the license to be compatible with Csound, and I am hosting
the CMask source code at https://github.com/gogins/cmask.

I am planning to bring most of the Composer's Desktop Project programs
into Csound as opcodes. This depends on the CDP source code, which now
has a license that is compatible with Csound.

My question is, what is the best way to integrate this external code?
In my own csound-extended repository I simply create git submodules
for such dependencies. I may then either use the external code's own
build system, or I may create my own CMakeLists.txt for the Csound
opcodes, and in it include the external sources.

It would also be possible to download, build, and install the external
projects before compiling the related Csound opcodes.

And of course with a compatible license, it is possible simply to
bring all of the external source code into the Csound git repository,
but it is then in effect a branch of the original project that we
become responsible for maintaining. This would not be a problem for
CMask but it would be a problem for CDP.

What approach would you prefer?

Regards,
Mike


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

My suggestion is that a library is provided as plugins that can be installed by users. With the Csound.cmake script third party opcodes can easily be provided by separate providers. I think this is the best solution for opcodes that have external dependencies or that bring other codebases into it. This will
also help us in moving to Csound 7.

I have some hid opcodes that I will provide in that way, and I think we should start promoting this type of work.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 24 Jul 2018, at 15:04, Michael Gogins  wrote:
> 
> There is some new work that I would like to contribute to core Csound.
> This work depends on external source code.
> 
> I have completed a new opcode that brings CMask into Csound. This
> depends on CMask source code. I obtained the permission of the author
> to change the license to be compatible with Csound, and I am hosting
> the CMask source code at https://github.com/gogins/cmask.
> 
> I am planning to bring most of the Composer's Desktop Project programs
> into Csound as opcodes. This depends on the CDP source code, which now
> has a license that is compatible with Csound.
> 
> My question is, what is the best way to integrate this external code?
> In my own csound-extended repository I simply create git submodules
> for such dependencies. I may then either use the external code's own
> build system, or I may create my own CMakeLists.txt for the Csound
> opcodes, and in it include the external sources.
> 
> It would also be possible to download, build, and install the external
> projects before compiling the related Csound opcodes.
> 
> And of course with a compatible license, it is possible simply to
> bring all of the external source code into the Csound git repository,
> but it is then in effect a branch of the original project that we
> become responsible for maintaining. This would not be a problem for
> CMask but it would be a problem for CDP.
> 
> What approach would you prefer?
> 
> Regards,
> Mike
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com

+1 to maintaining this separately.

If you can't support a plugin on another platform, then ask someone
who can to help. Use continuous integration services to build on OSX
and Windows if you don't have regular access to those platforms and
want to try to go it alone. (This is something that might be good to
work out as an example with documentation on how to do as part of the
Opcode SDK.)

On Tue, Jul 24, 2018 at 11:30 AM Victor Lazzarini
 wrote:
>
> In that case, they should offer the opcodes for the platform they have access to and can provide proper support. Otherwise they are just offloading that to the Csound project, which is problematic.
>
> I see no problem with that. PD uses this model for the majority of its components.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
> On 24 Jul 2018, at 16:16, Michael Gogins  wrote:
>
> The problem with this approach is that the developers of such plugins may not be equipped to support all the Csound platforms. Plugins in the csound repository, on the other hand, will be released for all platforms.
>
> What is your solution for that?
>
> Regards,
> Mike
>
>
> On Tue, Jul 24, 2018, 10:14 Victor Lazzarini  wrote:
>>
>> My suggestion is that a library is provided as plugins that can be installed by users. With the Csound.cmake script third party opcodes can easily be provided by separate providers. I think this is the best solution for opcodes that have external dependencies or that bring other codebases into it. This will
>> also help us in moving to Csound 7.
>>
>> I have some hid opcodes that I will provide in that way, and I think we should start promoting this type of work.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> > On 24 Jul 2018, at 15:04, Michael Gogins  wrote:
>> >
>> > There is some new work that I would like to contribute to core Csound.
>> > This work depends on external source code.
>> >
>> > I have completed a new opcode that brings CMask into Csound. This
>> > depends on CMask source code. I obtained the permission of the author
>> > to change the license to be compatible with Csound, and I am hosting
>> > the CMask source code at https://github.com/gogins/cmask.
>> >
>> > I am planning to bring most of the Composer's Desktop Project programs
>> > into Csound as opcodes. This depends on the CDP source code, which now
>> > has a license that is compatible with Csound.
>> >
>> > My question is, what is the best way to integrate this external code?
>> > In my own csound-extended repository I simply create git submodules
>> > for such dependencies. I may then either use the external code's own
>> > build system, or I may create my own CMakeLists.txt for the Csound
>> > opcodes, and in it include the external sources.
>> >
>> > It would also be possible to download, build, and install the external
>> > projects before compiling the related Csound opcodes.
>> >
>> > And of course with a compatible license, it is possible simply to
>> > bring all of the external source code into the Csound git repository,
>> > but it is then in effect a branch of the original project that we
>> > become responsible for maintaining. This would not be a problem for
>> > CMask but it would be a problem for CDP.
>> >
>> > What approach would you prefer?
>> >
>> > Regards,
>> > Mike
>> >
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com

Could you file an issue for the opcode_sdk project:

https://github.com/csound/opcode_sdk/issues

for "Example CI Builds with Travis and AppVeyor"?

I know Rory's done some work with Cabbage for building OSX (I have an
OSX build for Blue with Travis) and we have the CI build example from
core Csound for AppVeyor.  We can add further Build instructions to
the README.md as well.

Seems then someone could clone that repo to start a new opcode lib,
swap in their source and change some configurations, then voila.

On Tue, Jul 24, 2018 at 12:05 PM Michael Gogins
 wrote:
>
> I understand.
>
> I think good working examples of open integration for at least OSX, Windows, and Linux would be HIGHLY desirable as an accompaniment toto Csound.cmake.
>
> Regards,
> Mike
>
>
> On Tue, Jul 24, 2018, 12:00 Steven Yi  wrote:
>>
>> +1 to maintaining this separately.
>>
>> If you can't support a plugin on another platform, then ask someone
>> who can to help. Use continuous integration services to build on OSX
>> and Windows if you don't have regular access to those platforms and
>> want to try to go it alone. (This is something that might be good to
>> work out as an example with documentation on how to do as part of the
>> Opcode SDK.)
>>
>> On Tue, Jul 24, 2018 at 11:30 AM Victor Lazzarini
>>  wrote:
>> >
>> > In that case, they should offer the opcodes for the platform they have access to and can provide proper support. Otherwise they are just offloading that to the Csound project, which is problematic.
>> >
>> > I see no problem with that. PD uses this model for the majority of its components.
>> >
>> > Victor Lazzarini
>> > Dean of Arts, Celtic Studies, and Philosophy
>> > Maynooth University
>> > Ireland
>> >
>> > On 24 Jul 2018, at 16:16, Michael Gogins  wrote:
>> >
>> > The problem with this approach is that the developers of such plugins may not be equipped to support all the Csound platforms. Plugins in the csound repository, on the other hand, will be released for all platforms.
>> >
>> > What is your solution for that?
>> >
>> > Regards,
>> > Mike
>> >
>> >
>> > On Tue, Jul 24, 2018, 10:14 Victor Lazzarini  wrote:
>> >>
>> >> My suggestion is that a library is provided as plugins that can be installed by users. With the Csound.cmake script third party opcodes can easily be provided by separate providers. I think this is the best solution for opcodes that have external dependencies or that bring other codebases into it. This will
>> >> also help us in moving to Csound 7.
>> >>
>> >> I have some hid opcodes that I will provide in that way, and I think we should start promoting this type of work.
>> >>
>> >> Victor Lazzarini
>> >> Dean of Arts, Celtic Studies, and Philosophy
>> >> Maynooth University
>> >> Ireland
>> >>
>> >> > On 24 Jul 2018, at 15:04, Michael Gogins  wrote:
>> >> >
>> >> > There is some new work that I would like to contribute to core Csound.
>> >> > This work depends on external source code.
>> >> >
>> >> > I have completed a new opcode that brings CMask into Csound. This
>> >> > depends on CMask source code. I obtained the permission of the author
>> >> > to change the license to be compatible with Csound, and I am hosting
>> >> > the CMask source code at https://github.com/gogins/cmask.
>> >> >
>> >> > I am planning to bring most of the Composer's Desktop Project programs
>> >> > into Csound as opcodes. This depends on the CDP source code, which now
>> >> > has a license that is compatible with Csound.
>> >> >
>> >> > My question is, what is the best way to integrate this external code?
>> >> > In my own csound-extended repository I simply create git submodules
>> >> > for such dependencies. I may then either use the external code's own
>> >> > build system, or I may create my own CMakeLists.txt for the Csound
>> >> > opcodes, and in it include the external sources.
>> >> >
>> >> > It would also be possible to download, build, and install the external
>> >> > projects before compiling the related Csound opcodes.
>> >> >
>> >> > And of course with a compatible license, it is possible simply to
>> >> > bring all of the external source code into the Csound git repository,
>> >> > but it is then in effect a branch of the original project that we
>> >> > become responsible for maintaining. This would not be a problem for
>> >> > CMask but it would be a problem for CDP.
>> >> >
>> >> > What approach would you prefer?
>> >> >
>> >> > Regards,
>> >> > Mike
>> >> >
>> >> >
>> >> > -----------------------------------------------------
>> >> > Michael Gogins
>> >> > Irreducible Productions
>> >> > http://michaelgogins.tumblr.com