ich hatte mir ja im Vorfeld überlegt, was für ein Publikum vermutlich auf der FrOSCon herumläuft; dem entsprechend war der Vortrag auf »Allgemeinbildungs-Niveau« angelegt.... (was allerdings auch bereits für Benny eine erhebliche Herausforderung war, also vermutlich auch für andere Leute)

in die Sektion: Research

...mein langfristiger Plan: ich will eine Knowledge-Base schaffen

neues Git-Repo nur für den Demo-Code anlegen

verwende qrencode

Es war von Anfang an klar, daß wir speziell dieses Thema selber unter Kontrolle bringen müssen.

Christian hatte seinerzeit ein MMAP-Backend implementiert. Ich folge dem gleichen Ansatz, gehe aber mit der Linux-Kernelentwicklung mit...

was wir zeigen können

Die Liburing hüllt das eigentliche Ringbuffer-Interface ein, so daß man gar nicht mehr direkt mit den Ringbuffern zu tun hat. Was schön ist, aber man muß die Ringbuffer verstanden haben! Im Besonderen die Submission helpers sind Konfigurations-Funktionen, die eienen Submission-Queue-Entry ausfüllen mit passenden Parametern. Damit sind sie wieder so etwas wie eine funktionale Form der Kernel-calls, aber eben verzögert / geplant. Den eigentlichen Aufruf macht man dann mit io_uring_submit(ring);


  

IO_URING kann errno nicht sinnvoll direkt verwenden (errno ist eine globale variable)

man setzt einen Socket auf "asynchron". Durch cleveres Polling bekommt man mit, wann die IO-Operation »ready« wird. Aber das ist readyness-semantics, not completion-semantics. Und es ist sehr limitiert, und setzt eine komplexe State-Machine im Userland vorraus

Arbeitet in einem speziellen Modus, IO_DIRECT

Kann nur bereits allozierte/ geöffnete Files bearbeiten

kann nicht mit generischen Sockets arbeiten ⟶ auch kein Networking

geht am Page Cache vorbei

Aus einem Kommentar auf LWN

https://lwn.net/Articles/810898/

What it says about the state of hardware is easy.

Meltdown mitigations made context switching more expensive, and SSDs made the actual I/O cheaper. At some point, you're spending almost as much time context switching as you are doing actual work, and there's nothing Linux can do about it because it's all tied up in the architecture of the MMU and the processor's cache. Thus, it now makes sense to design the interface around reducing the number of context switches at all cost, instead of just assuming that the cost of doing the actual I/O will dominate.

extended Berkeley Package Filter: ein Framework, das Code als Reaktion auf Events direkt im Kernel-Kontext ausführt

Es wurde alsbald erheblich als Einfallstor für Exploits genutzt, da das bestehende Security-Tooling diese neuen Mechanismen überhaupt nicht »auf dem Schirm« hat. Im Jahr 2023 hat das Google-Security-Team 60% aller Linux-Exploits dem IO_URING subsystem zugeordnet. Daher ist es auf Android und ChromeOS und unter Docker in der Standard-Konfiguration deaktiviert (und hat einen schlechten Ruf unter den »Oldtimern«)

  • adoption is rising
  • io_uring is not going away anywhere soon

...denn das bedeutet, da ist nichts »mainstreamiges« unterwegs, von dem ich noch nichts wüßte.

AsyncIO für sehr hohen throughput

also ehr im Bereich von Millionen Requests / sec

deshalb war die Behandlung von Files stets etwas asymetrisch. Auch wenn der Socket ready ist, kann er dann doch noch blocken, wenn das System unter Druck steht.

man kann auch mehrere Einträge hinzufügen und dann antriggern

dann erkennt der Kernel sebständig, wenn was neues in der Queue ist

....vermutlich wird der Buffer-Speicher einfach geeignet auch in den Kernel-Space gemapped; jedoch das Setup mit den Command/Completion-Ringbuffern isoliert den User komplett von diesen Fragen. Sehr geschickt!

struct iovec {
     void  *iov_base;    /* Starting address */
     size_t iov_len;     /* Number of bytes to transfer */
};

Im Submission-Ringbuffer liegt nur eine Index-Nummer, die in ein daneben stehendes weiteres Array zeigt. Im Tutorial heißt es, das sei so konstruiert worden, um Applikationen zusätzliche Flexibilität zu geben (was ich nicht wirklich verstehe, da ja auch das externe SQ-Array im mmapped-mem liegen muß)

damit man zu Beginn die neuesten Updates vom Kernel mitbekommt, und am Ende dem Kernel die neue Schreib/Lese-Position sichtbar gemacht wird

im Tutorial-Beispiel: io_uring_prep_readv() füllt einen SQ-Entry passend aus für eine readv-Operation

weil der Buffer shared in den Client-Process-Space gemapped ist, muß der Kernel keine Daten mehr explizit in den Ziepuffer im Prozeß kopieren

Ist notwendig für andere Sprach-Bindings oder ältere Compiler; dadurch hat dann natürlich jeder Call einen Overhead

...also eine kleine State-machine implementieren: Completion-Entries entgegennehmen, schauen ob komplett und partiell, partielle nochmal auf den Weg schicken, Komplette am Buffer markieren. Danach würde die Render-Aktion laufen, und lediglich schauen, ob die Daten in »ihrem« Buffer schon da sind. Alles per Modulus gesteuert.

der sollte dann die gleiche Größe haben wie der Kernel-Ringbuffer; man würde damit einen Task sofort in den passenden Buffer-Slot schicken

Damit das funktioniert, muß sich das System selbst beobachten: einen EMA für den IO-Vorlauf; entsprechend viele Zyklen vorher eine neue IO-Aktion auf den Weg schicken.

letztes Jahr haben wir vier verschiedene Varianten gezeigt, die jeweils unterschiedliche Lib-Dependencies hatten. Deshalb war es ein Multimodule-Projekt. Das kann ich diesmal vereinfachen in ein einziges Projekt

Hatte immer die Fehlermeldung "build misconfigured" (o.ä). Hab lange rumgesucht, denn alle Settings waren effektiv gleich wie beim »VideoOutput«-Projekt. Bis ich dann im .project-File gesehen hab, daß auch noch ein C-Builder konfiguriert worden war (möglichweise ein Toolchain-Default).

die Zuhörer sind keine Systemprogrammierer

Der Desktop läuft mit z.B. 60fps, das video mit 25fps. Man sollte akzeptieren (und im Talk klar machen) daß das niemals aufgeht. Vielmehr sollte man regelmäßig die fertig geladenen Frames übergeben, wenn sie eben da sind. Für den Talk schlägt Claude vor, das Thema "tearing" mehr oder weniger zu ignorieren (hatte ich nicht gesagt, sehe ich aber genauso). Später, für die Prod-Version sei das ein nicht-trivialer Aspekt

...das sei zwar nicht notwendig (korrekt!), aber vermeide Komplexitäten. Ein OpenGL-Kontext ist an einen Thread gebunden, also müßte man nach jedem Thread-Wechsel umbinden.

⟹ sehr gut, damit hat sich eine Frage von selber geklärt, die ich noch stellen wollte

allerdings: der Worker wäre damit ein Proactor

....es wäre nämlich tatsächlich dann ganz ideomatisch (so hab ich die Doku verstanden, und Claude sagt das von sich aus auch).

