The csoundReadScore functions are renamed as

csoundEventString()

(and consolidated).

The reason I wasn't sure if we should keep csoundGetTable() is whether it is safe to share the memory. If we feel it is ok, then we should remove the copy functions because the host can easily implement them.


Prof. Victor Lazzarini
Maynooth University
Ireland

> On 2 Aug 2024, at 08:19, Francois PINOT  wrote:
> 
> 
> I nearly finished refactoring ctcsound.py for the new host API. I'd like to reintroduce the following functions in csound.h:
> 
> csoundReadScore, csoundReadScoreAsync (maybe merged with an async_mode flag), csoundGetTable and csoundGetTableArgs.
> 
> Reading score from a string is useful when coupled with csoundCompileOrc.
> csoundGetTable is interesting because it gives direct access to the memory data of the function table.
> csoundGetTableArgs can be useful when dealing with a  lot of tables.
> 
>  François



*Warning*

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

Effectively, csoundEventString() does the job.

CsoundGetSpin() and CsoundGetSpout() share memory too. I think people who use the host API should be aware of the risks of sharing memory with Csound. I prefer to keep csoundGetTable() and remove the copy functions. Sharing memory allows us to use numpy ndarray to access directly Csound memory: a powerful but evidently dangerous feature.

François

Le ven. 2 août 2024 à 09:48, vlz <viclazzarini@gmail.com> a écrit :

The csoundReadScore functions are renamed as

csoundEventString()

(and consolidated).

The reason I wasn't sure if we should keep csoundGetTable() is whether it is safe to share the memory. If we feel it is ok, then we should remove the copy functions because the host can easily implement them.


Prof. Victor Lazzarini
Maynooth University
Ireland

> On 2 Aug 2024, at 08:19, Francois PINOT <fggpinot@gmail.com> wrote:
>
> 
> I nearly finished refactoring ctcsound.py for the new host API. I'd like to reintroduce the following functions in csound.h:
>
> csoundReadScore, csoundReadScoreAsync (maybe merged with an async_mode flag), csoundGetTable and csoundGetTableArgs.
>
> Reading score from a string is useful when coupled with csoundCompileOrc.
> csoundGetTable is interesting because it gives direct access to the memory data of the function table.
> csoundGetTableArgs can be useful when dealing with a  lot of tables.
>
>  François

Would it be possible to add a csoundGetArray() function? That would ease 
a lot of things on my side…

And I agree with François regarding sharing memory. With great power 
comes great responsibility ;)

On 2024-08-02 14:08, Francois PINOT wrote:
> Effectively, csoundEventString() does the job.
> 
> CsoundGetSpin() and CsoundGetSpout() share memory too. I think people
> who use the host API should be aware of the risks of sharing memory
> with Csound. I prefer to keep csoundGetTable() and remove the copy
> functions. Sharing memory allows us to use numpy ndarray to access
> directly Csound memory: a powerful but evidently dangerous feature.
> 
> François
> 
> Le ven. 2 août 2024 à 09:48, vlz  a écrit :
> 
>> The csoundReadScore functions are renamed as
>> 
>> csoundEventString()
>> 
>> (and consolidated).
>> 
>> The reason I wasn't sure if we should keep csoundGetTable() is
>> whether it is safe to share the memory. If we feel it is ok, then we
>> should remove the copy functions because the host can easily
>> implement them.
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>> On 2 Aug 2024, at 08:19, Francois PINOT 
>> wrote:
>>> 
>>> 
>>> I nearly finished refactoring ctcsound.py for the new host API.
>> I'd like to reintroduce the following functions in csound.h:
>>> 
>>> csoundReadScore, csoundReadScoreAsync (maybe merged with an
>> async_mode flag), csoundGetTable and csoundGetTableArgs.
>>> 
>>> Reading score from a string is useful when coupled with
>> csoundCompileOrc.
>>> csoundGetTable is interesting because it gives direct access to
>> the memory data of the function table.
>>> csoundGetTableArgs can be useful when dealing with a  lot of
>> tables.
>>> 
>>> François

There is no direct access to variables, so access has to be through the software bus. We can look into adding array support through overloads. Note that you can already send and receive arrays but each item is given a separate channel.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 3 Aug 2024, at 15:08, Pierre Clisson  wrote:
> 
> Would it be possible to add a csoundGetArray() function? That would ease a lot of things on my side…
> 
> And I agree with François regarding sharing memory. With great power comes great responsibility ;)
> 
>> On 2024-08-02 14:08, Francois PINOT wrote:
>> Effectively, csoundEventString() does the job.
>> CsoundGetSpin() and CsoundGetSpout() share memory too. I think people
>> who use the host API should be aware of the risks of sharing memory
>> with Csound. I prefer to keep csoundGetTable() and remove the copy
>> functions. Sharing memory allows us to use numpy ndarray to access
>> directly Csound memory: a powerful but evidently dangerous feature.
>> François
>>> Le ven. 2 août 2024 à 09:48, vlz  a écrit :
>>> The csoundReadScore functions are renamed as
>>> csoundEventString()
>>> (and consolidated).
>>> The reason I wasn't sure if we should keep csoundGetTable() is
>>> whether it is safe to share the memory. If we feel it is ok, then we
>>> should remove the copy functions because the host can easily
>>> implement them.
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>> On 2 Aug 2024, at 08:19, Francois PINOT 
>>> wrote:
>>>> 
>>>> I nearly finished refactoring ctcsound.py for the new host API.
>>> I'd like to reintroduce the following functions in csound.h:
>>>> csoundReadScore, csoundReadScoreAsync (maybe merged with an
>>> async_mode flag), csoundGetTable and csoundGetTableArgs.
>>>> Reading score from a string is useful when coupled with
>>> csoundCompileOrc.
>>>> csoundGetTable is interesting because it gives direct access to
>>> the memory data of the function table.
>>>> csoundGetTableArgs can be useful when dealing with a  lot of
>>> tables.
>>>> François