I see opcodes using such functionality, like "active". But the underlying functionality 
is not exposed in the API. Could there be two new API functions with  the form:

INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)

This would return csound->engineState.instrtxtp[intrnum] and NULL if not found

and

INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum) 

This would find the exact instance and return NULL if not found.

It is possible to do this without the API but as far as I can see this 
implies traversing the list of all active instances.

Thanks!

Eduardo

To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table.

https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html

At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient.

Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance.

We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.

Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name

and returns the answer.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 7 Dec 2019, at 15:19, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

I see opcodes using such functionality, like "active". But the underlying functionality 
is not exposed in the API. Could there be two new API functions with  the form:

INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)

This would return csound->engineState.instrtxtp[intrnum] and NULL if not found

and

INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum) 

This would find the exact instance and return NULL if not found.

It is possible to do this without the API but as far as I can see this 
implies traversing the list of all active instances.

Thanks!

Eduardo

To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table.

https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html

At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient.

Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance.

On 09.12.19 00:22, Victor Lazzarini wrote:

We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.

Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name

and returns the answer.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 7 Dec 2019, at 15:19, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

I see opcodes using such functionality, like "active". But the underlying functionality 
is not exposed in the API. Could there be two new API functions with  the form:

INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)

This would return csound->engineState.instrtxtp[intrnum] and NULL if not found

and

INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum) 

This would find the exact instance and return NULL if not found.

It is possible to do this without the API but as far as I can see this 
implies traversing the list of all active instances.

Thanks!

Eduardo

A function in the CSOUND struct passed to plugin opcodes. One usecase for this is to schedule an event which can be adressed uniquely

inum uniqinstance 100
schedule inum, ...
... later on or in another instrument
turnoff2 inum

and the user is sure that the instance launched is a unique instance. Given that there are many different scheduling opcodes and usecases for this, I think it would be good to just expose this functionality so that the user can then choose one of the scheduling opcodes as needed.

So you mean you want a function in CSOUND, not the in the public API, is that what you are saying?

Prof. Victor Lazzarini

Maynooth University

Ireland

On 8 Dec 2019, at 23:47, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table.

https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html

At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient.

Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance.

On 09.12.19 00:22, Victor Lazzarini wrote:

We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.

Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name

and returns the answer.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 7 Dec 2019, at 15:19, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

I see opcodes using such functionality, like "active". But the underlying functionality 
is not exposed in the API. Could there be two new API functions with  the form:

INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)

This would return csound->engineState.instrtxtp[intrnum] and NULL if not found

and

INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum) 

This would find the exact instance and return NULL if not found.

It is possible to do this without the API but as far as I can see this 
implies traversing the list of all active instances.

Thanks!

Eduardo

A function in the CSOUND struct passed to plugin opcodes. One usecase for this is to schedule an event which can be adressed uniquely

inum uniqinstance 100
schedule inum, ...
... later on or in another instrument
turnoff2 inum

and the user is sure that the instance launched is a unique instance. Given that there are many different scheduling opcodes and usecases for this, I think it would be good to just expose this functionality so that the user can then choose one of the scheduling opcodes as needed.

On 09.12.19 07:38, Victor Lazzarini wrote:

So you mean you want a function in CSOUND, not the in the public API, is that what you are saying?

Prof. Victor Lazzarini

Maynooth University

Ireland

On 8 Dec 2019, at 23:47, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table.

https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html

At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient.

Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance.

On 09.12.19 00:22, Victor Lazzarini wrote:

We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.

Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name

and returns the answer.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 7 Dec 2019, at 15:19, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

I see opcodes using such functionality, like "active". But the underlying functionality 
is not exposed in the API. Could there be two new API functions with  the form:

INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)

This would return csound->engineState.instrtxtp[intrnum] and NULL if not found

and

INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum) 

This would find the exact instance and return NULL if not found.

It is possible to do this without the API but as far as I can see this 
implies traversing the list of all active instances.

Thanks!

Eduardo

Ok, it’s in

csoundGetInstrument(CSOUND *csound, int insno, const char *name);

accessed via

csound->GetInstrument(…)

If you have a named instrument, pass in the name as name, otherwise set that
as NULL.

Hope it does the job.

