Csound Csound-dev Csound-tekno Search About

[Csnd-dev] Statically link in Portaudio?

Date2019-10-25 18:02
FromSteven Yi
Subject[Csnd-dev] Statically link in Portaudio?
Hi All,

I was wondering what everyone thought about the idea of optionally statically linking in the PortAudio driver code into libcsound.  The idea is that libcsound64.dll/.so/.dylib would be enough from a host API on the desktop/embedded platforms to run Csound without any opcode libraries. Making it optionally linked in would be good for stripping it out on platforms where desirable (iOS, Android, Web for example). 

License-wise it seems compatible to statically link in:


I imagine it won't affect most people if this is linked in by default, but it could open up some options to simplify embedding into applications. 

Thoughts?

Steven

Date2019-10-25 18:11
FromRory Walsh
SubjectRe: [Csnd-dev] Statically link in Portaudio?
Sounds ok to me. I think anything that makes building Csound applications easier is to be welcomed.

On Fri 25 Oct 2019, 19:02 Steven Yi, <stevenyi@gmail.com> wrote:
Hi All,

I was wondering what everyone thought about the idea of optionally statically linking in the PortAudio driver code into libcsound.  The idea is that libcsound64.dll/.so/.dylib would be enough from a host API on the desktop/embedded platforms to run Csound without any opcode libraries. Making it optionally linked in would be good for stripping it out on platforms where desirable (iOS, Android, Web for example). 

License-wise it seems compatible to statically link in:


I imagine it won't affect most people if this is linked in by default, but it could open up some options to simplify embedding into applications. 

Thoughts?

Steven

Date2019-10-25 19:39
FromVictor Lazzarini
SubjectRe: [Csnd-dev] Statically link in Portaudio?
I'd prefer to keep it as a plugin module. We can of course link it up statically to librtpa.x

The reason is to try and keep all dependencies away from the main lib as
much as possible.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 25 Oct 2019, at 18:12, Rory Walsh <rorywalsh@ear.ie> wrote:

Sounds ok to me. I think anything that makes building Csound applications easier is to be welcomed.

On Fri 25 Oct 2019, 19:02 Steven Yi, <stevenyi@gmail.com> wrote:
Hi All,

I was wondering what everyone thought about the idea of optionally statically linking in the PortAudio driver code into libcsound.  The idea is that libcsound64.dll/.so/.dylib would be enough from a host API on the desktop/embedded platforms to run Csound without any opcode libraries. Making it optionally linked in would be good for stripping it out on platforms where desirable (iOS, Android, Web for example). 

License-wise it seems compatible to statically link in:


I imagine it won't affect most people if this is linked in by default, but it could open up some options to simplify embedding into applications. 

Thoughts?

Steven

Date2019-10-25 19:42
FromVictor Lazzarini
SubjectRe: [Csnd-dev] Statically link in Portaudio?
Also it might not make sense on Linux, where rtalsa and rtjack are preferred. Given
that we have the plugin system, I don't see
why we should change.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 25 Oct 2019, at 19:40, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

I'd prefer to keep it as a plugin module. We can of course link it up statically to librtpa.x

The reason is to try and keep all dependencies away from the main lib as
much as possible.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 25 Oct 2019, at 18:12, Rory Walsh <rorywalsh@ear.ie> wrote:

Sounds ok to me. I think anything that makes building Csound applications easier is to be welcomed.

On Fri 25 Oct 2019, 19:02 Steven Yi, <stevenyi@gmail.com> wrote:
Hi All,

I was wondering what everyone thought about the idea of optionally statically linking in the PortAudio driver code into libcsound.  The idea is that libcsound64.dll/.so/.dylib would be enough from a host API on the desktop/embedded platforms to run Csound without any opcode libraries. Making it optionally linked in would be good for stripping it out on platforms where desirable (iOS, Android, Web for example). 

License-wise it seems compatible to statically link in:


I imagine it won't affect most people if this is linked in by default, but it could open up some options to simplify embedding into applications. 

Thoughts?

Steven