I see  the change related to multicast

    p->addr = lo_address_new(hh, pp);
    // MKG: Seems to have been dropped from liblo. But TTL 1 should be the default for multicast.
    // if (p->multicast) lo_address_set_ttl(p->addr, 1);
    p->lhost = csound->Strdup(csound, hh);
    p->cnt = 0;

Can I have more detail?  lo_address_set_ttl is defined in my version of
liblo (0:0:2)  and is used in tests.  Also in documentation and
declared in
lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);

What is the problem?

Could you share these changes?

On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins  wrote:
> I have resolved this. Steven's liblo build for Android was out of date so I
> updated it locally. Nothing for you to do here.
>
> Best,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Sun, Sep 4, 2016 at 9:58 AM, jpff  wrote:
>>
>> I see  the change related to multicast
>>
>>     p->addr = lo_address_new(hh, pp);
>>     // MKG: Seems to have been dropped from liblo. But TTL 1 should be the
>> default for multicast.
>>     // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>>     p->lhost = csound->Strdup(csound, hh);
>>     p->cnt = 0;
>>
>> Can I have more detail?  lo_address_set_ttl is defined in my version of
>> liblo (0:0:2)  and is used in tests.  Also in documentation and
>> declared in
>> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>>
>> What is the problem?
>> ==John ffitch
>

A pull request would be easiest, as I think I'd have to pay money to
add a user at this point to allow direct committing.  (Or, if you
want, make a fork and we can redirect all the scripts to pull the
source from your fork, which would be fine with me as well.)

For Android Studio, 2.1 look to be the latest stable release.  Could
the changes you are thinking of doing be done such that the existing
command-line driven builds will work?  Also, are you talking about
doing this for the entire Csound build or just plugins?

The one thing is that the current system is designed to generate the
binaries and package them into a module such that end users can use
the module without having NDK installed.  That seems like the
appropriate thing to me as I don't imagine end users would want to
have to NDK installed and to compile Csound themselves (and have to
potentially deal with any licensing issues that arise from that).

I would rather support just stable Android Studio releases, but I
understand the draw to use 2.2 here.  I suppose the big questions are
about how this might affect end users, if at all, who are downloading
and using the Csound for Android SDK.

On Sun, Sep 4, 2016 at 4:49 PM, Michael Gogins  wrote:
> Yes, of course. I can issue a pull request, or you can give me authorization
> to commit to your clone.
>
> Also, I would like to mention that I am planning to change the build for the
> Android stuff to require the latest Android Studio (2.2) which supposedly
> permits one to build native modules using Android Studio with either
> ndk-build or CMake. Also to debug them. Of course I will make sure it
> actually works. What do you think?
>
> Best,
> Mike
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Sun, Sep 4, 2016 at 2:57 PM, Steven Yi  wrote:
>>
>> Could you share these changes?
>>
>> On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins 
>> wrote:
>> > I have resolved this. Steven's liblo build for Android was out of date
>> > so I
>> > updated it locally. Nothing for you to do here.
>> >
>> > Best,
>> > Mike
>> >
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com
>> > Michael dot Gogins at gmail dot com
>> >
>> > On Sun, Sep 4, 2016 at 9:58 AM, jpff  wrote:
>> >>
>> >> I see  the change related to multicast
>> >>
>> >>     p->addr = lo_address_new(hh, pp);
>> >>     // MKG: Seems to have been dropped from liblo. But TTL 1 should be
>> >> the
>> >> default for multicast.
>> >>     // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>> >>     p->lhost = csound->Strdup(csound, hh);
>> >>     p->cnt = 0;
>> >>
>> >> Can I have more detail?  lo_address_set_ttl is defined in my version of
>> >> liblo (0:0:2)  and is used in tests.  Also in documentation and
>> >> declared in
>> >> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>> >>
>> >> What is the problem?
>> >> ==John ffitch
>> >
>> >
>

Can you tell me how a change might affect users of the csound library? This would confine to be a target of the build.

Best, Mike

I can not answer your question because I still don't understand what
exactly are you planning to change. So let's start over:

The current system has developers building the native components
(libcsound, plugin opcodeLibs).  That is done with shell scripts and
NDK tools. Once that is done, the binaries are packaged into the
CsoundAndroid module where the Java code for csnd6 is copied into and
the CsoundObj API classes are located. That module, as well as the
Csound Examples and Csound6 application modules, are all part of what
we release to the users.  All of the stuff that goes to the users is
an Android Studio project.

So, you propose to use Android Studio 2.2.  I assumed that meant
migrating the above Android Studio project (what we release to users)
to 2.2.  However, 2.2 is not a stable release for Android Studio at
this time.  So any change there would certainly impact users.

You also mention that it would "confined to a build target", but I
don't understand what that means.  Is the proposal to change from
using commandline NDK tools to Android Studio projects for building
the native components?

So, given the above, could you explain what your plans are and where
they fit in within the build/release process?  Everything up until the
CsoundAndroid module assembly has traditionally been done by
developers and not end users, but any changes to the Studio project we
release would affect end users.

On Sun, Sep 4, 2016 at 5:24 PM, Michael Gogins  wrote:
> Can you tell me how a change might affect users of the csound library? This
> would confine to be a target of the build.
>
> Best, Mike
>
>
> On Sep 4, 2016 5:19 PM, "Steven Yi"  wrote:
>>
>> A pull request would be easiest, as I think I'd have to pay money to
>> add a user at this point to allow direct committing.  (Or, if you
>> want, make a fork and we can redirect all the scripts to pull the
>> source from your fork, which would be fine with me as well.)
>>
>> For Android Studio, 2.1 look to be the latest stable release.  Could
>> the changes you are thinking of doing be done such that the existing
>> command-line driven builds will work?  Also, are you talking about
>> doing this for the entire Csound build or just plugins?
>>
>> The one thing is that the current system is designed to generate the
>> binaries and package them into a module such that end users can use
>> the module without having NDK installed.  That seems like the
>> appropriate thing to me as I don't imagine end users would want to
>> have to NDK installed and to compile Csound themselves (and have to
>> potentially deal with any licensing issues that arise from that).
>>
>> I would rather support just stable Android Studio releases, but I
>> understand the draw to use 2.2 here.  I suppose the big questions are
>> about how this might affect end users, if at all, who are downloading
>> and using the Csound for Android SDK.
>>
>> On Sun, Sep 4, 2016 at 4:49 PM, Michael Gogins 
>> wrote:
>> > Yes, of course. I can issue a pull request, or you can give me
>> > authorization
>> > to commit to your clone.
>> >
>> > Also, I would like to mention that I am planning to change the build for
>> > the
>> > Android stuff to require the latest Android Studio (2.2) which
>> > supposedly
>> > permits one to build native modules using Android Studio with either
>> > ndk-build or CMake. Also to debug them. Of course I will make sure it
>> > actually works. What do you think?
>> >
>> > Best,
>> > Mike
>> >
>> >
>> >
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com
>> > Michael dot Gogins at gmail dot com
>> >
>> > On Sun, Sep 4, 2016 at 2:57 PM, Steven Yi  wrote:
>> >>
>> >> Could you share these changes?
>> >>
>> >> On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins
>> >> 
>> >> wrote:
>> >> > I have resolved this. Steven's liblo build for Android was out of
>> >> > date
>> >> > so I
>> >> > updated it locally. Nothing for you to do here.
>> >> >
>> >> > Best,
>> >> > Mike
>> >> >
>> >> >
>> >> > -----------------------------------------------------
>> >> > Michael Gogins
>> >> > Irreducible Productions
>> >> > http://michaelgogins.tumblr.com
>> >> > Michael dot Gogins at gmail dot com
>> >> >
>> >> > On Sun, Sep 4, 2016 at 9:58 AM, jpff  wrote:
>> >> >>
>> >> >> I see  the change related to multicast
>> >> >>
>> >> >>     p->addr = lo_address_new(hh, pp);
>> >> >>     // MKG: Seems to have been dropped from liblo. But TTL 1 should
>> >> >> be
>> >> >> the
>> >> >> default for multicast.
>> >> >>     // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>> >> >>     p->lhost = csound->Strdup(csound, hh);
>> >> >>     p->cnt = 0;
>> >> >>
>> >> >> Can I have more detail?  lo_address_set_ttl is defined in my version
>> >> >> of
>> >> >> liblo (0:0:2)  and is used in tests.  Also in documentation and
>> >> >> declared in
>> >> >> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>> >> >>
>> >> >> What is the problem?
>> >> >> ==John ffitch
>> >> >
>> >> >
>> >

Now I understand the goal. 2.2 is on rc2 and is recommended by Android for new projects. The Gradle format is not backwards compatible, unfortunately. On the other hand most Android developers will switch soon.

Best,
Mike

So could you explain further, what are the changes you are planning,
and how does it relate to the developer build (you mentioned being
able to debug, which I assume means introducing android studio project
changes and modules for the native code?), and what users would be
expected to do?  (Will they need to upgrade to 2.2 with your changes?)

