[Cs-dev] Android Csound 6
Date | 2013-05-31 12:42 |
From | Michael Gogins |
Subject | [Cs-dev] Android Csound 6 |
Attachments | None None |
Beta up on SourceForge in the Csound6 rc2 folder.
Question: How would this be used? Uses I've thought of:
On my beast of a phone (Samsung S4, fastest available right now) performance is 22 seconds to render Trapped in Convert to file compared to my beast of a laptop (Asus gaming laptop with 4 core i7 CPU) at an unbelievable 2.6 seconds, but this is still usable for real-time rendering of many sounds and orchestras. That's 8.5 times faster for the Asus...
I need not remind the rest of you Csound geezers that 22 seconds to render Trapped in Convert at 100 ksmps used to be OK for a "real computer," so I guess the S4 is a "real computer" despite its small size.
Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com |
Date | 2013-05-31 13:27 |
From | Rory Walsh |
Subject | Re: [Cs-dev] Android Csound 6 |
I have to admit that I was very excited when Steven and Victor released the first android package for Csound, but once I started using it I found it quite frustrating. Editing code on a phone is not really an option. On a tablet perhaps, but I certainly couldn't see it working on my Galaxy S3. I think it's real value is as a sound engine for Android apps. I might get shot down for saying this, but it blows pdlib away in terms of functionality. With the right marketing I could see it becoming one of the standard sound libs for Android. On 31 May 2013 12:42, Michael Gogins |
Date | 2013-05-31 13:58 |
From | Victor Lazzarini |
Subject | Re: [Cs-dev] Android Csound 6 |
I agree that for phones, at least, the best application is as a sound engine. Still, if anyone is patient enough to edit text on the phone, it is nice to enable it. On 31 May 2013, at 13:27, Rory Walsh wrote: > I have to admit that I was very excited when Steven and Victor > released the first android package for Csound, but once I started > using it I found it quite frustrating. Editing code on a phone is not > really an option. On a tablet perhaps, but I certainly couldn't see it > working on my Galaxy S3. I think it's real value is as a sound engine > for Android apps. I might get shot down for saying this, but it blows > pdlib away in terms of functionality. With the right marketing I could > see it becoming one of the standard sound libs for Android. > > > > > > On 31 May 2013 12:42, Michael Gogins |
Date | 2013-05-31 14:18 |
From | Michael Gogins |
Subject | Re: [Cs-dev] Android Csound 6 |
Attachments | None None |
I just timed Trapped in Convert on my netbook (26 seconds), and it actually runs a little faster on my phone (22 seconds). Note that I have rendered pieces for concert on this netbook. The Samsung Galaxy S4 has a 5 inch screen, and it's not nearly as bad for editing text as smaller phones. I don't know yet if I can live with it in the programming department, but I am certainly going to give it a try.
If I don't use widgets and I use Lua for algorithmic composition, then the phone and my other computers are the same environment, only some computers/phones are not as fast as others.
Regards, Mike On Fri, May 31, 2013 at 8:58 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote: I agree that for phones, at least, the best application is as a sound engine. Still, if anyone is patient enough to Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com |
Date | 2013-05-31 14:34 |
From | David Akbari |
Subject | Re: [Cs-dev] Android Csound 6 |
Attachments | None None |
The problem is that often times text input on a phone relies on lexical prediction to achieve any semblance of efficiency. I could see Csound code text editing working on a phone as long as there is a way to "import/add" a list of Csound opcodes to the phone's dictionary (think the output of csound -z1). I'd imagine the details of doing this differ depending on the product platform. To be honest it would be great if that dataflow/patcher looking Python GUI thing those German guys were working on a few years back could be implemented on phones (can't remember the name offhand). That could eliminate the need to deal with tedious and complex text entry but the scope of such a project may make it unfeasible.
Great work moving Csound towards a functional and prosperous life on embedded systems! -David On Fri, May 31, 2013 at 8:18 AM, Michael Gogins <michael.gogins@gmail.com> wrote:
|
Date | 2013-05-31 14:48 |
From | Steven Yi |
Subject | Re: [Cs-dev] Android Csound 6 |
Hi Michael, I think it's great to see these changes: thanks! I think too there's a lot of opportunity for mobile/desktop workflow integration. While editing a lot of code can be tedious on a phone, I definitely see tremendous possibilities where the phone becomes a part of a larger workflow. One can start a project on the desktop, do some modifications on the go, and synchronize between the two. At least, this was a design goal for me when I was doing some drafting of ideas for what a Blue Mobile would be (I had put that idea down for a while to work on other things, but this is inspiring me to think about it all again). Beyond this, another idea I had was a generative music player where the pieces were CSD's, and the player could be implemented on Mobile as well as Desktop. I had a dream of totally portable generative pieces that would be as easy to load as using a music player (i.e. google music, iTunes, etc.). I had the thought of profile support, so a CSD could say, this is built for quad, for ambisonics, for etc. and the player could support certain profiles. It'd be neat if profile conversion could happen automatically too. For example, a piece that's set for ambisonics could have player options for HRTF and Stereo to play, or on desktop with multichannel have player decoder options. I think something like this, especially with an option for mobile, could be great for the distribution of music works that don't have standard 2-channel, fixed medium requirements. This could be a very interesting thing if we had metadata fields for author, year, album, description, website, etc. such that a Csound project becomes instantly playable without any intervention by the end user. Back to the CSDPlayer, I had planned to do a bit of brush up on Android this summer, as it had been a couple years since I was last working on mobile software fulltime at my last job. One of the things we may wish to look at is using ActionBarSherlock [1] and RoboGuice [2] (particularly the RoboGuice-Sherlock library [3] to modernize the application. (I'm planning on redoing my "Peaceful Breathing" Android application using these libraries.) Anyways, hope these thoughts are interesting and thanks again for your work on Android! steven p.s. - One question I wondered, have you tried -j4 to do parallel on your S4? I'm very curious about parallel on mobile devices. It's an extremely compelling feature and I think it would differentiate Csound from other audio solutions for mobile devices. [1] - http://actionbarsherlock.com/ [2] - https://github.com/roboguice/roboguice [3] - https://github.com/rtyley/roboguice-sherlock On Fri, May 31, 2013 at 2:18 PM, Michael Gogins |
Date | 2013-05-31 15:03 |
From | Michael Gogins |
Subject | Re: [Cs-dev] Android Csound 6 |
Attachments | None None |
-j4 works on the Samsung Galaxy S4. I've only tried it with Trapped in Convert, where there's no speedup, in fact a bit of slowdown and audio grit. But it does work! I will be trying this with file rendering of some other pieces where it makes more sense. Thanks for the library references, I'm looking them up. Best, Mike On Fri, May 31, 2013 at 9:48 AM, Steven Yi <stevenyi@gmail.com> wrote: Hi Michael, Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com |
Date | 2013-05-31 19:31 |
From | Michael Gogins |
Subject | Re: [Cs-dev] Android Csound 6 |
Attachments | None None |
About these support libraries, they require Android API 11. Do you have any objections if I retarget the project from 10 to 11? About the "profile" idea, I'm not sure. Wouldn't that require changing the audio output methods in CsoundObj to target various output formats, instead of doing that by choosing appropriate Csound output opcodes/parameters? Or would you paste together different CSD files automatically in the app to target the different profiles? Regards, Mike On Fri, May 31, 2013 at 9:48 AM, Steven Yi <stevenyi@gmail.com> wrote: Hi Michael, Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com |
Date | 2013-05-31 21:29 |
From | Michael Gogins |
Subject | Re: [Cs-dev] Android Csound 6 |
Attachments | None None |
I've tested CsoundStrata.csd with Csound 6 on Android and with -j4 I get a 2 times speedup over a single thread. In general, if a piece benefits from multiple threads on another platform, it should receive the same benefit on Android. My impression now is that Android behavior is very similar to other platforms with respect to threading. Of course, not all phones have 4 cores.
Regards, Mike On Fri, May 31, 2013 at 9:48 AM, Steven Yi <stevenyi@gmail.com> wrote: Hi Michael, Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com |
Date | 2013-06-01 02:01 |
From | Steven Yi |
Subject | Re: [Cs-dev] Android Csound 6 |
I imagine it's alright. I have a Nexus One with Android 2.3.4 and I was able to install the Gaug.es app that the RoboGuide-Sherlock page cites as using that library. It's a little tricky to see what platform 11 maps to, but I assume it's 2.3.4. The Android dashboard shows platform 10 cover 2.3.3-2.3.7: http://developer.android.com/about/dashboards/index.html So, my best guess, considering my own device and the devices that came out around that time, and the dashboard, I think we'd be covered. If you want, we could do a poll on the user's list to double check if anyone has any particular needs for platform 10. As for the "profiles" idea, it's not an idea I've fully mapped out. The idea I had is that maybe CSD project could say it's using b-format. If that's known, then the app could run Csound and manually read the SPOUT and send that over to another Csound instance that decodes the signal to stereo. Other things like "accelerometer", "compass", etc. could be other features a project might depend upon. Then may that kind of project could run on Android or iOS, or maybe Win8, Ubuntu Touch, Blackberry 10, etc. Some of this is considering edge cases; the bigger goal would really be to have works that are dynamically generated be easier to distribute. On Fri, May 31, 2013 at 2:31 PM, Michael Gogins |
Date | 2013-06-01 02:03 |
From | Steven Yi |
Subject | Re: [Cs-dev] Android Csound 6 |
That's great news Michael, thanks! I hope the app developers on iOS and Android that consider using parallel processing will be a good source of feedback. On Fri, May 31, 2013 at 4:29 PM, Michael Gogins |
Date | 2013-06-01 02:57 |
From | Andres Cabrera |
Subject | Re: [Cs-dev] Android Csound 6 |
Attachments | None None |
Is there a way for an app to know how many cores its running on? A On May 31, 2013 6:04 PM, "Steven Yi" <stevenyi@gmail.com> wrote:
That's great news Michael, thanks! I hope the app developers on iOS |
Date | 2013-06-01 03:02 |
From | Steven Yi |
Subject | Re: [Cs-dev] Android Csound 6 |
I just did a quick search and found: http://stackoverflow.com/questions/7962155/how-can-you-detect-a-dual-core-cpu-on-an-android-device-from-code On Fri, May 31, 2013 at 9:57 PM, Andres Cabrera |
Date | 2013-06-01 03:20 |
From | Andres Cabrera |
Subject | Re: [Cs-dev] Android Csound 6 |
Attachments | None None |
Ok, cool, thanks. Cheers, Andrés On Fri, May 31, 2013 at 7:02 PM, Steven Yi <stevenyi@gmail.com> wrote: I just did a quick search and found: |