best
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 9 Dec 2019, at 11:56, Victor Lazzarini  wrote:
> 
> That should be no problem. I can look at it later today.
> 
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
> On 9 Dec 2019, at 08:20, Eduardo Moguillansky  wrote:
> 
>> A function in the CSOUND struct passed to plugin opcodes. One usecase for this is to schedule an event which can be adressed uniquely
>> 
>> inum uniqinstance 100
>> schedule inum, ...
>> ... later on or in another instrument
>> turnoff2 inum
>> 
>> and the user is sure that the instance launched is a unique instance. Given that there are many different scheduling opcodes and usecases for this, I think it would be good to just expose this functionality so that the user can then choose one of the scheduling opcodes as needed. 
>> 
>> 
>> 
>> On 09.12.19 07:38, Victor Lazzarini wrote:
>>> So you mean you want a function in CSOUND, not the in the public API, is that what you are saying?
>>> 
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>> 
>>> On 8 Dec 2019, at 23:47, Eduardo Moguillansky  wrote:
>>> 
>>>> To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table. 
>>>> 
>>>> https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html
>>>> 
>>>> At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient. 
>>>> 
>>>> Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance. 
>>>> 
>>>> On 09.12.19 00:22, Victor Lazzarini wrote:
>>>>> We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.
>>>>> 
>>>>> Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name
>>>>> and returns the answer.
>>>>> 
>>>>> Prof. Victor Lazzarini
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>> On 7 Dec 2019, at 15:19, Eduardo Moguillansky  wrote:
>>>>> 
>>>>>> I see opcodes using such functionality, like "active". But the underlying functionality 
>>>>>> is not exposed in the API. Could there be two new API functions with  the form:
>>>>>> 
>>>>>> INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)
>>>>>> This would return csound->engineState.instrtxtp[intrnum] and NULL if not found
>>>>>> 
>>>>>> and
>>>>>> INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum) 
>>>>>> 
>>>>>> This would find the exact instance and return NULL if not found.
>>>>>> It is possible to do this without the API but as far as I can see this 
>>>>>> implies traversing the list of all active instances.
>>>>>> 
>>>>>> Thanks!
>>>>>> Eduardo
>>>>>> 
>>>>

Behind in email, but a quick note that we might consider revising
instancing and handles to instances to permit some better usage than
having to deal with fractional instrument numbers. If we could mark
this as experimental for now that would be appreciated.

On Mon, Dec 9, 2019 at 7:58 AM Victor Lazzarini  wrote:
>
> Ok, it’s in
>
> csoundGetInstrument(CSOUND *csound, int insno, const char *name);
>
> accessed via
>
> csound->GetInstrument(…)
>
> If you have a named instrument, pass in the name as name, otherwise set that
> as NULL.
>
> Hope it does the job.
>
> best
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 9 Dec 2019, at 11:56, Victor Lazzarini  wrote:
> >
> > That should be no problem. I can look at it later today.
> >
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> > On 9 Dec 2019, at 08:20, Eduardo Moguillansky  wrote:
> >
> >> A function in the CSOUND struct passed to plugin opcodes. One usecase for this is to schedule an event which can be adressed uniquely
> >>
> >> inum uniqinstance 100
> >> schedule inum, ...
> >> ... later on or in another instrument
> >> turnoff2 inum
> >>
> >> and the user is sure that the instance launched is a unique instance. Given that there are many different scheduling opcodes and usecases for this, I think it would be good to just expose this functionality so that the user can then choose one of the scheduling opcodes as needed.
> >>
> >>
> >>
> >> On 09.12.19 07:38, Victor Lazzarini wrote:
> >>> So you mean you want a function in CSOUND, not the in the public API, is that what you are saying?
> >>>
> >>> Prof. Victor Lazzarini
> >>> Maynooth University
> >>> Ireland
> >>>
> >>> On 8 Dec 2019, at 23:47, Eduardo Moguillansky  wrote:
> >>>
> >>>> To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table.
> >>>>
> >>>> https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html
> >>>>
> >>>> At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient.
> >>>>
> >>>> Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance.
> >>>>
> >>>> On 09.12.19 00:22, Victor Lazzarini wrote:
> >>>>> We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.
> >>>>>
> >>>>> Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name
> >>>>> and returns the answer.
> >>>>>
> >>>>> Prof. Victor Lazzarini
> >>>>> Maynooth University
> >>>>> Ireland
> >>>>>
> >>>>> On 7 Dec 2019, at 15:19, Eduardo Moguillansky  wrote:
> >>>>>
> >>>>>> I see opcodes using such functionality, like "active". But the underlying functionality
> >>>>>> is not exposed in the API. Could there be two new API functions with  the form:
> >>>>>>
> >>>>>> INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)
> >>>>>> This would return csound->engineState.instrtxtp[intrnum] and NULL if not found
> >>>>>>
> >>>>>> and
> >>>>>> INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum)
> >>>>>>
> >>>>>> This would find the exact instance and return NULL if not found.
> >>>>>> It is possible to do this without the API but as far as I can see this
> >>>>>> implies traversing the list of all active instances.
> >>>>>>
> >>>>>> Thanks!
> >>>>>> Eduardo
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>