On Sun, Sep 4, 2016 at 6:04 PM, Michael Gogins  wrote:
> Now I understand the goal. 2.2 is on rc2 and is recommended by Android for
> new projects. The Gradle format is not backwards compatible, unfortunately.
> On the other hand most Android developers will switch soon.
>
> Best,
> Mike
>
>
> On Sep 4, 2016 5:49 PM, "Steven Yi"  wrote:
>>
>> I can not answer your question because I still don't understand what
>> exactly are you planning to change. So let's start over:
>>
>> The current system has developers building the native components
>> (libcsound, plugin opcodeLibs).  That is done with shell scripts and
>> NDK tools. Once that is done, the binaries are packaged into the
>> CsoundAndroid module where the Java code for csnd6 is copied into and
>> the CsoundObj API classes are located. That module, as well as the
>> Csound Examples and Csound6 application modules, are all part of what
>> we release to the users.  All of the stuff that goes to the users is
>> an Android Studio project.
>>
>> So, you propose to use Android Studio 2.2.  I assumed that meant
>> migrating the above Android Studio project (what we release to users)
>> to 2.2.  However, 2.2 is not a stable release for Android Studio at
>> this time.  So any change there would certainly impact users.
>>
>> You also mention that it would "confined to a build target", but I
>> don't understand what that means.  Is the proposal to change from
>> using commandline NDK tools to Android Studio projects for building
>> the native components?
>>
>> So, given the above, could you explain what your plans are and where
>> they fit in within the build/release process?  Everything up until the
>> CsoundAndroid module assembly has traditionally been done by
>> developers and not end users, but any changes to the Studio project we
>> release would affect end users.
>>
>> On Sun, Sep 4, 2016 at 5:24 PM, Michael Gogins 
>> wrote:
>> > Can you tell me how a change might affect users of the csound library?
>> > This
>> > would confine to be a target of the build.
>> >
>> > Best, Mike
>> >
>> >
>> > On Sep 4, 2016 5:19 PM, "Steven Yi"  wrote:
>> >>
>> >> A pull request would be easiest, as I think I'd have to pay money to
>> >> add a user at this point to allow direct committing.  (Or, if you
>> >> want, make a fork and we can redirect all the scripts to pull the
>> >> source from your fork, which would be fine with me as well.)
>> >>
>> >> For Android Studio, 2.1 look to be the latest stable release.  Could
>> >> the changes you are thinking of doing be done such that the existing
>> >> command-line driven builds will work?  Also, are you talking about
>> >> doing this for the entire Csound build or just plugins?
>> >>
>> >> The one thing is that the current system is designed to generate the
>> >> binaries and package them into a module such that end users can use
>> >> the module without having NDK installed.  That seems like the
>> >> appropriate thing to me as I don't imagine end users would want to
>> >> have to NDK installed and to compile Csound themselves (and have to
>> >> potentially deal with any licensing issues that arise from that).
>> >>
>> >> I would rather support just stable Android Studio releases, but I
>> >> understand the draw to use 2.2 here.  I suppose the big questions are
>> >> about how this might affect end users, if at all, who are downloading
>> >> and using the Csound for Android SDK.
>> >>
>> >> On Sun, Sep 4, 2016 at 4:49 PM, Michael Gogins
>> >> 
>> >> wrote:
>> >> > Yes, of course. I can issue a pull request, or you can give me
>> >> > authorization
>> >> > to commit to your clone.
>> >> >
>> >> > Also, I would like to mention that I am planning to change the build
>> >> > for
>> >> > the
>> >> > Android stuff to require the latest Android Studio (2.2) which
>> >> > supposedly
>> >> > permits one to build native modules using Android Studio with either
>> >> > ndk-build or CMake. Also to debug them. Of course I will make sure it
>> >> > actually works. What do you think?
>> >> >
>> >> > Best,
>> >> > Mike
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > -----------------------------------------------------
>> >> > Michael Gogins
>> >> > Irreducible Productions
>> >> > http://michaelgogins.tumblr.com
>> >> > Michael dot Gogins at gmail dot com
>> >> >
>> >> > On Sun, Sep 4, 2016 at 2:57 PM, Steven Yi  wrote:
>> >> >>
>> >> >> Could you share these changes?
>> >> >>
>> >> >> On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins
>> >> >> 
>> >> >> wrote:
>> >> >> > I have resolved this. Steven's liblo build for Android was out of
>> >> >> > date
>> >> >> > so I
>> >> >> > updated it locally. Nothing for you to do here.
>> >> >> >
>> >> >> > Best,
>> >> >> > Mike
>> >> >> >
>> >> >> >
>> >> >> > -----------------------------------------------------
>> >> >> > Michael Gogins
>> >> >> > Irreducible Productions
>> >> >> > http://michaelgogins.tumblr.com
>> >> >> > Michael dot Gogins at gmail dot com
>> >> >> >
>> >> >> > On Sun, Sep 4, 2016 at 9:58 AM, jpff  wrote:
>> >> >> >>
>> >> >> >> I see  the change related to multicast
>> >> >> >>
>> >> >> >>     p->addr = lo_address_new(hh, pp);
>> >> >> >>     // MKG: Seems to have been dropped from liblo. But TTL 1
>> >> >> >> should
>> >> >> >> be
>> >> >> >> the
>> >> >> >> default for multicast.
>> >> >> >>     // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>> >> >> >>     p->lhost = csound->Strdup(csound, hh);
>> >> >> >>     p->cnt = 0;
>> >> >> >>
>> >> >> >> Can I have more detail?  lo_address_set_ttl is defined in my
>> >> >> >> version
>> >> >> >> of
>> >> >> >> liblo (0:0:2)  and is used in tests.  Also in documentation and
>> >> >> >> declared in
>> >> >> >> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>> >> >> >>
>> >> >> >> What is the problem?
>> >> >> >> ==John ffitch
>> >> >> >
>> >> >> >
>> >> >

They would have to upgrade. My motive was just to simplify building the app, I wasn't aware that the lib was delivered as a project.  But I think it would simplify that too if users upgraded.

Best,
Mike

I will look at what you are delivering to understand that target better.

Best,
Mike

The scripts are update-android-studio.sh and
release-android-studio.sh.  They're executed after running
build-all.sh.

I think you should poll the Csound users' list if your change is going
to require users to upgrade Android Studio.

On Sun, Sep 4, 2016 at 7:26 PM, Michael Gogins  wrote:
> Which script do you run to package up the Android SDK?
>
> Best,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Sun, Sep 4, 2016 at 7:14 PM, Michael Gogins 
> wrote:
>>
>> I will look at what you are delivering to understand that target better.
>>
>> Best,
>> Mike
>>
>>
>> On Sep 4, 2016 7:11 PM, "Michael Gogins"  wrote:
>>>
>>> They would have to upgrade. My motive was just to simplify building the
>>> app, I wasn't aware that the lib was delivered as a project.  But I think it
>>> would simplify that too if users upgraded.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> On Sep 4, 2016 6:28 PM, "Steven Yi"  wrote:
>>>>
>>>> So could you explain further, what are the changes you are planning,
>>>> and how does it relate to the developer build (you mentioned being
>>>> able to debug, which I assume means introducing android studio project
>>>> changes and modules for the native code?), and what users would be
>>>> expected to do?  (Will they need to upgrade to 2.2 with your changes?)
>>>>
>>>> On Sun, Sep 4, 2016 at 6:04 PM, Michael Gogins
>>>>  wrote:
>>>> > Now I understand the goal. 2.2 is on rc2 and is recommended by Android
>>>> > for
>>>> > new projects. The Gradle format is not backwards compatible,
>>>> > unfortunately.
>>>> > On the other hand most Android developers will switch soon.
>>>> >
>>>> > Best,
>>>> > Mike
>>>> >
>>>> >
>>>> > On Sep 4, 2016 5:49 PM, "Steven Yi"  wrote:
>>>> >>
>>>> >> I can not answer your question because I still don't understand what
>>>> >> exactly are you planning to change. So let's start over:
>>>> >>
>>>> >> The current system has developers building the native components
>>>> >> (libcsound, plugin opcodeLibs).  That is done with shell scripts and
>>>> >> NDK tools. Once that is done, the binaries are packaged into the
>>>> >> CsoundAndroid module where the Java code for csnd6 is copied into and
>>>> >> the CsoundObj API classes are located. That module, as well as the
>>>> >> Csound Examples and Csound6 application modules, are all part of what
>>>> >> we release to the users.  All of the stuff that goes to the users is
>>>> >> an Android Studio project.
>>>> >>
>>>> >> So, you propose to use Android Studio 2.2.  I assumed that meant
>>>> >> migrating the above Android Studio project (what we release to users)
>>>> >> to 2.2.  However, 2.2 is not a stable release for Android Studio at
>>>> >> this time.  So any change there would certainly impact users.
>>>> >>
>>>> >> You also mention that it would "confined to a build target", but I
>>>> >> don't understand what that means.  Is the proposal to change from
>>>> >> using commandline NDK tools to Android Studio projects for building
>>>> >> the native components?
>>>> >>
>>>> >> So, given the above, could you explain what your plans are and where
>>>> >> they fit in within the build/release process?  Everything up until
>>>> >> the
>>>> >> CsoundAndroid module assembly has traditionally been done by
>>>> >> developers and not end users, but any changes to the Studio project
>>>> >> we
>>>> >> release would affect end users.
>>>> >>
>>>> >> On Sun, Sep 4, 2016 at 5:24 PM, Michael Gogins
>>>> >> 
>>>> >> wrote:
>>>> >> > Can you tell me how a change might affect users of the csound
>>>> >> > library?
>>>> >> > This
>>>> >> > would confine to be a target of the build.
>>>> >> >
>>>> >> > Best, Mike
>>>> >> >
>>>> >> >
>>>> >> > On Sep 4, 2016 5:19 PM, "Steven Yi"  wrote:
>>>> >> >>
>>>> >> >> A pull request would be easiest, as I think I'd have to pay money
>>>> >> >> to
>>>> >> >> add a user at this point to allow direct committing.  (Or, if you
>>>> >> >> want, make a fork and we can redirect all the scripts to pull the
>>>> >> >> source from your fork, which would be fine with me as well.)
>>>> >> >>
>>>> >> >> For Android Studio, 2.1 look to be the latest stable release.
>>>> >> >> Could
>>>> >> >> the changes you are thinking of doing be done such that the
>>>> >> >> existing
>>>> >> >> command-line driven builds will work?  Also, are you talking about
>>>> >> >> doing this for the entire Csound build or just plugins?
>>>> >> >>
>>>> >> >> The one thing is that the current system is designed to generate
>>>> >> >> the
>>>> >> >> binaries and package them into a module such that end users can
>>>> >> >> use
>>>> >> >> the module without having NDK installed.  That seems like the
>>>> >> >> appropriate thing to me as I don't imagine end users would want to
>>>> >> >> have to NDK installed and to compile Csound themselves (and have
>>>> >> >> to
>>>> >> >> potentially deal with any licensing issues that arise from that).
>>>> >> >>
>>>> >> >> I would rather support just stable Android Studio releases, but I
>>>> >> >> understand the draw to use 2.2 here.  I suppose the big questions
>>>> >> >> are
>>>> >> >> about how this might affect end users, if at all, who are
>>>> >> >> downloading
>>>> >> >> and using the Csound for Android SDK.
>>>> >> >>
>>>> >> >> On Sun, Sep 4, 2016 at 4:49 PM, Michael Gogins
>>>> >> >> 
>>>> >> >> wrote:
>>>> >> >> > Yes, of course. I can issue a pull request, or you can give me
>>>> >> >> > authorization
>>>> >> >> > to commit to your clone.
>>>> >> >> >
>>>> >> >> > Also, I would like to mention that I am planning to change the
>>>> >> >> > build
>>>> >> >> > for
>>>> >> >> > the
>>>> >> >> > Android stuff to require the latest Android Studio (2.2) which
>>>> >> >> > supposedly
>>>> >> >> > permits one to build native modules using Android Studio with
>>>> >> >> > either
>>>> >> >> > ndk-build or CMake. Also to debug them. Of course I will make
>>>> >> >> > sure it
>>>> >> >> > actually works. What do you think?
>>>> >> >> >
>>>> >> >> > Best,
>>>> >> >> > Mike
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > -----------------------------------------------------
>>>> >> >> > Michael Gogins
>>>> >> >> > Irreducible Productions
>>>> >> >> > http://michaelgogins.tumblr.com
>>>> >> >> > Michael dot Gogins at gmail dot com
>>>> >> >> >
>>>> >> >> > On Sun, Sep 4, 2016 at 2:57 PM, Steven Yi 
>>>> >> >> > wrote:
>>>> >> >> >>
>>>> >> >> >> Could you share these changes?
>>>> >> >> >>
>>>> >> >> >> On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins
>>>> >> >> >> 
>>>> >> >> >> wrote:
>>>> >> >> >> > I have resolved this. Steven's liblo build for Android was
>>>> >> >> >> > out of
>>>> >> >> >> > date
>>>> >> >> >> > so I
>>>> >> >> >> > updated it locally. Nothing for you to do here.
>>>> >> >> >> >
>>>> >> >> >> > Best,
>>>> >> >> >> > Mike
>>>> >> >> >> >
>>>> >> >> >> >
>>>> >> >> >> > -----------------------------------------------------
>>>> >> >> >> > Michael Gogins
>>>> >> >> >> > Irreducible Productions
>>>> >> >> >> > http://michaelgogins.tumblr.com
>>>> >> >> >> > Michael dot Gogins at gmail dot com
>>>> >> >> >> >
>>>> >> >> >> > On Sun, Sep 4, 2016 at 9:58 AM, jpff 
>>>> >> >> >> > wrote:
>>>> >> >> >> >>
>>>> >> >> >> >> I see  the change related to multicast
>>>> >> >> >> >>
>>>> >> >> >> >>     p->addr = lo_address_new(hh, pp);
>>>> >> >> >> >>     // MKG: Seems to have been dropped from liblo. But TTL 1
>>>> >> >> >> >> should
>>>> >> >> >> >> be
>>>> >> >> >> >> the
>>>> >> >> >> >> default for multicast.
>>>> >> >> >> >>     // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>>>> >> >> >> >>     p->lhost = csound->Strdup(csound, hh);
>>>> >> >> >> >>     p->cnt = 0;
>>>> >> >> >> >>
>>>> >> >> >> >> Can I have more detail?  lo_address_set_ttl is defined in my
>>>> >> >> >> >> version
>>>> >> >> >> >> of
>>>> >> >> >> >> liblo (0:0:2)  and is used in tests.  Also in documentation
>>>> >> >> >> >> and
>>>> >> >> >> >> declared in
>>>> >> >> >> >> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>>>> >> >> >> >>
>>>> >> >> >> >> What is the problem?
>>>> >> >> >> >> ==John ffitch
>>>> >> >> >> >
>>>> >> >> >> >
>>>> >> >> >
>>>> >> >> >
>