Zwar hatte ich die Idee, im Talk schon grundsätzlich etwas zu machen, was funktioniert wie in Lumiera geplant. Aber wenn ich mir das wirklich vom didaktischen Gesichtspunkt her nochmal überlege, ist es nicht so geschickt.

...es würde zur "toolkit, nicht framework"-Policy passen, und zudem wäre das Signal explizit von jedem Thread aus triggerbar

  • As an aside: do I assume correct that the OpenGL side will just redisplay the same data if nothing is sent for intermittent buffer flips (assuming that the desktop frame rate is higher than the video frame rate)?

Your aside — yes, and here's the actual mechanism: with swap interval 0 and swaps only triggered by frameReady.emit(), you are not relying on OpenGL to "resend" anything between your swaps — OpenGL/EGL has no ongoing activity at all in between. What actually keeps the picture on screen is the desktop compositor: once eglSwapBuffers() makes a buffer the current front buffer, that's simply what's there until you swap again, and the compositor samples it at its own repaint cadence (its vsync, typically 60Hz+) regardless of whether your app does anything. So your assumption holds, but the credit belongs to "a swapped buffer is persistent state the compositor keeps re-showing," not to any active redisplay behavior on your side — a good one-sentence clarification to have ready if someone in the audience asks "wait, doesn't something have to keep pushing frames?"

// --- GUI thread, once at setup ---

Glib::Dispatcher frameReady;

frameReady.connect([this]{ displayFrame(*processor_); });  // upload + draw + eglSwapBuffers()

// --- worker thread, once a frame is ready ---

frameReady.emit();   // thread-safe; wakes the GUI thread's main loop

ich habe das Stichwort "Proactor" gebraucht. Claude bestätigt das

das heißt: die Lösung, auf die es nun für den Talk hinausläuft, ist daß ich nicht wirklich einen "Worker" hab (kein Vorgriff auf die Lumiera Engine), sondern einen Proactor.

Darauf wäre ich nicht gekommen; ich hätte an meinem von Lumiera abgeleiteten Schema festgehalten....

Claude betont, das wäre idiomatisch und würde die Proactor-Loop ins Zentrum stellen. Das überzeugt mich ⟹ werde dann also doch einen Proactor in der Demo zeigen

Ich verwende das aktuelle "Sonnet" auf Stufe Medium. Das braucht erhebliche Rechenzeit für jede Antwort auf diesem Diskussionslevel (und zeigt auch jeweils expandierende, schlußfolgernde und kondensierende Phasen an)

Proactor, confirmed. io_uring is the textbook proactor: you submit a description of the completed operation you want, the kernel does the work, and your thread's job is purely to consume results and act on them — as opposed to a reactor (epoll-style), where you're told "this fd is ready," and you still perform the (potentially blocking, now guaranteed-non-blocking) I/O yourself. Good instinct to name this explicitly in the talk; it's the single sentence that makes the rest of the design legible.

On the "abstraction of state progression" claim — I think it's correct, but I'd collapse your four options into two families rather than four separate things:

  • Implicit state, paid for in threads. Thread-per-operation blocking I/O doesn't avoid needing a state machine — it hides one inside the OS thread: the thread's stack and program counter are  the state ("I am here, at this line, holding these locals"). You get state-tracking for free, but you pay for it in thread/stack cost per concurrent operation, which is exactly what proactor-style async I/O exists to avoid.
  • Explicit state, paid for in bookkeeping. Everything else — hand-rolled flags, continuation chains, and coroutines — is the same  idea at different levels of automation. A coroutine is, mechanically, a compiler-synthesized state machine: co_await points become case labels, locals that need to survive a suspension become member fields of a generated struct. Continuation-passing is the same thing done by hand with closures instead of compiler codegen. So "coroutines" and "explicit state engine" aren't really two different answers to your question — a coroutine is an explicit state engine, just one you didn't have to write by hand.

Given that framing: you're right that a flag-per-buffer is not a lesser or simplified version of "the real solution" — it's the same solution as coroutines, just written manually because your problem is small and linear enough that the compiler-generated version would be pure overhead (both in runtime terms and, more importantly here, in audience cognitive load — introducing C++20 coroutine machinery to explain a 3-state pipeline would be a bad trade for this talk).

std::atomic<SlotState>

Since each slot has exactly one producer (the worker) and one consumer (the GUI thread, via the dispatcher callback) and they never touch a slot at the same time by construction,

std::atomic<SlotState> with release-on-write / acquire-on-read is enough — no mutex needed. That pairing is worth a beat in the talk on its own: the atomic isn't there to prevent concurrent writes (there aren't any), it's there to guarantee the GUI thread sees the buffer contents the worker wrote, not just the state flag — a clean, concrete illustration of why acquire/release exists, tied directly to something the audience just watched you build.

The ring idea is correct, and it's the right way to lay out storage — but it solves a different problem than the one we flagged last time, and I think that's the thing worth pulling apart carefully, because the two compose nicely rather than one replacing the other.

What the cyclic layout gives you: a deterministic mapping from frame number to physical buffer — slot = frameNumber % N — so you never need a free-list, an allocator, or any "find me an empty slot" search. You always know exactly where frame K's data belongs before you even submit the read. That's a clean, standard pattern and exactly right for a fixed pool of reusable buffers.

What it does not give you for free: the display-order guarantee. The ring tells you where frame K's bytes live; it says nothing about when the read for frame K finishes relative to the read for frame K+1. Two SQEs submitted in order are not guaranteed to complete in order — for sequential reads against one local file on one machine it's very likely in practice, but "likely" is exactly the kind of unverified pragmatism you just said you don't accept. So you still need the mechanism from last time: track which frame is next expected for display, and only emit() once that specific slot says Ready  — regardless of what else has completed in the meantime.

  • Keep one cursor, nextExpected (monotonically increasing, starts at 0). On every completion, mark slots[frameNumber % N] as Ready. Separately — and this can literally be a small loop, since bursts of completions can land between two checks — while slots[nextExpected % N].state == Ready: emit the dispatcher for that slot, mark it Empty  again, ++nextExpected.
  • The same nextExpected-style counter also tells the submission  side what to do: whenever a slot frees up (goes back to Empty  after display), submit a new read for nextToSubmit, into slots[nextToSubmit % N], ++nextToSubmit. Priming at startup is just: submit frames 0..N-1 into slots 0..N-1 before the first wait_cqe.

...obschon man sie auf dem gleichen lokalen State aufbaut. Das Beispiel, das Claude nennt: man könnte das Quellfile loopen

struct io_uring ring;

io_uring_queue_init(QUEUE_DEPTH, &ring, 0);

// One reserved tag that can never collide with a real frame number:

constexpr uint64_t TICK_TAG = UINT64_MAX;

// The periodic beat — submitted ONCE, keeps firing on its own:

struct __kernel_timespec ts = { .tv_sec = 0, .tv_nsec = 40'000'000 }; // 40ms ≈ 25fps

struct io_uring_sqe* tsqe = io_uring_get_sqe(&ring);

io_uring_prep_timeout(tsqe, &ts, 0, IORING_TIMEOUT_MULTISHOT);

io_uring_sqe_set_data64(tsqe, TICK_TAG);

// Prime the pipeline — one read per slot, tagged with its frame number:

for (uint64_t f = 0; f < N; ++f) {

    struct io_uring_sqe* sqe = io_uring_get_sqe(&ring);

    io_uring_prep_read(sqe, fd, slots[f % N].buf, FRAME_BYTES, f * FRAME_BYTES);

    io_uring_sqe_set_data64(sqe, f);

}

