Hi,

I'm thinking of changing the way data is interchanged between Csound
and API hosts, as I think the current state is not great.

First, I would move the code for invalue and outvalue from aops.c to
bus.c, to unify it with the rest of bus opcodes, and I would make them
use the same code and internal API functions as the rest of the bus
opcodes, to avoid redundancy. The csoundSetInputValueChannelCallback
and OutputValueCallback functions would be removed from the API and
their corresponding fields in the CSOUND struct will be freed. This
would be a big API change, so I wanted to ask before proceeding.

But I would also like to go further and instead of having all those
IASet, IASetSample, IKSet, IKSetValue, OAGet, etc, it might be better
to have a single API function which uses the new type system, which
would enable exchange of more data types (in the future), and leave a
much cleaner API.

What do you all think?

Cheers,
Andrés

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/li

Hi Michael,

I'm thinking this would be for Csound6, which would be a great
opportunity for an API cleanup. My proposal also asked whether the
existing functions should be kept in a separate compatibility library
to ease the transition.

Cheers,
Andres

On Thu, Nov 1, 2012 at 7:02 PM, Michael Gogins  wrote:
> You need to leave the existing functions, which various projects are already
> using. Introducing new functions based on the type system probably is a good
> idea, though, and factoring out redundant code also is a good idea.
>
> I wouldn't worry about slots, they can always be added.
>
> Best,
> Mike
>
>
> On Thu, Nov 1, 2012 at 7:40 PM, Andres Cabrera 
> wrote:
>>
>> Hi,
>>
>> I'm thinking of changing the way data is interchanged between Csound
>> and API hosts, as I think the current state is not great.
>>
>> First, I would move the code for invalue and outvalue from aops.c to
>> bus.c, to unify it with the rest of bus opcodes, and I would make them
>> use the same code and internal API functions as the rest of the bus
>> opcodes, to avoid redundancy. The csoundSetInputValueChannelCallback
>> and OutputValueCallback functions would be removed from the API and
>> their corresponding fields in the CSOUND struct will be freed. This
>> would be a big API change, so I wanted to ask before proceeding.
>>
>> But I would also like to go further and instead of having all those
>> IASet, IASetSample, IKSet, IKSetValue, OAGet, etc, it might be better
>> to have a single API function which uses the new type system, which
>> would enable exchange of more data types (in the future), and leave a
>> much cleaner API.
>>
>> What do you all think?
>>
>> Cheers,
>> Andrés
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
htt

Andres,

this sounds good.
I was also thinking, to make all of this thread-safe, we could make the busses use circular buffers and then we can remove any locks. I have already added an interface in csound.h and csoundCore.h (implemented in InOut/ circularbuffer.c), which can be used for these applications.

I am planning to use this mechanism for asynchronous file IO.

Regards

Victor

On 1 Nov 2012, at 23:40, Andres Cabrera wrote:

> Hi,
> 
> I'm thinking of changing the way data is interchanged between Csound
> and API hosts, as I think the current state is not great.
> 
> First, I would move the code for invalue and outvalue from aops.c to
> bus.c, to unify it with the rest of bus opcodes, and I would make them
> use the same code and internal API functions as the rest of the bus
> opcodes, to avoid redundancy. The csoundSetInputValueChannelCallback
> and OutputValueCallback functions would be removed from the API and
> their corresponding fields in the CSOUND struct will be freed. This
> would be a big API change, so I wanted to ask before proceeding.
> 
> But I would also like to go further and instead of having all those
> IASet, IASetSample, IKSet, IKSetValue, OAGet, etc, it might be better
> to have a single API function which uses the new type system, which
> would enable exchange of more data types (in the future), and leave a
> much cleaner API.
> 
> What do you all think?
> 
> Cheers,
> Andrés
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

Yes, thread safety would be great. I could be provided by the core
API, or by an additional layer like csPerfThread. (Are there real
world cases where people would prefer not having that thread safety
because they are handling the interchange and synchronization
themselves?)

So I guess my question is: can I break backwards compatibility with
the Csound5 API?

and: can I break binary compatibility with previous versions of Csound6?

Cheers,
Andrés

