Diese Website verwendet Cookies, um Ihnen ein besseres Nutzungserlebnis bieten zu können. OK
8 Min Lesezeit 14 mal geteilt 38 Kommentare

[Userblog] Warum Apple bessere Musik-Apps hat

Android Music

Ist Dir wichtig, dass dein Smartphone wasserdicht ist oder ist es Dir egal?

Wähle wasserdicht oder egal.

VS
  • 20496
    Stimmen
    Ooops! Etwas ist schiefgelaufen. Aktualisieren sollte helfen.
    wasserdicht
  • 14638
    Stimmen
    Ooops! Etwas ist schiefgelaufen. Aktualisieren sollte helfen.
    egal

(Bild: Foto: chanelcoco872 via flickr.com)

Geht es Euch genauso wie mir? Als Hobby-Musiker will ich mit meinen Android-Geräten auch selbst Musik machen und habe dazu einige Apps ausprobiert, aber irgendwie sind fast alle enttäuschend und um Klassen schlechter als entsprechende iPhone- und iPad-Apps. Als Android-Entwickler habe ich mich also hingesetzt und versucht, eine (Kirchenorgel-)App zu schreiben, die besser ist. Was folgt, sind die Erfahrungen, die ich dabei gemacht habe – aus Entwicklersicht. Wer also wissen will, womit sich ein Android-Entwickler für eine 3 Euro-App herumschlägt  oder verstehen will warum eigentlich höhere Preise für Apps gerechtfertigt wären oder auch nur, warum Musik-Apps auf iPhone und iPad besser sind, der lese weiter.

Der Klang

Wer schonmal verschiedene Klavier-Apps ausprobiert hat, weiß bestimmt, wie schlecht die meisten klingen. In Android ist ein Sonivox Midi-Tongenerator enthalten. Er wird zum Beispiel vom MediaPlayer benutzt, um Midi-Dateien abzuspielen. Es sollte also ein Leichtes sein, eine Musik-App zu schreiben, oder? Erstes Problem: Android enthält keine offizielle Schnittstelle, um dynamische Midi-Daten abzuspielen. Man kann Android nur fertige Midi-Dateien übergeben. Eigentlich taugt das also nicht, um damit Musik zu machen. Manche Apps benutzen aber unsaubere Umwege und Hacks und gehen trotzdem diesen Weg. Damit kommt man zum zweiten Problem: es klingt auf vielen Geräten nicht gut. Wer es sich anhören will, kann xPiano und Musical Lite ausprobieren. Soweit ich es ohne Analyse der Apps sagen kann, verwenden sie diesen Weg. Das ist wohl auch der Grund, warum sie gleich klingen.

Viele Apps verwenden auch einen „SoundPool“ oder „AudioTrack“ im „static mode“. Im Prinzip bedeutet das, dass jeder Klang fest hinterlegt wird und die App dann nur das Abspielen auslöst. Manche Apps beenden den Klang dann aber nicht mehr wenn man die Taste loslässt (z.B. „My Piano“) und es ist praktisch unmöglich, einen „Loslassklang“ zum richtigen Zeitpunkt abzuspielen. Schließlich hören Klavierseiten beim Loslassen der Tasten nicht sofort auf zu schwingen, sondern werden in kurzer Zeit abgedämpft. Wenn man etwas genauer hinhört, kann man das hören.

Wie geht’s besser? Die einfachste Möglichkeit, die ich gefunden habe, ist FluidSynth. Etwas vereinfacht gesagt, ist das eine Soundblaster-Soundkarte in Software. Damit lassen sich SoundFont-Klangdateien nutzen und von diesen SoundFont-Dateien gibt es eine ganze Menge im Netz für die unterschiedlichsten Klänge - durchaus auch einige mit ordentlichem Klang. Allerdings ist es nicht ganz trivial FluidSynth auf Android zum Laufen zu bringen – nichts für Programmieranfänger. Dazu kommt, dass Android den Speicherplatz begrenzt, der einer App zur Verfügung steht. Das konkrete Limit hängt vom Gerät ab, liegt aber derzeit in der Regel zwischen 16 und 48MB. Manche der besten SoundFont-Dateien sind so groß, dass dieser Platz nicht ausreicht um die Datei zu laden. Immerhin, wenn man diese Größenbeschränkung einhält, geht’s.

Natürlich bleibt auch noch die Möglichkeit selbst Audiosamples zu verwalten, zu mischen etc. Auch das führt richtig gemacht zu einem sehr guten Klang. Ist aber ebenfalls „nicht ganz trivial“.

Fazit zum Klang: Musik-Apps müssen unter Android nicht schlecht klingen, es ist „nur“ eine Frage des Aufwands. Umso ärgerlicher ist der Klang vieler Apps.

Die Klaviatur