io_uring_submit(&ring);   // one syscall flushes everything prepped above

for (;;) {

    struct io_uring_cqe* cqe;

    io_uring_wait_cqe(&ring, &cqe);      // blocks — the worker's only wait point

    uint64_t tag = cqe->user_data;

    if (tag == TICK_TAG)

        onTick();

    else

        onReadComplete(/*frame=*/tag, cqe->res);

    io_uring_cqe_seen(&ring, cqe);       // MUST always call this, or the CQ ring fills and stalls

}

void onTick()
  {
    if (slots[nextExpected % N].state == Ready)
      {
         frameReady.emit(); // GUI thread will draw slots[nextExpected % N]
        ++nextExpected; // GUI marks the slot Empty once it's done drawing
      }
  // else: do nothing — this frame slips one tick later. Not dropped, just delayed.

  while (slots[nextToSubmit % N].state == Empty)
    {
      submitRead(nextToSubmit); // io_uring_prep_read + set_data64(nextToSubmit)
     ++nextToSubmit;
    }
  io_uring_submit(&ring);
}
      
    

The reason top-up belongs in onTick rather than in onReadComplete:
a slot only becomes reusable once the GUI thread has finished drawing it and flips it back to Empty  — and the worker, sitting blocked in io_uring_wait_cqe, has no way to know that happened except by waking up for something. The tick is that guaranteed periodic wake-up, so it doubles as "check if there's new capacity to fill," with a worst-case latency of one tick period (~40ms) before a freed slot gets reused — fine at this cadence, and a nice illustration that the timer isn't just pacing display, it's also the thing that keeps the whole state machine alive even when nothing else is happening.

  • can you write me a short inline function that takes the "40 millisecods" as a std::chrono spec ("40ms") and returns the struct __kernel_timespec

#include <chrono>

#include <linux/time_types.h>   // struct __kernel_timespec (also pulled in via liburing.h)

template<class Rep, class Period>

constexpr struct __kernel_timespec

toKernelTimespec(std::chrono::duration<Rep, Period> d)

{

    using namespace std::chrono;

    auto secs  = duration_cast<seconds>(d);

    auto nsecs = duration_cast<nanoseconds>(d - secs);

    return __kernel_timespec{ static_cast<long long>(secs.count()),

                               static_cast<long long>(nsecs.count()) };

}

auto ts = toKernelTimespec(40ms);

er hat dazu keine weiteren Fragen

bestätigt meine Analyse, ohne Diskrepanz

As far as I could see from looking at the liburing sources, there is a fundamental read barrier before retrieving/updating the rings, and a write barrier at the other side (when done with a completion or submitting). Now you also pointed out the conclusion that submitting the next IO task could itself be a scheduled activity. Combining both, if we ensure that interaction with io_uring happens only in the "mutual exclusive" phase (i.e. the worker holds the GroomingToken) -- then that would ensure that, at any given time, only one thread at max interacts with the urings. And Liburing inserts the necessary barriers, so that the next task to enter that zone would see the changes. Does that reasoning hold? What difficulties do you see?

Ja, weiß ich. Deshalb hab ich's so programmiert. Freut mich daß Claude da unabhängig zum gleichen Schluß kommt (denn ich hab mich oft gefragt, ob ich mich da in Spitzfindigkeiten verrenne).
Also nochmal explizit: memory_order_relaxed reicht hier nicht

Einmal geht es um shared-data zwischen Kernel und Userspace. Wohingegen das Grooming-Token die Sichtbarkeit über die Worker hinweg steuert.

Diese Unterscheidung ist konzeptionell (sehe ich so, Claude deutet es auch so). Beide Ansätze stören sich nicht, man sollte sie aber auseinanderhalten. Ich denke, das ist ein generischer guter Rat beim Design solcher Systeme, man sollte nicht danach streben, solche verschiedenen Belange zusammenzufassen, selbst wenn es im konkreten Fall möglich wäre (wie hier der Fall, aber nur weil keine data-dependenciy im memory-ordering includiert ist)

That's a much bigger problem than in the FrOSCon demo, where blocking on

wait_cqe was the worker's entire job. Here it would reintroduce exactly the kind of global stall your pull architecture is designed to avoid. The fix is straightforward but needs to be deliberate: only ever use the non-blocking io_uring_peek_cqe()  inside grooming — check if anything's ready, harvest what's there, submit what's ready to submit, and move on regardless of whether anything was found. That keeps the ring interaction cheap and bounded, consistent with a critical section that's already supposed to be short.

CQ overflow: if grooming genuinely doesn't run for a while under heavy CPU load, does a full completion queue drop completions, or buffer them? Recent kernels buffer overflow internally rather than dropping (subject to

IORING_FEATURE_NODROP-era behavior), but it's worth confirming for whatever kernel baseline you commit to, rather than assuming.

Deliberately avoid IORING_SETUP_SQPOLL

Deliberately avoid

IORING_SETUP_SQPOLL. It's tempting since it removes the need to call into the kernel for submission most of the time, but it works by adding a kernel-side polling thread that reads the SQ ring on its own schedule — an actor outside your GroomingToken discipline and outside your capacity self-calibration entirely. That's exactly the kind of uncontrolled independent actor your architecture is built to avoid.

Net: I think folding I/O into the same single-threaded grooming discipline you already have is the

consistent choice, not a compromise — you've already accepted one global serialization point for scheduling decisions, and a small, non-blocking peek/submit pair is cheap enough to ride along in that same section without becoming a new bottleneck category. The real design work is less "is this safe" (I think it is, modulo the ordering-semantics check and the non-blocking discipline) and more "how do we know, empirically, that grooming-section latency stays small enough once I/O bookkeeping is added" — which sounds like exactly the kind of thing you'd want numbers for before committing, rather than reasoning about further in the abstract.

Current 2 — thread-per-core, shared-nothing, and it's picking up real steam. This is the more consequential trend to be aware of, because it's a genuinely different answer to the same problem you're solving, and it's currently the fashionable one in high-performance I/O-heavy systems: pin one thread per core, partition data and work by that core (typically via hashing), eliminate cross-thread shared state entirely, and communicate exclusively via message passing rather than shared queues or locks. This is the architecture behind ScyllaDB and Redpanda via the Seastar framework, and it's spreading into the Rust ecosystem too (Glommio, compio, and others). A recent writeup from the Apache Iggy project frames the shift precisely as moving from work stealing to "work steering" — i.e., instead of idle workers reaching into a shared structure (what you have), work is routed to the specific core that already owns the relevant data, and nobody has to contend for anything. Interestingly, the standard advice against a single shared io_uring instance per application is exactly the contention concern we discussed for your ring — each thread in Glommio gets its own private set of rings instead, which is the thread-per-core answer to the same "who owns the ring" question you and I just spent a while on. Apache + 2

Even more directly relevant to your capacity-calibration idea: Glommio ships built-in "controllers" that automatically adjust per-task-queue scheduler shares to control throughput against a user-specified criterion — that's essentially your self-calibrating capacity-weights idea, independently arrived at by a different team solving an adjacent problem. Worth knowing that's not an idiosyncratic idea of yours — it's something the field has landed on more than once, which is generally a good sign for an architectural instinct.

Rust

