I finished implementing a quite usefull opcode 'poly', which allows to 
instantiate and control multiple instances of a given opcode, as

aOut[] poly 30, "oscili", 0.1, kFreqs

See here for an example and the resulting soundfile:

https://github.com/gesellkammer/csound-plugins/wiki/Poly-example

The problem is that it needs to access "find_opcode.h" to be able to 
call "find_opcode_new". As it is, this is not part of the plugin API, 
and thus I can't build this as a plugin. Would it be possible to 
include this header, or at least the very least to be able to call 
"find_opcode_new" as part of the plugin API?

thanks!

Best thing is to expose it via the API in the CSOUND struct, otherwise the plugin would 
need to link to the Csound lib, which is not
right

Which function(s) do you need?

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

> On 8 Mar 2019, at 01:07, Eduardo Moguillansky  wrote:
> 
> I finished implementing a quite usefull opcode 'poly', which allows to instantiate and control multiple instances of a given opcode, as
> 
> aOut[] poly 30, "oscili", 0.1, kFreqs
> 
> See here for an example and the resulting soundfile:
> 
> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
> 
> The problem is that it needs to access "find_opcode.h" to be able to call "find_opcode_new". As it is, this is not part of the plugin API, and thus I can't build this as a plugin. Would it be possible to include this header, or at least the very least to be able to call "find_opcode_new" as part of the plugin API?
> 
> thanks!

I only need "find_opcode_new".

On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini 
 wrote:
> Best thing is to expose it via the API in the CSOUND struct, 
> otherwise the plugin would
> need to link to the Csound lib, which is not
> right
> 
> Which function(s) do you need?
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
>>  On 8 Mar 2019, at 01:07, Eduardo Moguillansky 
>>  wrote:
>> 
>>  I finished implementing a quite usefull opcode 'poly', which allows 
>> to instantiate and control multiple instances of a given opcode, as
>> 
>>  aOut[] poly 30, "oscili", 0.1, kFreqs
>> 
>>  See here for an example and the resulting soundfile:
>> 
>>  https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>> 
>>  The problem is that it needs to access "find_opcode.h" to be able 
>> to call "find_opcode_new". As it is, this is not part of the plugin 
>> API, and thus I can't build this as a plugin. Would it be possible 
>> to include this header, or at least the very least to be able to 
>> call "find_opcode_new" as part of the plugin API?
>> 
>>  thanks!

Ok, I’ve exposed find_opcode_new() and find_opcode_exact(), they are available in the CSOUND object
now. Let me know if it works for you.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 8 Mar 2019, at 07:44, Eduardo Moguillansky  wrote:
> 
> I only need "find_opcode_new".
> 
> On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini  wrote:
>> Best thing is to expose it via the API in the CSOUND struct, otherwise the plugin would
>> need to link to the Csound lib, which is not
>> right
>> Which function(s) do you need?
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky  wrote:
>>> I finished implementing a quite usefull opcode 'poly', which allows to instantiate and control multiple instances of a given opcode, as
>>> aOut[] poly 30, "oscili", 0.1, kFreqs
>>> See here for an example and the resulting soundfile:
>>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>>> The problem is that it needs to access "find_opcode.h" to be able to call "find_opcode_new". As it is, this is not part of the plugin API, and thus I can't build this as a plugin. Would it be possible to include this header, or at least the very least to be able to call "find_opcode_new" as part of the plugin API?
>>> thanks!
>>> eduardo

Victor: tested and working fine, thanks for the quick response.

It is fine for me to mark these as experimental.

On a side note, I would like to extend the functionality of poly to 
support user defined opcodes. Is there a chance someone could take a 
look at the code [1] and see if this would be at all possible?

The design for poly is based on maparray, and maparray seems to support 
udos, but I have not found a way to make them work.

[1] 
https://github.com/gesellkammer/csound-plugins/blob/master/poly/poly.c

