Wofür viel Geld für angepasstes Studio/Audio-Mobiliar ausgeben, wenn man
1. eh genau weiss, was man machen will bzw. braucht und
2. ‘ne Stichsäge von Bosch, ein paar Eisenwinkel und Holzstücke übrig hat?
An OpenOffice/LibreOffice Macro to Colorize Internal References
26. November 2023 in Programming.
Since I found no way to assign a character style to all “reference” text fields of a document, to, for example have them colorized blue (indicating that they are links to some other place in the document) I had to write the following OOo BASIC macro to colorize them on the entire document
Sub ColorizeInternalReferences
Set varEnum = thisComponent.getTextFields().createEnumeration()
Set oDoc = ThisComponent
Set oText = oDoc.Text
Do While varEnum.hasMoreElements()
tF = varEnum.nextElement()
If tF.supportsService("com.sun.star.text.textfield.GetReference") Then
If IsEmpty(tF.Anchor.Cell) then
Curs = tF.Anchor.getText.createTextCursorByRange(tF.Anchor)
Else
Curs = tF.Anchor.Cell.Text.createTextCursorByRange(tF.Anchor)
End if
Curs.collapseToStart()
Curs.goRight(1,True)
Curs.CharColor = RGB(2,50,150)
End If
Loop
End Sub
This will turn all reference texts dark blue (“RGB(2,150,200)”).
seq24 mit padControl
26. Juli 2025 in GNU/Linux, Multimedia.
Mit der in diesem Artikel gezeigten ~/.seq24rc steuere ich seq24 mit meinem Korg padControl an.
Mit qmidiroute habe ich schnell mal bestimmt, welcher Pad auf meinem padControl eigentlich welche note sendet (ja ich weiss, das kann man einstellen, das hier ist nur ein Beispiel für eine ziemlich wirre Belegung):
| Zeile/Spalte | A | B | C | D |
| I | 61 | 69 | 65 | 63 |
| II | 60 | 59 | 57 | 55 |
| III | 49 | 51 | 68 | 56 |
| IV | 48 | 52 | 54 | 58 |
Die ersten zwei Zeilen habe ich in seq24 mal nachgebaut:
Daraus ergibt sich die nachfolgende ~/.seq24rc. Dazu zur Erläuterung (danke an Nedko für den Hinweis auf das Dokument SEQ24, in dem das erklärt wird):
Das Prinzipielle Zeilenformat ist
$NUMMER [$TOGGLE] [$ON] [$OFF]
$NUMMER ist die fortlaufende Nummer der seq24-Sequenzen (die weissen Kästen im Hauptfenster). Durchnummeriert wird spaltenweise beginnend mit Null, also: erste Spalte von oben bis unten sind die Nummern 0 bis 3, zweite Spalte sind 4 bis 7 usw.
$TOGGLE, $ON und $OFF sind MIDI-Muster, das heisst, sie treffen auf bestimmte MIDI-Signale zu. Dabei sind 6 Werte anzugeben:
- 0 oder 1 um zu bestimmen, ob dieses Muster aktiv ist
- 0 oder 1 um zu bestimmen, ob dieses Muster “invertiert” ist, das heisst, wenn hier 0 steht, löst das MIDI-Event das seq24-Event ganz normal aus, wenn hier 1 steht, haben $ON und $OFF vertauschte Bedeutung.
- Eine Dezimalzahl für das MIDI-Kommando. Für mich sind nur wichtig: 144 (Note On) und 128 (Note Off).
- Eine Dezimalzahl für das 1. Datenbyte des MIDI-Events. Bei Note-On/Off ist das die Note, 0 bis 127. Dies sind die Werte aus meiner Tabelle oben, spaltenweise entnommen.
- Zwei Dezimalzahlen für zulässige “von”- und “bis”-Werte des 2. MIDI-Datenbytes. Bei Note-On/Off ist das die “Velocity” (Stärke des Anschlags). Ich nehme jede Velocity, also sage ich 0 für “von” und 127 für “bis”.
Daraus ergibt sich der folgende Eintrag für die erste Sequenz, in meiner Tabelle in der ersten Zeile und ersten Spalte (A1), und auf dem seq24-Screenshot ebenso:
0 [0 0 0 0 0 0] [1 0 144 61 0 127] [1 0 128 61 0 127]
(beachte, dass ich $TOGGLE gar nicht verwende, weswegen da alles auf 0 gesetzt ist).
Mit einem brauchbaren Texteditor sind die restlichen 15 Zeilen schnell daraus dupliziert, man muss nur die “61” im 2. und 3. Block jeweils anpassen. Beispielhaft für die 1. Spalte:
0 [0 0 0 0 0 0] [1 0 144 61 0 127] [1 0 128 61 0 127]
1 [0 0 0 0 0 0] [1 0 144 60 0 127] [1 0 128 60 0 127]
2 [0 0 0 0 0 0] [1 0 144 49 0 127] [1 0 128 49 0 127]
3 [0 0 0 0 0 0] [1 0 144 48 0 127] [1 0 128 48 0 127]
Übrigens, die Version von seq24, die ich hier installiert habe, will aus mir nicht erklärlichen Gründen die Zahl “74” als erste Zeile der Konfiguration, sonst ignoriert er alles, was in der .seq24rc steht und macht es beim nächsten Programmende platt. Darum fängt meine .seq24rc auch so an:
[midi-control]
74
0 [0 0 0 0 0 0] [1 0 144 61 0 127] [1 0 128 61 0 127]
# ... usw.
Im Patch-Panel sieht das ganze dann so aus:
Thumbnails aus allen Bildern im aktuellen Verzeichnis …
27. April 2014 in Administration, GNU/Linux, Multimedia, Programming.
An Introduction to the VI Text Editor
16. Juli 2011 in Administration, GNU/Linux, Multimedia, Programming.
Geometrie erzwingen und EXIF-Orientation korrekt anwenden mit “convert -resize”
26. Juli 2025 in GNU/Linux, Multimedia, Programming.
Nach so vielen Jahren tritt immer noch ein Feature von “convert” zutage, das ich nicht gekannt habe, und bei dem ich mich frage, wie das überhaupt sein kann. Ich musste ein Batch-Skript mit ImageMagick prototypen, das nebst anderem Bilder auf eine vorgegebene Größe skalieren kann. Es seien also folgende Eingaben gegeben:
Pixmap "image_in": das originale Bild
int "width": geforderte Breite in Pixeln
int "height": geforderte Höhe in Pixeln
Als Ausgabe zu erstellen ist:
Pixmap "image_out": das skalierte Bild
Also schreibt man ja wohl
convert -resize ${width}x${height} $image_in $image_out
Das funktioniert auch, mit der merkwürdigen Einschränkung, dass “convert” mit diesem Aufruf das Seitenverhältnis nicht ändert, sondern stattdessen … naja, prinzipiell irgendwelche Breiten bzw. Höhen liefert. Es funktioniert genau genommen überhaupt nicht, bzw. in fast keinem Fall, ausser in denen, in denen das Verhältnis originaler Höhe zu originaler Breite (zufällig) genau dem Verhältnis von geforderter Höhe zu geforderter Breite entspricht. Um genauer zu sein, gibt es eine Systematik darin, wie die Eingabe-Geometrie in die Ausgabe-Geometrie umgesetzt wird, aber diese ist an einer unerwarteten Stelle dokumentiert [1] (wieder so eine Schnitzeljagd-Dokumentation, der man hinterher Googlen muss). Komisch eigentlich! Was ist also zu tun? Nun, wie [1] goldrichtig erklärt, muss der Geometrie-Spezifikation ein “!” nachgestellt werden. An derselben Stelle heisst es auch:
By default, the width and height given in a geometry argument are maximum values unless a percentage is specified.
Aha! 🙂 Also schreiben wir:
convert -resize ${width}x${height}\! $image_in $image_out
Beachte, dass das “! mit einem Backslash vor der Interpretation durch die Bourne Again Shell selbst geschützt werden muss, da “!” zumindest dort eine spezielle Bedeutung hat (nicht aber beispielsweise in der “dash”, der Debian-Auslegung der “POSIX-Shell”, dort bewirkt der Backslash in diesem Zusammenhang nichts, muss also nicht weggelassen werden).
Nicht gerade vereinfacht wird die Sachlage dadurch, dass “convert” in der mir vorliegenden Version bei einem “-resize” von und nach JPEG die EXIF-Orientierung durcheinanderbringt, das heisst, je nach deren Wert kann das Bild um 90 oder 180 Grad gedreht oder gar spiegelverkehrt erscheinen! Hilfreich bei der Auswertung des Wertes von EXIF:Orientation sind [2] und [3], den Wert erhältman mit dem ImageMagick-Befehl “identify”:
identify -verbose "$image_in" | fgrep exif:Orientation
Konkret geschieht bei einem Test-JPEG “IMG_0948.JPG” mit der EXIF-Orientation “6” bei oben beschriebenem Aufruf folgendes (getestet mit ImageMagick Version 6.6.0 auf Debian experimental):
Wie man sieht, verrafft es schon die WordPress-Vorschaufunktion, das Bild ist nämlich von meiner Kamera mit der korrekten EXIF-Orientation ausgestattet worden. Eigentlich sollte es um 90 Grad im Uhrzeigersinn hochkant dargestellt werden. Da ich am Rechner mit dem Original arbeite und einen EXIF-fähigen Viewer verwende (z.B. gliv), bekomme ich davon nichts mit, bis es zu spät ist.
Ich beschäftige mich erstmal mit der Skalierung: Ich will dieses Bild “plattdrücken”, das heisst, unter Berücksichtigung der EXIF-Orientierung soll die Höhe kleiner sein als die Breite. ich sage also:
convert -resize 200x100\! IMG_0948.JPG out.jpg
Das Ergebnis ist:
Das ist jetzt auch ungeachtet der Frage, ob mein Viewer EXIF-Orientation kann oder nicht, falsch. Es wurde nicht die tatsächliche Höhe kleiner als die tatsächliche Breite, sondern es wurden die Ausdehnungen des Bildes ohne Berücksichtigung derer Bedeutung unter Anwendung von EXIF-Orientation verändert: das Ergebnis ist also tatsächlich in die Höhe langgestreckt.
Was ist zu tun, damit dieser Effekt vermieden wird? Zum Glück hat “convert” die Option “-auto-orient”. Diese nimmt die EXIF-Orientierung, dreht und spiegelt das Bild entsprechend und setzt exif:Orientation dann immer auf “1” (TopLeft), was gerade dem Fall entspricht, dass gar keine Orientation angegeben wäre (also kompatibel mit Viewern ist, die keine Orientation berücksichtigen können). Wichtig ist, diese Operation vor dem “-resize” auszuführen, damit dieses dann bereits auf den tatsächlichen Bedeutungen von “Breite” und “Höhe” operiert und nicht auf denen, die EXIF-Orientation noch nicht eingerechnet haben:
convert -auto-orient -resize 200x100\! IMG_0948.JPG out2.jpg
Jetzt prüfe ich das Ergebnis nach:
identify -verbose out2.jpg | fgrep exif:Orientation
exif:Orientation: 1
Es sieht jetzt so aus:
Das ist richtig bzw. der gewollte Effekt.
[1] ImageMagick Website: ImageMagick Command-line Processing: Basic adjustments to width and height; the operators %, ^, and !
URL (10.05.2011): http://www.imagemagick.org/script/command-line-options.php#resize
[2] sylvana.net: Exif Orientation Tag (Feb 17 2002)
URL (10.05.2011): http://sylvana.net/jpegcrop/exif_orientation.html
[3] ImpulseAdventure: Digital Photography Articles: JPEG Rotation and EXIF Orientation
URL (10.05.2011): http://www.impulseadventure.com/photo/exif-orientation.html
IPv6
17. Mai 2025 in Society, Technology.
Stellen wir uns vor, es gäbe ein Gesetz, nachdem alle Hausnummern drei Stellen haben müssen.
Detailliertere Gesetzgebung beträfe die Reservierung spezieller Hausnummern für Infrastruktur (wie die Wasserwerke, Polizei o.ä.), und es gäbe “invalide” Hausnummern ausschliesslich für den privaten Gebrauch usw. Auch die Hausnummer 0 (Null) wäre unzulässig. Natürlich wären drei Stellen in allen Diensten vorgesehen, die irgend etwas mit Hausnummern zu tun haben. Die Post zum Beispiel würde intern mit dreistelligen Dezimalfeldern arbeiten, wann immer eine Hausnummer nieder zu schreiben ist.
Irgendwann wird jedenfalls das Haus mit der Nummer 999 gebaut, und das war’s. Ab jetzt können keine weiteren Häuser mehr gebaut werden. Finito.
Was macht man jetzt?
Es ist völlig klar, dass die Lösung eine vierte (oder fünfte) Stelle bei Hausnummern zuzulassen, so trivial und augenscheinlich sie einem vollkommenen Laien erscheinen mag, absolut nicht in Frage kommt. So stellte sich ja dann schon die unmöglich zu beantwortende Frage, ob diese zusätzlichen Stellen links oder rechts hinzugefügt werden sollen! So geht das nun wirklich nicht!
Stattdessen kommen bereits in der Frühzeit der “dreistelligen Ära”, als es ca. 55 Häuser gibt, sehr kluge Menschen auf die Idee, ein neues, zusätzliches Hausnummernsystem zu entwerfen, das 12-stellig ist. Viele Wissenschaftler und Techniker finden diese Betätigung sehr zukunftsträchtig und interessant und gesellen sich dazu. Recht bald ist ein System zu Papier gebracht worden, das mit Hausnummer-Präfixen arbeitet, von denen manche reserviert sind, andere rückwärts geschrieben werden oder werden dürfen, ausserdem darf man jedes beliebig vielmalige Auftreten der Zahl “6” zu einer einzelnen “6” zusammen kürzen, und man darf die Ziffer 0 auch weglassen, somit wird aus der Hausnummer 666066606660 ein einfaches “666”. Diese neuen Hausnummern sollen zusätzlich zu den alten Hausnummern an den Häusern angebracht werden. Jeder Postbote bekommt eine Schulung darin, wie er einen Brief, der nach dem alten Format adressiert ist, an eine neue Adresse ausliefert und umgekehrt, und die Post schafft sich intern eine zweite EDV an, so dass sie gleichzeitig das alte und das neue Format verwalten kann. Die Erfinder des neuen Systems bauen sich einen acht Kilometer hohen Turm aus Ebenholz voller kerzenbestückter Kronleuchter, Ritterrüstungen und nach Möbiusart verschlungener Gänge, und jeder, der etwas von ihnen will, muss erst mit dem Pförtnerdrachen sprechen.
Das ist dann die Lösung.
Array-Arithmetik in PHP
11. Januar 2015 in Programming.
Wirklich komisch finde ich das Ergebnis einer “Addition von Arrays” in PHP.
<?php
$a = array(101,20,31);
$b = array(19,42,300,101);
$c = $a + $b;
$d = array_merge($a,$b);
echo
'[a=('.implode(',',$a).')] + '.
'[b=('.implode(',',$b).')] = '.
''."\n";
echo
'array_merge(a,b) = '.
'[d=('.implode(',',$d).')]'."\n";
?>