Über Algorithmen (5)

(Thema)

Zum Vierten: Spannend wird es dann, wenn Algorithmen von einem Algorithmus gesteuert werden.

Bis zu diesem Punkt habe ich Verfahren beschrieben, die Daten algorithmisch verändern. Man kann aber auch in Abläufe (Logiken) eingreifen – zB. in den Ablauf eines Programms; und zwar auch dann, während es läuft.

Für ein eher einfaches Beispiel komme ich noch einmal auf die Logik hinter den Übergängen von Voicings zurück. Die dort waltende „Fuzzy-Logic“ ist „hart“ kodiert. Man könnte das aber auch anders implementieren, nämlich als einen Algorithmus, der, nach Vorgaben der User, lernt.

Mögliche Übergänge von einem Akkord in einen anderen könnte man einem (menschlichen) „Lehrer“ anbieten, der, aufgrund seiner Erfahrung und seines Wissens, darüber entscheidet, ob die „Lösung“, die das Programm gerade anbietet, „richtig“ ist, oder vielleicht einfach nur (mehr oder weniger) „gut gefällt“. Das Programm führt Buch über jene Entscheidungen, und pflegt zB. eine Datenbank, in der die „Wertschätzung“ jenes „Experten“ festgehalten wird, um sie später weiter zu verwenden.

Ich hatte, bei dem Chordtrack-Feature, die Idee, nicht hart-kodierte Fuzzy-Logic zu verwenden, sondern ein Programm zu schreiben, mit dessen Hilfe der Algorithmus auf ein Feedback reagieren kann und die „Wahrscheinlichkeiten“ (für die „Güte“ von Übergängen zwischen Voicings) aus diesem Feedback zu generieren. Im konkreten Fall hätte ich viel Code für ein vergleichsweise triviales Problem zu schreiben – ich habe das dann bleiben lassen, und das „Fine-Tuning“ des Algorithmus „zu Fuß“ erledigt.

Für die Aufgabe, einem Computer die Erkennung von Sprachbefehlen oder die Interpretation von von Hand geschriebenem Text beizubringen, bleibt jedoch, meiner Einschätzung nach, nichts anderes übrig, als sich mit solcher Meta-Ebene zu beschäftigen.

Über Algorithmen (4)

(Thema)

Zum Dritten: Einem Computer kann man durchaus beibringen, sich von einer strikten „wenn-dann“-Logik zu entfernen. Es gibt hier einen Mythos um die sog. „Fuzzy-Logic“, wo ein Algorithmus – freilich nur auf den ersten Blick – nicht mehr deterministisch vorgeht, sondern Wahrscheinlichkeiten implementiert (der Artikel in der Wikipedia schreibt hier am Mythos mit).

In der Praxis ist das relativ einfach. Statt einem „if-else“ (dem „wenn-dann“-Befehl in praktisch allen Hochsprachen) testet man, was solch ein „if-else“ für ein Ergebnis haben würde, bevor man dieses Ergebnis tatsächlich „abholt“.

Im Rahmen des Chordtrack-Features von Cubase habe ich dieses Verfahren für die Bestimmung der Folge von „Voicings“ verwendet.

Ich will hier nicht näher ins Detail; mir kommt es hier nur auf das Verfahren an (das ich nicht erfunden habe, und das man wohl bei ganz anderen Gelegenheiten ebenfalls benutzt).

Hier ist das Problem (bei dem es sich letztlich nur um ein allgemeines Problem beim Sortieren von Datensätzen handelt, das man auf ganz andere Computer-relevante Probleme recht unaufgeregt übertragen kann):

Auf einen C-Dur-Akkord, der aus einem „Datensatz“ aus konkreten Tönen besteht (einem sog. „Voicing”) , soll ein F-Dur-Akkord folgen. Für den F-Dur-Akkord gibt es eine Liste aus „Datensätzen von Tönen“, mit dem man ihn spielen kann. Der Algorithmus soll bestimmen, welcher Datensatz – welches Voicing – jenem nach C-Dur „am Besten” folgt.

Innerhalb der „Fuzzy-Logic“ wird jedes mögliche Voicing in F-Dur darauf getestet, wieweit es dem Vorgänger (dem in C-Dur) „am Besten“ folgen würde. Dafür gibt es einen Satz von Regeln, die musiktheoretischen Überlegungen über Stimmführung folgen. Eine Regel ist zB., daß der Sopran (die höchste Stimme innerhalb eines Voicings) möglichst kleine Schritte gehen soll (und nicht, wie der Baß, eine Quinte nach unten oder eine Quarte nach oben springt).