On Fr, Mar 8, 2019 at 11:33 AM, Steven Yi  wrote:
> Oof, from and API design perspective, I'm not sure those functions 
> are great for exposing. (I didn't even realize these were put into an 
> internal header file and exposed within our codebase.) Certainly want 
> to support the use case, but would prefer a better public-facing 
> function.
> 
> If these is going to be exposed for CS6 like this right now, let's 
> mark it as experimental, with the expectation that a better designed 
> public function will be created for CS7 and that developers should 
> expect this to be removed and that they will need to update their 
> code later.
> 
> 
> 
> On Fri, Mar 8, 2019 at 3:00 AM Victor Lazzarini 
>  wrote:
>> Ok, I’ve exposed find_opcode_new() and find_opcode_exact(), they 
>> are available in the CSOUND object
>>  now. Let me know if it works for you.
>>  ========================
>>  Prof. Victor Lazzarini
>>  Dean of Arts, Celtic Studies, and Philosophy,
>>  Maynooth University,
>>  Maynooth, Co Kildare, Ireland
>>  Tel: 00 353 7086936
>>  Fax: 00 353 1 7086952
>> 
>>  > On 8 Mar 2019, at 07:44, Eduardo Moguillansky 
>>  wrote:
>>  >
>>  > I only need "find_opcode_new".
>>  >
>>  > On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini 
>>  wrote:
>>  >> Best thing is to expose it via the API in the CSOUND struct, 
>> otherwise the plugin would
>>  >> need to link to the Csound lib, which is not
>>  >> right
>>  >> Which function(s) do you need?
>>  >> Victor Lazzarini
>>  >> Dean of Arts, Celtic Studies, and Philosophy
>>  >> Maynooth University
>>  >> Ireland
>>  >>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky 
>>  wrote:
>>  >>> I finished implementing a quite usefull opcode 'poly', which 
>> allows to instantiate and control multiple instances of a given 
>> opcode, as
>>  >>> aOut[] poly 30, "oscili", 0.1, kFreqs
>>  >>> See here for an example and the resulting soundfile:
>>  >>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>>  >>> The problem is that it needs to access "find_opcode.h" to be 
>> able to call "find_opcode_new". As it is, this is not part of the 
>> plugin API, and thus I can't build this as a plugin. Would it be 
>> possible to include this header, or at least the very least to be 
>> able to call "find_opcode_new" as part of the plugin API?
>>  >>> thanks!
>>  >>> eduardo
>> 

They were marked as PUBLIC.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 8 Mar 2019, at 10:33, Steven Yi  wrote:
> 
> Oof, from and API design perspective, I'm not sure those functions are great for exposing. (I didn't even realize these were put into an internal header file and exposed within our codebase.) Certainly want to support the use case, but would prefer a better public-facing function.  
> 
> If these is going to be exposed for CS6 like this right now, let's mark it as experimental, with the expectation that a better designed public function will be created for CS7 and that developers should expect this to be removed and that they will need to update their code later. 
> 
> 
> 
> On Fri, Mar 8, 2019 at 3:00 AM Victor Lazzarini  wrote:
> Ok, I’ve exposed find_opcode_new() and find_opcode_exact(), they are available in the CSOUND object
> now. Let me know if it works for you.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
> > On 8 Mar 2019, at 07:44, Eduardo Moguillansky  wrote:
> > 
> > I only need "find_opcode_new".
> > 
> > On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini  wrote:
> >> Best thing is to expose it via the API in the CSOUND struct, otherwise the plugin would
> >> need to link to the Csound lib, which is not
> >> right
> >> Which function(s) do you need?
> >> Victor Lazzarini
> >> Dean of Arts, Celtic Studies, and Philosophy
> >> Maynooth University
> >> Ireland
> >>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky  wrote:
> >>> I finished implementing a quite usefull opcode 'poly', which allows to instantiate and control multiple instances of a given opcode, as
> >>> aOut[] poly 30, "oscili", 0.1, kFreqs
> >>> See here for an example and the resulting soundfile:
> >>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
> >>> The problem is that it needs to access "find_opcode.h" to be able to call "find_opcode_new". As it is, this is not part of the plugin API, and thus I can't build this as a plugin. Would it be possible to include this header, or at least the very least to be able to call "find_opcode_new" as part of the plugin API?
> >>> thanks!
> >>> eduardo

yes, I think we should mainstream these things as part of the language in CS7 (parallel and serial opcodes).

I suppose this ‘poly’ opcode could be called ‘parallel’.

best
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 8 Mar 2019, at 10:56, Eduardo Moguillansky  wrote:
> 
> Victor: tested and working fine, thanks for the quick response.
> 
> It is fine for me to mark these as experimental.
> 
> On a side note, I would like to extend the functionality of poly to support user defined opcodes. Is there a chance someone could take a look at the code [1] and see if this would be at all possible?
> 
> The design for poly is based on maparray, and maparray seems to support udos, but I have not found a way to make them work.
> 
> [1] https://github.com/gesellkammer/csound-plugins/blob/master/poly/poly.c
> 
> On Fr, Mar 8, 2019 at 11:33 AM, Steven Yi  wrote:
>> Oof, from and API design perspective, I'm not sure those functions are great for exposing. (I didn't even realize these were put into an internal header file and exposed within our codebase.) Certainly want to support the use case, but would prefer a better public-facing function.
>> If these is going to be exposed for CS6 like this right now, let's mark it as experimental, with the expectation that a better designed public function will be created for CS7 and that developers should expect this to be removed and that they will need to update their code later.
>> On Fri, Mar 8, 2019 at 3:00 AM Victor Lazzarini  wrote:
>>> Ok, I´ve exposed find_opcode_new() and find_opcode_exact(), they are available in the CSOUND object
>>> now. Let me know if it works for you.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> > On 8 Mar 2019, at 07:44, Eduardo Moguillansky  wrote:
>>> >
>>> > I only need "find_opcode_new".
>>> >
>>> > On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini  wrote:
>>> >> Best thing is to expose it via the API in the CSOUND struct, otherwise the plugin would
>>> >> need to link to the Csound lib, which is not
>>> >> right
>>> >> Which function(s) do you need?
>>> >> Victor Lazzarini
>>> >> Dean of Arts, Celtic Studies, and Philosophy
>>> >> Maynooth University
>>> >> Ireland
>>> >>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky  wrote:
>>> >>> I finished implementing a quite usefull opcode 'poly', which allows to instantiate and control multiple instances of a given opcode, as
>>> >>> aOut[] poly 30, "oscili", 0.1, kFreqs
>>> >>> See here for an example and the resulting soundfile:
>>> >>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>>> >>> The problem is that it needs to access "find_opcode.h" to be able to call "find_opcode_new". As it is, this is not part of the plugin API, and thus I can't build this as a plugin. Would it be possible to include this header, or at least the very least to be able to call "find_opcode_new" as part of the plugin 