Thanks!

I can confirm, that fixed the issue.

tarmo

On Sunday 04 September 2016 14:58:34 jpff wrote:
> I see  the change related to multicast
> 
>     p->addr = lo_address_new(hh, pp);
>     // MKG: Seems to have been dropped from liblo. But TTL 1 should be the
> default for multicast. // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>     p->lhost = csound->Strdup(csound, hh);
>     p->cnt = 0;
> 
> Can I have more detail?  lo_address_set_ttl is defined in my version of
> liblo (0:0:2)  and is used in tests.  Also in documentation and
> declared in
> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
> 
> What is the problem?

Yes, I think you should have inquired earlier as I think you
misunderstand the purpose behind the folder structure as it was. While
I'm sure well-intentioned, the result has been that a lot of my work
has been simply deleted and the design of the Csound for Android SDK
has been compromised.

Some things were duplicates, but other things most certainly were done
intentionally. There were two folders, CsoundAndroidExamples and
CSDPlayer, which were in csound/android.  These were left there as
part of the Eclipse build and it was those that should be deleted if
anything. I have no problems with those being deleted now. (When I did
the transition to Android Studio, I left those so that developers
using the develop branch and still using Eclipse would not be
affected. There were requests at the time to make sure Eclipse still
worked so they remained.)

On the other hand, your proposed folder structure does not work as far
as I'm concerned.  The pre-existing structure (the one that you
deleted), did work.  The reasons are as I had mentioned in discussing
the build/release process.

1. The Csound for Android SDK was designed so that users do not have
to compile libcsound or any plugins themselves. They get the release,
add CsoundAndroid to their project, and start developing in Java. They
should not have to do any NDK builds themselves.

2. We had two CsoundAndroid folders, one in csound/android and another
in csound/android/CsoundForAndroid, which was on purpose.  The
top-level folder was for building libcsound using the NDK.  The built
artifacts were then copied into the second one as well as the
generated Java files.  The second one was what was delivered to the
user.  All of the NDK related stuff lived in the top-level version.
This kept it cleanly separated and was *not* a duplicate under the
design of the Csound for Android SDK.

3. The CsoundForAndroid tree wass what gets delivered to the end user
as the Csound for Android SDK.  We copied things into it so that it
could be released. However, we also copied into it so that developers
can build and work with the CsoundExamples and CsoundApplication
modules within the development tree as well. This made things easy to
track and the release scripts were designed around this. This also let
us open the project in Android Studio, make configuration changes, set
up properties, test the projects, etc. and it would reflect what the
end user would also receive.

4. Your proposed folder structure doesn't represent the Android Studio
project structure that included the CsoundAndroid, CsoundApplication,
and CsoundExamples modules.  The Android Studio project I setup had it
such that users could open up the project and build either of the
applications, as well as interrogate the module. They could also then
start their own application within the same project, or start one in a
separate project and import the CsoundAndroid module.  I discussed
what I came up with on the user's list when I did the work originally
and users at the time seemed to find the design worked and it was
approved.

5. If you make the Android Studio projects contain anything that
requires the NDK, you can not just zip up that directory tree, as
Studio would require the NDK when users tried to open those project.
(This also explains why the pluginLibs were kept outside of the
CsoundForAndroid folder tree.)

Anyways, I'm leaving on a trip tomorrow (Monday) and returning Sunday.
Because most of my own contributions are now broken and/or deleted, I
ended up spending a lot of time on this tonight explaining these
things and regret I did not spend the time otherwise. I will be
checking email intermittently while away, but, considering this has
been a frustrating evening, and since this upcoming week is meant to
be one with friends and family, I will likely not reply to this thread
until returning from the trip.

I'd ask that you please revert the relevant changes so that things
worked as previously, restoring the folder structure and the Android
Studio project structure that was previously developed.  From there,
please feel free to make further changes, but I'd ask that you
consider the design notes above, the release scripts, emails on the
user list, etc.  I don't claim that what I had put together was
perfect or couldn't be improved, but I also don't think they should
have been deleted without discussion either.

Also, after restoring the previous work, if you want to experiment
with bigger changes, I think it would be a good idea to create a
branch that you can push to Github for others to test and discuss.
Maybe if we collectively used branches more, a situation like the one
tonight might have been avoided altogether.






