Dieses Teil empfängt SMS und schickt sie als OSC-Daten weiter, damit sie von einer VJ-Software verarbeitet werden können.
Grobe Idee war es, bei öffentlichen Veranstaltungen mehr Interaktion mit den Besuchern zu ermöglichen. Der ein oder andere kennt vielleicht die Twitter-Wall. Bei der Letzten Cool-Savas-Tour wurde das glaube ich eingesetzt. Vor dem Gig war die Bühne mit Stoff verhangen und ein Beamer hat Tweets, die unter einem bestimmten #Hashtag liefen, aus dem Internet gezogen und auf den Vorhang projiziert. Die Konzertbesucher konnten also irgendwas unter einem bestimmten Hashtag twittern und es wurde dann quasi-live angezeigt. Ansonsten findet man soetwas typischerweise auch bei irgendwelchen Web2.0-Konferenzen, etc. Schätze überall da, wo man Sascha Lobo antrifft, steht auch eine Twitterwall.
Absolut sinnlos, klar, aber vielleicht ja für den Moment einfach lustig, und das reicht ja schon, um es wenigstens mal zu versuchen. Außerdem wollte ICH das einfach bauen. Ich hätt’s eh gemacht.
Twitter kann man machen, je nach Publikum und Veranstaltung ist es aber eben nicht das Medium mit der größten Verbreitung. Außerdem gibt’s das ja schon. SMS ist jetzt zwar auch nicht mehr der topaktuelle Bringer, aber zum Anfang ja nicht das Schlechteste. Außerdem hatten wir sofort eine 90er-Party im Kopf, als es darum ging, wo wir das ausprobieren und dort … naja, besser geht’s ja nicht.
Das Grundsystem besteht aus 2 Komponenten: Eine Hardware zum Empfang der SMS und eine nachgelagerte Software, die das Ganze weiter vergniesgnaddelt.
Die Hardware ist ein Arduino mit GSM Shield und Prepaid SIM (Lycamobile, vom Mobilfunkbillighöker um’s Eck). Die Textdaten der eingegangenen SMS werden per serieller Schnittstelle an die Software übertragen. Bei den verwendeten Libraries für die Arduino Firmware musste getrickst werden. Die Arduino-Standard-GSM-Library hat in Verbindung mit dem verwendeten Shield das Problem, dass SMS mit Leerzeichen am Ende nicht richtig verarbeitet werden. Ich bin daher kurzfristig auf die ITead Library umgestiegen. Damit tritt das Problem auf, dass jedem ‘w’ ein Steuerzeichen angehängt wird. Außerdem ist in bestimmten Situationen der verwendete Textpuffer zu klein, sodass man in der Library noch Anpassungen vornehmen muss.
In der Software passiert dann nochmal etwas mehr. Die Texte werden zuerst formattiert – je nach Absender und Inhalt läuft man hier bereits vor eine Wand. Wenn man mit einem aktuellen Smartphone einen Smiley als SMS verschickt, ist das nämlich oft eben nicht der berühmte “Semikolon Minus Klammer”, sondern eine Buchstabenkombi, die man herausfiltern muss. Stichwort PDU-Mode. [Update]Das war natürlich nur so halbrichtig. Tatsächlich gibt es eine Unicode-Konvention für Emojis. Muss man wissen. Ich bin über das aktuelle XKCD darauf gestossen. Als ich ursprünglich nach Anhaltspunkten gesucht habe, fand ich nicht mehr als eine obskure russische Seite auf vKontakte mit rudimentären Infos dazu. Mehr brauchbare Info zu dem Thema gibt es jedenfalls hier: http://apps.timwhitlock.info/emoji/tables/unicode#block-2-dingbats[/Update]
Anschließend werden potenzielle Schimpfwörter herausgefiltert. Das ist zwar nur sehr rudimentär realisiert, gibt aber in einigen Fällen einen zumindest groben Eindruck davon, ob der Text zeigenswert ist, oder vielleicht doch besser nach /dev/null projiziert werden sollte. Kleiner Exkurs: Das ist mal verdammt gar nicht trivial. Anfangs denkt man darüber nach, eine Black- bzw. Whitelist-Mechanik zu implementieren. Klassiker. Übliche Listen bewegen sich in der Größenordnung 35MB und drüber. Das wird schnell zu einem Performance-Thema. Also fängt man probehalber an, alle Schimpfwörter aufzuschreiben, die man kennt und baut selbst einen Mechanismus drumherum. Hier kommt dann mein jahrelang gepflegtes “Gnihihihi” zum Einsatz: Barsch und Wirtschatsexperte sind ja noch Amateurliga, aber bei Präventivotzelotpopulationsverminderung … (ja… ich denke über sowas nach). Man kann die Wörter ja nicht generell blocken, sobald man einen Treffer hat. Prinzipiell kann ja jemand allen Ernstes so ein Wort in seriösem Kontext verwenden wollen. Anschließend kommt dann noch dieser ganze Political Correctness-Blödsinn, Inhalte auf der Meta-Ebene, etc. etc.
Und selbst wenn man das sauber hinbekommt: In einer sehr frühen Phase habe ich zwei Freunde gebeten, mal ihre SMS-Flat auszunutzen und die Fantasie spielen zu lassen. (Profitip: In solchen Situationen zeigt sich, mit was für Verrückten man es eigentlich zu tun hat … Donnerschlag, da taten sich Abgründe auf.) Da kamen dann unter anderem so Sachen wie “Schlägerei um 3:00 vor der Tür”, “Die Blonde von der Theke will ich gerne mal umflexen” oder “Lass uns mal den DJ plätten”. Syntaktisch völlig in Ordnung (keine Schimpfwörter), inhaltlich bedenklich.
Kurzfristig kann man dem Problem jedenfalls nicht beikommen, deswegen werden die ankommenden Texte zunächst in einer Liste gespeichert und in der Software angezeigt. Das hat gleich mehrere Vorteile. Zum einen hat man so die Möglichkeit, nochmal drüber zu gucken und kann ungewünschte Nachrichten löschen. Zum anderen stellt das auch einen Puffer dar. Man muss ja damit rechnen, dass es im Verlauf einer Veranstaltung zu Schwankungen bezüglich der Nutzung kommt. Das kann man so ausgleichen.
Die Software kann in zwei Modi gefahren werden: Automatik und Handbetrieb. Im Automatik-Modus wird nach Ablauf einer einstellbaren Zeit (default 10 Sekunden, wird unten rechts angezeigt) die oberste verfügbare Nachricht gesendet und aus der Liste gelöscht. Im Handbetrieb wird die Nachricht gesendet, wenn man den Button “Step” betätigt.
Über das Eingabefeld lassen sich Texte in die Liste einpflegen, ohne dass man eine SMS dafür schicken muss. Wenn man auf “Shot” klickt, wird der aktuelle Text des Eingabefeldes sofort ausgegeben. Naja, und markierte Nachrichten kann man bei Bedarf löschen.
Die Text werden per OSC (Open Sound Control) ausgegeben. Aus mehrerlei Gründen. Vorneweg stand die Überlegung, dass man es eigentlich eh nur falsch machen kann. Wenn ich z.B. ein Bild erstellen würde, das den Text einer Nachricht darstellt, dann muss das auch irgendwohin ausgegeben werden. Auf einen Beamer z.B. . Aber wenn man das bei (Groß?-)Veranstaltungen oder in Diskotheken nutzt, ist es schlicht Blödsinn, das so zu machen. Zum Einen hat man meist ein etwas komplizierteres Video-Setup (mehrere Leinwände, Masking, etc), zum anderen wird man immer hinter den Anforderungen zurückbleiben. Ein- und Ausblend- Effekte, Schriftarten, Farben, Hintergründe … alles schlecht. Ein vollständiger Standalone-Modus als Blackbox fällt wegen der Schimpfwortproblematik vermutlich eh erstmal aus. Per OSC besteht hingegen die Möglichkeit, die reinen Textdaten zu verwenden und mit dem geeigneten Tool passig visuell aufzuarbeiten.
So sieht das dann aus. Klassischer Signalverlauf von hinten rechts nach vorne mitte. Die SMS kommen beim GSM Modul an. Die Software zur Verarbeitung der SMS läuft auf dem Thinkpad. Mittelfristig muss das natürlich kein Windows-Rechner sein. Ein Raspberry wird auch reichen, aber wenn man ganz genau hinschaut, erkennt man, dass im Hintergrund noch eine Eclipse-Umgebung läuft. (Wir reden hier über den allerersten Einsatz in der Wildnis, da ist das völlig legitim). Das Thinkpad sendet die Texte per OSC als Broadcast via Ethernet, u.a. an das MacBook rechts. Dort läuft VDMX mit dem Block Text Aligner Plugin und macht dann visuellen Kram mit den Texten. Theoretisch kann man das auch alles auf einem Rechner laufen lassen, aber zu Beginn habe ich es da lieber etwas übersichtlicher.
Extra Twist für das hier abgebildete Setup im Rosenhof: Bei meinem Macbook ist natürlich noch nicht Schluss. Hier werden nur die SMS als Visuals bereitgestellt. Der ganze Rest (Video-Content, Masking, …) passiert über einen zweiten Rechner. Muss auch nicht sein, wenn man einen potenten Rechner hat. Mein aktueller Rechner fängt aber schon derbe an zu schnaufen, wenn er nur die SMS-Texte aufbereitet.
Sprechen wir über kurz mal über richtig pfiffige Entscheidungen bezüglich Softwarearchitektur: Wenn sich das Thema Schimpfwortfilterung mal erledigt hat und man das Teil demnächst doch in einem Blackbox-Modus betreibt, ist die Möglichkeit dafür immer noch gegeben, ohne dass man hier etwas ändern muss. Man kann ja ohne Probleme eine zweite Software auf dem selben Rechner betreiben, die sich um eine vorzeigenswerte visuelle Aufbereitung der Texte kümmert. Die OSC-Daten werden dann einfach per 127.0.0.1 zwischen den Prozessen transportiert.
Ich finde, ich bin ganz schön schlau =)
Die Software verfügt über ein Feature, dass ich “OSC Cycle” genannt habe: Die Daten werden auf Wunsch mit alternierenden OSC-Signaturen gesendet: “/OSC/SMS_Text_1”, “/OSC/SMS_Text_2”, “/OSC/SMS_Text_…”. Dadurch kann man auf Seiten der visuellen Verarbeitung noch variabler auf einkommende Daten reagieren. Man kann z.B. vier Textfelder positionieren und damit mehrere Nachrichten unabhängig voneinander darstellen, mit Effekten versehen, etc.
Als Schmankerl gibt es dann noch den den “Gewinner-Modus”. Um die Akzeptanz und den Durchsatz zu steigern, kann man festlegen, dass Text und Absendernummer jeder x-ten SMS im Programm angezeigt werden. Damit kann man dann irgendwas machen. Die Idee dahinter ist klar: “Der Absender jeder 25. SMS nimmt an der Verlosung teil/ bekommt ein Freigetränk/ darf mal ein Lied lang DJ sein/ …”. Rein technisch kann man ohne große Probleme sogar automatisch eine Gewinner-Nachricht an die jeweilige Telefonnummer schicken. Organisatorisch lassen wir das erstmal. Ich hab’ in dem GSM-Modul eine Lycamobile Prepaid-Sim für 2,50€ drinstecken. Da kostet jede ausgehende SMS 15 Cent. Später vielleicht mal.
Whatsapp kommt als nächstes.