On Fri, Nov 2, 2012 at 6:44 AM, Victor Lazzarini
 wrote:
> Andres,
>
> this sounds good.
> I was also thinking, to make all of this thread-safe, we could make the busses use circular buffers and then we can remove any locks. I have already added an interface in csound.h and csoundCore.h (implemented in InOut/ circularbuffer.c), which can be used for these applications.
>
> I am planning to use this mechanism for asynchronous file IO.
>
> Regards
>
> Victor
>
> On 1 Nov 2012, at 23:40, Andres Cabrera wrote:
>
>> Hi,
>>
>> I'm thinking of changing the way data is interchanged between Csound
>> and API hosts, as I think the current state is not great.
>>
>> First, I would move the code for invalue and outvalue from aops.c to
>> bus.c, to unify it with the rest of bus opcodes, and I would make them
>> use the same code and internal API functions as the rest of the bus
>> opcodes, to avoid redundancy. The csoundSetInputValueChannelCallback
>> and OutputValueCallback functions would be removed from the API and
>> their corresponding fields in the CSOUND struct will be freed. This
>> would be a big API change, so I wanted to ask before proceeding.
>>
>> But I would also like to go further and instead of having all those
>> IASet, IASetSample, IKSet, IKSetValue, OAGet, etc, it might be better
>> to have a single API function which uses the new type system, which
>> would enable exchange of more data types (in the future), and leave a
>> much cleaner API.
>>
>> What do you all think?
>>
>> Cheers,
>> Andrés
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-deve

> So I guess my question is: can I break backwards compatibility with
> the Csound5 API?
>

Yes

> and: can I break binary compatibility with previous versions of Csound6?
>

most certainly -- csound6 is not released

> Cheers,
> Andrés
>

==John ff


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

If we include lockfree circular buffers in all communications by the API, the whole thing is seamless and we won't need special implementations like
csPerfThread. It should benefit all of csound, including PARCS.

The same goes for zak etc.

Victor
On 2 Nov 2012, at 16:57, Andres Cabrera wrote:

> Hi,
> 
> Yes, thread safety would be great. I could be provided by the core
> API, or by an additional layer like csPerfThread. (Are there real
> world cases where people would prefer not having that thread safety
> because they are handling the interchange and synchronization
> themselves?)
> 
> So I guess my question is: can I break backwards compatibility with
> the Csound5 API?
> 
> and: can I break binary compatibility with previous versions of Csound6?
> 
> Cheers,
> Andrés
> 
> On Fri, Nov 2, 2012 at 6:44 AM, Victor Lazzarini
>  wrote:
>> Andres,
>> 
>> this sounds good.
>> I was also thinking, to make all of this thread-safe, we could make the busses use circular buffers and then we can remove any locks. I have already added an interface in csound.h and csoundCore.h (implemented in InOut/ circularbuffer.c), which can be used for these applications.
>> 
>> I am planning to use this mechanism for asynchronous file IO.
>> 
>> Regards
>> 
>> Victor
>> 
>> On 1 Nov 2012, at 23:40, Andres Cabrera wrote:
>> 
>>> Hi,
>>> 
>>> I'm thinking of changing the way data is interchanged between Csound
>>> and API hosts, as I think the current state is not great.
>>> 
>>> First, I would move the code for invalue and outvalue from aops.c to
>>> bus.c, to unify it with the rest of bus opcodes, and I would make them
>>> use the same code and internal API functions as the rest of the bus
>>> opcodes, to avoid redundancy. The csoundSetInputValueChannelCallback
>>> and OutputValueCallback functions would be removed from the API and
>>> their corresponding fields in the CSOUND struct will be freed. This
>>> would be a big API change, so I wanted to ask before proceeding.
>>> 
>>> But I would also like to go further and instead of having all those
>>> IASet, IASetSample, IKSet, IKSetValue, OAGet, etc, it might be better
>>> to have a single API function which uses the new type system, which
>>> would enable exchange of more data types (in the future), and leave a
>>> much cleaner API.
>>> 
>>> What do you all think?
>>> 
>>> Cheers,
>>> Andrés
>>> 
>>> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net