On Sun, Sep 4, 2016 at 8:48 PM, Michael Gogins  wrote:
> I do not think it is ever a good idea to have two copies of the same sources
> in the same repository, that is why I deleted the duplicates. I diff'd them
> and merged them first to make sure nothing was missing. I do wish I had
> talked to you first. I can put the ones that remain back where the ones I
> deleted used to be.
>
> It is not necessary to copy the generated files from one CsoundAndroid
> folder to another, I modified the gradle.settings file to remove the need
> for that.
>
> Let's assume that we are going to maintain a Csound Android SDK and a Csound
> for Android app based on that SDK without duplication of effort or sources
> or the need to manually run scripts to perform a complete build. What makes
> the most sense to you? What makes sense to me, in terms of how Android
> Studio and Gradle work, is to have the following tree that clearly and
> cleanly reflects the dependecies:
>
> csound
>   android
>     CsoundForAndroidApp
>     CsoundAndroidSDK
>       CSDPlayer
>       CsoundAndroidExamples
>       CsoundAndroid
>       pluginlibs
>
> If we do that, we can just zip up the CsoundAndroidSDK dir and project,
> minus object files and other unneeded files, for the SDK.
>
> Best,
> Mike
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Sun, Sep 4, 2016 at 7:26 PM, Michael Gogins 
> wrote:
>>
>> Which script do you run to package up the Android SDK?
>>
>> Best,
>> Mike
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>> On Sun, Sep 4, 2016 at 7:14 PM, Michael Gogins 
>> wrote:
>>>
>>> I will look at what you are delivering to understand that target better.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> On Sep 4, 2016 7:11 PM, "Michael Gogins" 
>>> wrote:
>>>>
>>>> They would have to upgrade. My motive was just to simplify building the
>>>> app, I wasn't aware that the lib was delivered as a project.  But I think it
>>>> would simplify that too if users upgraded.
>>>>
>>>> Best,
>>>> Mike
>>>>
>>>>
>>>> On Sep 4, 2016 6:28 PM, "Steven Yi"  wrote:
>>>>>
>>>>> So could you explain further, what are the changes you are planning,
>>>>> and how does it relate to the developer build (you mentioned being
>>>>> able to debug, which I assume means introducing android studio project
>>>>> changes and modules for the native code?), and what users would be
>>>>> expected to do?  (Will they need to upgrade to 2.2 with your changes?)
>>>>>
>>>>> On Sun, Sep 4, 2016 at 6:04 PM, Michael Gogins
>>>>>  wrote:
>>>>> > Now I understand the goal. 2.2 is on rc2 and is recommended by
>>>>> > Android for
>>>>> > new projects. The Gradle format is not backwards compatible,
>>>>> > unfortunately.
>>>>> > On the other hand most Android developers will switch soon.
>>>>> >
>>>>> > Best,
>>>>> > Mike
>>>>> >
>>>>> >
>>>>> > On Sep 4, 2016 5:49 PM, "Steven Yi"  wrote:
>>>>> >>
>>>>> >> I can not answer your question because I still don't understand what
>>>>> >> exactly are you planning to change. So let's start over:
>>>>> >>
>>>>> >> The current system has developers building the native components
>>>>> >> (libcsound, plugin opcodeLibs).  That is done with shell scripts and
>>>>> >> NDK tools. Once that is done, the binaries are packaged into the
>>>>> >> CsoundAndroid module where the Java code for csnd6 is copied into
>>>>> >> and
>>>>> >> the CsoundObj API classes are located. That module, as well as the
>>>>> >> Csound Examples and Csound6 application modules, are all part of
>>>>> >> what
>>>>> >> we release to the users.  All of the stuff that goes to the users is
>>>>> >> an Android Studio project.
>>>>> >>
>>>>> >> So, you propose to use Android Studio 2.2.  I assumed that meant
>>>>> >> migrating the above Android Studio project (what we release to
>>>>> >> users)
>>>>> >> to 2.2.  However, 2.2 is not a stable release for Android Studio at
>>>>> >> this time.  So any change there would certainly impact users.
>>>>> >>
>>>>> >> You also mention that it would "confined to a build target", but I
>>>>> >> don't understand what that means.  Is the proposal to change from
>>>>> >> using commandline NDK tools to Android Studio projects for building
>>>>> >> the native components?
>>>>> >>
>>>>> >> So, given the above, could you explain what your plans are and where
>>>>> >> they fit in within the build/release process?  Everything up until
>>>>> >> the
>>>>> >> CsoundAndroid module assembly has traditionally been done by
>>>>> >> developers and not end users, but any changes to the Studio project
>>>>> >> we
>>>>> >> release would affect end users.
>>>>> >>
>>>>> >> On Sun, Sep 4, 2016 at 5:24 PM, Michael Gogins
>>>>> >> 
>>>>> >> wrote:
>>>>> >> > Can you tell me how a change might affect users of the csound
>>>>> >> > library?
>>>>> >> > This
>>>>> >> > would confine to be a target of the build.
>>>>> >> >
>>>>> >> > Best, Mike
>>>>> >> >
>>>>> >> >
>>>>> >> > On Sep 4, 2016 5:19 PM, "Steven Yi"  wrote:
>>>>> >> >>
>>>>> >> >> A pull request would be easiest, as I think I'd have to pay money
>>>>> >> >> to
>>>>> >> >> add a user at this point to allow direct committing.  (Or, if you
>>>>> >> >> want, make a fork and we can redirect all the scripts to pull the
>>>>> >> >> source from your fork, which would be fine with me as well.)
>>>>> >> >>
>>>>> >> >> For Android Studio, 2.1 look to be the latest stable release.
>>>>> >> >> Could
>>>>> >> >> the changes you are thinking of doing be done such that the
>>>>> >> >> existing
>>>>> >> >> command-line driven builds will work?  Also, are you talking
>>>>> >> >> about
>>>>> >> >> doing this for the entire Csound build or just plugins?
>>>>> >> >>
>>>>> >> >> The one thing is that the current system is designed to generate
>>>>> >> >> the
>>>>> >> >> binaries and package them into a module such that end users can
>>>>> >> >> use
>>>>> >> >> the module without having NDK installed.  That seems like the
>>>>> >> >> appropriate thing to me as I don't imagine end users would want
>>>>> >> >> to
>>>>> >> >> have to NDK installed and to compile Csound themselves (and have
>>>>> >> >> to
>>>>> >> >> potentially deal with any licensing issues that arise from that).
>>>>> >> >>
>>>>> >> >> I would rather support just stable Android Studio releases, but I
>>>>> >> >> understand the draw to use 2.2 here.  I suppose the big questions
>>>>> >> >> are
>>>>> >> >> about how this might affect end users, if at all, who are
>>>>> >> >> downloading
>>>>> >> >> and using the Csound for Android SDK.
>>>>> >> >>
>>>>> >> >> On Sun, Sep 4, 2016 at 4:49 PM, Michael Gogins
>>>>> >> >> 
>>>>> >> >> wrote:
>>>>> >> >> > Yes, of course. I can issue a pull request, or you can give me
>>>>> >> >> > authorization
>>>>> >> >> > to commit to your clone.
>>>>> >> >> >
>>>>> >> >> > Also, I would like to mention that I am planning to change the
>>>>> >> >> > build
>>>>> >> >> > for
>>>>> >> >> > the
>>>>> >> >> > Android stuff to require the latest Android Studio (2.2) which
>>>>> >> >> > supposedly
>>>>> >> >> > permits one to build native modules using Android Studio with
>>>>> >> >> > either
>>>>> >> >> > ndk-build or CMake. Also to debug them. Of course I will make
>>>>> >> >> > sure it
>>>>> >> >> > actually works. What do you think?
>>>>> >> >> >
>>>>> >> >> > Best,
>>>>> >> >> > Mike
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > -----------------------------------------------------
>>>>> >> >> > Michael Gogins
>>>>> >> >> > Irreducible Productions
>>>>> >> >> > http://michaelgogins.tumblr.com
>>>>> >> >> > Michael dot Gogins at gmail dot com
>>>>> >> >> >
>>>>> >> >> > On Sun, Sep 4, 2016 at 2:57 PM, Steven Yi 
>>>>> >> >> > wrote:
>>>>> >> >> >>
>>>>> >> >> >> Could you share these changes?
>>>>> >> >> >>
>>>>> >> >> >> On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins
>>>>> >> >> >> 
>>>>> >> >> >> wrote:
>>>>> >> >> >> > I have resolved this. Steven's liblo build for Android was
>>>>> >> >> >> > out of
>>>>> >> >> >> > date
>>>>> >> >> >> > so I
>>>>> >> >> >> > updated it locally. Nothing for you to do here.
>>>>> >> >> >> >
>>>>> >> >> >> > Best,
>>>>> >> >> >> > Mike
>>>>> >> >> >> >
>>>>> >> >> >> >
>>>>> >> >> >> > -----------------------------------------------------
>>>>> >> >> >> > Michael Gogins
>>>>> >> >> >> > Irreducible Productions
>>>>> >> >> >> > http://michaelgogins.tumblr.com
>>>>> >> >> >> > Michael dot Gogins at gmail dot com
>>>>> >> >> >> >
>>>>> >> >> >> > On Sun, Sep 4, 2016 at 9:58 AM, jpff 
>>>>> >> >> >> > wrote:
>>>>> >> >> >> >>
>>>>> >> >> >> >> I see  the change related to multicast
>>>>> >> >> >> >>
>>>>> >> >> >> >>     p->addr = lo_address_new(hh, pp);
>>>>> >> >> >> >>     // MKG: Seems to have been dropped from liblo. But TTL
>>>>> >> >> >> >> 1
>>>>> >> >> >> >> should
>>>>> >> >> >> >> be
>>>>> >> >> >> >> the
>>>>> >> >> >> >> default for multicast.
>>>>> >> >> >> >>     // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>>>>> >> >> >> >>     p->lhost = csound->Strdup(csound, hh);
>>>>> >> >> >> >>     p->cnt = 0;
>>>>> >> >> >> >>
>>>>> >> >> >> >> Can I have more detail?  lo_address_set_ttl is defined in
>>>>> >> >> >> >> my
>>>>> >> >> >> >> version
>>>>> >> >> >> >> of
>>>>> >> >> >> >> liblo (0:0:2)  and is used in tests.  Also in documentation
>>>>> >> >> >> >> and
>>>>> >> >> >> >> declared in
>>>>> >> >> >> >> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>>>>> >> >> >> >>
>>>>> >> >> >> >> What is the problem?
>>>>> >> >> >> >> ==John ffitch
>>>>> >> >> >> >
>>>>> >> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>
>>

Please revert the changes as I have a research project that depends on them. I cannot afford to refactor the code to make it work with these changes. We're just about to deliver a report to the EU and can't be derailed now.

Why can't the changes be made into a branch? Then we can evaluate and merge if
everyone is happy.

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