Jene „kleine-Schritte-Regel“ für den Sopran zB. halte ich für extrem wichig; deshalb gebe ich ihr zB. 8 Punkte, wenn der Übergang zwischen C- zu F-Dur, mit dem entsprechenden Voicing, sie einhält. Wenn der Tenor sich an dieselbe Regel hält, ist das zwar ebenfalls „gut“, aber etwas weniger wichtig; dem Befolgen dieser Regel gebe ich dann zB. nur 4 Punkte; etc. pp.

Ein Übergang von einem Voicing in das nächste beruht auf einem ganzen Satz von Regeln. Dabei kommt es darauf an, welche Regel wie gewichtet wird. Das macht hier nicht der Computer, sondern der User; in diesem Fall: der Programmierer. (Ich habe ganz erheblich Zeit investiert, um, mit dem Ohr, Gewichtungen für diese spezielle Fuzzy-Logic zu finden).

Zum Schluß – nachdem alle möglichen Voicings (Datensätze) eines F-Dur-Akkords, die einem C-Dur-Voicing folgen könnten – von der Fuzzy-Logic des Algorithmus „ausprobiert“ wurden, „gewinnt” das Voicing mit den meisten Punkten, und wird von Cubase angeboten. Easy as pie.

Zum Vierten:

(wird fortgesetzt)

Über Algorithmen (3)

(Thema)

Zum Zweiten: Im Score-Editor von Cubase folgt die Interpretation von rhythmischen Strukturen einem eher rudimentären Verfahren: es gibt einen Grundbestand an Regeln, die dann von Ausnahmen begleitet werden.

Eine grundlegende Regel ist etwa, daß eine Note, die über einen Taktstrich „hinausragt“, in zwei grafische Repräsentationen zerteilt werden muß.

Eine zweite Regel besagt, daß dies auch dann zu geschehen hat, wenn eine Note die Taktmitte überschreitet.

Eine erste Ausnahme von der Regel (die der User im Setup aktivieren kann) geht damit um, daß es Stilistiken in der Musik gibt, in denen man ein anderes Verständnis vom „Offbeat“ hat: ein Jazzmusiker etwa wird an dieser Stelle eine etwas andere Darstellung der Noten erwarten.

Gelegentlich „kippt” eine Ausnahme von der Regel: im Beispiel rechts werden Noten an jedem Offbeat zerteilt, nur weil der User hier eine Option aktiviert hat, die für diese spezielle Situation eher wenig Sinn macht (ich deute diesen Zusammenhang hier nur an).

Der Code in Cubase, der die Rhythmik von MIDI-Daten in Notenschrift übersetzt, funktioniert nur deshalb einigermaßen gut, weil er von Ausnahmeregeln geradezu verseucht ist - wobei die User aber immer noch, mehr oder weniger detailliert, bestimmen können, wo diese greifen.

Eine grundsätzliche These: Ein im Lesen von Notenschrift geübter Betrachter eines Notats weiß, wenn die Darstellung „Sinn“ ergibt (oder nicht); er kann aber nicht erklären, warum das so ist.

Eine zweite These (und die wird man wohl nur dann als Spekulation zurückweisen, wenn man auch die erste These verneint): Wenn man dieses „Wissen“ mit einem Computeralgorithmus nachstellen will, läuft man in das grundsätzliche Problem, daß ein Computer immer nur ein „wenn-dann“, nicht aber ein „nebeneinander“ kennt.

Wenn man davon ausgeht, daß beide Thesen zutreffen, kann man folgern, daß sie für eine große Zahl von Algorithmen zutreffen, die so etwas wie Verhältnisse in der „realen Welt“ modellieren versuchen. Man hat es in der Realität eben nur manchmal (These 1) mit Beziehungen zwischen „Ursache“ und „Wirkung“ zu tun. Oft sind die Beziehungen zwischen Verhältnissen aber etwas ganz anderes, nämlich, zumindest auf den ersten Blick, scheinbar zufällige „Koinzidenzen“.

Dabei verstellt schon diese Unterscheidung (zwischen „Kausalität” und „Indetermination”) den Blick auf Wege der Erkenntnis, die Menschen halt mal so eben machen. Man „sieht” etwas, und zieht, ohne darüber näher Rechenschaft ablegen zu können, Schlüsse, hinter denen man auch nach einigem Nachdenken immer noch stehen kann (die sich dann womöglich sogar als „richtig” erweisen). – Das kann man, auf ganz prinzipieller Ebene, im Computer nicht nachstellen (These 2).