yes, we need a better way. That should be tied in with the ideas we had about insertion 
points for instances. We need to allow more flexibility.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 9 Dec 2019, at 13:06, Steven Yi  wrote:
> 
> Behind in email, but a quick note that we might consider revising
> instancing and handles to instances to permit some better usage than
> having to deal with fractional instrument numbers. If we could mark
> this as experimental for now that would be appreciated.
> 
> On Mon, Dec 9, 2019 at 7:58 AM Victor Lazzarini  wrote:
>> 
>> Ok, it’s in
>> 
>> csoundGetInstrument(CSOUND *csound, int insno, const char *name);
>> 
>> accessed via
>> 
>> csound->GetInstrument(…)
>> 
>> If you have a named instrument, pass in the name as name, otherwise set that
>> as NULL.
>> 
>> Hope it does the job.
>> 
>> best
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>> On 9 Dec 2019, at 11:56, Victor Lazzarini  wrote:
>>> 
>>> That should be no problem. I can look at it later today.
>>> 
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>> 
>>> On 9 Dec 2019, at 08:20, Eduardo Moguillansky  wrote:
>>> 
>>>> A function in the CSOUND struct passed to plugin opcodes. One usecase for this is to schedule an event which can be adressed uniquely
>>>> 
>>>> inum uniqinstance 100
>>>> schedule inum, ...
>>>> ... later on or in another instrument
>>>> turnoff2 inum
>>>> 
>>>> and the user is sure that the instance launched is a unique instance. Given that there are many different scheduling opcodes and usecases for this, I think it would be good to just expose this functionality so that the user can then choose one of the scheduling opcodes as needed.
>>>> 
>>>> 
>>>> 
>>>> On 09.12.19 07:38, Victor Lazzarini wrote:
>>>>> So you mean you want a function in CSOUND, not the in the public API, is that what you are saying?
>>>>> 
>>>>> Prof. Victor Lazzarini
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>> On 8 Dec 2019, at 23:47, Eduardo Moguillansky  wrote:
>>>>> 
>>>>>> To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table.
>>>>>> 
>>>>>> https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html
>>>>>> 
>>>>>> At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient.
>>>>>> 
>>>>>> Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance.
>>>>>> 
>>>>>> On 09.12.19 00:22, Victor Lazzarini wrote:
>>>>>>> We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.
>>>>>>> 
>>>>>>> Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name
>>>>>>> and returns the answer.
>>>>>>> 
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>> 
>>>>>>> On 7 Dec 2019, at 15:19, Eduardo Moguillansky  wrote:
>>>>>>> 
>>>>>>>> I see opcodes using such functionality, like "active". But the underlying functionality
>>>>>>>> is not exposed in the API. Could there be two new API functions with  the form:
>>>>>>>> 
>>>>>>>> INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)
>>>>>>>> This would return csound->engineState.instrtxtp[intrnum] and NULL if not found
>>>>>>>> 
>>>>>>>> and
>>>>>>>> INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum)
>>>>>>>> 
>>>>>>>> This would find the exact instance and return NULL if not found.
>>>>>>>> It is possible to do this without the API but as far as I can see this
>>>>>>>> implies traversing the list of all active instances.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> Eduardo
>>>>>>>> 
>>>>>>>> 
>>>