Where I'd place your design relative to these two currents: your GroomingToken-serialized shared-scheduler model sits closer to "classic" worker-pool architecture than to shared-nothing thread-per-core — and I think that's the right call for Lumiera specifically, not a lag behind the state of the art. The strongest argument for thread-per-core is when per-request overhead is so small (network request handling, KV-store lookups — sub-microsecond territory) that even brief lock contention or cache-line bouncing dominates the cost. Your own numbers — single-digit milliseconds up into seconds per frame task — are three to six orders of magnitude coarser than that regime. A brief critical section for grooming and ring bookkeeping is genuinely negligible next to task costs measured in milliseconds; it would not be negligible next to costs measured in tens of nanoseconds, which is the world Seastar/ScyllaDB actually live in. So I wouldn't read "thread-per-core is trendy" as pressure to abandon your model — I'd read it as: the technique exists and is well-proven if your task granularity ever drops by several orders of magnitude (which, for a video render engine, seems unlikely — your bottleneck is decode/filter/encode work, not tiny message dispatch).

One trend worth just keeping an eye on, not acting on: core counts keep climbing — high core-count workstation and consumer chips are increasingly normal — and any single serialization point gets proportionally more expensive as contention scales with thread count, even if each individual crossing is cheap. Not a problem today, and your task granularity buys you a lot of headroom, but it's the kind of thing worth having empirical data on (exactly the "more empirics needed" conclusion you already reached) if Lumiera is ever deployed on genuinely large core counts rather than typical desktop/workstation counts.

Lumiera könnte ja schon auch auf eine high-end-Workstation laufen

von Claude erwähnt im Zusammenhang mit Locking visibility. Er weist auch darauf hin daß io_uring keine multiple thread submissions unterstützt. Zu dem Schluß war ich ja auch gekommen

der Kernel kann nicht zaubern; stattdessen hat er dann einfach einen poll-Worker. Keine gute Idee in einer Architektur die selber alle Resourcen steuern möchte

Wayland/X11

Your instinct is basically right, but I'd sharpen "not too deep" a bit: the EGL calls that matter for your loop — eglCreateContext, eglMakeCurrent, eglSwapBuffers — are identical either way. What differs is only the step just before eglCreateWindowSurface, i.e. how you obtain the native window handle from GDK:

  • X11: you already have this — gdk_x11_window_get_xid() gives you a raw Window XID directly usable as the native window type.
  • Wayland: GDK gives you a wl_surface* (gdk_wayland_window_get_wl_surface()), but EGL on Wayland doesn't accept that directly — you have to wrap it with wl_egl_window_create() (from libwayland-egl) to get something usable as EGLNativeWindowType.

So it's genuinely a small, well-isolated patch of platform glue — a handful of lines, gated behind a runtime check of which GDK backend is active (GDK_IS_X11_DISPLAY / GDK_IS_WAYLAND_DISPLAY) — everything downstream of surface creation is untouched.

aber man sollte konzeptionell zwischen der visibility mit dem Kernel und der Visibility zwischen den Workern unterscheiden; für ersteres gibt es die Barrieren in Liburing

der Umstand daß neue IO-Aktivitäten gescheduled werden und Completions entnommen werden müssen, garantiert nur eine passive Backpressure (nicht entnommene Completions gehen nicht verloren, und der Platz in den URings ist begrenzt). Sehr wahrscheinlich ist mehr notwendig, damit die Engine rund läuft.

Es ist eine etablierte und bewährte Methode, und wird nicht weggehen. Was wir geschaffen haben konvergiert gut mit den allgemeinen Einsichten im Feld

das ist ein Gegentrend, der aber auf einer anderen Größenordnung arbeitet (im Nanosekunden-Bereich)

Hier möchte ich sowohl den GTK-Code selber verbergen, alsauch dem Umstand daß die Start-Lokik in der Applikation nicht ganz trivial ist, und mit dem Start des Players verwoben. Lesbarkeit ist eine weitere Motivation: man kann dadurch Dinge benennen

dazu gehört auch, keine »Tricks« anzuwenden und keine schlechten Praktiken vorzuführen. Der Zustands-Träge sollte unique sein, ohne Wenn und Aber.

...es war nicht so, daß Claude diese „Idee gehabt“ hätte — denn ich hatte die Konversation ja so geführt, daß Claude mir meine Konzept-Ansätze validiert und verfeinert. Dann habe ich das Prinzip formuliert, daß für Async-IO irgendwo eine State-Machine sein muß. Claude hat das aufgegriffen, validiert und verschärft; und damit war offensichtlich geworden, daß man diese State-Flag als Atomic auslegen kann. Das habe ich in dem Moment genauso »offensichtlich« gesehen, und Claude hat es ebenso formuliert.

Warum ich hier nochmal nachzeichne, wie das zustandegekommen ist:

  • weil ich allein da nicht draufgekommen wäre
  • aber weil es offensichtlich nicht von Claude stammt

⟹ das wirft ein Licht darauf, wie dieses scheinbar intelligente »Generieren« funktioniert, auf Basis einer industriellen Daten-Technik, die Plausibilitäten integriert und interpoliert.

hier muß auch die Backpressure beachtet und realisiert werden

Sofern er aus dem GUI-Thread alloziert wird, also bevor der Proactor-Thread startet, ist die Position für beide Threads sichtbar (und unveränderlich)

Diese wäre dann ebenfalls teil der cross-Trade-Synchronisation (ebenfalls bewirkt durch release-Semantik auf dem State-Atomic)

...nur als lokale Variable, die er jeweils hochzählt, wenn er einen Trigger bekommt (Nachteil: duplizierter State, dessen Konsistenz sich nur implizit ergibt und nicht offensichtlich ist)

Das wäre dann ein Pointer (const void *); seine Sichtbarkeit ergibt sich auch hier aus dem atomic-State

...da ich immer in Zuständigkeiten denke, ist es mir unsympatisch, einen Satz gemeinsamer Zustands-Variablen zu verwenden

...das gilt für ein Prod-System, in dem der Speicher framentiert ist, und man vermutlich Buffer-Pools hat

Für die Demo ist das die offensichtliche Lösung: man bekommt unique-ownership und Subscript-Operator einfach vom std::unique_ptr. Wenn man den notwendigen Speicher nicht bekommt, dann läuft die Demo eh nicht, also wozu die Umstände?

heißt: hier gibt es keine Möglichkeit, ein Auge zuzudrücken

Eine Operation zum Zugriff und eine Operation um den abgeschlossenen Zugriff zu markieren; zudem gibt es auch noch den Dispatcher.

Mehrere Argumente dafür: man könnte die low-level-Flags setzen (wie O_CLOEXEX, O_NOFOLLOW, oder gar O_DIRECT). Das Öffnen ist atomic,  d.h. das File kann nicht mehr gelöscht/verschoben werden beform man das Filehandle hat (was bei einem getrennten STAT und Path-Check durchaus möglich ist)

Begründung

  • da wir stets in bulk die Submissions hinzufügen und erst danach (synchronisiert) den Output antriggern, können das maximal so viele Einträge sein, wie wir Buffer haben
  • zusätzlich wird ein Eintrag benötigt, um am Anfang auch den periodischen Timer in Gang zu setzen
  • eben dieser eine zusätzliche Eintrag genügt auch, um jeweils noch ein Timer-Event zu empfangen
  • weitere Completions können nicht kommen, da wir nicht mehr Submissions abgeschickt haben
  • weitere Timer-Events könnten kommen, falls wir zum Entnehmen und Übergeben mehr als einen Timer-tick brauchen (unwahrscheinlich, aber nicht auszuschließen). In einem solchen Fall würden schlimmstenfalls hinten weitere Timer-Events „runterfallen“ (wobei aktuelle Kernel ein internes Backlog haben). Sollten wir dergestalt Timer-Events verpassen, sind sie aber auch schon überholt, und das nächste reguläre Event wird uns wieder weiterschieben

