Opus #1 - Android Organ App based on Jeuxdorgues 2 / Stiehr-

[achim]

Hi,

I want to briefly introduce Opus #1, a virtual Android organ app that uses a subset of Jeuxdorgues2 / Stiehr-Mockers (disclosure: I'm the author of Opus #1).

You can find details, sample recordings and a trial of the pro version on http://www.refined-apps.com/opus-1/

It's available as ad-supported free version at
https://play.google.com/store/apps/deta ... .als.opus1

A pro version without ads but with midi in/out support via usb and a midi player is available at
https://play.google.com/store/apps/deta ... .opus1.pro

I also plan to publish a "full" version with all stops from Jeuxdorgues, 2 manuals + pedal etc. in the future.

Any thoughts, wishes for future versions, ...?

Thanks Joseph for the opportunity to introduce Opus #1 here.

Achim

[CatOrg]

Dear Achim, wow, great, at least a really portable organ at acceptable price (must by an android).
Thoughts, surely, but rather wishes.
- A version without visible keyboards and pedal, but all accessible through MIDI (or only the mid c displayed tests), divisionals, if place is ok, generals (on a 10,1 display, there should be enough place for 88 buttons 19x18 side by side). Important: forward-backward buttons
- other organs: Burea, Pitea, St Augustine...
In the Bux-Toccata, there are many gaps. Is it the android or my computer? It seems to be the recording. Can it be "healed" in future version?
Unfortunately cant help with programming

[achim]

Thanks, CatOrg, for your input.

I think, at least for the "full" version, there should be both possible, to play it on-screen "on the move" and to use it similar to Hauptwerk as a kind of specialized expander (i.e. as you suggested without on-screen keyboards). It will probably take multiple versions to get there, but yes that would be a great goal.

It's quite easy to make versions with other samplesets, if they are in sf2 format and are not that large (android limits the memory available to a single app). I'm not sure though if its better to go for the "full" organ first (i.e. implement multiple manuals, etc.).

I don't hear any unexpected gaps in the youtube recording of BuxWV 156. It should be like the version at http://www.realmac.info/jeux1.htm (except for registration of course). Can you tell me more?

[CatOrg]

Hi Achim,

Wir koennen auch deutsch sprechen, aber da verteht kein Schw... mehr
In the Video here https://play.google.com/store/apps/deta ... .als.opus1 there are gaps, the same as yesterday. in the mp3 they arent, so I suppose this is not the Android.

About the practical side: one keyboard is fine, when I need smthg better than the deeply damaged organ in my cathedral to accompany a mass or the choir. I understand that, with a limited memory, this will never run big anyway, so idisplay to connect to a bigger computer would be a better solution when I need a big organ.

But a little solution, even with 12-15 stops and II/P would be practical, later on.

[achim]

Hi,

I can't see a gap in the video, nothing different than the mp3 (actually, the video was made from the mp3).

I'm hoping the memory restrictions will go away over time: on old devices, an app may only use 16MB; on current devices, it may be up to 64MB... I will just try to do what can be done within the then current limits.

[masi]

Hi Achim,

it is quite interesting to see that on Android you have to cope with similar limitations like what I encountered when I started to develop StrandOrgan for iOS last year. For me it was clear from the beginning that to play big samplesets I do not want to wait for devices with more memory. Even if the available RAM would double each year one would have to wait about five years to be able to play 1GB-samplesets on a mobile device. I think the RAM will stay to be a problem for some time, see here:

http://www.appleinsider.com/print/11/10/12/limited_ram_in_apples_a5_chip_in_ipad_2_iphone_4s_motivated_by_battery_life_concerns.html

In my apps, the data is continually streamed from the SSD. I cannot reach the polyphony (256 simultaneous pipes) of Opus #1 but only about 100 - 200 voices on an iPad 2, but I am able to use much more sampledata. Several 100 MB sampledata is not a problem even on an iPod touch with just 256 MB RAM. And I think the difference in sound quality can well be heard. These examples are recorded on an iPad with a prototype app using the Pitea sampleset (about 1.3 GB):

http://infimum.de/Boellmann.wav
http://infimum.de/PraeludiumC-Dur.wav

