Hi All,

I'm writing in regards to some proposed changes to the CsoundObj API
that are being worked on by Aure.  I think the changes are good and
would like to merge them, but it does break API compatibility.
However, the changes required to update projects based on the API is
fairly easy.  The changes are in this pull request:

https://github.com/csound/csound/pull/352

What the proposed changes do are:

1. Moves code related to adding built-in ValueCacheables to new
CsoundUI class.  This is, IMO, a smart change, making CsoundObj more
generic and moves the UI-specific code outside from CsoundObj.  (see
code in https://github.com/aure/csound/commit/d09e00a5fde19849d511e6f6cd5a1fadfedebb4c)

2. Moves sensor specific code from CsoundObj into CsoundMotion.  Same
comments as for #1.

3. Introduces a corresponding CsoundObj API for OSX. (see code in
https://github.com/aure/csound/commit/bc805ee2905c88b82829c15833f23012c5f01c6f).
The payoff here is that one could theoretically reuse a lot of the
same code when building both an iOS and OSX desktop application.  (I
think this is fantastic!)

What I think should happen:

1. I think the direction this is going makes a lot of sense to me. I
think we should move forward with this.

2. We should update the Android API to introduce a CsoundUI and
CsoundMotion classes to keep the API's parallel.

3. We should look at adding a CsoundUI and CsoundMotion classes to the
Web (Emscripten, PNaCl) versions of Csound.

4. We might consider making similar API's for the Desktop.  These
would be of course custom to each GUI toolkit, something we could
include in the csound release.  User could then include some source
files for use in their projects.  (I can imagine Juce, QT, and Java
versions happening first, then adding things like a Tk version for
Python, etc.)


As this change breaks API compatibility, it'd be great to hear from
Csound-based application developers what they think.

Thanks!
steven

Hi Michael,

Thanks for the quick reply!  Could you explain what you mean by "value
semantics value cacheable"?

As for SWIG, I think there are limits to what we can auto-generate and
what we need to do manually.  Things like UI and Motion are definitely
platform specific.  CsoundObj itself is borderline too, as it sets
itself up for audio for the local platform.  The audio stuff could
perhaps be abstracted out into a platform-specific custom class, and
we could have a CsoundObjBase that does everything but the
platform-specific things.  We could then maybe add CsoundObjBase and
ValueCacheable to the C++ API for wrapping, then having the rest be
custom code. Does that sound right to you?

Thanks!
steven

On Mon, Jul 14, 2014 at 8:13 AM, Michael Gogins
 wrote:
> I think these changes are good, they are similar to what I was proposing.
> Aure's CsoundUI and CsoundMotion APIs are similar to my csoundApp obj in
> Android now.
>
> There should be a value semantics value cacheable object that works out of
> the box for developers who can't or don't want to derive from the abstract
> interface.
>
> In moving to a unified API across platforms, there should be a set of
> interfaces that define the API in C or C++ that can either be used to
> automatically generate wrappers, or used as a guide to manually define
> interfaces.
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Jul 14, 2014 at 7:57 AM, Steven Yi  wrote:
>>
>> Hi All,
>>
>> I'm writing in regards to some proposed changes to the CsoundObj API
>> that are being worked on by Aure.  I think the changes are good and
>> would like to merge them, but it does break API compatibility.
>> However, the changes required to update projects based on the API is
>> fairly easy.  The changes are in this pull request:
>>
>> https://github.com/csound/csound/pull/352
>>
>> What the proposed changes do are:
>>
>> 1. Moves code related to adding built-in ValueCacheables to new
>> CsoundUI class.  This is, IMO, a smart change, making CsoundObj more
>> generic and moves the UI-specific code outside from CsoundObj.  (see
>> code in
>> https://github.com/aure/csound/commit/d09e00a5fde19849d511e6f6cd5a1fadfedebb4c)
>>
>> 2. Moves sensor specific code from CsoundObj into CsoundMotion.  Same
>> comments as for #1.
>>
>> 3. Introduces a corresponding CsoundObj API for OSX. (see code in
>>
>> https://github.com/aure/csound/commit/bc805ee2905c88b82829c15833f23012c5f01c6f).
>> The payoff here is that one could theoretically reuse a lot of the
>> same code when building both an iOS and OSX desktop application.  (I
>> think this is fantastic!)
>>
>> What I think should happen:
>>
>> 1. I think the direction this is going makes a lot of sense to me. I
>> think we should move forward with this.
>>
>> 2. We should update the Android API to introduce a CsoundUI and
>> CsoundMotion classes to keep the API's parallel.
>>
>> 3. We should look at adding a CsoundUI and CsoundMotion classes to the
>> Web (Emscripten, PNaCl) versions of Csound.
>>
>> 4. We might consider making similar API's for the Desktop.  These
>> would be of course custom to each GUI toolkit, something we could
>> include in the csound release.  User could then include some source
>> files for use in their projects.  (I can imagine Juce, QT, and Java
>> versions happening first, then adding things like a Tk version for
>> Python, etc.)
>>
>>
>> As this change breaks API compatibility, it'd be great to hear from
>> Csound-based application developers what they think.
>>
>> Thanks!
>> steven
>>
>>
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>>
>

Hi Dan,

One thing that could be done towards this is breaking out CsoundObj to
have its own AudioUnit node by itself.  That way, CsoundObj could use
it, but it could also be used separately.

As per your code, or anyone who's added Audiobus, please post code
modifications to CsoundObj here for review or contribute back to
Csound in some way.

Thanks,
steven

On Mon, Jul 14, 2014 at 8:34 AM, Daniel Moore  wrote:
> These are nice!  Perhaps a change to CsoundObj.m to allow for
> Audiobus/Inter-App audio Integration?
> Changes I typically make to CsoundObj.m are wrapping csound in an AUGraph
> just to get rid of the while loop inside of runCsound:
>
> while(!mCsData.ret && mCsData.running)
>     NSThread sleepForTimeInterval:.001];
> }
>
> Am I the only one hacking it up like this?
>
> -Dan
>
>
>
> On Mon, Jul 14, 2014 at 8:13 AM, Michael Gogins 
> wrote:
>>
>> I think these changes are good, they are similar to what I was proposing.
>> Aure's CsoundUI and CsoundMotion APIs are similar to my csoundApp obj in
>> Android now.
>>
>> There should be a value semantics value cacheable object that works out of
>> the box for developers who can't or don't want to derive from the abstract
>> interface.
>>
>> In moving to a unified API across platforms, there should be a set of
>> interfaces that define the API in C or C++ that can either be used to
>> automatically generate wrappers, or used as a guide to manually define
>> interfaces.
>>
>> Regards,
>> Mike
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Mon, Jul 14, 2014 at 7:57 AM, Steven Yi  wrote:
>>>
>>> Hi All,
>>>
>>> I'm writing in regards to some proposed changes to the CsoundObj API
>>> that are being worked on by Aure.  I think the changes are good and
>>> would like to merge them, but it does break API compatibility.
>>> However, the changes required to update projects based on the API is
>>> fairly easy.  The changes are in this pull request:
>>>
>>> https://github.com/csound/csound/pull/352
>>>
>>> What the proposed changes do are:
>>>
>>> 1. Moves code related to adding built-in ValueCacheables to new
>>> CsoundUI class.  This is, IMO, a smart change, making CsoundObj more
>>> generic and moves the UI-specific code outside from CsoundObj.  (see
>>> code in
>>> https://github.com/aure/csound/commit/d09e00a5fde19849d511e6f6cd5a1fadfedebb4c)
>>>
>>> 2. Moves sensor specific code from CsoundObj into CsoundMotion.  Same
>>> comments as for #1.
>>>
>>> 3. Introduces a corresponding CsoundObj API for OSX. (see code in
>>>
>>> https://github.com/aure/csound/commit/bc805ee2905c88b82829c15833f23012c5f01c6f).
>>> The payoff here is that one could theoretically reuse a lot of the
>>> same code when building both an iOS and OSX desktop application.  (I
>>> think this is fantastic!)
>>>
>>> What I think should happen:
>>>
>>> 1. I think the direction this is going makes a lot of sense to me. I
>>> think we should move forward with this.
>>>
>>> 2. We should update the Android API to introduce a CsoundUI and
>>> CsoundMotion classes to keep the API's parallel.
>>>
>>> 3. We should look at adding a CsoundUI and CsoundMotion classes to the
>>> Web (Emscripten, PNaCl) versions of Csound.
>>>
>>> 4. We might consider making similar API's for the Desktop.  These
>>> would be of course custom to each GUI toolkit, something we could
>>> include in the csound release.  User could then include some source
>>> files for use in their projects.  (I can imagine Juce, QT, and Java
>>> versions happening first, then adding things like a Tk version for
>>> Python, etc.)
>>>
>>>
>>> As this change breaks API compatibility, it'd be great to hear from
>>> Csound-based application developers what they think.
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>>
>>
>

Just an update to the CsoundObj changes: I've pulled in Aure's pull
request.  Many names have changed and/or been updated to follow Apple
coding guidelines.  Some exceptions were made so that things could be
more closely aligned between what is in the Csound SDK for iOS and
what is in Android (and other platforms).  Two things need to happen
now:

1. Android needs to be updated for updated methods names/classes
2. Csound FLOSS manual needs to be updated.

Thanks,
steven

On Wed, Jul 23, 2014 at 10:32 AM, Steven Yi  wrote:
> Hi Dan,
>
> One thing that could be done towards this is breaking out CsoundObj to
> have its own AudioUnit node by itself.  That way, CsoundObj could use
> it, but it could also be used separately.
>
> As per your code, or anyone who's added Audiobus, please post code
> modifications to CsoundObj here for review or contribute back to
> Csound in some way.
>
> Thanks,
> steven
>
> On Mon, Jul 14, 2014 at 8:34 AM, Daniel Moore  wrote:
>> These are nice!  Perhaps a change to CsoundObj.m to allow for
>> Audiobus/Inter-App audio Integration?
>> Changes I typically make to CsoundObj.m are wrapping csound in an AUGraph
>> just to get rid of the while loop inside of runCsound:
>>
>> while(!mCsData.ret && mCsData.running)
>>     NSThread sleepForTimeInterval:.001];
>> }
>>
>> Am I the only one hacking it up like this?
>>
>> -Dan
>>
>>
>>
>> On Mon, Jul 14, 2014 at 8:13 AM, Michael Gogins 
>> wrote:
>>>
>>> I think these changes are good, they are similar to what I was proposing.
>>> Aure's CsoundUI and CsoundMotion APIs are similar to my csoundApp obj in
>>> Android now.
>>>
>>> There should be a value semantics value cacheable object that works out of
>>> the box for developers who can't or don't want to derive from the abstract
>>> interface.
>>>
>>> In moving to a unified API across platforms, there should be a set of
>>> interfaces that define the API in C or C++ that can either be used to
>>> automatically generate wrappers, or used as a guide to manually define
>>> interfaces.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Mon, Jul 14, 2014 at 7:57 AM, Steven Yi  wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I'm writing in regards to some proposed changes to the CsoundObj API
>>>> that are being worked on by Aure.  I think the changes are good and
>>>> would like to merge them, but it does break API compatibility.
>>>> However, the changes required to update projects based on the API is
>>>> fairly easy.  The changes are in this pull request:
>>>>
>>>> https://github.com/csound/csound/pull/352
>>>>
>>>> What the proposed changes do are:
>>>>
>>>> 1. Moves code related to adding built-in ValueCacheables to new
>>>> CsoundUI class.  This is, IMO, a smart change, making CsoundObj more
>>>> generic and moves the UI-specific code outside from CsoundObj.  (see
>>>> code in
>>>> https://github.com/aure/csound/commit/d09e00a5fde19849d511e6f6cd5a1fadfedebb4c)
>>>>
>>>> 2. Moves sensor specific code from CsoundObj into CsoundMotion.  Same
>>>> comments as for #1.
>>>>
>>>> 3. Introduces a corresponding CsoundObj API for OSX. (see code in
>>>>
>>>> https://github.com/aure/csound/commit/bc805ee2905c88b82829c15833f23012c5f01c6f).
>>>> The payoff here is that one could theoretically reuse a lot of the
>>>> same code when building both an iOS and OSX desktop application.  (I
>>>> think this is fantastic!)
>>>>
>>>> What I think should happen:
>>>>
>>>> 1. I think the direction this is going makes a lot of sense to me. I
>>>> think we should move forward with this.
>>>>
>>>> 2. We should update the Android API to introduce a CsoundUI and
>>>> CsoundMotion classes to keep the API's parallel.
>>>>
>>>> 3. We should look at adding a CsoundUI and CsoundMotion classes to the
>>>> Web (Emscripten, PNaCl) versions of Csound.
>>>>
>>>> 4. We might consider making similar API's for the Desktop.  These
>>>> would be of course custom to each GUI toolkit, something we could
>>>> include in the csound release.  User could then include some source
>>>> files for use in their projects.  (I can imagine Juce, QT, and Java
>>>> versions happening first, then adding things like a Tk version for
>>>> Python, etc.)
>>>>
>>>>
>>>> As this change breaks API compatibility, it'd be great to hear from
>>>> Csound-based application developers what they think.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>>
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>>
>>>
>>