[Talk-de] RFC: Ereignisgesteuerter Parameterverlauf // Re: Existenzkrise: Wofür Wege?

RalfGesellensetter rgx at gmx.de
So Jan 18 15:21:35 UTC 2009


Hi, 

deine Mail nehme ich zum Anlass, ein Konzept vorzustellen, das mir aus dem 
MIDI-Bereich vertraut ist (Kontext: elektronische Musik; Sequenzer):

Kurz lässt sich der Ansatz vielleicht mit "ereignisgesteuerter 
Parameterverlauf" beschreiben. Statt einen Track (z.B. die Streicherspur in 
einem MIDI-File) in einzelne Parts mit unterschiedlichen Parametern zu 
zerlegen, steuert sog. Controller-Events regeln in Echtzeit z.B. für jeden 
Zeitpunkt den Wert für die Stärke des Vibrato-Effekts. Dieser wird aber nicht 
mit jeder einzelnen Note (einem Waypoint entsprechend?) gespeichert, sondern 
über unabhängige Events, die jeweils eine Änderung des Parameters steuern. 

Auf Ebene des Editors (der Sequenzersoftware) ermöglicht dies eine komfortable 
Steuerung der Parameter über Hüllkurven bzw. mit Hilfe von linealartigen 
Schneidewerkzeugen. 

Es wäre bei Parametern wie maxspeed oder width (später auch altitude) ehr 
komfortabel, wenn eine Art Timeline entlang eines Weges in ähnlicher Weise 
bearbeitet werden könnte, ohne den Weg zu segmentieren. Dazu bräuchte man auf 
Ebene des Datenmodells Events, vielleicht in der Form von Wegpunkten mit den 
Tags traffic_sign=maxspeed:70 oder allgemein control_event=altitude:244.

Zusätzlich braucht man die Information, in welche Richtung das Zeichen zu 
lesen ist (wie geht das bei Ortsschildern eigentlich, dass klar ist, auf 
welcher Seite die Ortschaft beginnt?). Ggf. braucht man dazu für jede Straße 
zwei Tracks (in jede Richtung eine), die aber durchaus gemeinsame Punkte 
(Waypoints) verwenden können. 

Über geschickte Relationen (Timeline/Track) kombiniert mit geeigneten Control-
Markern wäre eine Übertragung der ereignisgesteuerten Parametersteuerung und 
damit die Vereinfachung der Parameterbearbeitung vorstellbar.

Was meinen die anderen?

Am Samstag 17 Januar 2009 15:51:22 schrieb Gerrit Lammert:
> Einiges wird wohl demnächst eh geändert werden (name kommt in die
> Relation und nicht mehr an den Weg etc.), aber ich denke man könnte mal
> langsam darüber nachdenken ob man nicht mit den Altlasten aufräumt um
> die tatsächlich relevanten Teile einfacher gestalten zu können

Vielleicht der richtige Ansatz - aber das Wort "Relation" schreckt nach meiner 
Erfahrung viele ab, die damit Normalformen in Datenbanken oder andere 
vermeintlich komplexe Modelle verbinden. Mit dem Begriff "Gruppen" können 
einige Relationen alltagssprachlich besser abgebildet werden - für andere 
Fälle könnte das Wort "Zuordnung" aushelfen.

Gruß
Ralf




Mehr Informationen über die Mailingliste Talk-de