> On 5 Sep 2016, at 04:19, Steven Yi  wrote:
> 
> Yes, I think you should have inquired earlier as I think you
> misunderstand the purpose behind the folder structure as it was. While
> I'm sure well-intentioned, the result has been that a lot of my work
> has been simply deleted and the design of the Csound for Android SDK
> has been compromised.
> 
> Some things were duplicates, but other things most certainly were done
> intentionally. There were two folders, CsoundAndroidExamples and
> CSDPlayer, which were in csound/android.  These were left there as
> part of the Eclipse build and it was those that should be deleted if
> anything. I have no problems with those being deleted now. (When I did
> the transition to Android Studio, I left those so that developers
> using the develop branch and still using Eclipse would not be
> affected. There were requests at the time to make sure Eclipse still
> worked so they remained.)
> 
> On the other hand, your proposed folder structure does not work as far
> as I'm concerned.  The pre-existing structure (the one that you
> deleted), did work.  The reasons are as I had mentioned in discussing
> the build/release process.
> 
> 1. The Csound for Android SDK was designed so that users do not have
> to compile libcsound or any plugins themselves. They get the release,
> add CsoundAndroid to their project, and start developing in Java. They
> should not have to do any NDK builds themselves.
> 
> 2. We had two CsoundAndroid folders, one in csound/android and another
> in csound/android/CsoundForAndroid, which was on purpose.  The
> top-level folder was for building libcsound using the NDK.  The built
> artifacts were then copied into the second one as well as the
> generated Java files.  The second one was what was delivered to the
> user.  All of the NDK related stuff lived in the top-level version.
> This kept it cleanly separated and was *not* a duplicate under the
> design of the Csound for Android SDK.
> 
> 3. The CsoundForAndroid tree wass what gets delivered to the end user
> as the Csound for Android SDK.  We copied things into it so that it
> could be released. However, we also copied into it so that developers
> can build and work with the CsoundExamples and CsoundApplication
> modules within the development tree as well. This made things easy to
> track and the release scripts were designed around this. This also let
> us open the project in Android Studio, make configuration changes, set
> up properties, test the projects, etc. and it would reflect what the
> end user would also receive.
> 
> 4. Your proposed folder structure doesn't represent the Android Studio
> project structure that included the CsoundAndroid, CsoundApplication,
> and CsoundExamples modules.  The Android Studio project I setup had it
> such that users could open up the project and build either of the
> applications, as well as interrogate the module. They could also then
> start their own application within the same project, or start one in a
> separate project and import the CsoundAndroid module.  I discussed
> what I came up with on the user's list when I did the work originally
> and users at the time seemed to find the design worked and it was
> approved.
> 
> 5. If you make the Android Studio projects contain anything that
> requires the NDK, you can not just zip up that directory tree, as
> Studio would require the NDK when users tried to open those project.
> (This also explains why the pluginLibs were kept outside of the
> CsoundForAndroid folder tree.)
> 
> Anyways, I'm leaving on a trip tomorrow (Monday) and returning Sunday.
> Because most of my own contributions are now broken and/or deleted, I
> ended up spending a lot of time on this tonight explaining these
> things and regret I did not spend the time otherwise. I will be
> checking email intermittently while away, but, considering this has
> been a frustrating evening, and since this upcoming week is meant to
> be one with friends and family, I will likely not reply to this thread
> until returning from the trip.
> 
> I'd ask that you please revert the relevant changes so that things
> worked as previously, restoring the folder structure and the Android
> Studio project structure that was previously developed.  From there,
> please feel free to make further changes, but I'd ask that you
> consider the design notes above, the release scripts, emails on the
> user list, etc.  I don't claim that what I had put together was
> perfect or couldn't be improved, but I also don't think they should
> have been deleted without discussion either.
> 
> Also, after restoring the previous work, if you want to experiment
> with bigger changes, I think it would be a good idea to create a
> branch that you can push to Github for others to test and discuss.
> Maybe if we collectively used branches more, a situation like the one
> tonight might have been avoided altogether.
> 
> 
> 
> 
> 
> 
>> On Sun, Sep 4, 2016 at 8:48 PM, Michael Gogins  wrote:
>> I do not think it is ever a good idea to have two copies of the same sources
>> in the same repository, that is why I deleted the duplicates. I diff'd them
>> and merged them first to make sure nothing was missing. I do wish I had
>> talked to you first. I can put the ones that remain back where the ones I
>> deleted used to be.
>> 
>> It is not necessary to copy the generated files from one CsoundAndroid
>> folder to another, I modified the gradle.settings file to remove the need
>> for that.
>> 
>> Let's assume that we are going to maintain a Csound Android SDK and a Csound
>> for Android app based on that SDK without duplication of effort or sources
>> or the need to manually run scripts to perform a complete build. What makes
>> the most sense to you? What makes sense to me, in terms of how Android
>> Studio and Gradle work, is to have the following tree that clearly and
>> cleanly reflects the dependecies:
>> 
>> csound
>>  android
>>    CsoundForAndroidApp
>>    CsoundAndroidSDK
>>      CSDPlayer
>>      CsoundAndroidExamples
>>      CsoundAndroid
>>      pluginlibs
>> 
>> If we do that, we can just zip up the CsoundAndroidSDK dir and project,
>> minus object files and other unneeded files, for the SDK.
>> 
>> Best,
>> Mike
>> 
>> 
>> 
>> 
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>> 
>> On Sun, Sep 4, 2016 at 7:26 PM, Michael Gogins 
>> wrote:
>>> 
>>> Which script do you run to package up the Android SDK?
>>> 
>>> Best,
>>> Mike
>>> 
>>> 
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>> 
>>> On Sun, Sep 4, 2016 at 7:14 PM, Michael Gogins 
>>> wrote:
>>>> 
>>>> I will look at what you are delivering to understand that target better.
>>>> 
>>>> Best,
>>>> Mike
>>>> 
>>>> 
>>>> On Sep 4, 2016 7:11 PM, "Michael Gogins" 
>>>> wrote:
>>>>> 
>>>>> They would have to upgrade. My motive was just to simplify building the
>>>>> app, I wasn't aware that the lib was delivered as a project.  But I think it
>>>>> would simplify that too if users upgraded.
>>>>> 
>>>>> Best,
>>>>> Mike
>>>>> 
>>>>> 
>>>>>> On Sep 4, 2016 6:28 PM, "Steven Yi"  wrote:
>>>>>> 
>>>>>> So could you explain further, what are the changes you are planning,
>>>>>> and how does it relate to the developer build (you mentioned being
>>>>>> able to debug, which I assume means introducing android studio project
>>>>>> changes and modules for the native code?), and what users would be
>>>>>> expected to do?  (Will they need to upgrade to 2.2 with your changes?)
>>>>>> 
>>>>>> On Sun, Sep 4, 2016 at 6:04 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> Now I understand the goal. 2.2 is on rc2 and is recommended by
>>>>>>> Android for
>>>>>>> new projects. The Gradle format is not backwards compatible,
>>>>>>> unfortunately.
>>>>>>> On the other hand most Android developers will switch soon.
>>>>>>> 
>>>>>>> Best,
>>>>>>> Mike
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sep 4, 2016 5:49 PM, "Steven Yi"  wrote:
>>>>>>>> 
>>>>>>>> I can not answer your question because I still don't understand what
>>>>>>>> exactly are you planning to change. So let's start over:
>>>>>>>> 
>>>>>>>> The current system has developers building the native components
>>>>>>>> (libcsound, plugin opcodeLibs).  That is done with shell scripts and
>>>>>>>> NDK tools. Once that is done, the binaries are packaged into the
>>>>>>>> CsoundAndroid module where the Java code for csnd6 is copied into
>>>>>>>> and
>>>>>>>> the CsoundObj API classes are located. That module, as well as the
>>>>>>>> Csound Examples and Csound6 application modules, are all part of
>>>>>>>> what
>>>>>>>> we release to the users.  All of the stuff that goes to the users is
>>>>>>>> an Android Studio project.
>>>>>>>> 
>>>>>>>> So, you propose to use Android Studio 2.2.  I assumed that meant
>>>>>>>> migrating the above Android Studio project (what we release to
>>>>>>>> users)
>>>>>>>> to 2.2.  However, 2.2 is not a stable release for Android Studio at
>>>>>>>> this time.  So any change there would certainly impact users.
>>>>>>>> 
>>>>>>>> You also mention that it would "confined to a build target", but I
>>>>>>>> don't understand what that means.  Is the proposal to change from
>>>>>>>> using commandline NDK tools to Android Studio projects for building
>>>>>>>> the native components?
>>>>>>>> 
>>>>>>>> So, given the above, could you explain what your plans are and where
>>>>>>>> they fit in within the build/release process?  Everything up until
>>>>>>>> the
>>>>>>>> CsoundAndroid module assembly has traditionally been done by
>>>>>>>> developers and not end users, but any changes to the Studio project
>>>>>>>> we
>>>>>>>> release would affect end users.
>>>>>>>> 
>>>>>>>> On Sun, Sep 4, 2016 at 5:24 PM, Michael Gogins
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>> Can you tell me how a change might affect users of the csound
>>>>>>>>> library?
>>>>>>>>> This
>>>>>>>>> would confine to be a target of the build.
>>>>>>>>> 
>>>>>>>>> Best, Mike
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Sep 4, 2016 5:19 PM, "Steven Yi"  wrote:
>>>>>>>>>> 
>>>>>>>>>> A pull request would be easiest, as I think I'd have to pay money
>>>>>>>>>> to
>>>>>>>>>> add a user at this point to allow direct committing.  (Or, if you
>>>>>>>>>> want, make a fork and we can redirect all the scripts to pull the
>>>>>>>>>> source from your fork, which would be fine with me as well.)
>>>>>>>>>> 
>>>>>>>>>> For Android Studio, 2.1 look to be the latest stable release.
>>>>>>>>>> Could
>>>>>>>>>> the changes you are thinking of doing be done such that the
>>>>>>>>>> existing
>>>>>>>>>> command-line driven builds will work?  Also, are you talking
>>>>>>>>>> about
>>>>>>>>>> doing this for the entire Csound build or just plugins?
>>>>>>>>>> 
>>>>>>>>>> The one thing is that the current system is designed to generate
>>>>>>>>>> the
>>>>>>>>>> binaries and package them into a module such that end users can
>>>>>>>>>> use
>>>>>>>>>> the module without having NDK installed.  That seems like the
>>>>>>>>>> appropriate thing to me as I don't imagine end users would want
>>>>>>>>>> to
>>>>>>>>>> have to NDK installed and to compile Csound themselves (and have
>>>>>>>>>> to
>>>>>>>>>> potentially deal with any licensing issues that arise from that).
>>>>>>>>>> 
>>>>>>>>>> I would rather support just stable Android Studio releases, but I
>>>>>>>>>> understand the draw to use 2.2 here.  I suppose the big questions
>>>>>>>>>> are
>>>>>>>>>> about how this might affect end users, if at all, who are
>>>>>>>>>> downloading
>>>>>>>>>> and using the Csound for Android SDK.
>>>>>>>>>> 
>>>>>>>>>> On Sun, Sep 4, 2016 at 4:49 PM, Michael Gogins
>>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>> Yes, of course. I can issue a pull request, or you can give me
>>>>>>>>>>> authorization
>>>>>>>>>>> to commit to your clone.
>>>>>>>>>>> 
>>>>>>>>>>> Also, I would like to mention that I am planning to change the
>>>>>>>>>>> build
>>>>>>>>>>> for
>>>>>>>>>>> the
>>>>>>>>>>> Android stuff to require the latest Android Studio (2.2) which
>>>>>>>>>>> supposedly
>>>>>>>>>>> permits one to build native modules using Android Studio with
>>>>>>>>>>> either
>>>>>>>>>>> ndk-build or CMake. Also to debug them. Of course I will make
>>>>>>>>>>> sure it
>>>>>>>>>>> actually works. What do you think?
>>>>>>>>>>> 
>>>>>>>>>>> Best,
>>>>>>>>>>> Mike
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>>> Michael Gogins
>>>>>>>>>>> Irreducible Productions
>>>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>>> 
>>>>>>>>>>> On Sun, Sep 4, 2016 at 2:57 PM, Steven Yi 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Could you share these changes?
>>>>>>>>>>>> 
>>>>>>>>>>>> On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins
>>>>>>>>>>>> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> I have resolved this. Steven's liblo build for Android was
>>>>>>>>>>>>> out of
>>>>>>>>>>>>> date
>>>>>>>>>>>>> so I
>>>>>>>>>>>>> updated it locally. Nothing for you to do here.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Mike
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>>>>> Michael Gogins
>>>>>>>>>>>>> Irreducible Productions
>>>>>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sun, Sep 4, 2016 at 9:58 AM, jpff 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I see  the change related to multicast
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>    p->addr = lo_address_new(hh, pp);
>>>>>>>>>>>>>>    // MKG: Seems to have been dropped from liblo. But TTL
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> default for multicast.
>>>>>>>>>>>>>>    // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>>>>>>>>>>>>>>    p->lhost = csound->Strdup(csound, hh);
>>>>>>>>>>>>>>    p->cnt = 0;
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Can I have more detail?  lo_address_set_ttl is defined in
>>>>>>>>>>>>>> my
>>>>>>>>>>>>>> version
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> liblo (0:0:2)  and is used in tests.  Also in documentation
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> declared in
>>>>>>>>>>>>>> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> What is the problem?
>>>>>>>>>>>>>> ==John ffitch

I will revert the changes today. I agree that a branch would have been a better idea. I apologize for not discussing before deleting.

However, I think it should be obvious that a project where you click on "Build" and it just happens would be much better. I will create a branch where that will happen with the existing directory structure for the SDK. This will use android studio 2.2 and do the ndk builds also.

Best,
Mike

I will revert the changes today. I agree that a branch would have been a better idea. I apologize for not discussing before deleting.