This is not a host API function, just for plugins. Adding it to the host API is more problematic as we would need to expose INSTRTXT etc
and that’s not really something we want to contemplate at this stage.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 9 Dec 2019, at 18:00, Francois PINOT  wrote:
> 
> I see that new API functions recently added appear in csoundCore.h but not in csound.h which I thought was the 'official' reference for the C API. Is there any reason for that?
> 
> François
> 
> Le lun. 9 déc. 2019 à 13:58, Victor Lazzarini  a écrit :
> Ok, it’s in
> 
> csoundGetInstrument(CSOUND *csound, int insno, const char *name);
> 
> accessed via
> 
> csound->GetInstrument(…)
> 
> If you have a named instrument, pass in the name as name, otherwise set that
> as NULL.
> 
> Hope it does the job.
> 
> best
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
> > On 9 Dec 2019, at 11:56, Victor Lazzarini  wrote:
> > 
> > That should be no problem. I can look at it later today.
> > 
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> > 
> > On 9 Dec 2019, at 08:20, Eduardo Moguillansky  wrote:
> > 
> >> A function in the CSOUND struct passed to plugin opcodes. One usecase for this is to schedule an event which can be adressed uniquely
> >> 
> >> inum uniqinstance 100
> >> schedule inum, ...
> >> ... later on or in another instrument
> >> turnoff2 inum
> >> 
> >> and the user is sure that the instance launched is a unique instance. Given that there are many different scheduling opcodes and usecases for this, I think it would be good to just expose this functionality so that the user can then choose one of the scheduling opcodes as needed. 
> >> 
> >> 
> >> 
> >> On 09.12.19 07:38, Victor Lazzarini wrote:
> >>> So you mean you want a function in CSOUND, not the in the public API, is that what you are saying?
> >>> 
> >>> Prof. Victor Lazzarini
> >>> Maynooth University
> >>> Ireland
> >>> 
> >>> On 8 Dec 2019, at 23:47, Eduardo Moguillansky  wrote:
> >>> 
> >>>> To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table. 
> >>>> 
> >>>> https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html
> >>>> 
> >>>> At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient. 
> >>>> 
> >>>> Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance. 
> >>>> 
> >>>> On 09.12.19 00:22, Victor Lazzarini wrote:
> >>>>> We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.
> >>>>> 
> >>>>> Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name
> >>>>> and returns the answer.
> >>>>> 
> >>>>> Prof. Victor Lazzarini
> >>>>> Maynooth University
> >>>>> Ireland
> >>>>> 
> >>>>> On 7 Dec 2019, at 15:19, Eduardo Moguillansky  wrote:
> >>>>> 
> >>>>>> I see opcodes using such functionality, like "active". But the underlying functionality 
> >>>>>> is not exposed in the API. Could there be two new API functions with  the form:
> >>>>>> 
> >>>>>> INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)
> >>>>>> This would return csound->engineState.instrtxtp[intrnum] and NULL if not found
> >>>>>> 
> >>>>>> and
> >>>>>> INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum) 
> >>>>>> 
> >>>>>> This would find the exact instance and return NULL if not found.
> >>>>>> It is possible to do this without the API but as far as I can see this 
> >>>>>> implies traversing the list of all active instances.
> >>>>>> 
> >>>>>> Thanks!
> >>>>>> Eduardo
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 

The reason is almost certainly my incometence.  I trt not to mess with the 
API nbut sometimes I am forced to.

==John ff

On Mon, 9 Dec 2019, Francois PINOT wrote:

