Hi Michael,

I'm finding the build instructions confusing.  The way it was before was:

1. There is a CsoundAndroid project contained the prebuilt
libcsoundandroid.so.  This was setup as a library project, so that if
you started new Csound for Android based projects, all you had to do
was add CsoundAndroid as a library project to your new project, then
you'd have everything needed.

2. The libraries were set to build using dependencies found in a
folder called "android" that was placed in the same folder as the
csound6 src root.

3. The projects were set to build with platform 10 as a default.  This
is to get the widest coverage of Android devices.

Some things I'm seeing from the instructions and this email (note,
I've been busy apartment hunting and dealing with the mac osx
installer, so if I've misread something, please correct me!):

1. Your instructions mention building for ICS and up. I think the
defaults and instructions should mention and build for platform 11 and
up, to get Android 2.3.4+.  This is to support older android devices,
as Gingerbread still makes up 36.4% of the active device market
(according to http://developer.android.com/about/dashboards/index.html).

2. I question the use use of install_libs.sh automatically from
build.sh.  I'd rather just have the developer call it.  Really, I'd
rather there be an install_lib.sh in each opcode plugin project, so
you could do ./build.sh;./install_lib.sh.  The reason for this is that
to have install_lib.sh called during the normal build means there's a
dependency relationship between the core csound library and the
plugins, but that's not the relationship that makes sense.  Why not
put the install_libs.sh script a location higher, put it into the
CSDPlayer project?

Also, I question the design here of installing these opcodes into the
lib folder.  AFAIK, the lib folder is really used for native libs that
are used as JNI libs.  The opcode libraries really are only loaded by
native code by Csound.  They should, IMO, be installed elsewhere (as
mentioned in the email thread:
http://sourceforge.net/mailarchive/message.php?msg_id=30922820). Also,
we know loading of libraries works from any folder from the
exploratory work:

http://sourceforge.net/mailarchive/message.php?msg_id=29957081

with loading stdutil (I think the fluidopcodes stuff was worked out on
the user list).  The code from that link should probably be changed
to:

  csound.SetGlobalEnv("OPCODE6DIR", SOME_LOCATION_IN_PROJECT);



I think the critical thing we need to really figure out is: what is
the default mechanism we should use for loading opcode libraries? If
we figure this out, we can design the rest around it.

Thanks!
steven


On Wed, Jun 5, 2013 at 7:24 AM, Michael Gogins  wrote:
> I have added instructions for building on Android to the android directory.
>
> I have also added an install_libs.sh script for copying "local" libs, which
> the NDK uses for building the Android Csound 6 shared library, to the
> "installation" libs directories. These libraries are then automatically
> packed up by the CsoundAndroid and CSDPlayer projects, and end up in the
> CsoundApp.apk archive's libs directory.
>
> I do not know if this is sufficient for Csound to pick up plugin opcodes,
> but I will know pretty soon.
>
> I found this script much easier than the canonical approach, which I tried
> and failed to get to work.
>
> Currently the installed libs are signalflowgraph, luajit, stdutils, and
> fluidOpcodes.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Michael,

(Replies inline below)

On Wed, Jun 5, 2013 at 11:02 AM, Michael Gogins
 wrote:
> What in particular is confusing about the directions? Tell me and I will
> clarify them.

I don't understand having these as environment variables:

export CSOUND_SRC_ROOT=/c/Users/new/csound-csound6-git
export NDK_MODULE_PATH=${CSOUND_SRC_ROOT}/android/pluginlibs

This sort of hardcodes the src root, which can be determined from the
build directory (I think it previously was being determined with
relative paths).  This also sort of complicates having multiple builds
on a system.

Also, I find:

B U I L D   A N D   I N S T A L L   L U A J I T   M O D U L E

The spacing in the words makes it hard for me to read.  Could you
modify to something like:


LUAJIT MODULE
==============

and have extra line of space before it? I think the repetition of the
"Build and Install" for each section is noisy in the document.


The section "install source code for modules" is confusing. It says to
download from:

http://sourceforge.net/projects/csound/files/csound5/Android/csound-android-5.19.01.zip/download

I'm assuming this section refers to downloading things like libsndfile
and fluidsynth sources that were modified for Android? It'd be nice if
this section could be clarified for that.


For the organization, I think it'd make sense to break it up into sections for:

1. Toolchain Setup
2. Csound6 Main Build
3. Opcode Libraries
   a. FluidSynth
   b. libstdutil
   c. luajit
   d. etc.


> There were no build instructions before, at least not in the git repository
> that I could see. Naturally, I was confused myself, and things were not
> working, so I had to do something to get things to build.

Yes, this was an oversight and mistake to not have build instructions.
 Unfortunately, we did not have anyone else building from scratch to
alert us to the issue.  The only instructions we ever gave out was
when we released Csound for Android.

> The differences between the old way and the new way are:
>
> ALL native lib trees go into pluginlibs, no exceptions.

This breaks my build system with multiple android builds, but I can
live with it.

> ALL native lib builds are run manually from their tree/jni directory as
> $NDK/ndk-build. Except for the csoundandroid build, which uses ./build.sh

This is a good improvement.

> Now about what to do about your comments:
>
> I will move the platform back the original 10. The reason I moved the
> targeting forward is simply that I like the look and feel I'm getting with
> newer Android.

As long as platform 10 or 11 is used as the minimum, it's no problem
to build with newer android.  There are libraries that will help to
have a more modern theme but still work on older platforms (i.e. I
think the ActionBarSherlock library should help in this regard, but
I'm still exploring it).  Since we want to cover as many devices as
possible, I think it's just a necessity for the library itself to
support as many platforms as possible.

> I will make install_libs.sh a manual or optional step. But these libs do
> belong in the csoundandroid project, as they called by native Csound, not by
> an app. Putting them where they are guarantees they get installed in the
> archive. If there is another easy way to get them installed, I will change
> from libs to an opcode6dir somewhere. Could it be as simple as
> libs/archxx/opcode6dir?

I don't quite agree here that they belong with CsoundAndroid.  The use
case I'm imaging is that I may have multiple projects in my workspace
with different opcode libs required, but they may all use the same
CsoundAndroid library project.  In that case, one project might not
need fluidsynth, while another may, and there needs to be a way to
differentiate.

For the folder, from what Hector mentioned, it looks like we should
use the /assets folder within a project.  There's info here:

http://thedevelopersinfo.com/2009/11/17/using-assets-in-android/

We can use that to maybe lookup the opcode libs, then from their get
the parent path to set OPCODE6DIR to.


> I'm glad to hear that plugins do get loaded.
>
> What are the alternative mechanisms for loading opcode libraries on Android?

You should be able to use --opcode-lib=/path/to/.so.

> Finally, what do you think needs to be in CsoundApp to be considered a final
> release?

I haven't had a chance to do a test build here, so I can't say.  Is
there a built-in text editor now?  We just signed a lease today and am
in the middle of a lot of travels, so I'll try to do a build soon to
give better comments.

Thanks!
steven

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks Mike!  BTW: If I haven't said it before, I think these are all
really good things you're doing and that these changes are leading us
all in the right direction.  The confusions I have are just that, and
I think at the end of this we'll all be better off.  So thanks very
much!

On Wed, Jun 5, 2013 at 3:30 PM, Michael Gogins  wrote:
> Thanks for your comments.
>
> About CSOUND_SRC_ROOT, you are correct. I have already changed the
> Android.mk files to use relative paths, because I realized this myself. If
> there are any more to change I will take care of it.
>
> I will rewrite the build instructions to take your suggestions, which are
> good, into account.
>
> I will move back to platform 11.
>
> There is not a built-in text editor,  but text editing works by Intent with
> the freebie Jota text editor and perhaps with other text editors as well.
>
> I won't use --opcode-lib=/path/to/.so as I think this is too technical for
> most users, but I will research the best practice for dynamically loading
> libraries on Android and where to put them, then set OPCODE6DIR for that in
> code. This could be an overrideable app setting.
>
> Best,
> Mike
>
>
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
>
> Michael dot Gogins at gmail dot com
>
>
> On Wed, Jun 5, 2013 at 3:05 PM, Steven Yi  wrote:
>>
>> Hi Michael,
>>
>> (Replies inline below)
>>
>> On Wed, Jun 5, 2013 at 11:02 AM, Michael Gogins
>>  wrote:
>> > What in particular is confusing about the directions? Tell me and I will
>> > clarify them.
>>
>> I don't understand having these as environment variables:
>>
>> export CSOUND_SRC_ROOT=/c/Users/new/csound-csound6-git
>> export NDK_MODULE_PATH=${CSOUND_SRC_ROOT}/android/pluginlibs
>>
>> This sort of hardcodes the src root, which can be determined from the
>> build directory (I think it previously was being determined with
>> relative paths).  This also sort of complicates having multiple builds
>> on a system.
>>
>> Also, I find:
>>
>> B U I L D   A N D   I N S T A L L   L U A J I T   M O D U L E
>>
>> The spacing in the words makes it hard for me to read.  Could you
>> modify to something like:
>>
>>
>> LUAJIT MODULE
>> ==============
>>
>> and have extra line of space before it? I think the repetition of the
>> "Build and Install" for each section is noisy in the document.
>>
>>
>> The section "install source code for modules" is confusing. It says to
>> download from:
>>
>>
>> http://sourceforge.net/projects/csound/files/csound5/Android/csound-android-5.19.01.zip/download
>>
>> I'm assuming this section refers to downloading things like libsndfile
>> and fluidsynth sources that were modified for Android? It'd be nice if
>> this section could be clarified for that.
>>
>>
>> For the organization, I think it'd make sense to break it up into sections
>> for:
>>
>> 1. Toolchain Setup
>> 2. Csound6 Main Build
>> 3. Opcode Libraries
>>    a. FluidSynth
>>    b. libstdutil
>>    c. luajit
>>    d. etc.
>>
>>
>> > There were no build instructions before, at least not in the git
>> > repository
>> > that I could see. Naturally, I was confused myself, and things were not
>> > working, so I had to do something to get things to build.
>>
>> Yes, this was an oversight and mistake to not have build instructions.
>>  Unfortunately, we did not have anyone else building from scratch to
>> alert us to the issue.  The only instructions we ever gave out was
>> when we released Csound for Android.
>>
>> > The differences between the old way and the new way are:
>> >
>> > ALL native lib trees go into pluginlibs, no exceptions.
>>
>> This breaks my build system with multiple android builds, but I can
>> live with it.
>>
>> > ALL native lib builds are run manually from their tree/jni directory as
>> > $NDK/ndk-build. Except for the csoundandroid build, which uses
>> > ./build.sh
>>
>> This is a good improvement.
>>
>> > Now about what to do about your comments:
>> >
>> > I will move the platform back the original 10. The reason I moved the
>> > targeting forward is simply that I like the look and feel I'm getting
>> > with
>> > newer Android.
>>
>> As long as platform 10 or 11 is used as the minimum, it's no problem
>> to build with newer android.  There are libraries that will help to
>> have a more modern theme but still work on older platforms (i.e. I
>> think the ActionBarSherlock library should help in this regard, but
>> I'm still exploring it).  Since we want to cover as many devices as
>> possible, I think it's just a necessity for the library itself to
>> support as many platforms as possible.
>>
>> > I will make install_libs.sh a manual or optional step. But these libs do
>> > belong in the csoundandroid project, as they called by native Csound,
>> > not by
>> > an app. Putting them where they are guarantees they get installed in the
>> > archive. If there is another easy way to get them installed, I will
>> > change
>> > from libs to an opcode6dir somewhere. Could it be as simple as
>> > libs/archxx/opcode6dir?
>>
>> I don't quite agree here that they belong with CsoundAndroid.  The use
>> case I'm imaging is that I may have multiple projects in my workspace
>> with different opcode libs required, but they may all use the same
>> CsoundAndroid library project.  In that case, one project might not
>> need fluidsynth, while another may, and there needs to be a way to
>> differentiate.
>>
>> For the folder, from what Hector mentioned, it looks like we should
>> use the /assets folder within a project.  There's info here:
>>
>> http://thedevelopersinfo.com/2009/11/17/using-assets-in-android/
>>
>> We can use that to maybe lookup the opcode libs, then from their get
>> the parent path to set OPCODE6DIR to.
>>
>>
>> > I'm glad to hear that plugins do get loaded.
>> >
>> > What are the alternative mechanisms for loading opcode libraries on
>> > Android?
>>
>> You should be able to use --opcode-lib=/path/to/.so.
>>
>> > Finally, what do you think needs to be in CsoundApp to be considered a
>> > final
>> > release?
>>
>> I haven't had a chance to do a test build here, so I can't say.  Is
>> there a built-in text editor now?  We just signed a lease today and am
>> in the middle of a lot of travels, so I'll try to do a build soon to
>> give better comments.
>>
>> Thanks!
>> steven
>>
>>
>> ------------------------------------------------------------------------------
>> How ServiceNow helps IT people transform IT departments:
>> 1. A cloud service to automate IT design, transition and operations
>> 2. Dashboards that offer high-level views of enterprise services
>> 3. A single system of record for all IT processes
>> http://p.sf.net/sfu/servicenow-d2d-j
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net