verwende hier den zweiten Cursor: nextShow_

...und zwar via Glib::Dispatcher ⟶ GUI-Thread.

Der zugehörige Handler-Code läuft dann bei nächster Gelegenheit in der GUI-Event-Loop, und holt sich per Callback (Interface PixelFeed) die Daten; in diesem Callback muß die Read-Barrier realisiert sein, damit der GUI-Thread alle vor diesem Punkt erfolgten Datenänderungen auch tatsächlich sieht

Beachte: das darf erst hier passieren, weil wir hier den nächst niedersten erwarteten Frame anschauen; da wir immer etwas im Voraus lesen, werden wir auch ein end-of-File schon einige Ticks früher markieren, müssen aber die Schleife noch solange weiterlaufen lassen, bis die letzten erfolgreich gelesenen Frames in die Anzeige übertragen wurden

brauche doch einen 3.Cursor: currShow_

also brauche ich die cross-Thread-Barriere erst hier

In der Chase-Phase werden blank-Frames ausgegeben, solange bis wir Frames mit genügend Vorlauf im Speicher haben. Danach, in der Lock-Phase ist eine Relation zwischen der rotierenden Buffer-Position und dem aktuellen Flip gesetzt. Ab dem Punkt kann man N Frames im Voraus die IO-Aktion losschicken.

Zu Beginn schicken wir M Frames auf den Weg; die brauchen u.U länger. Schön wäre es natürlich, wenn man diesen Selbs-regulierenden Mechanismus auch live zeigen könnte

also keine explizite Steuerung

ist jeweils nur möglich wenn der dafür vorgesehene Buffer bereits frei geworden ist

Ist nur möglich wenn diese Daten für den erwartungsgemäß nächsten Frame bereits da sind, und der unmittelbar vorausgegangene Frame schon komplett vom Video-Displayer übernommen wurde

im State SHOW pasiert jetzt gar nicht mehr das Display, sondern es bedeutet nun, daß der Frame weitergegeben werden muß

suche einen 4-Buchstaben-Namen, da bin ich Ästhet. PUSH wäre auch denkbar, natürlich wäre PROPAGATE viel korrekter ;-)

...anders als bei dem Video-Output-Thema, bei dem wir uns die zentralen Element überhaupt erst aufschließen mußten, und dies nur mithilfe bestehender GPL-Codebasen geschafft haben. Diesmal ist die Situation ganz anders, das Thema ist ziemlich gut in Tutorials und Blogs aufbereitet. Viele haben zwar kein brauchbares Lizenz-Statement, aber andererseits ist die Aufgabe so einfach, daß ich nirgends Code abschreiben muß, den ich nicht auch genauso selber schreiben könnte.

  • es schaut ja eh keiner auf unseren Beispielcode. Da mach ich mir keine Illusionen. Der Code ist für "uns" selber später wichtig....
  • wer interessiert sich überhaupt noch für LIzenzen, die AI stiehlt ja sowiso alles, und Jedermann kann behaupten, er hätte seine Weisheit von einem LLM.

mein Bauchgefühl: GPL

Das ist ein politisches Statement. Das ist wichtiger denn je

Der Vollständigkeit halber: es gibt den Unterschied zwischen negativer Freiheit und positiver Feiheit; letztere ist der Entschluß zu einer klar formulierten Vision. Die GPL formuliert hierzu die »vier Freiheiten«. Dahinter steht das Ideal des Gemeinwohls. Das muß leider verteidigt werden gegen Ausbeutung und Veruntreuung.

...und der beruht, transitiv argumentiert, nicht nur pro-forma, sondern auch dem Geist nach auf Publikationen unter Copyleft

...so daß es höher steht als das Ubuntu-Paket, aber von einem offiziellen Ubuntu-Paket der gleichen Version ersetzt würde

sonst scheitert der Build womöglich noch....

wenn überhaupt, würde ich den Build später in einem Docker-Container wiederholen;

für die PPAs dagegen wäre mein angepaßtes Source-Paket so wie es vorliegt grade richtig (signiert, ohne Binaries)

Quellen auch kopiert; das Binary tut drüben ohne Weiteres auch...

das Trac startet nicht auf dem Laptop. Habe keine Zeit mehr zur Untersuchung. Daher meine Idee: versuchen, das aktuelle Debian-Paket in einem Ubuntu-Image gebaut zu bekommen

Explanation of the Assignment:

arrange a given MIDI file

es ist komplex und verwendet viele Effekte — und ist (wenn ich Will recht verstehe) "not really contemporary"

Vivaldi's Concerto in D minor for two violins and obbligato violoncello, Op.3, No.11 (RV 565)

Ich würde natürlich nur das Präludium nehmen...

...das war schön für mich, ist aber nicht wirklich hilfreich....

  • weil meine Instrumente eigentlich ein Sound-Matering erfordern
  • der Sound recht ungewohnt ist — ganz bestimmt nicht »cool«

das ist zwingend, denn unsere geplante Demo des Arrangierens soll diesen Ansatz zeigen

und entschieden wird ganz nüchtern, gemeinsam

getriggert wird es, wenn der vorherige Note-off nicht direkt mit dem nächsen Note-on aligned, aber sehr kurzzeitig davor endet. Bei mir ist das entstanden aus dem Time-Stretching der zunächst per Grid eingegebenen MIDI-Noten. Und weil Ardour immer noch nicht seine off-by-one-Probleme im Griff hat. Das müssen wir in Lumiera besser machen!!!

letzten Endes haben wir nur eine Demo gemacht,

und etwas von Lorenzo's Stück (auszugsweise) gespielt

für mein Arrangement war da gar kein Platz, was mir aber auch recht war (das wäre anders gewesen, wenn wir einen richtigen Workshop mit ausreichend Zeit gehabt hätten)

paßt nicht zum Charakter der Veranstaltung

...und wir sind nochmal alles durchgegangen und haben unser Demo-Material ausprobiert.

...hab ich versucht, aber in ganz München nicht mehr bekommen. Lindberg hätte es gehabt, ist aber im Konkurs. Music-Shop hatte nichts, hat auch bei der Konkurrenz in Pasing angerufen. War dann ein nettes Gespräch mit einem andern alten Musik-Hacker :-)

weiter nicht schlimm ... das passiert vielen Leuten, deshalb gibt es das in Irland in jedem "convenience store"

In dem Fall bedeutet das konkret, daß man in München bereits durch eine Sonderkontroll-Zone gelotst wird, nachdem man duch den Security-Check durch ist. Auch der Security-Check ist schon auf einer anderen Ebene. D.h. man wird hier durch die Kanäle für echtes Ausland geschleust. Dann gibt es aber überall Abkürzungen, da Irland zwar kein Schengen-Staat ist, aber letztlich doch EU. Insgesamt wurde in München meine Identität 5 mal unabhängig gecheckt. Bei der Gepäckabgabe, am Security-Check, dann im Ausreisecheck mit automatischer Biometrie-Erfassung in einer Schleuse. Danach nochmal an einem Checkpoint durch die Polizei. Und am Gate ein weiteres Mal, durch das Lufthansa-Personal. Alles sehr freundlich, aber bestimmt.