Reden wir nicht um den heißen Brei herum: Klaviaturen auf dem Bildschirm sind ein miserabler Kompromiss: zu klein, ohne gutes haptisches Feedback, auf den meisten Geräten ohne Anschlagsdynamik und damit ohne die Möglichkeit Töne lauter oder leiser zu spielen. Und mehrere Tasten gleichzeitig zu drücken funktioniert auch nur „fast immer“.

Multitouch

Starten wir mit letzterem: Damit man mehrere Tasten gleichzeitig drücken kann, muss das Gerät „Multitouch“ beherrschen. Die meisten einigermaßen aktuellen Geräte können das – mehr oder weniger. Die Herausforderung fängt bei der Hardware an. Viele Handys erkennen z.B. nur maximal 2 Finger, manche Tablets schaffen 5, manche 10. Sind die Finger zu nahe beieinander, werden sie oft nur als einer erkannt. Manche Geräte erkennen technisch bedingt die x- und y-Koordinaten der Finger unabhängig voneinander, was dazu führt, dass die Koordinaten manchmal falsch zugeordnet werden. Sehr schön zeigt das das Video http://www.youtube.com/watch?v=Ds5qZ_3XRzI . Und schließlich leitet Android die Berührungen auch nicht an das jeweilige Oberflächenelement - sprich die gedrückte Klaviertaste - weiter, sondern immer an das vom ersten Finger berührte. In neueren Versionen kann man das als Entwickler anders vorgeben, aber aus Gründen der Rückwärtskompatibiltät muss man trotzdem damit klar kommen die Berührungen selbst den Tasten zuordnen. Das alles hört sich recht harmlos an, oder? In der Praxis ist es aber na ja, sagen wir „anspruchsvoll“, unter anderem aufgrund der Art und Weise wie Android die Berührungsereignisse modelliert und weiterleitet.

Fazit zu Multitouch: Multitouch kann man ganz gut in den Griff bekommen. Das ist aber ebenfalls nichts für Programmieranfänger.

Midi-Schnittstelle

Hat man Multitouch im Griff, bleiben immer noch die anderen Tastaturprobleme: für unterwegs mag eine Bildschirmklaviatur noch ok sein, um damit „richtig“ zu spielen ist sie es definitiv nicht. Kurzum, früher oder später will man ein Keyboard anschließen. Für diesen Zweck gibt es einen Standard: Midi. Über Midi kann ein Gerät einem anderen mitteilen, dass und welchen Ton es spielen soll. Dabei werden keine Klänge übertragen, sondern Kommandos, einen bestimmten Ton ein- oder auszuschalten. Soweit, so gut. Wo liegt diesmal das Problem? Na ja, Android-Geräte haben keine Midi-Buchse.

Manche Apps umgehen das, indem sie die Midi-Signale über Funk, also z.B. über Wlan oder Bluetooth empfangen. Dazu muss man das Keyboard aber erstmal mit einem Computer verbinden, der das Signal dann über Wlan weiterleitet. Eigentlich kann dann aber auch gleich dieser Computer die Klangerzeugung übernehmen. Ironischerweise würde damit sogar das Setup etwas mobiler. Dazu kommt, dass so eine Funkübertragung meist zu lange dauert. Die Zeit, die vom Drücken der Taste am Keyboard bis zum Empfang des Midi-Signals vergeht (d.h. die Latenz über die Funkschnittstelle), ist auf diesem Weg zu hoch. Beim Musikmachen gibt es eine Art Feedback-Schleife, d.h. man reagiert auch auf das, was man hört. Wenn dabei die Latenz zu hoch ist, führt das unweigerlich zu schlechtem Timing und Fehlern.

Wer sich mit Midi etwas auskennt, kommt vielleicht auch auf die Idee, dass Midi-Signale ja oft über USB übertragen werden und Android-Geräte haben doch einen USB-Anschluss, oder? Keine schlechte Idee. Allerdings haben die meisten Geräte nur einen USB-Device-Anschluss. Um ein USB/Midi-Interface anschließen zu können, braucht man aber USB-Host. Eine Ausnahme sind manche Tablets; z.B. hat das Acer A500 auch einen USB-Host-Anschluss eingebaut. Für manche andere Tablets gibt es passende Docking-Stations oder wie beim Transformer anschließbare Tastaturen mit USB-Host. Und siehe da, damit kann es funktionieren – wenn diese Geräte mindestens Android 3.1 verwenden. Mit Android 3.1 ist es möglich geworden, aus einer App heraus auf USB-Geräte zuzugreifen. Damit lassen sich auch USB/Midi-Interfaces ansprechen, obwohl Android selbst keinen passenden Treiber für solche Geräte hat.

Fazit zu Keyboards: Auf Geräten mit Android 3.1 und USB-Host-Unterstützung kann man Apps entwickeln, an die man ein Keyboard (oder ein anderes Midi-Device) anschließen kann. Alle anderen Android-Geräte müssen erstmal außen vor bleiben.

Audio-Latenz