Diese Erkenntnis ist letztlich nichts Neues. Man trickst dann halt weiter herum.

Zum Dritten:

(wird fortgesetzt)

Über Algorithmen (2)

(Thema)

Auf eine – wie auch immer verfeinerte - Suche läuft letztlich jeder Algorithmus hinaus: ein Computerprogramm läuft über Datenbestände, und liefert ein Ergebnis – einen für den User sichtbaren Output –, wo die Daten nach bestimmten Kriterien geordnet bzw. gefiltert sind.

Das ist ein grundsätzliches Verfahren, dem auch zB. die Algorithmen hinter dem Score-Editor in Cubase gewissermaßen gehorchen. Die Datensätze hier sind die musikalischen Daten – eine Folge aus „Note-On“- und „Note-Off“-Befehlen –, die dann von den Algorithmen so sortiert werden, daß sie für eine Ausgabe in Notenschrift auf dem Bildschirm taugen.

Ich will versuchen, das ein wenig konkreter zu fassen.

Zum Ersten: Wenn man einen Datenstrom, der aus „Note-On“ und „Note-Off“-Befehlen besteht, in ein lesbares Notenbild transformieren will, braucht es als erstes ein Raster in der Timeline: man kann rhythmische Strukturen nur dann erkennen, wenn man das Taktmaß kennt – und das Problem der Darstellung von rhythmischen Verhältnissen ist womöglich das zentrale Problem, wenn man musikalische Datenströme in Notenschrift übersetzen will.

In Cubase ist dafür bekanntlich der der Signaturetrack zuständig. Hier findet sich das Raster, an dem sich die Algorithmen in den Scores entlang tasten.

Bevor man etwas ordnet, muß man also die Kriterien der Ordnung schon im Vorfeld festlegen. Die Algorithmen in den Scores von Cubase ähneln hier, auf eine freilich sehr abstrakte Weise, jenen bei der Rasterfahndung von welchem Geheimdienst auch immer – und verweisen auf eine grundsätzliche Gemeinsamkeit von Algorithmen, welcher Art auch immer: man muß sortieren; und das geht nur, wenn man schon im Vorfeld festlegt, nach welchen Kriterien dies zu geschehen hat.

Zum Zweiten:

(wird fortgesetzt)

Über Algorithmen

(Thema)

Das Thema „künstliche Intelligenz“ (AI, artifical intelligence) ist anläßlich der Enthüllungen um das Prism-Projekt der NSA brandaktuell.

Die pure Erfassung von Datenbeständen durch die Geheimdienste ist ja zunächst gar nicht das Problem. Problematisch wird es erst, wenn man diese Datensätze zueinander in Beziehung setzt, und aus diesen Beziehungen eine Bedeutung ableitet, die dann zu einem Handeln führt. Der Erhebung von Daten folgt deren Sichtung, und erst dann kann man bestimmen, ob es lohnt, einen Anfangsverdacht (auf was auch immer) zu formulieren, dem man dann weiter nachgeht.

Das Verfahren gab es schon immer: man sammelt Beobachtungen (aka Intelligence), und läßt diese dann von Experten auswerten. Früher – zB. bei Echelon – brauchte man ganze Abteilungen in der NSA oder der CIA, deren Mitarbeiter die (analogen) Daten „zu Fuß” abhörten und analysierten, um gelegentlich Alarm zu schlagen.

Die unfaßbar hohe Anzahl der Datensätze, die bei Prism (und anderen, verwandten Projekten) abgegriffen werden, läßt sich unmöglich von einem auch noch so großen Stab von Geheimdienstlern auswerten. Zumindest eine grobe Vorauswahl muß zwangsläufig automatisiert erfolgen, mittels „intelligenter“ Computeralgorithmen.

(Disclaimer: Ich habe keine Ausbildung in der Wissenschaft der AI – ich habe aber einige Algorithmen in diesem Bereich geschrieben, und kenne die Forschung zumindest soweit, wie ich sie für meine konkrete Arbeit hilfreich fand.)

Grundsätzlich kann man mE. festhalten, daß die Forschung im Bereich der AI letztlich zum Stillstand gekommen ist. Nach einer großen Aufbruchstimmung in den 80ern des letzten Jahrhunderts folgte eine Welle der Ernüchterung, von der die allermeisten Projekte weggespült wurden.

Ein Algorithmus ist letztlich immer ein Computerprogramm: eine Abfolge von Befehlen, die von der CPU ausgeführt werden.