> I see that new API functions recently added appear in csoundCore.h but not in
> csound.h which I thought was the 'official' reference for the C API. Is there
> any reason for that?
> 
> François
> 
> Le lun. 9 déc. 2019 à 13:58, Victor Lazzarini  a
> écrit :
>       Ok, it’s in
>
>       csoundGetInstrument(CSOUND *csound, int insno, const char *name);
>
>       accessed via
>
>       csound->GetInstrument(…)
>
>       If you have a named instrument, pass in the name as name,
>       otherwise set that
>       as NULL.
>
>       Hope it does the job.
>
>       best
>       ========================
>       Prof. Victor Lazzarini
>       Maynooth University
>       Ireland
>
>       > On 9 Dec 2019, at 11:56, Victor Lazzarini
>        wrote:
>       >
>       > That should be no problem. I can look at it later today.
>       >
>       > Prof. Victor Lazzarini
>       > Maynooth University
>       > Ireland
>       >
>       > On 9 Dec 2019, at 08:20, Eduardo Moguillansky
>        wrote:
>       >
>       >> A function in the CSOUND struct passed to plugin opcodes. One
>       usecase for this is to schedule an event which can be adressed
>       uniquely
>       >>
>       >> inum uniqinstance 100
>       >> schedule inum, ...
>       >> ... later on or in another instrument
>       >> turnoff2 inum
>       >>
>       >> and the user is sure that the instance launched is a unique
>       instance. Given that there are many different scheduling opcodes
>       and usecases for this, I think it would be good to just expose
>       this functionality so that the user can then choose one of the
>       scheduling opcodes as needed.
>       >>
>       >>
>       >>
>       >> On 09.12.19 07:38, Victor Lazzarini wrote:
>       >>> So you mean you want a function in CSOUND, not the in the
>       public API, is that what you are saying?
>       >>>
>       >>> Prof. Victor Lazzarini
>       >>> Maynooth University
>       >>> Ireland
>       >>>
>       >>> On 8 Dec 2019, at 23:47, Eduardo Moguillansky
>        wrote:
>       >>>
>       >>>> To be concrete, I just implemented an opcode "uniqinstance"
>       which returns a fractional instrument number which is guaranteed
>       to not exist at the moment. The idea behind it is to allow for
>       instruments what already is in place for tables, where the user
>       does not need to take care of table numbers and can rely on ftgen
>       returning a new table.
>       >>>>
>       >>>>
>       https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html
>       >>>>
>       >>>> At the moment it is not as efficient as it could be because
>       it needs to traverse the active instruments to find what
>       instrument numbers are in use. It could be more efficient if we
>       could have a function like "find_instr_definition" which would
>       return the INSTRTXT, and this structure holds a list of all active
>       instances of this instr so the search would be more efficient.
>       >>>>
>       >>>> Of course another solution would be a variant of schedule
>       which creates a unique instance and returns the instrument number.
>       But I see other use cases where an opcode might want to have
>       access to another instance.
>       >>>>
>       >>>> On 09.12.19 00:22, Victor Lazzarini wrote:
>       >>>>> We need to see how best to present this. Currently INSDS and
>       INSTRTXT are not exposed, and maybe that's the right thing.
>       >>>>>
>       >>>>> Possibly using opaque handles? But do we need it, if the aim
>       is to implement "active" etc in the API, we may just need a
>       function that takes an instrument number or name
>       >>>>> and returns the answer.
>       >>>>>
>       >>>>> Prof. Victor Lazzarini
>       >>>>> Maynooth University
>       >>>>> Ireland
>       >>>>>
>       >>>>> On 7 Dec 2019, at 15:19, Eduardo Moguillansky
>        wrote:
>       >>>>>
>       >>>>>> I see opcodes using such functionality, like "active". But
>       the underlying functionality
>       >>>>>> is not exposed in the API. Could there be two new API
>       functions with  the form:
>       >>>>>>
>       >>>>>> INSTRTXT * find_instr_definition(CSOUND *csound, int
>       instrnum)
>       >>>>>> This would return csound->engineState.instrtxtp[intrnum]
>       and NULL if not found
>       >>>>>>
>       >>>>>> and
>       >>>>>> INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum)
>       >>>>>>
>       >>>>>> This would find the exact instance and return NULL if not
>       found.
>       >>>>>> It is possible to do this without the API but as far as I
>       can see this
>       >>>>>> implies traversing the list of all active instances.
>       >>>>>>
>       >>>>>> Thanks!
>       >>>>>> Eduardo
>       >>>>>>
>       >>>>>>
>       >>>>>>
>       >>>>>>
>       >>>>>>
> 
> 
>