However, I think it should be obvious that a project where you click on "Build" and it just happens would be much better. I will create a branch where that will happen with the existing directory structure for the SDK. This will use android studio 2.2 and do the ndk builds also.

Best,
Mike

On Sep 5, 2016 1:38 AM, "Victor Lazzarini" <Victor.Lazzarini@nuim.ie> wrote:

Please revert the changes as I have a research project that depends on them. I cannot afford to refactor the code to make it work with these changes. We're just about to deliver a report to the EU and can't be derailed now.

Why can't the changes be made into a branch? Then we can evaluate and merge if
everyone is happy.

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

> On 5 Sep 2016, at 04:19, Steven Yi <stevenyi@GMAIL.COM> wrote:
>
> Yes, I think you should have inquired earlier as I think you
> misunderstand the purpose behind the folder structure as it was. While
> I'm sure well-intentioned, the result has been that a lot of my work
> has been simply deleted and the design of the Csound for Android SDK
> has been compromised.
>
> Some things were duplicates, but other things most certainly were done
> intentionally. There were two folders, CsoundAndroidExamples and
> CSDPlayer, which were in csound/android.  These were left there as
> part of the Eclipse build and it was those that should be deleted if
> anything. I have no problems with those being deleted now. (When I did
> the transition to Android Studio, I left those so that developers
> using the develop branch and still using Eclipse would not be
> affected. There were requests at the time to make sure Eclipse still
> worked so they remained.)
>
> On the other hand, your proposed folder structure does not work as far
> as I'm concerned.  The pre-existing structure (the one that you
> deleted), did work.  The reasons are as I had mentioned in discussing
> the build/release process.
>
> 1. The Csound for Android SDK was designed so that users do not have
> to compile libcsound or any plugins themselves. They get the release,
> add CsoundAndroid to their project, and start developing in Java. They
> should not have to do any NDK builds themselves.
>
> 2. We had two CsoundAndroid folders, one in csound/android and another
> in csound/android/CsoundForAndroid, which was on purpose.  The
> top-level folder was for building libcsound using the NDK.  The built
> artifacts were then copied into the second one as well as the
> generated Java files.  The second one was what was delivered to the
> user.  All of the NDK related stuff lived in the top-level version.
> This kept it cleanly separated and was *not* a duplicate under the
> design of the Csound for Android SDK.
>
> 3. The CsoundForAndroid tree wass what gets delivered to the end user
> as the Csound for Android SDK.  We copied things into it so that it
> could be released. However, we also copied into it so that developers
> can build and work with the CsoundExamples and CsoundApplication
> modules within the development tree as well. This made things easy to
> track and the release scripts were designed around this. This also let
> us open the project in Android Studio, make configuration changes, set
> up properties, test the projects, etc. and it would reflect what the
> end user would also receive.
>
> 4. Your proposed folder structure doesn't represent the Android Studio
> project structure that included the CsoundAndroid, CsoundApplication,
> and CsoundExamples modules.  The Android Studio project I setup had it
> such that users could open up the project and build either of the
> applications, as well as interrogate the module. They could also then
> start their own application within the same project, or start one in a
> separate project and import the CsoundAndroid module.  I discussed
> what I came up with on the user's list when I did the work originally
> and users at the time seemed to find the design worked and it was
> approved.
>
> 5. If you make the Android Studio projects contain anything that
> requires the NDK, you can not just zip up that directory tree, as
> Studio would require the NDK when users tried to open those project.
> (This also explains why the pluginLibs were kept outside of the
> CsoundForAndroid folder tree.)
>
> Anyways, I'm leaving on a trip tomorrow (Monday) and returning Sunday.
> Because most of my own contributions are now broken and/or deleted, I
> ended up spending a lot of time on this tonight explaining these
> things and regret I did not spend the time otherwise. I will be
> checking email intermittently while away, but, considering this has
> been a frustrating evening, and since this upcoming week is meant to
> be one with friends and family, I will likely not reply to this thread
> until returning from the trip.
>
> I'd ask that you please revert the relevant changes so that things
> worked as previously, restoring the folder structure and the Android
> Studio project structure that was previously developed.  From there,
> please feel free to make further changes, but I'd ask that you
> consider the design notes above, the release scripts, emails on the
> user list, etc.  I don't claim that what I had put together was
> perfect or couldn't be improved, but I also don't think they should
> have been deleted without discussion either.
>
> Also, after restoring the previous work, if you want to experiment
> with bigger changes, I think it would be a good idea to create a
> branch that you can push to Github for others to test and discuss.
> Maybe if we collectively used branches more, a situation like the one
> tonight might have been avoided altogether.
>
>
>
>
>
>
>> On Sun, Sep 4, 2016 at 8:48 PM, Michael Gogins <michael.gogins@gmail.com> wrote:
>> I do not think it is ever a good idea to have two copies of the same sources
>> in the same repository, that is why I deleted the duplicates. I diff'd them
>> and merged them first to make sure nothing was missing. I do wish I had
>> talked to you first. I can put the ones that remain back where the ones I
>> deleted used to be.
>>
>> It is not necessary to copy the generated files from one CsoundAndroid
>> folder to another, I modified the gradle.settings file to remove the need
>> for that.
>>
>> Let's assume that we are going to maintain a Csound Android SDK and a Csound
>> for Android app based on that SDK without duplication of effort or sources
>> or the need to manually run scripts to perform a complete build. What makes
>> the most sense to you? What makes sense to me, in terms of how Android
>> Studio and Gradle work, is to have the following tree that clearly and
>> cleanly reflects the dependecies:
>>
>> csound
>>  android
>>    CsoundForAndroidApp
>>    CsoundAndroidSDK
>>      CSDPlayer
>>      CsoundAndroidExamples
>>      CsoundAndroid
>>      pluginlibs
>>
>> If we do that, we can just zip up the CsoundAndroidSDK dir and project,
>> minus object files and other unneeded files, for the SDK.
>>
>> Best,
>> Mike
>>
>>
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>> On Sun, Sep 4, 2016 at 7:26 PM, Michael Gogins <michael.gogins@gmail.com>
>> wrote:
>>>
>>> Which script do you run to package up the Android SDK?
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> On Sun, Sep 4, 2016 at 7:14 PM, Michael Gogins <michael.gogins@gmail.com>
>>> wrote:
>>>>
>>>> I will look at what you are delivering to understand that target better.
>>>>
>>>> Best,
>>>> Mike
>>>>
>>>>
>>>> On Sep 4, 2016 7:11 PM, "Michael Gogins" <michael.gogins@gmail.com>
>>>> wrote:
>>>>>
>>>>> They would have to upgrade. My motive was just to simplify building the
>>>>> app, I wasn't aware that the lib was delivered as a project.  But I think it
>>>>> would simplify that too if users upgraded.
>>>>>
>>>>> Best,
>>>>> Mike
>>>>>
>>>>>
>>>>>> On Sep 4, 2016 6:28 PM, "Steven Yi" <stevenyi@gmail.com> wrote:
>>>>>>
>>>>>> So could you explain further, what are the changes you are planning,
>>>>>> and how does it relate to the developer build (you mentioned being
>>>>>> able to debug, which I assume means introducing android studio project
>>>>>> changes and modules for the native code?), and what users would be
>>>>>> expected to do?  (Will they need to upgrade to 2.2 with your changes?)
>>>>>>
>>>>>> On Sun, Sep 4, 2016 at 6:04 PM, Michael Gogins
>>>>>> <michael.gogins@gmail.com> wrote:
>>>>>>> Now I understand the goal. 2.2 is on rc2 and is recommended by
>>>>>>> Android for
>>>>>>> new projects. The Gradle format is not backwards compatible,
>>>>>>> unfortunately.
>>>>>>> On the other hand most Android developers will switch soon.
>>>>>>>
>>>>>>> Best,
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>> On Sep 4, 2016 5:49 PM, "Steven Yi" <stevenyi@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I can not answer your question because I still don't understand what
>>>>>>>> exactly are you planning to change. So let's start over:
>>>>>>>>
>>>>>>>> The current system has developers building the native components
>>>>>>>> (libcsound, plugin opcodeLibs).  That is done with shell scripts and
>>>>>>>> NDK tools. Once that is done, the binaries are packaged into the
>>>>>>>> CsoundAndroid module where the Java code for csnd6 is copied into
>>>>>>>> and
>>>>>>>> the CsoundObj API classes are located. That module, as well as the
>>>>>>>> Csound Examples and Csound6 application modules, are all part of
>>>>>>>> what
>>>>>>>> we release to the users.  All of the stuff that goes to the users is
>>>>>>>> an Android Studio project.
>>>>>>>>
>>>>>>>> So, you propose to use Android Studio 2.2.  I assumed that meant
>>>>>>>> migrating the above Android Studio project (what we release to
>>>>>>>> users)
>>>>>>>> to 2.2.  However, 2.2 is not a stable release for Android Studio at
>>>>>>>> this time.  So any change there would certainly impact users.
>>>>>>>>
>>>>>>>> You also mention that it would "confined to a build target", but I
>>>>>>>> don't understand what that means.  Is the proposal to change from
>>>>>>>> using commandline NDK tools to Android Studio projects for building
>>>>>>>> the native components?
>>>>>>>>
>>>>>>>> So, given the above, could you explain what your plans are and where
>>>>>>>> they fit in within the build/release process?  Everything up until
>>>>>>>> the
>>>>>>>> CsoundAndroid module assembly has traditionally been done by
>>>>>>>> developers and not end users, but any changes to the Studio project
>>>>>>>> we
>>>>>>>> release would affect end users.
>>>>>>>>
>>>>>>>> On Sun, Sep 4, 2016 at 5:24 PM, Michael Gogins
>>>>>>>> <michael.gogins@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Can you tell me how a change might affect users of the csound
>>>>>>>>> library?
>>>>>>>>> This
>>>>>>>>> would confine to be a target of the build.
>>>>>>>>>
>>>>>>>>> Best, Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Sep 4, 2016 5:19 PM, "Steven Yi" <stevenyi@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> A pull request would be easiest, as I think I'd have to pay money
>>>>>>>>>> to
>>>>>>>>>> add a user at this point to allow direct committing.  (Or, if you
>>>>>>>>>> want, make a fork and we can redirect all the scripts to pull the
>>>>>>>>>> source from your fork, which would be fine with me as well.)
>>>>>>>>>>
>>>>>>>>>> For Android Studio, 2.1 look to be the latest stable release.
>>>>>>>>>> Could
>>>>>>>>>> the changes you are thinking of doing be done such that the
>>>>>>>>>> existing
>>>>>>>>>> command-line driven builds will work?  Also, are you talking
>>>>>>>>>> about
>>>>>>>>>> doing this for the entire Csound build or just plugins?
>>>>>>>>>>
>>>>>>>>>> The one thing is that the current system is designed to generate
>>>>>>>>>> the
>>>>>>>>>> binaries and package them into a module such that end users can
>>>>>>>>>> use
>>>>>>>>>> the module without having NDK installed.  That seems like the
>>>>>>>>>> appropriate thing to me as I don't imagine end users would want
>>>>>>>>>> to
>>>>>>>>>> have to NDK installed and to compile Csound themselves (and have
>>>>>>>>>> to
>>>>>>>>>> potentially deal with any licensing issues that arise from that).
>>>>>>>>>>
>>>>>>>>>> I would rather support just stable Android Studio releases, but I
>>>>>>>>>> understand the draw to use 2.2 here.  I suppose the big questions
>>>>>>>>>> are
>>>>>>>>>> about how this might affect end users, if at all, who are
>>>>>>>>>> downloading
>>>>>>>>>> and using the Csound for Android SDK.
>>>>>>>>>>
>>>>>>>>>> On Sun, Sep 4, 2016 at 4:49 PM, Michael Gogins
>>>>>>>>>> <michael.gogins@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Yes, of course. I can issue a pull request, or you can give me
>>>>>>>>>>> authorization
>>>>>>>>>>> to commit to your clone.
>>>>>>>>>>>
>>>>>>>>>>> Also, I would like to mention that I am planning to change the
>>>>>>>>>>> build
>>>>>>>>>>> for
>>>>>>>>>>> the
>>>>>>>>>>> Android stuff to require the latest Android Studio (2.2) which
>>>>>>>>>>> supposedly
>>>>>>>>>>> permits one to build native modules using Android Studio with
>>>>>>>>>>> either
>>>>>>>>>>> ndk-build or CMake. Also to debug them. Of course I will make
>>>>>>>>>>> sure it
>>>>>>>>>>> actually works. What do you think?
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Mike
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>>> Michael Gogins
>>>>>>>>>>> Irreducible Productions
>>>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Sep 4, 2016 at 2:57 PM, Steven Yi <stevenyi@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Could you share these changes?
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins
>>>>>>>>>>>> <michael.gogins@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> I have resolved this. Steven's liblo build for Android was
>>>>>>>>>>>>> out of
>>>>>>>>>>>>> date
>>>>>>>>>>>>> so I
>>>>>>>>>>>>> updated it locally. Nothing for you to do here.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Mike
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>>>>> Michael Gogins
>>>>>>>>>>>>> Irreducible Productions
>>>>>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Sep 4, 2016 at 9:58 AM, jpff <jpff@codemist.co.uk>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I see  the change related to multicast
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    p->addr = lo_address_new(hh, pp);
>>>>>>>>>>>>>>    // MKG: Seems to have been dropped from liblo. But TTL
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> default for multicast.
>>>>>>>>>>>>>>    // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>>>>>>>>>>>>>>    p->lhost = csound->Strdup(csound, hh);
>>>>>>>>>>>>>>    p->cnt = 0;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can I have more detail?  lo_address_set_ttl is defined in
>>>>>>>>>>>>>> my
>>>>>>>>>>>>>> version
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> liblo (0:0:2)  and is used in tests.  Also in documentation
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> declared in
>>>>>>>>>>>>>> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is the problem?
>>>>>>>>>>>>>> ==John ffitch
>>

