b. wenn es eigentlich um die transformation des simultanen ins lineare geht, ist es sinniger, ein
vollkommen bedeutungsloses bild vorlesen zu lassen. eine semantik ist dabei eher hinderlich. sie
lenkt den gedanken von dem ziel des hexdumpers ab.
2. welche rolle spielt automatisierung und wie kann man dies realisieren?
sinnig wäre dann nach 1. b. eine bildersuche über eine suchmaschine zu veranlassen.
b. hierzu braucht man einen shellskript oder aber den getimage.pl (perl) von sascha oder ähnliches.
die bilder würden zunächst in einen ordner laufen. hierzu muss näher bestimmt werden, in welchem
turnus und in welcher menge überhaupt bilder verarbeitet werden sollen. da das dargestellte keine
rolle spielt, außer, dass es darstellt, was es darstellt und eine darstellung ist, die vorgefunden
wurde, ist jedes bild gleichwertig. daher bekommt es eine bloße nummer. die könnte beispielsweise
das eingangsdatum sein (z. b. 200411061042.jpg). dann benötige ich ein weiteres skript, das den
eingangsordner ausliest und sich die jeweils jüngste datei heraussucht. diese wird dann an hexdump
übergeben. hexdump schreibt per cat eine textdatei in den ausgangsordner. nun muss festival
aktiviert werden. die txt2speech-software liest jeweils immer den letzten, jüngsten text. dies aber
bis zuende. danach wird wiederum der jüngste text herausgegriffen. dabei muss natürlich
gewährleistet sein, dass die suchabfrage schneller bzw. simultan (was wahrscheinlich unmöglich ist)
bilder abgreift. hierzu sollte dann auch noch klar sein, dass eine bestimmte bildgröße erforderlich
ist, um den rhythmus einhalten zu können. beispiel: ein 2 kb großes gif wird in x minuten gelesen.
die suchabfrage startet aber in x+15 minuten wieder. damit ensteht eine streamingpause. erwünscht,
sinnvoll? im hintergrund läuft übrigens der upstream. der prozess sollte simultan angestoßen werden,
da sonst übertragungsbrüche bei beendigung der lesung entstehen.
protokoll
07.11.2004 habe echt schlecht geschlafen. gegen 2 bin ich kurz aufgestanden. das sirren der rechenknechte. überall im wohnzimmer blinkt es. gespenstisch. nach 0,7 liter wasser, die ich kopf über in mich stürzte, drehe ich kurz am lautstärkeregler der stereoanlage. der hexdumpfluter plappert noch. und auch der stream geht noch ab.
jetzt ist es 7.18 uhr. alles beim alten. alles läuft. wenn's mehr nicht ist. einer hört noch zu. sascha? bestimmt. dafür ist sein dyndns nicht erreichbar. timeout vom timessquare.
wer beziffert den traffic? kann man ihn beziffern?
von hier aus gehen 96 kbits per sekunde ab. das sind 12 kbyte. ca. zehn stunden läuft der kram jetzt durchgängig, das sind 432000 kbytes also 432 mbyte. gestern habe ich den stream am vormittag gegen neun gestartet, und bis auf die seg fault-unterbrechungen lief der stream. das heißt, man müsste verdoppeln.
die raten, die bilder, die texte:
81K 2004-11-06 08:19 bullcam2.jpg
36K 2004-11-06 08:19 cam96.jpg
62K 2004-11-06 08:19 cam_lut.jpg
33K 2004-11-06 08:19 cam_rp.jpg
44K 2004-11-06 08:19 cam_rpn.jpg
58K 2004-11-06 08:19 camgoerd.jpg
18K 2004-11-06 08:19 cammercu.jpg
28K 2004-11-06 08:19 kamkreuz.jpg
28K 2004-11-06 08:19 kamstasi.jpg
macht per cat
384K 2004-11-06 08:27 ueberwachen.jpg
sind 4 kb weniger als bei schlichter addition
hexdump:
1,2M 2004-11-06 09:42 lesung1.txt
macht dann das 3,125-fache des addierten bildes.
aber erst die übersetzung in "gesprochene" zeit katapultiert die menge extrem in die höhe. wobei die lesung noch nicht beendet ist. ich kann nicht nachvollziehen, an welcher stelle die maschine gerade im text ist. ob sie bis 24 uhr zuende gelesen hat? 11 mb waren nach einer frühen rechnung aus dem august ca. 30 tage lesung. also drei tage über den daumen. macht zu guter letzt ca. 3 gb traffic.
festival stürzt immer ab. versuch neu, alte besetzung, apple speech
06.11.2004: 12:54: ~/bin/festival/bin/festival --tts lesung1.txt Speicherzugriffsfehler programm neu gestartet.
neue pläne: heute klappt die schleife. der linux-rechner reicht von seiner leistung aus, um sowohl den stream zu schicken als ihn auch zu produzieren. ich lasse also festival vorlesen und darkice streamen. dies gibt mir die gelegenheit, mich um die kameras in leipzig zu kümmern. ich werde nun versuchen, ein skript zu schreiben, was webcam-bilder abgreift, diese in einen ordner speichert, hexdumpt und streamt. immer schön der reihe nach.
-- MatthiasWeiss - 05 Nov 2004
die sache steht jetzt endlich. nach einer phase des experimentierens ist klar, dass der hexdump-stream gelesen werden kann. dank sascha haben wir auch auf serverfestival.net wieder einen sender, einen netz-radiosender.
es gab einige schwierigkeiten mit dem upstream über mac os x, aber da linux-alternativen zur verfügung stehen, ist das marginal. ich werde in den nächsten tagen hier noch die laienhafte versuchsanordnung präsentieren.
mir ist es in diesem stadium des projekts wichtig, alexander rose (www.weirdbyte.de) dank zu sagen. alex, der bereits 2002 lowlife auf art.net.dortmund betreute, hat mir mit einigen wesentlichen tipps und kommandos (cool, mr sed!) derart geholfen, dass ohne ihn das projekt gescheitert wäre.
jetzt werden wir folgende versuchsanordnung realisieren:
powerbook (pismo) --- spricht den stream, der aus einem leipziger bild generiert wird.
amd xp 2000+ streamt über linux und darkice.
das bild wird an dieser stelle folgen.
MATERIAL
The image “http://wiki-institute.com/pub/Serverfestival/WohnzimmerLeipzig/ueberwachen.jpg” cannot be displayed, because it contains errors.
das ist nicht wieter tragisch und hat den hintergrund in der simplen tatsache des versuchsaufbaus, der mit dem cat-befehl sämtliche bilder in eine pseudo-bild-datei geschrieben hat.
-- MatthiasWeiss - 06 Nov 2004
2.jpg:
4.jpg:
5.jpg:
6.jpg:
7.jpg:
8.jpg:
9.jpg:
10.jpg:
13.jpg:
14.jpg:
15.jpg:
16.jpg:
19.jpg:
Anhänge
lesung1.txtder zu lesende text mit einem kurzen vorspann