No, it’s not for that purpose. We have two APIs, the host (functions/data structures  in csound.h) and the plugin (CSOUND struct in csoundCore.h), some functionality overlaps, but there are functions that only make sense in one and not the other.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 9 Dec 2019, at 18:10, Francois PINOT  wrote:
> 
> Ok, I got it. So I won't show them in ctcsound...
> 
> François
> 
> Le lun. 9 déc. 2019 à 19:08, Victor Lazzarini  a écrit :
> This is not a host API function, just for plugins. Adding it to the host API is more problematic as we would need to expose INSTRTXT etc
> and that’s not really something we want to contemplate at this stage.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
> > On 9 Dec 2019, at 18:00, Francois PINOT  wrote:
> > 
> > I see that new API functions recently added appear in csoundCore.h but not in csound.h which I thought was the 'official' reference for the C API. Is there any reason for that?
> > 
> > François
> > 
> > Le lun. 9 déc. 2019 à 13:58, Victor Lazzarini  a écrit :
> > Ok, it’s in
> > 
> > csoundGetInstrument(CSOUND *csound, int insno, const char *name);
> > 
> > accessed via
> > 
> > csound->GetInstrument(…)
> > 
> > If you have a named instrument, pass in the name as name, otherwise set that
> > as NULL.
> > 
> > Hope it does the job.
> > 
> > best
> > ========================
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> > 
> > > On 9 Dec 2019, at 11:56, Victor Lazzarini  wrote:
> > > 
> > > That should be no problem. I can look at it later today.
> > > 
> > > Prof. Victor Lazzarini
> > > Maynooth University
> > > Ireland
> > > 
> > > On 9 Dec 2019, at 08:20, Eduardo Moguillansky  wrote:
> > > 
> > >> A function in the CSOUND struct passed to plugin opcodes. One usecase for this is to schedule an event which can be adressed uniquely
> > >> 
> > >> inum uniqinstance 100
> > >> schedule inum, ...
> > >> ... later on or in another instrument
> > >> turnoff2 inum
> > >> 
> > >> and the user is sure that the instance launched is a unique instance. Given that there are many different scheduling opcodes and usecases for this, I think it would be good to just expose this functionality so that the user can then choose one of the scheduling opcodes as needed. 
> > >> 
> > >> 
> > >> 
> > >> On 09.12.19 07:38, Victor Lazzarini wrote:
> > >>> So you mean you want a function in CSOUND, not the in the public API, is that what you are saying?
> > >>> 
> > >>> Prof. Victor Lazzarini
> > >>> Maynooth University
> > >>> Ireland
> > >>> 
> > >>> On 8 Dec 2019, at 23:47, Eduardo Moguillansky  wrote:
> > >>> 
> > >>>> To be concrete, I just implemented an opcode "uniqinstance" which returns a fractional instrument number which is guaranteed to not exist at the moment. The idea behind it is to allow for instruments what already is in place for tables, where the user does not need to take care of table numbers and can rely on ftgen returning a new table. 
> > >>>> 
> > >>>> https://csound-plugins.github.io/csound-plugins/opcodes/uniqinstance.html
> > >>>> 
> > >>>> At the moment it is not as efficient as it could be because it needs to traverse the active instruments to find what instrument numbers are in use. It could be more efficient if we could have a function like "find_instr_definition" which would return the INSTRTXT, and this structure holds a list of all active instances of this instr so the search would be more efficient. 
> > >>>> 
> > >>>> Of course another solution would be a variant of schedule which creates a unique instance and returns the instrument number. But I see other use cases where an opcode might want to have access to another instance. 
> > >>>> 
> > >>>> On 09.12.19 00:22, Victor Lazzarini wrote:
> > >>>>> We need to see how best to present this. Currently INSDS and INSTRTXT are not exposed, and maybe that's the right thing.
> > >>>>> 
> > >>>>> Possibly using opaque handles? But do we need it, if the aim is to implement "active" etc in the API, we may just need a function that takes an instrument number or name
> > >>>>> and returns the answer.
> > >>>>> 
> > >>>>> Prof. Victor Lazzarini
> > >>>>> Maynooth University
> > >>>>> Ireland
> > >>>>> 
> > >>>>> On 7 Dec 2019, at 15:19, Eduardo Moguillansky  wrote:
> > >>>>> 
> > >>>>>> I see opcodes using such functionality, like "active". But the underlying functionality 
> > >>>>>> is not exposed in the API. Could there be two new API functions with  the form:
> > >>>>>> 
> > >>>>>> INSTRTXT * find_instr_definition(CSOUND *csound, int instrnum)
> > >>>>>> This would return csound->engineState.instrtxtp[intrnum] and NULL if not found
> > >>>>>> 
> > >>>>>> and
> > >>>>>> INSDS *find_instr_exact(CSOUND *csound, MYFLT instrnum) 
> > >>>>>> 
> > >>>>>> This would find the exact instance and return NULL if not found.
> > >>>>>> It is possible to do this without the API but as far as I can see this 
> > >>>>>> implies traversing the list of all active instances.
> > >>>>>> 
> > >>>>>> Thanks!
> > >>>>>> Eduardo
> > >>>>>> 
> > >>>>