Damit haben wir alles beisammen, um vom Anschlag einer Taste am Keyboard bis zur Erzeugung der Klangdaten zu kommen. Wer jetzt aber denkt, ich hätte kein weiteres Problem mehr in der Hinterhand, hat den Artikel wohl nicht bis hierher gelesen. Das Problem: Die Audio-Latenz ist auf praktisch allen Android-Geräten zu hoch. Konkret: vom Zeitpunkt an dem die App die Klangdaten an Android übergibt bis zum Zeitpunkt, an dem man einen Ton hört vergehen typischerweise mindestens 120 Millisekunden, auf vielen Geräten auch bis zu 200 Millisekunden. Für einen MediaPlayer ist das kein Problem, fürs Musizieren schon. Das Problem ist mindestens seit Ende Juli 2009 bekannt (siehe http://code.google.com/p/android/issues/detail?id=3434), für Google gibt es aber offenbar wichtigeres als Musik-Apps. Jedenfalls hat Google es nicht gelöst, obwohl das prinzipiell möglich scheint: Ein gewisser Arun Raghavan hat entsprechende Versuche mit einem Galaxy Nexus und Android 4.0 gemacht und konnte die Latenz von 176 Millisekunden auf ca. 20 Millisekunden reduzieren (siehe http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/). Wer von Euch in diesem Punkt anderer Meinung ist als Google, darf sich hiermit aufgefordert fühlen auf http://code.google.com/p/android/issues/detail?id=3434 für die Lösung dieses Problems zu stimmen.

Fazit zur Audio-Latenz: Wirklich gelöst werden kann das Problem der Audio-Latenz nur von Google und den Herstellern der Android-Geräte. Damit ist das wohl der größte Show Stopper für Musik-Apps auf Android und der wesentliche Grund, warum Apple in diesem Bereich die Oberhand hat.

Summa Summarum

Es ist eine ordentliche Herausforderung eine gute Musik-App für Android zu schreiben. Es lassen sich aber alle Probleme lösen. Alle? Wirklich alle? Wie war das mit der Audio-Latenz?

Auch das Problem lässt sich mit genügend Aufwand Massenmarkt-tauglich lösen: Man könnte eine Art „Android-Soundkarte“ entwickeln, die an den USB-Device-Anschluss angesteckt wird und die Klangdaten an einem Audio-Ausgang ausgibt. Wenn man dazu auch noch Midi-Anschlüsse einbaut, würde sich auch die Einschränkung bzgl. Android 3.1 und USB-Host erledigen. Ich selbst habe ein gewisses Verständnis von Hardware und könnte so ein Gerät wohl für den Privatgebrauch bauen (tatsächlich habe ich sogar eine recht konkrete Vorstellung davon wie ich das tun werde), nicht aber für den „Massenmarkt“.

Hm, ich werde für mich wohl alle Probleme lösen, aber für Euch tut es mir Leid: Ihr müsst mit dem Latenz-Problem leben. Oder hat jemand die Fähigkeiten und die Lust so eine „Android-Soundkarte“ mit mir zu entwickeln?

14 mal geteilt

38 Kommentare

Neuen Kommentar schreiben:
  • @thungsten: Ist ja schön, dass du so begeistert bist von Android. Ich bin's auch - so sehr, dass ich einiges an Zeit und Aufwand in Android-Apps (und keine in iOS-Apps) stecke. Mit den sich selbst verstärkenden Marketing-Effekt hast du sicher nicht ganz unrecht. Die von dir genannten technischen Punkte sind aber leider an vielen Stellen einfach falsch bzw. zu oberflächlich. Das sage ich nicht, um recht zu behalten. Mir wäre es wesentlich lieber, wenn Android insbesondere die Latenzschwäche nicht hätte oder wenn jemand eine echte Lösung kennen würde. Der Artikel sollte auch kein Android-Verriss sein und mir liegt nichts ferner als iOS in den Himmel zu loben, aber es gibt nunmal Gründe, warum es keine durch und durch guten interaktiven Instrumental-Apps auf Android gibt.

    1. Ich kenne den "hochkarätigen Verstärker im Galaxy“ nicht (welches der verschiedenen Galaxy-Geräte meinst du eigentlich?). Ich kenne aber auch kein Android-Gerät mit einer niedrigen Audio-Latenz und das ist für interaktive Apps ein sehr wichtiger Punkt, den für diese Anwendungsfälle auch kein hochkarätiger Verstärker wettmachen kann. Wenn Du ein Gerät mit niedriger Latenz kennst, bitte raus damit. Ich würde ernsthaft in Betracht ziehen es zu kaufen und zu empfehlen.

    Tatsächlich hat Google in den Kompatibilitätsvorschriften Angaben zur Latenz der Geräte gemacht. Die dort spezifizierten Zeiten wären auch recht akzeptabel. Leider hat Google diesen Teil aber nur als "soll" und nicht als "muss" spezifiziert, mit dem Ergebnis, dass sich die Hersteller nicht kümmern.

    Übrigens, wenn kein Hersteller niedrige Latenz implementiert oder das nicht öffentlich bekannt wird, kann man sich dieses Gerät auch nicht aussuchen. Die mehr als 1000 (sic) Gerätevarianten durchzutesten ist jedenfalls keine praktikable Alternative. Ich würde mir wünschen, dass ein Hersteller ein Gerät veröffentlicht, das speziell für Musik-Apps ausgelegt ist (also z.B. niedrige Latenz hat) und das auch entsprechend bewirbt. Wahrscheinlich würde ich mir dieses Gerät kaufen.

    2. Anschluss
    Die Behauptung, die meisten aktuellen Android-Handys wären Host-Modus-fähig ist interessant. Entsprechende Programmierschnittstellen gibt es erst seit Android 3.1. Für Tablets habe ich das im Artikel diskutiert. Bei Handys müssten die Handys Android 4 besitzen. Das aber sind nicht „die meisten aktuellen Android-Handys“. Zurzeit gibt es nur sehr sehr wenige Android-Handys, auf denen offiziell Android 4 läuft.
    Damit dann z.B. USB-Lautsprecher anzusteuern scheitert übrigens daran, dass die meisten USB-Lautsprecher die Daten im isochronen Übertragungsmodus haben wollen. Ausgerechnet der wird aber von der USB-API von Android nicht unterstützt. Ich habe versucht USB-Lautsprecher anzusprechen, weiss das also aus erster Hand. Hast Du das jemals versucht? Wenn Du einen solchen Lautsprecher oder ein anderes USB-Audio-Ausgabegerät kennst, das mit Allerwelts-Android-Geräten zusammenspielt, würde mich die Marke interessieren. Evtl. würde ich dieses Gerät in meinen Apps unterstützen.

    3. Latenzen
    Soweit mir bekannt, liegt die hohe Latenz an AudioFlinger, dem Audio-Stack von Android (s. http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/. Den Artikel hatte ich übrigens im Beitrag erwähnt). Auch die in Android 2.3 eingeführte "low latency" Audio-Implementierung via "OpenSL" im NDK (also die Schnittstelle, die man von C aus verwenden würde) geht über AudioFlinger. Damit relativiert sich das "low latency". AudioFlinger selbst ist übrigens in C++ implementiert. Java mag nicht die schnellste Programmiersprache sein, aber es ist nicht an allem schuld.

    Und wenn Du Entwickler in der Pflicht siehst, "die optimalen Optionen auszuwählen" - ich sehe da auch eine gewisse Pflicht bei Behauptungen in Kommentaren tief genug zu recherchieren. Sorry, aber bei Andeutungen, dass ich meine Hausaufgaben nicht machen würde, reagiere ich angesichts des Aufwands, den ich betreibe, leicht allergisch.

    4. Multitouch
    Ich kann und will nicht für iOS reden und ich kann mir vorstellen, dass auch iOS Stärken und Schwächen in diesem Bereich haben mag, aber es geht im Artikel um die Schwächen von Android. Ich habe mit Android eine Multitouch-App implementiert. Daher kann ich wiederum aus erster Hand sagen, dass das nicht die Stärke von Android ist. Es ließe sich leicht eine bessere Multitouch-Implementierung entwerfen. In den aktuellsten Versionen von Android wird Multitouch etwas besser unterstützt. Aber Apps müssen nunmal auch etwas ältere Android-Versionen unterstützen (ich spreche da gar nicht mehr von Android 1.x, sondern meine 2.1/2.2 als Mindestvoraussetzung). Bis man sich als Entwickler nur noch auf die neue Variante stützen kann, weil der Anteil der alten Geräte gering genug geworden ist, werden wohl noch 1-2 Jahre vergehen.

    5. Speicherbeschränkung
    Laut der offiziellen Android-Dokumentation gibt es eine Begrenzung des Heaps von Java-Apps. Es gibt sogar eine Schnittstelle, um die Grenze abzufragen: http://developer.android.com/reference/android/app/ActivityManager.html#getMemoryClass%28%29 Typischerweise liegt die Grenze bei 16-48MB. Falsch ist also nicht meine Angabe, wie du behauptest, sondern deine Behauptung.

    6. Multitasking / 7. Intents / 8. Dateisystem
    Das sind die einzigen Punkte, bei denen ich Dir recht gebe. Multitasking, Intents und die Möglichkeit, Daten über das Dateisystem weiterzugeben, lassen Dinge zu, die so unter iOS nicht gehen.

    Diese Punkte hatte ich im Artikel übrigens nicht kritisiert und sie beseitigen leider auch nicht die Schwächen.


    Dein Fazit stimmt nur teilweise: Ja, es gibt definitiv technische Punkte, bei der Android vorne liegt. Es gibt aber auch Teile, bei denen Android noch(?) hinterher hinkt. So sehr ich auch Android-Fan bin, ich bin halt auch Realist.

  • Das iPad ist durch professionelle Firmen im Bereich wesentlich besser unterstützt.
    Da wird sich die Schlange in den Schwanz beißen:
    Da es besser unterstützt ist, werden Musiker eher das iPad nutzen und da mehr Musiker das iPad verwenden werden mehr Applikationen dort entstehen und diese besser unterstützt.

    So weit der nicht technische Part.

    Zum technischen Part: vieles was in diesem Artikel beschrieben wird ist eine Halbwahrheit - also unvollständig oder schlecht recherchiert - oder es ist etwas, das nicht nur auf Android, sondern genauso auf das iPad zutrifft.
    Aber vieles was Android kann und das für Musikprogramme interessant sein kann, kann iOS aus Prinzip nicht!

    1. Audiohardware
    Die Audiokomponenten des iPads und iPhones sind im Schnitt schlechter als die von Android-Geräten. Ein besonderes Beispiel ist das Galaxy, das sogar einen hochkarätigen Verstärker verbaut hat.
    Abgesehen davon kann man hier nicht von Android sprechen, viel mehr ist es der jeweilige Hersteller, der Einfluß auf die Qualität der Audio-Hardare hat.
    Und im Android-Eco-System kann man sich aussuchen worauf man Wert legt. Beim iPad ist es einfach, man muss gar nicht darüber nachdenken, was einem wichtig ist & man muss sich nicht informieren, es gibt ja nur eine Möglichkeit.

    2. Anschluss
    Es gibt Hardware-break-out-Boxen, die speziell für das iPad konzipiert sind. Das ist toll. Android bietet die Möglichkeit über den Host-Modus ganz normale USB-Geräte, die auch am PC - ob Win, Mac oder Linux - verwendet werden können, anzuschließen. Die meisten aktuellen Geräte sind Host-Modus-fähig.
    Für den Hersteller weniger Absatz und zusätzlicher, unvergüteter Aufwand, während die proprietäre iPad-Variante viel lukrativer ist, da hier noch mal gezählt werden muss.
    Trotzdem ist daran nicht Android schuld.
    Im Gegenteil, Android böte hier wesentlich bessere Optionen für den Kunden.

    3. Latenzen
    Solange man in den Virtual-Machines auf Java-Ebene bleibt, trifft das Problem der höheren Latenz wohl zu.
    Aber auch für das iPad muss in Objective-C, einem C-Derivat, programmiert werden. Wieso also kein Vergleich mit Latenzen, die über die hardwarenahen Schnittstellen von Android erreicht werden können? Ich bin sicher, dass Android-Apps, die im Kontext des nativen C-Unterbaus entwickelt wurden, nicht langsamer sind - vermutlich sogar schneller als beim iPad, da die CPU und RAM bei Android-Geräten meist schneller bzw. grösser sind. Auch hier sind Hersteller und Entwickler in der Pflicht die optimalen Optionen auszuwählen, das bedeutet ggf. aber mehr Arbeit oder Einarbeitung in ein neues Feld.

    4. Multitouch
    Weder iPad noch Android beschränken Multitouch in einer Weise, die hier oder z.B. bei Spielen, die da weitaus problematisher sind, Probleme bereiten würde.
    Das angedeutete Bounding-Box-Modell, 2-Finger-Beschränkung, verwendete HTC, aber das kommt auch schon lange nicht mehr zum Einsatz.
    Die Interaktionssteuerung ist unterschiedlich gelöst, aber beide Varianten, iOS und Android, haben Stärken und Schwächen.

    5. Speicherbeschränkung
    Es ist falsch, dass es eine Speicherbeschränkung bei Android pro Applikation gibt.
    Richtig ist, dass bei zu vielen parallelen, gestarteten Applikationen der Speicher so sinnvoll wie möglich bereinigt wird.
    Eine unoptimierte, einzeln gestartete App zog bei mir durchaus schon 128MB und mehr.
    Es kommt eben drauf an, was sonst noch läuft.

    6. Multitasking
    Android bietet eine sehr mächtige Parallelisierung von verschiedenen Applikationen - anders als iOS.
    Das wirkt sich oft auf Punkt 5. aus. Aber es bietet auch Möglichkeiten, die unter iOS nicht existieren.

    7. Intents
    In Android können alle Applikationen untereinander Daten austauschen, auf iOS nicht. Das ist für das modulare Ineinanderklicken von Musiksoftware spannend.
    Auf iOS wird eine One-fits-all-App benötigt, auf Android ist eine Toolchain von einfach aufgebauten, optimierten und leicht bedienbaren Apps realisierbar.

    8. Dateisystem
    Auf Android kann jeder alle Dateien verwalten und auf andere Medien - Festplatte über Host-Modus, CD-Brenner, SD-Karte, ... - ausspielen, kopieren, laden. Auf iOS wird dazu stets ein PC oder der Umweg über die Cloud benötigt. Eine App kann Ihre Ergebnisse auch über Dateien anderen Applikationen zur Verfügung stellen.
    Auch das zeigt die Flexibilität und Offenheit von Android, sie muss nur genutzt werden.

    Mein Fazit sieht daher so aus: Im Maketing, der Verfügbarkeit und dem Support durch Majors liegt iOS mit iPad und Co ganz weit vorne, bei der Technik ist es aber von Android schon lange abgehängt und laggt. ;-)

  • wenn jemand nur daran denkt, dass man eine virtuelle klaviatur auf einem touchscreen nicht spielen kann und musik-apps desswegen sinnlos sind, sollte sich auch mal das hier angucken: http://de-bug.de/musiktechnik/archives/5595.html
    beim video wirds ab 3:30 richtig interesant.

    touchscreens eröffenen da völlig neue möglichkeiten. man darf nur eben nicht denken, dass man konventionelle methoden einfach so auf nen touchscreen übertragen kann. es würde ja auch niemand (der keine experimentelle musik macht) darauf kommen ein piano aufzumachen und die saiten wie bei einer gitarre zu zupfen oder bei einer gitarre die saiten mit nem hammer anzuschlagen.
    genau so wenig sollte man eben meinen, dass man eine konventionelle klaviatur 1:1 auf einen touchscreen übertragen kann. neue technick erfordert neue konzepte.

  • @Mark A.: Für Apple-Devices gibt's von Apogee Connectoren; an die Dinger kannst Du z.B. direkt Gitarren anschließen.

    Aber das bekommen Android Fanboys in ihrer eingeschränkten Welt nichtmal ansatzweise mit!

    Wenn man keine Ahnung hat, lieber mal die Klappe halten!

  • adl 27.01.2012 Link zum Kommentar

    @Jupp S.

    Wie geil! :D

    Hier mal ein Link zu einen Video über die App Caustic 2:
    http://www.youtube.com/watch?v=nhpJdqd09S4

  •   15

    Die vom Autor des Artikels vorgeschlagene "Android-Soundkarte" hätte für mich kaum Nutzen. Wenn ein externer Tonerzeuger (wie auch eine Klaviatur) per MIDI angeschlossen werden kann, dann besteht kein Bedarf für spezielle Hardware-Lösungen.

    Den Sinn einer Android-Musik-Software sehe ich natürlich nicht im professionellen Mastering, sondern in der Möglichkeit, musikalische Ideen aufzuzeichnen, wo immer man gerade ist bzw. ohne ein großes Setup hochzufahren.

    Es kann sein, dass schnelle Android-Geräte überwiegend hinreichend geringe Latenz-Zeiten aufweisen. Damit sind sie als musikalisches Notizbuch bereits brauchbar.

    Als seriöser Entwickler entsprechender Apps sollte man allerdings eine gewisse Latenz-Zeit garantieren können. Und das ist, wie gesagt, ein echtes Problem und erfordert eine aufwändige Analyse bis auf Kernel-Ebene. Sonst kann irgendein routinemäßiger Prozess des Betriebssystems die Latenz-Zeit in den Keller bringen.

  • @Achim Leubner
    hab auch nicht behauptet, dass im kernel was umgebaut werden müsste. jemand vor mir dachte das und ich wollte es nur wiederlegen.
    der mod für das galaxy nexus (wo ich eh schon scharf drauf bin und jetzt noch mehr) ist da ja das beste beispiel.

    @Mark A.
    usb-host ist bei ios geräten weniger nötig als bei android. da es viele geräte gibt, die direkt mit der standard buchse von apple arbeiten:

    http://www.drlima.net/2012/01/ipad-mixer-von-behringer/

    http://www.gadgetoz.com/post/alesis-pro-studiodock-for-ipad/

    http://www.gadgetreview.com/2011/01/akai-synthstation49-full-fledged-ipad-keyboard-dock.html

    http://blog.jokerbrand.net/blog/2012/01/25/akai-mpc-fly-for-ipad2/

    http://www.gadgetreview.com/2010/11/synthstation25-keyboard-for-iphone-from-akai-pro.html

    sowas wünsch ich mir auch für android geräte. die halterung müsste zwar was universeller gebaut werden, aber verschiedene gamepads mit halter zeigen, dass es trotzdem auch bei android-geräten möglich ist.
    usb-host währe dann natürlich auch praktisch, aber notfalls greift man eben auf bluetooth zurück. abgesehen von den ersten beiden geräten werden bei keinem von dem oben geposteten geräten audio-daten übertragen. nur kontroll-daten (midi).

    @adl
    interessant. das internet ist ein dorf. ich bin juschu ausm live-forum.

  • Ich bin zwar kein Hardcore-Musiker, aber ich hätte da auch keine Lust zu das Handy, das Pad oder sonst ein kleine Kiste dazu zu nutzen Musik zu produzieren. Ich würde das Grundsätzlich über eine Hardware erstellen, die vom Platz für das aufgenommene und auch entsprechende Qualität liefert und mir nicht die Augen versaut.
    Ich würde dafür immer einen Rechner nutzen. Dort habe ich zwei Bildschirme, genügend Anschlussmöglichkeiten für verschiedene Instrumente, die dann sogar gleichzeitig genutzt werden könnten wie bei einer Produktion im Tonstudio. Mal abgesehen davon das ich je nach Betriebssystem verschiedene Programme gleichzeitig nutzen könnte. Geht zum Beispiel mit dem IPad/IPhone schonmal nicht.
    Hätte seine Vor und Nachteile mit den Smartphone oder Pads. Just for Fun hätte ich keine Zeit dazu und auch nicht das Interesse. ;)

    Greetz
    Alex

  • adl 27.01.2012 Link zum Kommentar

    Wer elektronische Musik machen will und kein Klavier braucht,der sollte unbedingt die App Caustic 2 anschauen. Meiner Meinung nach die derzeit beste App in diesen Dingen.

  • gut geschrieben aber ich hatte gedacht es geht mehr um player apps. aber es liefert einen guten Einblick in die Hintergründe.

  • @Manuel Kohl: Ein ernstzunehmender Musiker macht immer, überall und mit allem was ihm unterkommt Musik - uns sei's nur zum Spaß ;)

    Im Ernst:
    http://www.youtube.com/watch?v=bdGL8H0WdUU
    http://www.youtube.com/watch?v=-Pf934cM6xA
    http://www.giga.de/musik/gorillaz/news/neues-gorillaz-album-mit-diesen-ipad-apps-wurde-es-aufgenommen/

    Preisfrage: Weiß jemand, warum die alle iPads verwenden und kein Android?

  • welcher ernstzunehmende musiker produziert denn bitte mit seinem handy musik???!

  • @Mark A.: Im Artikel wird durchaus erwähnt was das Kernproblem ist: die Audio-Latenz. Bei iOS soll sie bei bis zu 5,8ms, also im einstelligen Bereich liegen (s. z.B. http://soundcloud.com/musique-tactile/ios-audio-latency-5-8-ms) im Gegensatz zu 120-200ms bei Android. Eine Midi-Buchse haben auch die Apple-Geräte nicht, wie domlen aber richtig festgestellt hat, kann man über das Camera Connection Kit und USB/Midi-Adapter Keyboards anschließen. iOS bringt auch die entsprechende Unterstützung bereits mit.

  • Der Blog scheint mir sein Thema verfehlt zu haben. Es heißt doch "Warum Apple bessere Musik-Apps hat". Ja, warum denn? Darauf wird in dem Text nicht eingegangen.
    Es werden einige Probleme von Android aufgezeigt. Aber in wie fern ist Apple hier besser? Wie hoch ist da die Latenz, funktioniert USB Host, haben die Geräte eine Midi-Buchse?
    Drückt man bei iOS direkt irgendwelche GUI Elemente?

    Gerade der Abschnitt "Klaviatur" scheint doch eher auf allgemeine Probleme abzuzielen.

  •   15

    @Jupp S.:
    Zum Thema Latenz: ASIO gibt's leider nicht für Linux. Das JACK Audio Connection Kit bietet eine gute Alternative, die mit den gängigen Linux-Programmen läuft (z.B. der Rosegarden Sequenzer-Software):

    http://de.wikipedia.org/wiki/JACK_Audio_Connection_Kit

    Wenn man einen JACK-optimierten Custom Kernel mit Android zum Laufen bekommt, wäre das ideal. Also ein Custom Android für Musiker, um das Latenz-Problem zu lösen. Wäre ordentlich Arbeit...

  • Es gibt aber auch ein Smartphone mit 2.3, welches USB-Host besitzt: Samsung Galaxy S2 ;)

  • @Jupp S.: Der Artikel unter http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/ ist recht interessant zum Thema "woran liegt's". Arun hat einfach ein Galaxy Nexus mit Android 4.0 genommen (also aktuelle Hardware & aktuelles Android) und den Audio-Stack von Android ("AudioFlinger") durch "PulseAudio" ersetzt. Das ist keine Änderung "im Kernel" sondern in den "Systemprogrammen / Audiotreibern", die zu Android gehören. Im Resultat hat PulseAudio etwas mehr Speicher benötigt (3020kB vs. 2600kB) aber weniger Strom verbraucht und die Latenz von 176ms auf 20ms reduziert. Mit Optimierungen wären wohl noch bessere Zeiten möglich.

    Das Problem scheint also zumindest auf manchen Geräten "in Software" lösbar zu sein.

  • ich reg mich schon seit ewigkeiten über die latenz unter android auf. besonders seit google in einem feature-video zu gingerbread behauptet hat, dass sie das problem jetzt gelößt haben.

    aber instrumente, die man direkt "spielt" finde ich für touchscrenngeräte eh nicht so sinnvoll (ausser man könnte über midi ein keyboard anschließen).
    eine ausnahme ist da vielleicht die synthesizer-app von moog (auch für android). die haben sich bei dem keybard wirklich gedanken darüber gemacht, wie man es am besten auf einem touchscreen umsetzt.
    trotzdem machen unter den audio-apps sicher sequencer wie sketch und rd3 noch am meisten sinn. aber auch da ist die latenz ein problem. wenn man mit dem cutoff oder anderen parameter rythmisch rumspielt, dann stört das auch.

    trotzdem bleiben solche apps immer nur ein zeitvertreib für zwichendurch. wenn ich ernsthaft musik machen will setze auch ich mich an meinen pc. da hab ich ableton, ein midikeyboard, andere midicontroller und ein interface wo gute monitore dran hängen.
    in dieses setup könnte man ein tablet aber auch gut integrieren: als midicontroller à la jazzmutant lemur.
    dabei stört die audiolatenz ja auch nicht mehr, da wieder nur midisignale verarbeitet werden, die man über wlan zum rechner schickt.
    hier währe es also um einiges leichter für die entwickler. trotzdem gibt es apps wie touch osc oder lemur nur für ios. unter android gibt es fingerplay, aber die ist im vergleich zu den anderen ein witz.

    aber ich denke, dass auch für android geräte wie die mpc fly umzusetzen währen.
    da hier auch nur mididaten ausgetauscht werden, könnte man die verbindung einfach über bluetooth herstellen.

    aber noch mal wegen der latenz:
    es gibt ja asio4all womit man unter windows auch mit der internen soundkarte ne akzeptable latenz hinkriegt. in den jeweiligen programmen muss man dann asio4all anstatt der herstellertreiber wählen. also es ist es wahrscheinlich doch eine treibersache und nichts, was man im kernel verändern müsste. somit liegt der schwarze peter wieder bei den herstellern.
    und ich hab auch ein video mit sketch gesehen, wo die latenz erstaunlich gering aussah. hat jemand (der ahnung von der materie hat) ein aktuelles tablet und könnte das mal testen?

  • @Leif Sikorski: Ich schaue mir das mit den Dev Hours mal an. Derzeit bin ich dabei, wahrscheinlich auf der Basis von IOIO (ein Arduino-Klon, der speziell dafür gedacht ist mit Android-Geräten zu kommunizieren) und eines VS1053b (ein Audio-Chip) so eine "Soundkarte" zu bauen. Mal sehen, wenn alles klappt werde ich wohl eine Bauanleitung veröffentlichen.

    @Tim F: Natürlich ist ein echtes (gutes) Klavier nicht zu schlagen. Ich schwärme heute von einem Steinway-Flügel, auf dem ich mal spielen durfte. Der hat aber auch irgendwas über 100.000DM gekostet. Außerdem ist das Thema Klavier-App nur ein Beispiel. Die App, die ich geschrieben habe, bildet eine Kirchenorgel nach. Und wer kann sich schon eine Kirchenorgel ins Wohnzimmer stellen? Als ich das Orgelspielen gelernt habe, wäre ein Orgelspieltisch plus Hauptwerk oder eben eine Android-Lösung "Der Traum" gewesen. Dann hätte ich nicht so oft in der kalten Kirche sitzen müssen. Mit einem Android-Tab wären auch ganz andere Instrumentenkonzepte realisierbar als man das jemals "klassisch" bauen könnte. Außerdem wäre es so möglich, nicht nur ein "Klavier" zu haben, sondern auch noch ein Cembalo, einen Synthesizer, ein Spinett, .... und das ohne ein Musikzimmer in der Größe einer Turnhalle. Ich denke schon, dass es eine Reihe von "Anreizen" gibt, "Instrumenten-Apps" einzusetzen.

    Zum Thema "es gibt doch gute Android-Audio-Apps, z.B. ...": alle Android-Audio-Apps haben derzeit dieses Latenz-Problem, je nach Art der Tonerzeugung etwas mehr oder etwas weniger. Bei Sequencer-Apps bzw. allen Apps, die nicht "sofort auf Tastendruck einen Ton erzeugen" müssen, spielt das aber erstmal keine so große Rolle.

    Ich habe hier übrigens auch eine "Klavier-Variante" meiner Orgel-App, die sich zwar gut anhört, aber wegen der Latenzprobleme nicht gut spielen lässt. Und irgendwie finde ich das einfach blöde.

  • Schade. Solche Beiträge wie diesen sollte mal jemand für 2 Wochen auf die Startseite heften, damit wirklich jeder User mal liest, womit ein Entwickler konfrontiert wird. Vielleicht honorieren dann User, denen eine App aus irgendeinem Grund eine Funktion zuwenig bietet, die App trotzdem mit 3 statt 1 Stern und einer wohlwollenden Formulierung statt Ghetto-Asi-Slang.

Zeige alle Kommentare

Diese Website verwendet Cookies, um Ihnen ein besseres Nutzungserlebnis bieten zu können. Mehr dazu

Alles klar!