Ganz anders in Dublin. Bei der Ankunft wird man vom Terminal direkt durch die Zollstation geleitet. Das ist derzeit eine Baustelle, funktioniert aber reibungslos (man merkt sofort den andern Stil der Leute dort, gegenüber Deutschland). Einmal die Kennkarte vorzeigen, die wird kurz auf einen Scanner gelegt, und das war's ("welcome in Ireland" und tatsächlich ein freundliches Lächeln). Beim Rückflug gab es gar keine spezielle Umleitung, sondern nur den üblichen ID-Check beim Boarding. Zurück in München wird man wieder durch eine Polizeistation geleitet, kann dort aber die fast-Lane für EU-Residents nehmen. Ein strenger säuerlicher Blick von einem Beamten, Kennkarte auf einen Scanner, und ein kurzes Nicken.

Andere Leute haben wesentlich mehr Gepäckvolumen als ich. Wenn man sich an die Regeln hält (Waffen, Werkzeuge, Elektronik), dann ist es auch heute noch so wie vor 20 Jahren. Eigentlich sogar einfacher, da die Scanner besser sind. Der security-Check in München hat sich mein USB-Inteface genau angeschaut, auch erkannt was es ist. Ansonsten alles andere gemäß Anzeige am Bildschirm durchgewunken. Man kann heutzutage auch alles in eine einzige Schale kippen. Was ich immer wieder vergesse: die Taschentücher raus aus den Hosentaschen, und auch die Medikamente aus der Brusttasche. Ist aber nur ein Schmunzeln wert. Ein Detail: ich hatte eine Tube Bepanthen in einer Klarsichttüte im Rucksack. Wurde angeschaut, war OK. Besser wäre es gewesen, sich eine Klarsichttüte mit Zip-Lock zu besorgen, dann könnte man auch ein Deo und eine Zahnbürste mit dabei haben (falls man von seinem Gepäck getrennt wird). Akkus müssen allesamt nicht nur im Handgepäck-Rucksack sein, sondern direkt am Körper/Handtasche. Da achtet man drauf (wußte ich vorher).

Will hat mich noch zum Bahnhof gebracht...

Tip: die App installieren!

...man geht in so einen »convenience store« am Block gegenüber der Connolly Station. Das ist Bahnhofs-Gegend, aber immerhin nicht direkt im Bahnhof. Im Laden kommt so ein gestresster syrischer Ladenbesitzer (allerdings: in Irland ist Jedermann viel taktvoller als hier in Deutschland), macht ein Foto mit seinem Handy, und stellt das Gepäck dann auf ein Regal direkt hinter dem Tresen. Später, beim Abholen, erkennt er einen "you want to pick up your luggage?", wuchtet die zwei Sachen raus, und das wars dann. Wenn während der Zeit jemand in meinen Rucksack "geschaut" hätte, dann hätte ich eine Beschwerde machen müssen...

Weiß nicht, ob mir eine Halle mit Schließfächern dort wirklich sympatischer wäre. Naja, hab Connolly Station eigentlich als ungefährlich empfunden.

Die Info im Internet war falsch. Die Station ist nicht an George's Quay, sondern direkt gegenüber am (sehr bekannten) Zollhaus. Alles sehr relaxed, kurzer Blick auf das Handy, daß man ein Ticket hat, niemand schaut genau hin. Der erste Bus war zu voll. Ich stand mit 20 weiteren Leuten da. Ein Mitarbeiter des Busbetreibers ist dort vor Ort. 5 Minuten später kam der nächste Bus, der war halb leer.

also gute 2 Stunden Zeit.

Ein Schalter für First, drei Schalter für Business + Ecconomy. Keine Warteschlange

Ist in Terminal-1 im obersten Stockwerk. Kurze Wartezeit in der Schlange. Alles in eine Schale, danach sortiert das System in "sofort OK" vs. "manuelle Nachkontrolle". Ich war in ersterer Kategorie.

wie üblich: die WCs direkt bei der Sicherheitskontrolle sind nicht sonderlich frequentiert, und sehr sauber.

Hab mir eine Cola gekauft, und dann mein Schmerzmittel genommen. Das war ein sehr guter Trick. Vorher, tagsüber war es noch mühsam.

Im Vergleich dazu sind die Behörden in Deutschland wirklich paranoid.

daher das übliche Spiel, ob jemand noch sein Handgepeck aufgeben möchte. Da waren aber auch Leute mit Rollkoffern. Bei mir hat niemand gefragt, und letztlich hat der Platz im Flugzeug dann auch locker gereicht