How would that work for opcodes with multiple outputs, like pan2?



On Fr, Mar 8, 2019 at 3:16 PM, Dave Seidel  
wrote:
> +1 for using map() et al.
> 
> On Fri, Mar 8, 2019 at 7:35 AM Steven Yi  wrote:
>> Well, I was thinking we have map, reduce, apply be implemented like 
>> other functional programming languages, as well as having opcode 
>> names be usable without strings as types, something like:
>> 
>> ;; init-time
>> kfreqs[] = [] ;; initialize some array of frequencies
>> ops:Opcode[] = map(oscili, 0.1, kfreqs)
>> 
>> ;; run-time
>> asigs[] = map(call, ops)
>> 
>> (ties into https://github.com/csound/csound/issues/322)
>> 
>> Though if opcode names are interpreted as types, it might also work 
>> to have:
>> 
>> ops:oscili[] = map(oscili, 0.1, kfreqs)
>> 
>> 
>> As for the functions being marked PUBLIC, that looks like it was 
>> done to enable some coding convenience (maybe for the unit tests?) 
>> rather than being a result of API design. I certainly didn't write 
>> find_opcode_new or find_opcode_exact for CS6 with the intention that 
>> it be exposed publicly.
>> 
>> On Fri, Mar 8, 2019 at 7:00 AM Victor Lazzarini 
>>  wrote:
>>> yes, I think we should mainstream these things as part of the 
>>> language in CS7 (parallel and serial opcodes).
>>> 
>>>  I suppose this ‘poly’ opcode could be called ‘parallel’.
>>> 
>>>  best
>>>  ========================
>>>  Prof. Victor Lazzarini
>>>  Dean of Arts, Celtic Studies, and Philosophy,
>>>  Maynooth University,
>>>  Maynooth, Co Kildare, Ireland
>>>  Tel: 00 353 7086936
>>>  Fax: 00 353 1 7086952
>>> 
>>>  > On 8 Mar 2019, at 10:56, Eduardo Moguillansky 
>>>  wrote:
>>>  >
>>>  > Victor: tested and working fine, thanks for the quick response.
>>>  >
>>>  > It is fine for me to mark these as experimental.
>>>  >
>>>  > On a side note, I would like to extend the functionality of poly 
>>> to support user defined opcodes. Is there a chance someone could 
>>> take a look at the code [1] and see if this would be at all 
>>> possible?
>>>  >
>>>  > The design for poly is based on maparray, and maparray seems to 
>>> support udos, but I have not found a way to make them work.
>>>  >
>>>  > [1] 
>>> https://github.com/gesellkammer/csound-plugins/blob/master/poly/poly.c
>>>  >
>>>  > On Fr, Mar 8, 2019 at 11:33 AM, Steven Yi  
>>> wrote:
>>>  >> Oof, from and API design perspective, I'm not sure those 
>>> functions are great for exposing. (I didn't even realize these were 
>>> put into an internal header file and exposed within our codebase.) 
>>> Certainly want to support the use case, but would prefer a better 
>>> public-facing function.
>>>  >> If these is going to be exposed for CS6 like this right now, 
>>> let's mark it as experimental, with the expectation that a better 
>>> designed public function will be created for CS7 and that 
>>> developers should expect this to be removed and that they will need 
>>> to update their code later.
>>>  >> On Fri, Mar 8, 2019 at 3:00 AM Victor Lazzarini 
>>>  wrote:
>>>  >>> Ok, I´ve exposed find_opcode_new() and find_opcode_exact(), 
>>> they are available in the CSOUND object
>>>  >>> now. Let me know if it works for you.
>>>  >>> ========================
>>>  >>> Prof. Victor Lazzarini
>>>  >>> Dean of Arts, Celtic Studies, and Philosophy,
>>>  >>> Maynooth University,
>>>  >>> Maynooth, Co Kildare, Ireland
>>>  >>> Tel: 00 353 7086936
>>>  >>> Fax: 00 353 1 7086952
>>>  >>> > On 8 Mar 2019, at 07:44, Eduardo Moguillansky 
>>>  wrote:
>>>  >>> >
>>>  >>> > I only need "find_opcode_new".
>>>  >>> >
>>>  >>> > On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini 
>>>  wrote:
>>>  >>> >> Best thing is to expose it via the API in the CSOUND 
>>> struct, otherwise the plugin would
>>>  >>> >> need to link to the Csound lib, which is not
>>>  >>> >> right
>>>  >>> >> Which function(s) do you need?
>>>  >>> >> Victor Lazzarini
>>>  >>> >> Dean of Arts, Celtic Studies, and Philosophy
>>>  >>> >> Maynooth University
>>>  >>> >> Ireland
>>>  >>> >>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky 
>>>  wrote:
>>>  >>> >>> I finished implementing a quite usefull opcode 'poly', 
>>> which allows to instantiate and control multiple instances of a 
>>> given opcode, as
>>>  >>> >>> aOut[] poly 30, "oscili", 0.1, kFreqs
>>>  >>> >>> See here for an example and the resulting soundfile:
>>>  >>> >>> 
>>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>>>  >>> >>> The problem is that it needs to access "find_opcode.h" to 
>>> be able to call "find_opcode_new". As it is, this is not part of 
>>> the plugin API, and thus I can't build this as a plugin. Would it 
>>> be possible to include this header, or at least the very least to 
>>> be able to call "find_opcode_new" as part of the plugin API?
>>>  >>> >>> thanks!
>>>  >>> >>> eduardo
>>>  >
>>> 
> 
> 
> --
> http://mysterybear.net
> https://soundcloud.com/mysterybear
> https://mysterybear.bandcamp.com
> https://www.youtube.com/channel/UCo0--3uN5ycq_aupZXskBgA
> 
> http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz

I’ll defer the final decision to Steven and John to keep these functions exposed or not. 
I am happy either way.

best
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 8 Mar 2019, at 15:16, Eduardo Moguillansky  wrote:
> 
> How would that work for opcodes with multiple outputs, like pan2?
> 
> 
> 
> On Fr, Mar 8, 2019 at 3:16 PM, Dave Seidel  wrote:
>> +1 for using map() et al.
>> On Fri, Mar 8, 2019 at 7:35 AM Steven Yi  wrote:
>>> Well, I was thinking we have map, reduce, apply be implemented like other functional programming languages, as well as having opcode names be usable without strings as types, something like:
>>> ;; init-time
>>> kfreqs[] = [] ;; initialize some array of frequencies
>>> ops:Opcode[] = map(oscili, 0.1, kfreqs)
>>> ;; run-time
>>> asigs[] = map(call, ops)
>>> (ties into https://github.com/csound/csound/issues/322)
>>> Though if opcode names are interpreted as types, it might also work to have:
>>> ops:oscili[] = map(oscili, 0.1, kfreqs)
>>> As for the functions being marked PUBLIC, that looks like it was done to enable some coding convenience (maybe for the unit tests?) rather than being a result of API design. I certainly didn't write find_opcode_new or find_opcode_exact for CS6 with the intention that it be exposed publicly.
>>> On Fri, Mar 8, 2019 at 7:00 AM Victor Lazzarini  wrote:
>>>> yes, I think we should mainstream these things as part of the language in CS7 (parallel and serial opcodes).
>>>> I suppose this ‘poly’ opcode could be called ‘parallel’.
>>>> best
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>> > On 8 Mar 2019, at 10:56, Eduardo Moguillansky  wrote:
>>>> >
>>>> > Victor: tested and working fine, thanks for the quick response.
>>>> >
>>>> > It is fine for me to mark these as experimental.
>>>> >
>>>> > On a side note, I would like to extend the functionality of poly to support user defined opcodes. Is there a chance someone could take a look at the code [1] and see if this would be at all possible?
>>>> >
>>>> > The design for poly is based on maparray, and maparray seems to support udos, but I have not found a way to make them work.
>>>> >
>>>> > [1] https://github.com/gesellkammer/csound-plugins/blob/master/poly/poly.c
>>>> >
>>>> > On Fr, Mar 8, 2019 at 11:33 AM, Steven Yi  wrote:
>>>> >> Oof, from and API design perspective, I'm not sure those functions are great for exposing. (I didn't even realize these were put into an internal header file and exposed within our codebase.) Certainly want to support the use case, but would prefer a better public-facing function.
>>>> >> If these is going to be exposed for CS6 like this right now, let's mark it as experimental, with the expectation that a better designed public function will be created for CS7 and that developers should expect this to be removed and that they will need to update their code later.
>>>> >> On Fri, Mar 8, 2019 at 3:00 AM Victor Lazzarini  wrote:
>>>> >>> Ok, I´ve exposed find_opcode_new() and find_opcode_exact(), they are available in the CSOUND object
>>>> >>> now. Let me know if it works for you.
>>>> >>> ========================
>>>> >>> Prof. Victor Lazzarini
>>>> >>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> >>> Maynooth University,
>>>> >>> Maynooth, Co Kildare, Ireland
>>>> >>> Tel: 00 353 7086936
>>>> >>> Fax: 00 353 1 7086952
>>>> >>> > On 8 Mar 2019, at 07:44, Eduardo Moguillansky  wrote:
>>>> >>> >
>>>> >>> > I only need "find_opcode_new".
>>>> >>> >
>>>> >>> > On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini  wrote:
>>>> >>> >> Best thing is to expose it via the API in the CSOUND struct, otherwise the plugin would
>>>> >>> >> need to link to the Csound lib, which is not
>>>> >>> >> right
>>>> >>> >> Which function(s) do you need?
>>>> >>> >> Victor Lazzarini
>>>> >>> >> Dean of Arts, Celtic Studies, and Philosophy
>>>> >>> >> Maynooth University
>>>> >>> >> Ireland
>>>> >>> >>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky  wrote:
>>>> >>> >>> I finished implementing a quite usefull opcode 'poly', which allows to instantiate and control multiple instances of a given opcode, as
>>>> >>> >>> aOut[] poly 30, "oscili", 0.1, kFreqs
>>>> >>> >>> See here for an example and the resulting soundfile:
>>>> >>> >>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>>>> >>> >>> The problem is that it needs to access "find_opcode.h" to be able to call "find_opcode_new". As it is, this is not part of the plugin API, and thus I can't build this as a plugin. Would it be possible to include this header, or at least the very least to be able to call "find_opcode_new" as part of the plugin API?
>>>> >>> >>> thanks!
>>>> >>> >>> eduardo
>>>> >
>> --
>> http://mysterybear.net
>> https://soundcloud.com/mysterybear
>> https://mysterybear.bandcamp.com
>> https://www.youtube.com/channel/UCo0--3uN5ycq_aupZXskBgA
>> http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
>

Victor: the fix earlier does actually not solve the problem entirely, 
since find_opcode.h is missing from the installed header files. Maybe 
it should be have been moved from "H" to "include"?

/usr/local/include/csound/csoundCore.h:987:10: fatal error: 
find_opcode.h: No such file or directory



On Fr, Mar 8, 2019 at 4:48 PM, Victor Lazzarini 
 wrote:
> I’ll defer the final decision to Steven and John to keep these 
> functions exposed or not.
> I am happy either way.
> 
> best
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
> 
>>  On 8 Mar 2019, at 15:16, Eduardo Moguillansky 
>>  wrote:
>> 
>>  How would that work for opcodes with multiple outputs, like pan2?
>> 
>> 
>> 
>>  On Fr, Mar 8, 2019 at 3:16 PM, Dave Seidel  
>> wrote:
>>>  +1 for using map() et al.
>>>  On Fri, Mar 8, 2019 at 7:35 AM Steven Yi  
>>> wrote:
>>>>  Well, I was thinking we have map, reduce, apply be implemented 
>>>> like other functional programming languages, as well as having 
>>>> opcode names be usable without strings as types, something like:
>>>>  ;; init-time
>>>>  kfreqs[] = [] ;; initialize some array of frequencies
>>>>  ops:Opcode[] = map(oscili, 0.1, kfreqs)
>>>>  ;; run-time
>>>>  asigs[] = map(call, ops)
>>>>  (ties into https://github.com/csound/csound/issues/322)
>>>>  Though if opcode names are interpreted as types, it might also 
>>>> work to have:
>>>>  ops:oscili[] = map(oscili, 0.1, kfreqs)
>>>>  As for the functions being marked PUBLIC, that looks like it was 
>>>> done to enable some coding convenience (maybe for the unit tests?) 
>>>> rather than being a result of API design. I certainly didn't write 
>>>> find_opcode_new or find_opcode_exact for CS6 with the intention 
>>>> that it be exposed publicly.
>>>>  On Fri, Mar 8, 2019 at 7:00 AM Victor Lazzarini 
>>>>  wrote:
>>>>>  yes, I think we should mainstream these things as part of the 
>>>>> language in CS7 (parallel and serial opcodes).
>>>>>  I suppose this ‘poly’ opcode could be called ‘parallel’.
>>>>>  best
>>>>>  ========================
>>>>>  Prof. Victor Lazzarini
>>>>>  Dean of Arts, Celtic Studies, and Philosophy,
>>>>>  Maynooth University,
>>>>>  Maynooth, Co Kildare, Ireland
>>>>>  Tel: 00 353 7086936
>>>>>  Fax: 00 353 1 7086952
>>>>>  > On 8 Mar 2019, at 10:56, Eduardo Moguillansky 
>>>>>  wrote:
>>>>>  >
>>>>>  > Victor: tested and working fine, thanks for the quick response.
>>>>>  >
>>>>>  > It is fine for me to mark these as experimental.
>>>>>  >
>>>>>  > On a side note, I would like to extend the functionality of 
>>>>> poly to support user defined opcodes. Is there a chance someone 
>>>>> could take a look at the code [1] and see if this would be at all 
>>>>> possible?
>>>>>  >
>>>>>  > The design for poly is based on maparray, and maparray seems 
>>>>> to support udos, but I have not found a way to make them work.
>>>>>  >
>>>>>  > [1] 
>>>>> https://github.com/gesellkammer/csound-plugins/blob/master/poly/poly.c
>>>>>  >
>>>>>  > On Fr, Mar 8, 2019 at 11:33 AM, Steven Yi  
>>>>> wrote:
>>>>>  >> Oof, from and API design perspective, I'm not sure those 
>>>>> functions are great for exposing. (I didn't even realize these 
>>>>> were put into an internal header file and exposed within our 
>>>>> codebase.) Certainly want to support the use case, but would 
>>>>> prefer a better public-facing function.
>>>>>  >> If these is going to be exposed for CS6 like this right now, 
>>>>> let's mark it as experimental, with the expectation that a better 
>>>>> designed public function will be created for CS7 and that 
>>>>> developers should expect this to be removed and that they will 
>>>>> need to update their code later.
>>>>>  >> On Fri, Mar 8, 2019 at 3:00 AM Victor Lazzarini 
>>>>>  wrote:
>>>>>  >>> Ok, I´ve exposed find_opcode_new() and find_opcode_exact(), 
>>>>> they are available in the CSOUND object
>>>>>  >>> now. Let me know if it works for you.
>>>>>  >>> ========================
>>>>>  >>> Prof. Victor Lazzarini
>>>>>  >>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>  >>> Maynooth University,
>>>>>  >>> Maynooth, Co Kildare, Ireland
>>>>>  >>> Tel: 00 353 7086936
>>>>>  >>> Fax: 00 353 1 7086952
>>>>>  >>> > On 8 Mar 2019, at 07:44, Eduardo Moguillansky 
>>>>>  wrote:
>>>>>  >>> >
>>>>>  >>> > I only need "find_opcode_new".
>>>>>  >>> >
>>>>>  >>> > On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini 
>>>>>  wrote:
>>>>>  >>> >> Best thing is to expose it via the API in the CSOUND 
>>>>> struct, otherwise the plugin would
>>>>>  >>> >> need to link to the Csound lib, which is not
>>>>>  >>> >> right
>>>>>  >>> >> Which function(s) do you need?
>>>>>  >>> >> Victor Lazzarini
>>>>>  >>> >> Dean of Arts, Celtic Studies, and Philosophy
>>>>>  >>> >> Maynooth University
>>>>>  >>> >> Ireland
>>>>>  >>> >>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky 
>>>>>  wrote:
>>>>>  >>> >>> I finished implementing a quite usefull opcode 'poly', 
>>>>> which allows to instantiate and control multiple instances of a 
>>>>> given opcode, as
>>>>>  >>> >>> aOut[] poly 30, "oscili", 0.1, kFreqs
>>>>>  >>> >>> See here for an example and the resulting soundfile:
>>>>>  >>> >>> 
>>>>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>>>>>  >>> >>> The problem is that it needs to access "find_opcode.h" 
>>>>> to be able to call "find_opcode_new". As it is, this is not part 
>>>>> of the plugin API, and thus I can't build this as a plugin. Would 
>>>>> it be possible to include this header, or at least the very least 
>>>>> to be able to call "find_opcode_new" as part of the plugin API?
>>>>>  >>> >>> thanks!
>>>>>  >>> >>> eduardo
>>>>>  >
>>>  --
>>>  http://mysterybear.net
>>>  https://soundcloud.com/mysterybear
>>>  https://mysterybear.bandcamp.com
>>>  https://www.youtube.com/channel/UCo0--3uN5ycq_aupZXskBgA
>>>  http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
>> 
> 

I see. I would prefer to wait now for Steven as he was querying this move.

For development, it should still work as you probably have the full sources there with you. 

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

> On 9 Mar 2019, at 11:58, Eduardo Moguillansky  wrote:
> 
> Victor: the fix earlier does actually not solve the problem entirely, since find_opcode.h is missing from the installed header files. Maybe it should be have been moved from "H" to "include"?
> 
> /usr/local/include/csound/csoundCore.h:987:10: fatal error: find_opcode.h: No such file or directory
> 
> 
> 
>> On Fr, Mar 8, 2019 at 4:48 PM, Victor Lazzarini  wrote:
>> I’ll defer the final decision to Steven and John to keep these functions exposed or not.
>> I am happy either way.
>> best
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>> On 8 Mar 2019, at 15:16, Eduardo Moguillansky  wrote:
>>> How would that work for opcodes with multiple outputs, like pan2?
>>> On Fr, Mar 8, 2019 at 3:16 PM, Dave Seidel  wrote:
>>>> +1 for using map() et al.
>>>>> On Fri, Mar 8, 2019 at 7:35 AM Steven Yi  wrote:
>>>>> Well, I was thinking we have map, reduce, apply be implemented like other functional programming languages, as well as having opcode names be usable without strings as types, something like:
>>>>> ;; init-time
>>>>> kfreqs[] = [] ;; initialize some array of frequencies
>>>>> ops:Opcode[] = map(oscili, 0.1, kfreqs)
>>>>> ;; run-time
>>>>> asigs[] = map(call, ops)
>>>>> (ties into https://github.com/csound/csound/issues/322)
>>>>> Though if opcode names are interpreted as types, it might also work to have:
>>>>> ops:oscili[] = map(oscili, 0.1, kfreqs)
>>>>> As for the functions being marked PUBLIC, that looks like it was done to enable some coding convenience (maybe for the unit tests?) rather than being a result of API design. I certainly didn't write find_opcode_new or find_opcode_exact for CS6 with the intention that it be exposed publicly.
>>>>>> On Fri, Mar 8, 2019 at 7:00 AM Victor Lazzarini  wrote:
>>>>>> yes, I think we should mainstream these things as part of the language in CS7 (parallel and serial opcodes).
>>>>>> I suppose this ‘poly’ opcode could be called ‘parallel’.
>>>>>> best
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>> > On 8 Mar 2019, at 10:56, Eduardo Moguillansky  wrote:
>>>>>> >
>>>>>> > Victor: tested and working fine, thanks for the quick response.
>>>>>> >
>>>>>> > It is fine for me to mark these as experimental.
>>>>>> >
>>>>>> > On a side note, I would like to extend the functionality of poly to support user defined opcodes. Is there a chance someone could take a look at the code [1] and see if this would be at all possible?
>>>>>> >
>>>>>> > The design for poly is based on maparray, and maparray seems to support udos, but I have not found a way to make them work.
>>>>>> >
>>>>>> > [1] https://github.com/gesellkammer/csound-plugins/blob/master/poly/poly.c
>>>>>> >
>>>>>> > On Fr, Mar 8, 2019 at 11:33 AM, Steven Yi  wrote:
>>>>>> >> Oof, from and API design perspective, I'm not sure those functions are great for exposing. (I didn't even realize these were put into an internal header file and exposed within our codebase.) Certainly want to support the use case, but would prefer a better public-facing function.
>>>>>> >> If these is going to be exposed for CS6 like this right now, let's mark it as experimental, with the expectation that a better designed public function will be created for CS7 and that developers should expect this to be removed and that they will need to update their code later.
>>>>>> >> On Fri, Mar 8, 2019 at 3:00 AM Victor Lazzarini  wrote:
>>>>>> >>> Ok, I´ve exposed find_opcode_new() and find_opcode_exact(), they are available in the CSOUND object
>>>>>> >>> now. Let me know if it works for you.
>>>>>> >>> ========================
>>>>>> >>> Prof. Victor Lazzarini
>>>>>> >>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> >>> Maynooth University,
>>>>>> >>> Maynooth, Co Kildare, Ireland
>>>>>> >>> Tel: 00 353 7086936
>>>>>> >>> Fax: 00 353 1 7086952
>>>>>> >>> > On 8 Mar 2019, at 07:44, Eduardo Moguillansky  wrote:
>>>>>> >>> >
>>>>>> >>> > I only need "find_opcode_new".
>>>>>> >>> >
>>>>>> >>> > On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini  wrote:
>>>>>> >>> >> Best thing is to expose it via the API in the CSOUND struct, otherwise the plugin would
>>>>>> >>> >> need to link to the Csound lib, which is not
>>>>>> >>> >> right
>>>>>> >>> >> Which function(s) do you need?
>>>>>> >>> >> Victor Lazzarini
>>>>>> >>> >> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> >>> >> Maynooth University
>>>>>> >>> >> Ireland
>>>>>> >>> >>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky  wrote:
>>>>>> >>> >>> I finished implementing a quite usefull opcode 'poly', which allows to instantiate and control multiple instances of a given opcode, as
>>>>>> >>> >>> aOut[] poly 30, "oscili", 0.1, kFreqs
>>>>>> >>> >>> See here for an example and the resulting soundfile:
>>>>>> >>> >>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>>>>>> >>> >>> The problem is that it needs to access "find_opcode.h" to be able to call "find_opcode_new". As it is, this is not part of the plugin API, and thus I can't build this as a plugin. Would it be possible to include this header, or at least the very least to be able to call "find_opcode_new" as part of the plugin API?
>>>>>> >>> >>> thanks!
>>>>>> >>> >>> eduardo
>>>>>> >
>>>> --
>>>> http://mysterybear.net
>>>> https://soundcloud.com/mysterybear
>>>> https://mysterybear.bandcamp.com
>>>> https://www.youtube.com/channel/UCo0--3uN5ycq_aupZXskBgA
>>>> http://recordings.irritablehedgehog.com/album/da

On second thoughts, due to the changes, not moving that file breaks things. So I moved it for now. If we decide to revert this, I'll move it back.

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

> On 9 Mar 2019, at 12:16, Victor Lazzarini  wrote:
> 
> I see. I would prefer to wait now for Steven as he was querying this move.
> 
> For development, it should still work as you probably have the full sources there with you. 
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
>> On 9 Mar 2019, at 11:58, Eduardo Moguillansky  wrote:
>> 
>> Victor: the fix earlier does actually not solve the problem entirely, since find_opcode.h is missing from the installed header files. Maybe it should be have been moved from "H" to "include"?
>> 
>> /usr/local/include/csound/csoundCore.h:987:10: fatal error: find_opcode.h: No such file or directory
>> 
>> 
>> 
>>> On Fr, Mar 8, 2019 at 4:48 PM, Victor Lazzarini  wrote:
>>> I’ll defer the final decision to Steven and John to keep these functions exposed or not.
>>> I am happy either way.
>>> best
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>>> On 8 Mar 2019, at 15:16, Eduardo Moguillansky  wrote:
>>>> How would that work for opcodes with multiple outputs, like pan2?
>>>> On Fr, Mar 8, 2019 at 3:16 PM, Dave Seidel  wrote:
>>>>> +1 for using map() et al.
>>>>>> On Fri, Mar 8, 2019 at 7:35 AM Steven Yi  wrote:
>>>>>> Well, I was thinking we have map, reduce, apply be implemented like other functional programming languages, as well as having opcode names be usable without strings as types, something like:
>>>>>> ;; init-time
>>>>>> kfreqs[] = [] ;; initialize some array of frequencies
>>>>>> ops:Opcode[] = map(oscili, 0.1, kfreqs)
>>>>>> ;; run-time
>>>>>> asigs[] = map(call, ops)
>>>>>> (ties into https://github.com/csound/csound/issues/322)
>>>>>> Though if opcode names are interpreted as types, it might also work to have:
>>>>>> ops:oscili[] = map(oscili, 0.1, kfreqs)
>>>>>> As for the functions being marked PUBLIC, that looks like it was done to enable some coding convenience (maybe for the unit tests?) rather than being a result of API design. I certainly didn't write find_opcode_new or find_opcode_exact for CS6 with the intention that it be exposed publicly.
>>>>>>> On Fri, Mar 8, 2019 at 7:00 AM Victor Lazzarini  wrote:
>>>>>>> yes, I think we should mainstream these things as part of the language in CS7 (parallel and serial opcodes).
>>>>>>> I suppose this ‘poly’ opcode could be called ‘parallel’.
>>>>>>> best
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>>> On 8 Mar 2019, at 10:56, Eduardo Moguillansky  wrote:
>>>>>>>> 
>>>>>>>> Victor: tested and working fine, thanks for the quick response.
>>>>>>>> 
>>>>>>>> It is fine for me to mark these as experimental.
>>>>>>>> 
>>>>>>>> On a side note, I would like to extend the functionality of poly to support user defined opcodes. Is there a chance someone could take a look at the code [1] and see if this would be at all possible?
>>>>>>>> 
>>>>>>>> The design for poly is based on maparray, and maparray seems to support udos, but I have not found a way to make them work.
>>>>>>>> 
>>>>>>>> [1] https://github.com/gesellkammer/csound-plugins/blob/master/poly/poly.c
>>>>>>>> 
>>>>>>>>> On Fr, Mar 8, 2019 at 11:33 AM, Steven Yi  wrote:
>>>>>>>>> Oof, from and API design perspective, I'm not sure those functions are great for exposing. (I didn't even realize these were put into an internal header file and exposed within our codebase.) Certainly want to support the use case, but would prefer a better public-facing function.
>>>>>>>>> If these is going to be exposed for CS6 like this right now, let's mark it as experimental, with the expectation that a better designed public function will be created for CS7 and that developers should expect this to be removed and that they will need to update their code later.
>>>>>>>>>> On Fri, Mar 8, 2019 at 3:00 AM Victor Lazzarini  wrote:
>>>>>>>>>> Ok, I´ve exposed find_opcode_new() and find_opcode_exact(), they are available in the CSOUND object
>>>>>>>>>> now. Let me know if it works for you.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>> On 8 Mar 2019, at 07:44, Eduardo Moguillansky  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I only need "find_opcode_new".
>>>>>>>>>>> 
>>>>>>>>>>>> On Fr, Mar 8, 2019 at 6:45 AM, Victor Lazzarini  wrote:
>>>>>>>>>>>> Best thing is to expose it via the API in the CSOUND struct, otherwise the plugin would
>>>>>>>>>>>> need to link to the Csound lib, which is not
>>>>>>>>>>>> right
>>>>>>>>>>>> Which function(s) do you need?
>>>>>>>>>>>> Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>>> Maynooth University
>>>>>>>>>>>> Ireland
>>>>>>>>>>>>> On 8 Mar 2019, at 01:07, Eduardo Moguillansky  wrote:
>>>>>>>>>>>>> I finished implementing a quite usefull opcode 'poly', which allows to instantiate and control multiple instances of a given opcode, as
>>>>>>>>>>>>> aOut[] poly 30, "oscili", 0.1, kFreqs
>>>>>>>>>>>>> See here for an example and the resulting soundfile:
>>>>>>>>>>>>> https://github.com/gesellkammer/csound-plugins/wiki/Poly-example
>>>>>>>>>>>>> The problem is that it needs to access "find_opcode.h" to be able to call "find_opcode_new". As it is, this is not part of the plugin API, and thus I can't build this as a plugin. Would it be possible to include this header, or at least the very least to be able to call "find_opcode_new" as part of the plugin API?
>>>>>>>>>>>>> thanks!
>>>>>>>>>>>>> eduardo
>>>>>>>> 
>>>>> --
>>>>> http://mysterybear.net
>>>>> https://soundcloud.com/mysterybear
>>>>> https://mysterybear.bandcamp.com
>>>>> https://www.youtube.com/channel/UCo0--3uN5ycq_aupZXskBgA
>>>>> http://recordings.irritablehedgehog.com/album/dave-seidel-60