Man versuchte jedoch schon immer, sich von der Prozessorlogik soweit wie möglich zu entfernen, indem man von ihr abstrahiert. Solche Abstraktionen sind Grundbestand im Werkzeugkasten der Computerwissenschaft; im Alltag benutzt sie jeder Programmierer, der eine „Hochsprache“ benutzt, um Sourcecode zu schreiben (Assembler, C++, Basic, Javascript – selbst HTML-Quellcode ist letztlich solch eine „Sprache“).

Ein Algorithmus setzt hier noch eine Abstraktionsebene oben drauf: er formuliert ein Konzept, wie bestimmte „hochsprachliche Konstrukte“ ineinander greifen müssen, um ein bestimmtes Ergebnis zu produzieren.

Ein gutes Beispiel für einen (letztlich gar nicht so) einfachen Algorithmus ist das Sortieren von Datensätzen. Wenn man etwa – als User – vom Betriebssystem (MS Windows; Mac OSX; Linux; etc.) seine Dateien zB. nach Namen sortiert haben will, aktiviert man einen Algorithmus, der über ein bestimmtes Wissen über das Alphabet verfügt. Dieses Wissen ist seinerseits wieder ein Computerprogramm, das auf Tabellen zurückgreift, die einer Zahl (aus denen jeder Datensatz letztlich besteht) ein Symbol (im Alphabet einer bestimmten Sprache) zuordnet.

Auf solch ganz rudimentären Verhältnisse muß jeder Algorithmus immer zurück – unabhängig davon, welche „Magie“ sich hinter ihm zu verbergen scheint.

(Wird fortgesetzt)

Cubase 7 - Chord Track - Der schwere Einstieg

(Thema)

Zum Chordtrack gibt es das Statement: „Generell ist das Feature eher technisch ausgerichtet“.

Das kann ich nur unterschreiben. Tatsächlich bin ich sogar ein Fan davon, zumindest die „innovativen“ Features in Cubase so zu gestalten, daß sie keine(!) konkreten „Usecases“ abdecken, sondern den Usern möglichst großen Raum geben, selber kreativ zu werden. Das führt dann oft dazu, daß ein User erst einmal ein eher abstraktes Konzept lernen muß, bevor er es für seine eigene Arbeit kreativ nutzen kann. Dafür hat er dann Optionen, die nicht auf von Steinberg im Vorhinein „festgetackerte“ Arbeitsschritte – eben sog. Usecases – festlegt sind.

Es ist – meiner Erfahrung nach – irre schwierig, eine Balance zu finden zwischen Einstiegshürden auf der einen, und Einschränkungen in der Benutzbarkeit auf der anderen Seite[1].

Kreative Tools[2] wie der Chordtrack verursachen dabei zwei Probleme, die man mE. strikt auseinander halten muß:

Ein gutes Beispiel für letzteres ist der Mixer. Es gibt bei Steinberg wohl niemanden, der größere Probleme damit hat, dort (in dieser Problem-Domain) das ganze Feld von Features wie Routing, Inserts, Sends, Equalizer, Side-Chain etc. pp. zu verstehen. Wir sind hier alle Domain-Experten. Dabei hätte (habe!) ich durchaus Probleme, einem Außenstehenden meinen eher rudimentären Gebrauch des 12-Kanal-Mischpults zu erklären, mit dem ich die verschiedenen Multi-Media-Geräte in meinem Wohnzimmer so verdrahte, daß 5.1 Surround möglich ist.

Für eine bestimmte Gruppe von Usern gilt genau dasselbe hinsichtlich des Chordtracks: sie wissen sehr genau, was man mit solch einem Feature machen kann. „Voicings“, „Tensions“, „Kadenz“ sind für sie genauso selbstverständliche Begriffe wie „Sends“ etc. für all jene User, die ein Mischpult alltäglich benutzen[3].

Dann gibt es – auf einer zweiten, komplett anderen Ebene – das grundlegende Problem, daß es ein User mit einer konkreten Umsetzung seiner Wissens-Domain in Software zu tun hat. Selbst jemand, der sich mit den Features eines (Hardware-)Mischpults bestens auskennt, kann an einer Software scheitern, die mit Konzepten arbeitet, die er nicht versteht (indem sie zB. die Einstellungen für „Multi-Outs” auf verschiedene Ausgänge des Mischpults so versteckt, daß er sie nur sehr schwer findet).