hab dann bei Smith 2 Adapter gekauft, Stück 10€. Problem gelöst. Leap Visitor Card gabs da aber nur für 1 Tag (genauso wie's ChatGPT sagte). Bin dann weiter zu Terminal-2 gelaufen. War sehr gut, daß ich mir spät nachts noch Google-Maps angeschaut habe. Merke, das ist keine Paranoia, sondern eine sehr gute Gewohnhait von mir!!!

In Terminal-2 war "Spar" etwas versteckt, ist nämlich im oberen Stock, beim Eingang zum Abflug (während WL Smith in Terminal-1 unten bei der Ankunft ist, ganz links). Leap Visitor Card dort gekauft, dann einen neuen Bus gebucht

Definitiv so: man muß die Tickets online buchen. Das geht aber auch noch vor Ort (per WLan), wenige Minuten vor Abfahrt. Visa-Debitkarte von ING und Consors hat problemlos funktioniert. Das muß man aber im Griff haben (also kein Zeitdruck! ruhige Ecke suchen, eine App verwenden, von der man sicher ist, daß die Verifikation funktioniert, wie hier, die ING-App). Was ich nicht wußte: ich hätte mir gar nicht nochmal ein Ticket kaufen müssen, mein vorher gebuchtes Ticket für den Bus 30 minuten früher, den ich versäumt habe, wegen der Geschichte mit dem Netz-Adaptor, wäre informell akzeptiert worden, weil die Leute dort "common sense" haben.

Die Busfahrt dauert ca 40 Minuten. Davon gefühlt die Hälfte durch ein endloses Tunell unter der Stadt durch. Das letzte Stück im Stadtverkehr zieht sich endlos. George's Quay ist die erste Station in der Stadt, und die nächste zu Connolly Station. Tara Street Station wäre sogar direkt daneben, aber mein Zug fuhr von Connolly.

Der Bus fährt von dort weiter den Liffy-River entlang, insges. braucht er 40 Minuten, bis er auf der anderen (nördlichen) Seite, vor dem Zoll-Gebäude wieder ankommt. Die Pläne und Angaben auf der Website sind irreführend. Für den Rückflug sollte man nicht ab George's Quay buchen, sondern gegenüber. Spielt aber in der Praxis keine Rolle. Gegenüber, beim Zoll-Gebäude ist ein Mitarbeiter der Buslinie vor Ort. Fahrgäste werden einfach nach vorhandener Kapazität mitgenommen, da die Busse tatsächlich alle 10 Minuten fahren. Wäre ich, wie gebucht, an George's Quay eingestiegen, dann wäre ich 40 Minuten durch die Stadt gezockelt. Aber der Busfahrer drüben am George's Quay hat mir das gleich gesagt. Vorher hatte ich einen Passanten angesprochen, auch der war, wie typisch in Irland, nicht betont freundlich, aber offen und gesprächig. Er hat mir gleich gesagt, wie das hier läuft, und mir dann gleich erzählt, daß er einen Freund in Deuschland hat, der jetzt nach Finnland übersiedelt, usw... Ja so sind die drauf. Kann man sich in DE gar nicht vorstellen.

Den Umständen enstprechend ist das wohl die praktischste Lösung. Man installiert eine App, bucht und bezahlt sich das kurz vorher (bei mir: am Abend vorher). Dann geht man in den jeweilgen "convenience store".

Mir persönlich, als old-Timer wäre eine Halle mit Schließfächern am Bahnhof viel sympatischer. Aber Bahnhöfe sind auch nicht mehr das, was sie mal waren. Wobei Irland hier einen sehr guten Eindruck hinterläßt. Aber auch das mit dem lokalen Shop ist letztlich OK, da es in Irland der normale Stil ist. In Deutschland sind solche Shops praktisch immer "zwielichtig", in Irland nicht. Außerdem hat man ja den Storage-Betreiber mit der App, und ein Foto vom Gepäck wird vorher auch gemacht, das gibt eine gewisse Sicherheit. Wobei mir klar ist, daß man im Problemfall erst mal selber sich um eine Beschwerde kümmern müßte.

...aber, realistisch geshen, ist das für mich vorbei. Es ist besser, wenn ich nichts esse, und es ist sicherlich kein Genuß mehr, mit anderen Leuten zum Essen zu gehen, sondern ein ziemlicher Streßfaktor. Die ersten beiden Tage ging's noch relativ glatt. Und ich war froh, mich an Will dranhängen zu können, der die Gepflogenheiten besser versteht.

...und das hab ich genossen. Jetzt weiß ich, was "black pudding" ist.

An den letzten Tagen war dieses Frühstück praktisch das einzige, was ich den ganzen Tag gegessen habe, und das war so die beste Lösung. Im Grunde ähnlich wie in Lyon, und auch dort hat sich das bewährt (auch wenn ich immer noch die andere Vorstellung im Kopf habe, daß man auf einer Reise irgendwo genußvoll und entspannt zum Essen geht, mit Leuten, bei denen man sich wohlfühlt)

das ist meine Welt. Hab praktisch den ganzen Tag dort verbracht. Mit dem ganzen sonstigen sight-seeing können die sich mal ihren Schuh aufblasen.

Das ist eine Touristen-Attraktion. War mir vorher klar. Ist aber leider auch wirklich so. Ich war praktisch die ganze Zeit nur mit meinem eigenen Hass auf diesen leeren Betrieb beschäftigt.

Warum ich aber dann doch nach Howt gefahren bin, war der Klippen-Trail, den ich auf der Karte gesehen hatte. Ich bin die zweitlängste Strecke gelaufen, 12km, rote Markierung. Damit war ich nach den ersten 45 Minuten raus aus dem Touristen-Strom. Außerdem war ich schon wohlweislich erst am späten Nachmittag, um 17:00 angekommen. Es war Sonnwend, also Sonnenuntergang kurz vor 22:00 Irischer Sommerzeit. Tatsächlich bin ich sogar früher wieder heim, um 21:00. Den schmalen Pfad über dieses eigenartige Hochland werde ich in Erinnerung behalten. Und die Möven. Ansonsten ist es dort laut, denn es liegt in der Einflugschneise vom Flughafen. Und eine Techno-Party war auch noch, vermutlich wegen Sonnwend.

Hab die Wellenlänge dieser Stadt nicht wirklich gefunden.

Hatte dafür aber auch gar keine Zeit, und keinen Grund.

Was ich gesehen habe, war eine Mitte, die keine ist. Ein Hafen, der nicht mehr zugänglich ist, sondern ein Industriegebiet. Massiver Autoverkehr. Keine U-Bahn. Enge Straßen, durch die sich auch noch diese Stockbusse durchzwängen. Massen an Touristen, für die kein Raum ist. Und massives Elend überall. Verfallende Altbauten, und moderne Architektur, die wie ein Raumschiff eingepflanzt ist, und um sich herum keinen Stadtraum schafft.

Es war der letzte Slot im Programm, und wir haben es geschafft, daß es bei uns »Musik« gab (keine "Avant-Garde" und keine Tech-Demo). Die allgemeine Stimmung war sehr erfreulich. So einige Zuhörer waren wieder sichtlich beeindruckt von den klanglichen Möglichkeiten. Einige kamen nachher noch, und haben auf dem Keyboard gespielt.

Ich hatte die ganzen Abende vorher, im Hotell geübt, und wußte schon jeden Punkt auswendig. Das hat sich bewährt. Thematisch bin ich in dieser Vorbereitung, während der Konferenz etwas »zurückgerudert«. Auch das war angemessen. Ich hatte das Gefühl, daß niemand im Publikum verärgert war, ich aber auch nichts wirklich Erhellendes gesagt habe. Was ich aber im Rückblick als gut empfinde, denn ich hatte nicht die Position für etwas Weitergehendes.

Um es nochmal zu rekapitulieren, ich wollte diesen Themenblock nicht, aber Will war es wichtig. Ich selber empfinde die Schwierigkeiten, die wir letztes Jahr hatten, als normal und keiner Rede wert. Was mich dabei nur ärgert ist, daß ausgerechnet ich diese Drecksarbeit andauernd machen muß. Aber letztlich gibt es nur mich und Will, Kristian ist berufstätig und hat Familie, und nur sporadisch mal Zeit, Jesper will sich raushalten (und nicht wieder Project-Lead werden). Und wenn man Will persönlich trifft, ist völlig klar, wer er ist, was sein Horizont ist, und was er nicht machen kann. Insofern bleibe ich einfach übrig, und wenn mir an Yoshimi weiterhin was liegt, werde ich diese Arbeit machen müssen, oder das Projekt geht vor die Säue. All das hab ich aber nicht gesagt, und ich habe es inhaltlich gut hinbekommen, stattdessen etwas Generisches zu sagen, das doch immerhin den Sachverhalt bezeichnet. Hab mich ziemlich genau an die hier skizzierte Gliederung gehalten. Weiterungen zu AI habe ich nicht ausgeführt, obwohl das das Einzige gewesen wäre, was mich daran interessiert hätte. Es ist aber auch gut so, das habe ich an der Diskussion in den vorangegangenen Tagen gemerkt.

Vom Sprechen her war es so la-la. Ich glaube, ich hab nicht mehr so viel gestottert. Daß meine Aussprache grauenhaft deutsch klingt, habe ich inzwischen einfach akzeptiert, und ignoriere es (was mir sehr hilft, mich auf die Wortwahl zu konzentrieren). Duch die Vorbereitung mußte ich nicht "nach Worten suchen". Ansonsten war mein Vortrag nach meinen eigenen Maßstäben ziemlich mittelmäßig. Es gab auch keinen Spannungsbogen (und ich hatte eigentlich nach meinem eigenen Empfinden nichts zu sagen).

Am Ende habe ich meinen Block nicht ganz zuende formuliert, da mir Will mit einem Einwurf eine Brücke zurück gebaut hat (die viel geschickter war, als das, was ich grade sagen wollte, daher habe ich sie sofort genommen)

Damit hat sich mein ursprüngliches Bauchgefühl bestätigt. Will kann nicht einmal 45 Minuten füllen, er würde nur Demo nach Demo machen. Durch die Gliederung, die wir uns vorher gmacht haben, waren wir aber eigentlich gut sortiert. Insofern bestätigt sich, warum Will mich gebeten hat, mitzumachen. Er hat nämlich jeden meiner Vorschläge gerne aufgenommen; die Zusammenarbeit war sehr konstruktv, vor allem, als wir uns persönlich abstimmen konnten, im Hotel in Maynooth.

Am Ende vom Zeit-Slot blieb etwas Luft, und so hat Will noch einen weiteren Track von sich gespielt, der aber nur noch wenig zum Thema beigetragen hat. Ich hab ihm dann signalisiert, daß es reicht, und er hat das verstanden. Da waren wir in Minute 40. Insofern konnten wir sogar noch etwas Diskussion machen. Da kam dann eine Frage zu meinem Themenblock und zur Dokumentation. Im Rückblick ärgert es mich, daß ich nicht im Stande war, das besser aufzugreifen (da hätte ich nämlich nochmal eine Brücke zur A.I. schlagen können). Aber was ich gesagt habe, war OK, und mehr wollte der Fragende ja eigentlich nicht. Ansonsten kamen noch zwei technische Detail- / Verständnisfragen, die wieder zeigen, daß viele Zuhörer nur mit CSound oder PureData experimentieren, aber nicht mit so einem typsichen "Synthie" vertraut sind (denn in dieser Hinsicht ist Zyn/Yoshimi überhaupt nicht überraschend)

Für mich war dazu essentiell, daß ich nicht bloß Zuhörer war, sondern ein Projekt vertreten habe. Bezüglich »Networking« hatte ich keine Ambitionen, hab aber auch nichts versäumt; ich habe zwei oder drei Leuten ausführlich von Lumiera erzählen können, und die schienen alle durchaus im Stande, die Tragweite zu erkennen. Allerdings war niemand da, der mich jetzt direkt etwas voranbringen würde. Hätte ich aber auch nicht erwartet, ich kenne diese Community. Möglich wäre es, aber die Community wird kleiner und kleiner, und wer noch da ist, sitzt in seiner Ecke. Ich hätte mich gefreut, etwas mehr mit Robin reden zu können. Das hat sich aber nicht ergeben, und ich habe keinerlei Interesse, da "zu drücken". Robin zeigt seinerseits kein Interesse, und fühlt sich mir gegenüber etwas unwohl, obwohl er oberflächlich immer den "alten Bekannten" begrüßt. Bemerkenswerterweise hatte Robin alles vergessen, was ich ihm in Lyon von Lumiera erzählt hatte. Er war erstaunt, zu hören, daß ich immer noch mit Lumiera weitermache. Ich komme mit ihm nicht auf die Ebene, die interessant wäre (würde mir davon aber auch nichts erwarten, da ich inzwischen ziemlich genau vestehe, wo er steht). Drei bis vier andere Leute, die ich in Lyon kennengelernt hatte, und mit denen ich gerne wieder anknüpfen wollte, waren nicht da. Insgesamt war sonst kaum jemand da, mit dem mich persönlich ein Gespräch interessiert hätte. Ich bin aber weiterhin vorsichtig, mich nicht zu aggressiv zu positionieren. Aktuell geht es mir nur darum, präsent zu sein (ich könnte auch in keine Art von Kollaboration einsteigen derzeit, weil ich meine Kräfte zusammenhalten muß, insofern bin ich froh, daß sich auch dazu keine Gelegenheit ergab).

Ohne diese Aufgabe, ein Projekt zu vertreten (und Networking zu machen), würde mich die LAC (schon seit langer Zeit) nicht hinter dem Ofen vorlocken. Die "Konzerte" sind immer gleich. Da genügt ein Termin, weil es schon schön ist, ein gut aufgebautes Ambisonics zu hören. Das zweite und drite Konzert habe ich "geschwenzt". Das war ein Glück, denn anstelle des zweiten Konzerts hatte ich Zeit, in dieser alten Universitäts-Anlage zu sein und nichts zu tun, und die Stille und Ruhe des Ortes aufzunehmen. Das war auch der Abend mit dem Gewitter und dem Regenbogen.

Insgesamt war Maynooth viel kleiner und bescheidener aufgebaut, als Lyon, was aber einfach an den dahinter stehenden Organisationen lag. Das dritte Konzert, in Dublin, wäre ein allgemeines Experimental-Konzert für elektronische Musik gewesen. Von mir aus hätte mich das nur gelangweilt, und da Will auch kein Interesse hatte, war die Konferenz sehr schnell beendet. So hatte ich Zeit für eine Wanderung zum Carton Demense, und hab so tatsächlich ein Stück von Irland gesehen.

Hinzu kommt, daß ich doch bei einer solchen Gelegenheit immer wieder merke, wie sehr ich gesundheitlich angeschlagen bin. Am vierten Tag, an dem ich nach Dublin wollte, ging es mir ziemlich dreckig. Später, gegen Abend zu, hat es sich etwas mehr eingependelt, was aber auch damit zusammenhängt, daß ich da in Howt im Freien war, und mehrere Stunden einfach allein laufen konnte.

Insgesamt war es ein »Nicht-Urlaub« von einer Art, die ich noch gut ertragen kann. Dieses kleine Universitäts-Städtchen mutet an wie aus einer andern Zeit, da war die »Quality without a Name«, von der Christopher Alexander spricht. Und zum Glück muß ich dort nicht leben. Das Hotel war mindestens eine Kategorie zu edel für mich, aber ich konnte gut unerkannt bleiben, die Leute in Irland sind wirklich auf eine unaufdringliche Art zugewandt, und ich hab mich sehr wohl gefühlt. Vom Hotel aus war alles fußläufig zu erreichen, die wüste Welt der Automobile war zwar zu hören, aber nur auf der anderen Seite. Und zum Glück gibt es praktisch nichts "Sehenswertes" im Maynooth.

Wenn ich nur bedenke, was Daniela garde im Moment mit ihrer LItauen-Bildungsreise alles um die Ohren geworfen bekommt, dann graut mir, und ich fühle mich verloren. Was für ein lehrer und eitler Betrieb das alles.

organisatorisch

-----BEGIN PGP MESSAGE-----

hF4DgGNXC/FW0HQSAQdAynTDJxP4gey1VAsJ/2fb/Pz/7SdEDaH99pGL3xFNBhgw

gOXq9+2npcG+wn9stWNHsIHJlCTcgMQWoBSQX8w2irTkUYncReWhdiAbz971t4Cs

0sBJAXhQ13ML9umVxaY9+RGxUUZqZ1dLDfcAbDTh0b9xbjrrGclWCA8kO9y8cVOI

afQLpsGCRvSaDCGIDTe2sbK1knwCiZK7sQIz6GOYEHQYvyRTwNHhmCivLy4aqy1U

jLJVbx0qgbUu+mMJGugNbITFRyfIu2W9P4ceBX4AE0KUaXwwg8CIbQfGld+0+cMc

IafKrmBGrIAYf6APYSDbBxXV3V5QfTN4Ew220rxcO8HIpYJDYyaNbHpyT3OjcSgy

GVpZ7L8f88aXGKbiwX2rdW1iLbmfBdbFixY0Me4on4A0qHzXpMB7ZeGZ6yvq6j5q

/K7d77gSJdwLWRyE49RwdmRXe1Siv/iP4WM9lQ==

=RxD1

-----END PGP MESSAGE-----

Titel: Reading Video data with IO_URING