Out of curiosity: Is Opus #1 written in Java? If so, you have my highest admiration. I did not expect that an app like this could be implemented in Java.

Regards,
Markus

[achim]

Hi Masi,

both are mobile platforms. It's not that surprising they share some limitations, right?

Regarding Java, the answer is yes and no. Opus #1 is based on FluidSynth (http://fluidsynth.sourceforge.net/), basically a software implementation of a soundfont soundcard - in C++. The UI, event routing, etc. is done in Scala. I think though it should be possible to implement something similar completely in Java. I know, many developers think Java is slow etc. But actually, it depends on the virtual machine and the dalvik implementation in recent android versions is acceptably fast (current desktop Java vm's are fast too by the way).

Scala by the way is typically as fast as or just slightly slower than Java. I choose it mainly out of curiosity and because features like traits, closures etc. seemed to be handy. That said, I currently would not recommend Scala for Android apps, because there are some problems related to Scala on Android: the Scala library is too huge for Android (meaning there has to be some treeshaking as part of every build), compile times are slower than Java, the tooling is not quite on par yet, ... However, when those limitations some day become irrelevant, Scala will definitively be my preferred choice. On the language level its clearly better than Java.

Regards,
Achim

[masi]

Hi Achim,

Hi Masi,

both are mobile platforms. It's not that surprising they share some limitations, right?

it is not suprising, but it is not self-evident either. Instead of running many apps and giving each only maybe 50 MB, it could be possible to run less apps and allowing a single app to use more RAM. I just did not know how Android handles this. Nor do I know how Windows 8 behaves in this respect.

Regarding Java, the answer is yes and no. Opus #1 is based on FluidSynth (http://fluidsynth.sourceforge.net/), basically a software implementation of a soundfont soundcard - in C++. The UI, event routing, etc. is done in Scala.

An elegant solution. I did similar experiments with early versions of timidity many years ago, but there did not exist sound fonts of a quality like nowadays, so I did not pursue this and never created a GUI for it.

I think though it should be possible to implement something similar completely in Java. I know, many developers think Java is slow etc. But actually, it depends on the virtual machine and the dalvik implementation in recent android versions is acceptably fast (current desktop Java vm's are fast too by the way).

As long as one can avoid heavy object creation, it could work. But I doubt that Java can compete with Objective-C for applications like this.

Scala by the way is typically as fast as or just slightly slower than Java. I choose it mainly out of curiosity and because features like traits, closures etc. seemed to be handy. That said, I currently would not recommend Scala for Android apps, because there are some problems related to Scala on Android: the Scala library is too huge for Android (meaning there has to be some treeshaking as part of every build), compile times are slower than Java, the tooling is not quite on par yet, ... However, when those limitations some day become irrelevant, Scala will definitively be my preferred choice. On the language level its clearly better than Java.

Scala seems to be an interesting language. As I like Java, I always wanted to look at Scala also, but never found the time.

Markus

[achim]

Yes, it seems not to be self-evident given that older "conventional" platforms had no memory management in the style of current mobile platforms at times when their resources were smaller than on current mobile platforms. On the other hand, Windows 8 seems to get similar memory management (see e.g. http://www.electronista.com/articles/12 ... reclaimed/).

Funny that you mention timidity. I first checked timidity. If I remember correctly, it compiles and runs on Android. However it's GPL while FluidSynth is LGPL. So I switched.

Regarding language performance, I long ago decided not to discuss this in-depth on a forum anymore. It's a wide and complicated field; it's easy to compare apples with pears and to forget about important other factors. For example, it heavily depends on the quality of the compiler, the runtime environment, the platform etc. Oh and by the way, speed of execution is not the only dimension on which the competitiveness of programming languages can be compared...

In the end, all that does not matter for a customer. He just wants a "good app". And there are surely more aspects and even more important aspects to good apps than the programming language used, assuming it's "fast & good enough".

Grüße aus Augsburg nach Freiburg,
Achim

[masi]

Hi Achim,

thanks for the Windows 8 link. Obviously Microsoft is still busy with finding a way to do miracles. Who would have thought that?

Greeting back to Augsburg,
Markus