Gleiches gilt für den Chordtrack. Selbst wenn ein User zB. weiß, daß ein Akkordsymbol nicht direkt abspielbar ist, muß er erst einmal die Stelle finden, an welcher Stelle im GUI („Grafic User Interface”) der Software man einem Akkordsymbol ein Voicing zuweist.

Usf.

Als Entwickler pendelt man im Design des GUI zwischen zwei sehr unterschiedlichen Polen, und adressiert sehr unterschiedliche Gruppen von „Bedürfnissen” (aka GUI-Needs):

Konkret für den Chordtrack ist der Kompromiß, den man zwischen diesen beiden Polen versucht hat, längst nicht optimal gelungen. Das Problem – diese Komplexität – bekommt man aber nicht aus der Welt, indem man an Symptomen bastelt.

BSI warnt vor manipulierten Werbebannern auf Online-Portalen

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt Internetnutzer vor manipulierten Werbebannern auf Online-Portalen, über die Kriminelle vertrauliche Daten abgreifen. An viele bekannte und gut besuchte deutschsprachige Webseiten würden derzeit Banner mit schadhaften Codes ausgeliefert, teilte das BSI mit.

[…]

Es reiche allein der Besuch der Website, auf der die Werbung eingeblendet sei.

(Quelle: SZ. Bei Heise-Security findet sich ein Artikel, der die Zusammenhänge ein wenig präziser erklärt.)

Ein von technischen Details eher gelangweilter User ist leicht der Meinung, daß eine Seite im Internet analog zu einer Seite in einer Zeitung funktioniert. Man ruft eine Internetadresse auf in der Erwartung, es mit etwas wie einem „Drucker auf den Computermonitor” zu tun zu haben, der analog zum Aufblättern einer Seite in einer Zeitung oder einem Buch funktioniert.

Wenn man eine Seite einer Online-Zeitung anfährt, gibt es dort – genau wie in der Print-Ausgabe – eine Mixtur aus redaktionellen Texten und kommerziellen Anzeigen. Eine Seite im HTML-Internet ist jedoch aus einer ganzen Reihe von Versatzstücken zusammengebaut, die nicht nur inhaltlich, sondern auch technisch voneinander getrennt sind. Wo redaktionelle Inhalte und Annoncen im Print auf einem physikalischem Medium (der bedruckten Fläche in einer Zeitung) zusammen gefaßt sind, kommen sie Online von unterschiedlichen Servern, von physikalisch unabhängigen Quellen, die erst von einer Software auf der Seite des Clients zusammengebaut werden.

Der letzte Satz klingt kompliziert – er beschreibt jedoch nur (sehr vereinfacht) das Funktionieren eines Browsers, mit dem dann die „Endkunden“ durch das Internet navigieren.

Der oben angerissene Artikel bei SZ-Online zB. bindet Services ein, die nicht (nur) von den Servern der SZ stammen, sondern extern eingebunden werden. Da geht es nicht nur um Werbung, sondern auch um Schnüffeldienste wie zB. doubleclick.net, die das Click-Verhalten der Leser protokollieren, um zB. statistische Auswertungen des Userverhaltens zur Optimierung der Werbung zu ermöglichen; etc.pp.

Mit einem Klick auf den Link zum Artikel oben navigiert man nicht zum Text der Redaktion, sondern aktiviert all jene Software, die von unterschiedlichsten Servern stammt (wobei jene Software, die den redaktionellen Text herunterlädt, nur eine von vielen ist). – Eine Seite im Internet ist keine Seite in einer Zeitung, sondern eine Versammlung all jener Dienste, die der Browser abruft, um die Darstellung dieser Seite zu ermöglichen.

Mit Reklame-Blockern wie Adblock-Plus kann man sich anzeigen lassen, welche „externe Quellen“ eine Website einbindet. Hier ist die Liste der Domains/Subdomains, die von der oben angerissenen Seite in der SZ eingebunden werden (ich habe mir die Mühe gemacht, die komplette Liste zusammen zu stellen, um den Hauch einer Ahnung davon zu vermitteln, womit man es hier zu tun hat – dabei kommen von jeder der (Sub)Domains noch bis zu zwanzig unterschiedliche Scripts, mit ihren jeweils undurchschaubaren Aktionen):

Using Cubase as a Blind Person - Ross McGregor

[…]

So that's basically how I use Cubase. […] So being blind […] can be quite frustrating […]. But I and many other blind persons still have ambitions and hopes and things we want to achieve.

[…]

(Via Ross McGregor; Dank an Heiko Bischoff für den Link).