Thank Michael.  If you can make changes that simplifies development
but maintains that users don't have to get the NDK involved, then I'm
all for it.

On Mon, Sep 5, 2016 at 8:14 AM, Michael Gogins  wrote:
> I will revert the changes today. I agree that a branch would have been a
> better idea. I apologize for not discussing before deleting.
>
> However, I think it should be obvious that a project where you click on
> "Build" and it just happens would be much better. I will create a branch
> where that will happen with the existing directory structure for the SDK.
> This will use android studio 2.2 and do the ndk builds also.
>
> Best,
> Mike
>
>
> On Sep 5, 2016 1:38 AM, "Victor Lazzarini"  wrote:
>>
>> Please revert the changes as I have a research project that depends on
>> them. I cannot afford to refactor the code to make it work with these
>> changes. We're just about to deliver a report to the EU and can't be
>> derailed now.
>>
>> Why can't the changes be made into a branch? Then we can evaluate and
>> merge if
>> everyone is happy.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> > On 5 Sep 2016, at 04:19, Steven Yi  wrote:
>> >
>> > Yes, I think you should have inquired earlier as I think you
>> > misunderstand the purpose behind the folder structure as it was. While
>> > I'm sure well-intentioned, the result has been that a lot of my work
>> > has been simply deleted and the design of the Csound for Android SDK
>> > has been compromised.
>> >
>> > Some things were duplicates, but other things most certainly were done
>> > intentionally. There were two folders, CsoundAndroidExamples and
>> > CSDPlayer, which were in csound/android.  These were left there as
>> > part of the Eclipse build and it was those that should be deleted if
>> > anything. I have no problems with those being deleted now. (When I did
>> > the transition to Android Studio, I left those so that developers
>> > using the develop branch and still using Eclipse would not be
>> > affected. There were requests at the time to make sure Eclipse still
>> > worked so they remained.)
>> >
>> > On the other hand, your proposed folder structure does not work as far
>> > as I'm concerned.  The pre-existing structure (the one that you
>> > deleted), did work.  The reasons are as I had mentioned in discussing
>> > the build/release process.
>> >
>> > 1. The Csound for Android SDK was designed so that users do not have
>> > to compile libcsound or any plugins themselves. They get the release,
>> > add CsoundAndroid to their project, and start developing in Java. They
>> > should not have to do any NDK builds themselves.
>> >
>> > 2. We had two CsoundAndroid folders, one in csound/android and another
>> > in csound/android/CsoundForAndroid, which was on purpose.  The
>> > top-level folder was for building libcsound using the NDK.  The built
>> > artifacts were then copied into the second one as well as the
>> > generated Java files.  The second one was what was delivered to the
>> > user.  All of the NDK related stuff lived in the top-level version.
>> > This kept it cleanly separated and was *not* a duplicate under the
>> > design of the Csound for Android SDK.
>> >
>> > 3. The CsoundForAndroid tree wass what gets delivered to the end user
>> > as the Csound for Android SDK.  We copied things into it so that it
>> > could be released. However, we also copied into it so that developers
>> > can build and work with the CsoundExamples and CsoundApplication
>> > modules within the development tree as well. This made things easy to
>> > track and the release scripts were designed around this. This also let
>> > us open the project in Android Studio, make configuration changes, set
>> > up properties, test the projects, etc. and it would reflect what the
>> > end user would also receive.
>> >
>> > 4. Your proposed folder structure doesn't represent the Android Studio
>> > project structure that included the CsoundAndroid, CsoundApplication,
>> > and CsoundExamples modules.  The Android Studio project I setup had it
>> > such that users could open up the project and build either of the
>> > applications, as well as interrogate the module. They could also then
>> > start their own application within the same project, or start one in a
>> > separate project and import the CsoundAndroid module.  I discussed
>> > what I came up with on the user's list when I did the work originally
>> > and users at the time seemed to find the design worked and it was
>> > approved.
>> >
>> > 5. If you make the Android Studio projects contain anything that
>> > requires the NDK, you can not just zip up that directory tree, as
>> > Studio would require the NDK when users tried to open those project.
>> > (This also explains why the pluginLibs were kept outside of the
>> > CsoundForAndroid folder tree.)
>> >
>> > Anyways, I'm leaving on a trip tomorrow (Monday) and returning Sunday.
>> > Because most of my own contributions are now broken and/or deleted, I
>> > ended up spending a lot of time on this tonight explaining these
>> > things and regret I did not spend the time otherwise. I will be
>> > checking email intermittently while away, but, considering this has
>> > been a frustrating evening, and since this upcoming week is meant to
>> > be one with friends and family, I will likely not reply to this thread
>> > until returning from the trip.
>> >
>> > I'd ask that you please revert the relevant changes so that things
>> > worked as previously, restoring the folder structure and the Android
>> > Studio project structure that was previously developed.  From there,
>> > please feel free to make further changes, but I'd ask that you
>> > consider the design notes above, the release scripts, emails on the
>> > user list, etc.  I don't claim that what I had put together was
>> > perfect or couldn't be improved, but I also don't think they should
>> > have been deleted without discussion either.
>> >
>> > Also, after restoring the previous work, if you want to experiment
>> > with bigger changes, I think it would be a good idea to create a
>> > branch that you can push to Github for others to test and discuss.
>> > Maybe if we collectively used branches more, a situation like the one
>> > tonight might have been avoided altogether.
>> >
>> >
>> >
>> >
>> >
>> >
>> >> On Sun, Sep 4, 2016 at 8:48 PM, Michael Gogins
>> >>  wrote:
>> >> I do not think it is ever a good idea to have two copies of the same
>> >> sources
>> >> in the same repository, that is why I deleted the duplicates. I diff'd
>> >> them
>> >> and merged them first to make sure nothing was missing. I do wish I had
>> >> talked to you first. I can put the ones that remain back where the ones
>> >> I
>> >> deleted used to be.
>> >>
>> >> It is not necessary to copy the generated files from one CsoundAndroid
>> >> folder to another, I modified the gradle.settings file to remove the
>> >> need
>> >> for that.
>> >>
>> >> Let's assume that we are going to maintain a Csound Android SDK and a
>> >> Csound
>> >> for Android app based on that SDK without duplication of effort or
>> >> sources
>> >> or the need to manually run scripts to perform a complete build. What
>> >> makes
>> >> the most sense to you? What makes sense to me, in terms of how Android
>> >> Studio and Gradle work, is to have the following tree that clearly and
>> >> cleanly reflects the dependecies:
>> >>
>> >> csound
>> >>  android
>> >>    CsoundForAndroidApp
>> >>    CsoundAndroidSDK
>> >>      CSDPlayer
>> >>      CsoundAndroidExamples
>> >>      CsoundAndroid
>> >>      pluginlibs
>> >>
>> >> If we do that, we can just zip up the CsoundAndroidSDK dir and project,
>> >> minus object files and other unneeded files, for the SDK.
>> >>
>> >> Best,
>> >> Mike
>> >>
>> >>
>> >>
>> >>
>> >> -----------------------------------------------------
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://michaelgogins.tumblr.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >> On Sun, Sep 4, 2016 at 7:26 PM, Michael Gogins
>> >> 
>> >> wrote:
>> >>>
>> >>> Which script do you run to package up the Android SDK?
>> >>>
>> >>> Best,
>> >>> Mike
>> >>>
>> >>>
>> >>> -----------------------------------------------------
>> >>> Michael Gogins
>> >>> Irreducible Productions
>> >>> http://michaelgogins.tumblr.com
>> >>> Michael dot Gogins at gmail dot com
>> >>>
>> >>> On Sun, Sep 4, 2016 at 7:14 PM, Michael Gogins
>> >>> 
>> >>> wrote:
>> >>>>
>> >>>> I will look at what you are delivering to understand that target
>> >>>> better.
>> >>>>
>> >>>> Best,
>> >>>> Mike
>> >>>>
>> >>>>
>> >>>> On Sep 4, 2016 7:11 PM, "Michael Gogins" 
>> >>>> wrote:
>> >>>>>
>> >>>>> They would have to upgrade. My motive was just to simplify building
>> >>>>> the
>> >>>>> app, I wasn't aware that the lib was delivered as a project.  But I
>> >>>>> think it
>> >>>>> would simplify that too if users upgraded.
>> >>>>>
>> >>>>> Best,
>> >>>>> Mike
>> >>>>>
>> >>>>>
>> >>>>>> On Sep 4, 2016 6:28 PM, "Steven Yi"  wrote:
>> >>>>>>
>> >>>>>> So could you explain further, what are the changes you are
>> >>>>>> planning,
>> >>>>>> and how does it relate to the developer build (you mentioned being
>> >>>>>> able to debug, which I assume means introducing android studio
>> >>>>>> project
>> >>>>>> changes and modules for the native code?), and what users would be
>> >>>>>> expected to do?  (Will they need to upgrade to 2.2 with your
>> >>>>>> changes?)
>> >>>>>>
>> >>>>>> On Sun, Sep 4, 2016 at 6:04 PM, Michael Gogins
>> >>>>>>  wrote:
>> >>>>>>> Now I understand the goal. 2.2 is on rc2 and is recommended by
>> >>>>>>> Android for
>> >>>>>>> new projects. The Gradle format is not backwards compatible,
>> >>>>>>> unfortunately.
>> >>>>>>> On the other hand most Android developers will switch soon.
>> >>>>>>>
>> >>>>>>> Best,
>> >>>>>>> Mike
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On Sep 4, 2016 5:49 PM, "Steven Yi"  wrote:
>> >>>>>>>>
>> >>>>>>>> I can not answer your question because I still don't understand
>> >>>>>>>> what
>> >>>>>>>> exactly are you planning to change. So let's start over:
>> >>>>>>>>
>> >>>>>>>> The current system has developers building the native components
>> >>>>>>>> (libcsound, plugin opcodeLibs).  That is done with shell scripts
>> >>>>>>>> and
>> >>>>>>>> NDK tools. Once that is done, the binaries are packaged into the
>> >>>>>>>> CsoundAndroid module where the Java code for csnd6 is copied into
>> >>>>>>>> and
>> >>>>>>>> the CsoundObj API classes are located. That module, as well as
>> >>>>>>>> the
>> >>>>>>>> Csound Examples and Csound6 application modules, are all part of
>> >>>>>>>> what
>> >>>>>>>> we release to the users.  All of the stuff that goes to the users
>> >>>>>>>> is
>> >>>>>>>> an Android Studio project.
>> >>>>>>>>
>> >>>>>>>> So, you propose to use Android Studio 2.2.  I assumed that meant
>> >>>>>>>> migrating the above Android Studio project (what we release to
>> >>>>>>>> users)
>> >>>>>>>> to 2.2.  However, 2.2 is not a stable release for Android Studio
>> >>>>>>>> at
>> >>>>>>>> this time.  So any change there would certainly impact users.
>> >>>>>>>>
>> >>>>>>>> You also mention that it would "confined to a build target", but
>> >>>>>>>> I
>> >>>>>>>> don't understand what that means.  Is the proposal to change from
>> >>>>>>>> using commandline NDK tools to Android Studio projects for
>> >>>>>>>> building
>> >>>>>>>> the native components?
>> >>>>>>>>
>> >>>>>>>> So, given the above, could you explain what your plans are and
>> >>>>>>>> where
>> >>>>>>>> they fit in within the build/release process?  Everything up
>> >>>>>>>> until
>> >>>>>>>> the
>> >>>>>>>> CsoundAndroid module assembly has traditionally been done by
>> >>>>>>>> developers and not end users, but any changes to the Studio
>> >>>>>>>> project
>> >>>>>>>> we
>> >>>>>>>> release would affect end users.
>> >>>>>>>>
>> >>>>>>>> On Sun, Sep 4, 2016 at 5:24 PM, Michael Gogins
>> >>>>>>>> 
>> >>>>>>>> wrote:
>> >>>>>>>>> Can you tell me how a change might affect users of the csound
>> >>>>>>>>> library?
>> >>>>>>>>> This
>> >>>>>>>>> would confine to be a target of the build.
>> >>>>>>>>>
>> >>>>>>>>> Best, Mike
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> On Sep 4, 2016 5:19 PM, "Steven Yi"  wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> A pull request would be easiest, as I think I'd have to pay
>> >>>>>>>>>> money
>> >>>>>>>>>> to
>> >>>>>>>>>> add a user at this point to allow direct committing.  (Or, if
>> >>>>>>>>>> you
>> >>>>>>>>>> want, make a fork and we can redirect all the scripts to pull
>> >>>>>>>>>> the
>> >>>>>>>>>> source from your fork, which would be fine with me as well.)
>> >>>>>>>>>>
>> >>>>>>>>>> For Android Studio, 2.1 look to be the latest stable release.
>> >>>>>>>>>> Could
>> >>>>>>>>>> the changes you are thinking of doing be done such that the
>> >>>>>>>>>> existing
>> >>>>>>>>>> command-line driven builds will work?  Also, are you talking
>> >>>>>>>>>> about
>> >>>>>>>>>> doing this for the entire Csound build or just plugins?
>> >>>>>>>>>>
>> >>>>>>>>>> The one thing is that the current system is designed to
>> >>>>>>>>>> generate
>> >>>>>>>>>> the
>> >>>>>>>>>> binaries and package them into a module such that end users can
>> >>>>>>>>>> use
>> >>>>>>>>>> the module without having NDK installed.  That seems like the
>> >>>>>>>>>> appropriate thing to me as I don't imagine end users would want
>> >>>>>>>>>> to
>> >>>>>>>>>> have to NDK installed and to compile Csound themselves (and
>> >>>>>>>>>> have
>> >>>>>>>>>> to
>> >>>>>>>>>> potentially deal with any licensing issues that arise from
>> >>>>>>>>>> that).
>> >>>>>>>>>>
>> >>>>>>>>>> I would rather support just stable Android Studio releases, but
>> >>>>>>>>>> I
>> >>>>>>>>>> understand the draw to use 2.2 here.  I suppose the big
>> >>>>>>>>>> questions
>> >>>>>>>>>> are
>> >>>>>>>>>> about how this might affect end users, if at all, who are
>> >>>>>>>>>> downloading
>> >>>>>>>>>> and using the Csound for Android SDK.
>> >>>>>>>>>>
>> >>>>>>>>>> On Sun, Sep 4, 2016 at 4:49 PM, Michael Gogins
>> >>>>>>>>>> 
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>> Yes, of course. I can issue a pull request, or you can give me
>> >>>>>>>>>>> authorization
>> >>>>>>>>>>> to commit to your clone.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Also, I would like to mention that I am planning to change the
>> >>>>>>>>>>> build
>> >>>>>>>>>>> for
>> >>>>>>>>>>> the
>> >>>>>>>>>>> Android stuff to require the latest Android Studio (2.2) which
>> >>>>>>>>>>> supposedly
>> >>>>>>>>>>> permits one to build native modules using Android Studio with
>> >>>>>>>>>>> either
>> >>>>>>>>>>> ndk-build or CMake. Also to debug them. Of course I will make
>> >>>>>>>>>>> sure it
>> >>>>>>>>>>> actually works. What do you think?
>> >>>>>>>>>>>
>> >>>>>>>>>>> Best,
>> >>>>>>>>>>> Mike
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> -----------------------------------------------------
>> >>>>>>>>>>> Michael Gogins
>> >>>>>>>>>>> Irreducible Productions
>> >>>>>>>>>>> http://michaelgogins.tumblr.com
>> >>>>>>>>>>> Michael dot Gogins at gmail dot com
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Sun, Sep 4, 2016 at 2:57 PM, Steven Yi 
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Could you share these changes?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Sun, Sep 4, 2016 at 1:47 PM, Michael Gogins
>> >>>>>>>>>>>> 
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>> I have resolved this. Steven's liblo build for Android was
>> >>>>>>>>>>>>> out of
>> >>>>>>>>>>>>> date
>> >>>>>>>>>>>>> so I
>> >>>>>>>>>>>>> updated it locally. Nothing for you to do here.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Best,
>> >>>>>>>>>>>>> Mike
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> -----------------------------------------------------
>> >>>>>>>>>>>>> Michael Gogins
>> >>>>>>>>>>>>> Irreducible Productions
>> >>>>>>>>>>>>> http://michaelgogins.tumblr.com
>> >>>>>>>>>>>>> Michael dot Gogins at gmail dot com
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Sun, Sep 4, 2016 at 9:58 AM, jpff 
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I see  the change related to multicast
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>    p->addr = lo_address_new(hh, pp);
>> >>>>>>>>>>>>>>    // MKG: Seems to have been dropped from liblo. But TTL
>> >>>>>>>>>>>>>> 1
>> >>>>>>>>>>>>>> should
>> >>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>> default for multicast.
>> >>>>>>>>>>>>>>    // if (p->multicast) lo_address_set_ttl(p->addr, 1);
>> >>>>>>>>>>>>>>    p->lhost = csound->Strdup(csound, hh);
>> >>>>>>>>>>>>>>    p->cnt = 0;
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Can I have more detail?  lo_address_set_ttl is defined in
>> >>>>>>>>>>>>>> my
>> >>>>>>>>>>>>>> version
>> >>>>>>>>>>>>>> of
>> >>>>>>>>>>>>>> liblo (0:0:2)  and is used in tests.  Also in documentation
>> >>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>> declared in
>> >>>>>>>>>>>>>> lo/lo.h:void lo_address_set_ttl(lo_address t, int ttl);
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> What is the problem?
>> >>>>>>>>>>>>>> ==John ffitch

You should be able to fork the project I think.

I typically use my Mac for Android builds but that's at home. For my part I will test when I return (probably Monday).