InterPHase by MvKeinen

[MvKeinen]

Vorbetrachtung:

Zentraler Aspekt des Musizierens ist für mich die Liveperformance. Als "Undergrind" (mein ehemaliges Projekt) konnte ich die letzten 5 Jahre viel Erfahrung auf der Bühne sammeln. Ferner habe ich von Kindesbeinen bis jetzt ununterbrochen akustische Instrumente gespielt. Auch mein Elektrosetup bestand bisher immer komplett aus Hardware. Der Vorteil ist meiner Meinung nach eine einfachere und schnellere Gestaltung des individuellen Interfaces was sich positiv auf den kreativen Prozess und die Impulsivität niederschlägt. "Das Auge spielt mit" sozusagen.

InterPHase in youre face:

Haben sich Beethoven, Mozart und Bach jemals Gedanken über Interface gemacht? Vielleicht ein wenig, aber sicher nicht so viel wie wir. Dass die Musik damals nicht schlechter war als heute dürfte als abgesichert gelten. Instrumente (Werkzeuge) wurden von der damals möglichen Fertigungsqualität bestimmt und hatten räumliche Grenzen. Davon Abgesehen waren Musikinstrumente damals eine seltene Besonderheit. Der Musiker hatte sich also mit den vorhandenen Möglichkeiten zu arrangieren und hielt sich nicht groß damit auf sich Gedanken über das Interface zu machen. Ich würde sogar soweit gehen zu behaupten, dass das Interface damals nicht existierte. Oder würde man den Griff eines Hammers als Interface bezeichnen? Das Ziel ist es also ein Interface zu programmieren welches als solches nicht wahrgenommen wird, es wie den Griff des Hammers greifbar zu machen. Da heute die Architektur des Instrumentes variabel sein kann und die Mechanik nicht existiert muss das Interface auch noch visuelles Feedback über den Zustand des Instrumentes ausgeben.

Reaktor:

Ich Bin seit Reaktor 3 dabei. Die erste Zeit beschränkte sich aber nur auf planloses verbinden von Instrumenten und versuche mit Phasenmodulation wobei ich stundenlang verschiedene Frequenzverhälnisse "erforscht" habe. Als Core rauskam hat mich die Sache erstmal ziemlich gefrustet und ich habe mich als "Undergrind" auf Hardware Liveacts konzentriert, hatte aber immer im Kopf, dass man mit Reaktor eine geniale Livemaschine bauen könnte. Seit ich nun "Undergrind" vor einem halben Jahr beendet habe bin ich mit Hochdruck zu Reaktor zurückgekehrt um diesen Traum zu verwirklichen.

InterPHase:

InterPHase soll ein komplettes Livesetup für Reaktor (Wenn möglich Standalone) werden.

Sequencer:
- 2 mit Pitch, Gate, Velocity (aktuelle Version 0.1076)
- 4 mit Gate, Velocity (aktuelle Version 0.1076)
- 2 Triggersequencer (Konzept in der Entwicklung)

Modulationsquellen:
- 4 LFOs die individuell sowie auch vernetzt zur verfügung stehen (aktuelle Version 0.0880)
- 2 Dualband Envelope/Pitch follower (aktuelle Version 0.0880)

Klangmodule:
- 2 Identische 3op Wavegeneratoren (aktuelle Version 0.12)
- 2-4 Sampler (Konzept in der Entwicklung)
- 1 additiver experimenteller Flächengenerator (Konzept in der Entwicklung)

hier mal ein nicht mehr ganz aktuelles Bild des Wavegenerators:

interscreen2.jpg

Dieser Thread:

Mein ursprüngliches Vorhaben war eigentlich alles auf einmal zu präsentieren. Da sich aber in den letzten Monaten mein Wissen über Core vertieft hat wurde es mir klar, dass die älteren Teile eine Überarbeitung nötig haben was noch viel Arbeit bedeutet. Nun bin ich aber in einer PHase bin in der ich Hilfe und Feedback von Aussen benötige. Deswegen hab ich mich entschieden in diesem Thread progressiv vorzugehen und die Einzelteile nach und nach zu posten.

Gliederung:

1. Einleitung (Post#1)
2. Der Sequencer (Post#2)

[MvKeinen]

2. Der Sequencer:

Inspiriert von diesem Blogposting von Peter Dines
http://kore.noisepages.com/2008/09/25/r ... the-clock/
und dem Monoliner aus der Factorylib hab ich mich mal an meine eigene Vorstellung von Sequencer gemacht.

Seq1.jpg

Die Tables von oben nach unten sind:
- Pitch
- Read (hier kann man die Steps aktivieren deren Daten für die Kopierfunktion gelesen werden)
- Write (hier kann man die Steps aktivieren auf die die gelesenen Daten geschrieben werden)
- Gate: Der hier eingestellte Wert V bestimmt das Triggern des Gates folgendermaßen
V=0 kein Gate
V>0 & V<1 Das Gate wird getriggert mit der Gatelänge V*Steplänge
V=1 Das Gate wird getriggert mit Gatelänge= Steplänge + Gatelänge des nächsten Steps in diesem Fall wird das Gate des nächsten Steps nicht getriggert. So kann man gatezeiten über beliebig viele Steps einstellen.
- Velocity: Der Wert mit dem das Gate ausgegeben wird. Ist hier V=0 dann wird kein Gate ausgegeben.
Wichtiger Unterschied zu normalen Midisequencern ist die Ausgabe von Pitchdaten auch wenn kein Gate getriggert wird.

Linke Seite von oben nach unten:
- Sync: Tempo (hier fehlt noch 12 als teiler)
- Range: tonaler Bereich des Sequencers in Halbtönen (Da die Werte bei der Weitergabe den Bereich -1...+1 nicht verlassen muss die hier Eingestellte Range per IC Verbindung zum Empfänger weitergereicht werden und dort mit den Pitchdaten des Sequencers multipliziert werden. Im Sequencer selber regelt die Range lediglich die Quantisierung des Userinputs.
- Copy: Auslösen der Kopierfunktion (Buggy siehe unten)
- Length: Länge der Sequenz in Steps. Ändert sich erst wenn die Maustaste loßgelassen wird. (Buggy)
- Swing: Swingfaktor

Die Struktur:

Parent.jpg

Aufgeteilt in Interface (Orange) und Brain (Blau). Dazwischen die Iterationen (Grün) die in beide Richtungen für die Adressierung der Schreibvorgänge sorgen. Sync&Position (Gelb) soll noch aufgeteilt und auf Interface und Brain verteilt werden. Auch die Module rechts werden in das Brain integriert. Dazu muss das Brain aber eine Audiocorecell werden. Diesen Schritt will ich erst machen, wenn ein unten angesprochenes Problem gelöst ist.

Sync&Pos:

Sync&pos.jpg

Danke an herw für das Audio song position Makro

Hier will ich später alles was möglich ist ins Brain transferieren.

Fortsetzung folgt im nächsten Posting, wegen maximaler Anzahl an Dateianhängen.

[MvKeinen]

InterFace:

InterFace.jpg

In "Globals" befinden sich die Panelelemente der globalen Steuerung. Links oben in "Tables" die Primarytables und Mouseareas. Hier hab ich ein Stacked Makro gewählt weil ich später verschiedene Ansichten verwenden will. Die Primarytables sind nur für das Visuelle Feedback da und nicht für das Auslesen der Daten. So sind die Mouseareas nicht direkt mit den Primarytables Verbunden. Leider müssen diese aber im gleichen Makro sein, damit sie die Primarytables überdecken und diese nicht vom User aktiviert werden können. In der Mitte "User Action" Interpretation des User Inputs. Rechts der Speicher "Snaps" (Lila).

Snaps:

Snaps.jpg

Hier werden Daten aus dem Brain und dem Interface kommend gespeichert und weitergegeben. Und hier liegt auch das Problem was ich habe. Dazu mehr unten.

Iterations:

Iterations.jpg

Gelegen zwischen Interface und Brain werden hier für die Kopierfunktionen die Steps addressiert.

[MvKeinen]

Brain:

brain.jpg

Das Herz des Sequencers. Der Positioner (Braun) steuert die Adressierung der Kopiervorgänge. Pitch (Hellgrün), Gatetime und Velocity enthalten die Arrays und sind im Aufbau identisch.

Positioner:

Positioner.jpg

Hier haben wir 3 Arrays die technisch Identisch sind.

Write.jpg

Eingänge:
- rd[]: Index des auszulesenden Wertes (ReadIndex)
- W: Wert der in das Array geschrieben wird
- wr[]: Index der Schreibaktion.
- IT'Cp: Eingang für die Iteration beim Kopiervorgang

"Read" (Ocker) und "Write" enthalten Arrays mit den Daten der Primary read und write Tables des Interfaces. Diese Daten sind binär, also an und aus. "Positions" hat keine Entsprechung auf dem Panel ist aber der Kern der Sache.

Positions: Hier werden die Adressen der Steps gespeichert, die von dem User mit dem Read-Table für den Kopiervorgang aktiviert wurden. Wenn der User das Table "Read" auf dem Panel anklickt wird der Inhalt per Iteration gelöscht, wenn er die Maustaste loslässt wird es neu beschrieben.

Read: Aktivierung von Steps für den Kopiervorgang. Dieses Array wird ausgelesen, wenn der User die Maustaste loslässt.

Write:

Dieses Array wird in der Reihenfolge 0 - (length-1) ausgelesen. Ist der Wert = 0 so passiert nichts. Ist der Wert = 1 wird der Wert des Positions arrays (rechte corecell) gelesen und als Position an die Pitch, Gate und Velocity arrays über den Ausgang p'Pos geleitet.

[MvKeinen]

Weiter:

Im Anhang ist das Testensemble.

zum verständnis bitte ich erstmal nur die Snaps des Sequenzer Instrumentes durchzumachen ohne selbst das Panel zu bedienen.

Snap 1:Init (Ich baue eine sequenz)
-> Snap 2: (Ich verdopple die Länge)
-> Snap 3: (Ich setze Quell und Zielsteps) schon jetzt hört man das Ergebnis.
-> Snap 4: (Ich kopiere)
-> Snap 5:

und hier ist das Problem: Bei Erstellen der Sequenz habe ich ab Snap 5 alles so gehört wie es sein soll. Beim späteren Anwählen der Snaps allerdings nicht mehr. Die Ergebnisse der Kopierfunktion werden also nicht durch Snapwechsel abgerufen. Das hängt wohl mit den Snaparrays zusammen die müssen bei snapwechsel die Corearrays neu beschreiben was sie zwar tun aber nicht mit den kopierten Daten sondern mit den ursprünglichen. Das heisst ich muss irgendwie das "Alte" Array mit dem Neuen aktualisieren ohne einen Eventfeedback zu bekommen.

Weiterhin frage ich mich ob ich einen Eventbus zwischen Interface und Brain einrichten soll (Und wenn ja wie) um die Übersichtlichkeit zu erhöhen.

Versucht auch mal komplexere Anordnungen der Read und Write tables.

Ich finde die Positioner funktionalität sehr musikalisch und gut dazu geeignet relativ schnell komplexe sachen zu machen.
Wenn man das Problem gelöst hat kann man auch endlich an weitere kreative Funktionen denken wie Zufällige abfolge der Positionen, Offset usw.

Feedback erwünscht!

Soll ich erstmal die Struktur mit dem Eventbus vereinfachen um etwas klarer zu sehen wo das Problem ist?
da hab ich grad noch keine Ahnung wie ich das am besten anpacken sollte. Der Eventbus ist mir noch etwas verschlossen, da ich meinte ihn bisher nicht zu brauchen. Ich denke aber dass er mir hier vorteile bringen würde.

Gruss

EDIT: .Ens im Anhang Gelöscht. Aktuellere Version weiter unten

[KlangRaum]

Kleiner Einschub, ist ein wenig Off-Topic:

VorbDie erste Zeit beschränkte sich aber nur auf planloses verbinden von Instrumenten und versuche mit Phasenmodulation wobei ich stundenlang verschiedene Frequenzverhälnisse "erforscht" habe.

Das ist ein sehr komplexes Thema: Bei Frequenz- btw Phasen- wie auch bei Ring- & Kreuzmodulation gibt es für das Obertonspektrum 3 bestimmende und relevante Grössen:
Zur Festlegung der Grundfrequenz des Carrier das exponentielle Signal (Pro Halbton eine Differenz von [12√2] - Das P-Signal wird ja entsprechend umgerechnet...) und für die Modulatoren, die letztendlich den Klang btw. die Obertöne bestimmen ein, mitlaufendes Versatzverhältnis zum Carrier wie zB 1:2 … 1:3 … 1:4 …… 2:3 … 3:4 … 4:5 … usw…etcetc plus evtl eine lineare Differenz in Hertz.

Letzteres -die lineare Differenz- ist speziell bei der Ringmodulation eine wichtige Grösse da hier Summe und Differenz der beiden Frequenzen erzeugt werden. Ohne die lineare Differenz lässt sich bei RM keine gleichmässig spielbare Tonleiter aufbauen.

Man kann dann generell mit solchen Modulationsarten noch sehr viel rumexperimentieren und andere Kennlinien und Grössen einrechnen, Einen LFO für weitere FM und schnelle wie langsame Amplitudenmodulationen , das ist aber meistens nur schwer beherschbar, meisten irgendwie auch nicht sinnvoll.

Gruss


Edit_PS: Dein Ens sieht interessant aus, ich werd es mir mal näher anschauen

[MvKeinen]

das ist alles andere als Offtopic

Danke
Schonmal gut, dass du das ansprichst das ist ein Thema was hier demnächst Reinkommt. Meine Lösung ist nicht Perfekt aber hat meiner Meinung nach was musikalisches, muss aber noch sehr überarbeitet werden. Gerade bei der Modulationen im Audiobereich haben mir Deine Postings hier einiges gebracht.

[KlangRaum]

…freut mich das ich Dir bisserl helfen konnte
Ich hatte mal sehr viel mit einigen FM und anderen Modulationarten experimentiert und irgendwann mit einem OPL6 begonnen, bei dem etliche Parameter mit einer eigenen algorithmischen Sequencerspur gesteuert werden. Grade bei schnellen und harten Tekknobeatz bringt das Ding absolut abartige Morpingpattern zustande... eine echte Clubsäge

Leider ist das Ensemble ziemlich CPU-lastig geworden und müsste nicht nur deswegen an einigen Stellen nochmal dringend umgearbeitet werden.
Ich habe aber seit längerem kaum noch Zeit & Ruhe um an diesem Konzept weiterzuarbeiten, eigentlich bräuchte ich auch nen schnelleren Rechner, mein alter Mac kommt bei vielen meiner Ensembles arg ins Schwitzen.

Eine weitere Idee war das auf 2 Reaktorechner per OSC zu verteilen, der eine als Sequencer und der andere als Klangerzeugung. Die Tage hab ich noch ne neue Idee bekommen: das iPad ist ja mittlerweile midifähig geworden..... damit könnte mal das eigenlich umständliche User-Inferface auf der Bühne mit der Maus ersetzen oder ergänzen

Meine Lösung ist nicht Perfekt aber hat meiner Meinung nach was musikalisches, muss aber noch sehr überarbeitet werden.

Pass auf, das Du Dich auf der Suche nach der Perfektion nicht verzettelst. Grade bei Frequenz- & Phasenmodulation gibts in komplexen Schaltungen wie einem OPL6 waaaaaahnsinnig viele Möglichkeiten noch komplexere oder drastischere Sounds zu erzeugen. Wenn man da nicht gleich den Stein der Weisen hat, wird die Schaltung entweder CPU-lastig, unübersichtlich oder fehleranfällig. Dann schiessen einem sehr schnell seltsame Gedanken durchn Kopf:
Eigentlich müsse ich das Teil nochmal völlig neu machen…

Kommt Zeit, kommt Rad ……

Gruss

[MvKeinen]

Pass auf, das Du Dich auf der Suche nach der Perfektion nicht verzettelst. Grade bei Frequenz- & Phasenmodulation gibts in komplexen Schaltungen wie einem OPL6 waaaaaahnsinnig viele Möglichkeiten noch komplexere oder drastischere Sounds zu erzeugen. Wenn man da nicht gleich den Stein der Weisen hat, wird die Schaltung entweder CPU-lastig, unübersichtlich oder fehleranfällig.

Ja das stimmt. Wenn man dann auch noch nen Sampler oder Effekte haben will wirds schwierig. Für die Praktikabilität hab ich mich beim "Wavegenerator" ziemlich beschränkt. Da aber jeder OP bei mir einen eigenen Filter haben soll der auch von den anderen Modulatoren "Frequenzmoduliert" werden kann und jedes Modulatorsignal vor oder hinter dem Filter abgegriffen werden kann ergibt sich schon bei 3OPs ne wilde Parameterflut. Ich versuche das aber mit einem übersichtlichen Modulationsbus und einem animierten Blockschaltbild per Polydisplay zu lösen.

Eine weitere Idee war das auf 2 Reaktorechner per OSC zu verteilen, der eine als Sequencer und der andere als Klangerzeugung. Die Tage hab ich noch ne neue Idee bekommen: das iPad ist ja mittlerweile midifähig geworden..... damit könnte mal das eigenlich umständliche User-Inferface auf der Bühne mit der Maus ersetzen oder ergänzen

Das ist Interessant. Ich versuchs schon länger hiermit: http://vvvv.org/

das sendet und versteht OSC und kann ALLES was mit echtzeit rendering zu tun hat, man kann bis zu 64 rechner im netzwerk rechnen lassen, Kameratracking, usw. (die Graphik von Reactable wurde damit gemacht)

Damit würde ich gern eine Art Molekulare Struktur darstellen in der die Atome die Operatoren darstellen. und die verbindungen in form farbe und helligkeit die Art der verbindung darstellen. Verschränkte Atome zittern dann zB. Das alles dann zum anfassen mit irgendeinem PAD oder per Kameratracking an der Leinwand den Synth spielen.

Ich weiss bloß nicht. Eigentlich habe ich gehört, dass Reaktor nur mit Reaktor über OSC sprechen kann (Bisher) Ich hoffe das wird angegangen in R6. Andererseits hab ich aber auch schon sachen gesehen wo touchOSC zum Einsatz kommt.

Übrigens hab ich das Problem gelößt:

Snaps2.jpg

Die Ausgänge der Arrays werden gemerged und ins Brain geleitet. Durch die Verbindung von Linkes Array "Gate" out zum rechten Array "R" in wird alles immer aktualisiert ohne ein Feedback zu haben.

Seq0.1076.ens

Gleich altes Ens löschen und beim neuen die Snaps durchmachen um die Funktionalität zu erkennen, dazu folgende Beschreibung lesen:

Snap1: Init
Snap2: Ausgangssequenz
Snap3: Verdoppeln der Länge
Snap4: Setzen der Quell und Zielsteps im Positioner (jetzt hört man schon was beim Koperen passiert)
Snap5: Nach dem Kopiervorgang. Der positioner ist noch aktiv
Snap6: Neue Sequenz. Der positioner ist deaktiviert.
Snap7: Neues "positioning"
Snap8: Nach dem Kopiervorgang
Snap9: Ein paar Töne ändern
Snap10: Länge ein weiteres mal verdoppeln
Snap11: Neues "positioning". Einfaches Wiederholden der sequenz
Snap12: Nach dem Kopiervorgang
Snap13: Die neue Sequenz
Snap14: Ein bischen verändern

Fertig.

Bin echt froh dass das jetzt klappt. Sonst hätt ich das ganze Konzept verwerfen können.
Nächster Schritt ist das Brain in eine Audiocorecell zu verfrachten damit ich Sync&Position sowie das eigentliche Gate im Brain haben kann. Wird mir fast schlecht wenn ich dran denke was dann alles möglich wird. Dann werd ich nämlich noch ein Array bauen das die Steplängen speichert. So könnte man verschiedene Tempi innerhalb einer Sequenz verwirklichen. Dann funktionieren aber die Primary Tables nicht mehr, dann müssen Polydisplays her. uiuiui

[MvKeinen]

Nächster Schritt ist das Brain in eine Audiocorecell zu verfrachten damit ich Sync&Position sowie das eigentliche Gate im Brain haben kann. Wird mir fast schlecht wenn ich dran denke was dann alles möglich wird. Dann werd ich nämlich noch ein Array bauen das die Steplängen speichert. So könnte man verschiedene Tempi innerhalb einer Sequenz verwirklichen. Dann funktionieren aber die Primary Tables nicht mehr, dann müssen Polydisplays her. uiuiui

Habe jetzt die "Brain" event corecell in eine Audiocorecell verfrachtet.

Problem:

ich bekomme die zu kopierenden Daten die in Iterationsgeschwindigkeit an die Eventtables geschickt werden nicht aus der Audiocell raus. Ist auch klar, weil die Audioausgänge ja mit SR.C ausgelesen werden.

Beim Schreiben geht mir aber folgende Idee ein: Wie wärs wenn Ich die Daten nicht aus der corecell nehme, sondern aus dem primaryPendant der tables. Das müsste gehn, weil die ja ein exakter Spiegel des Inhaltes der Core Arrays sind. Das heisst ich muss wohl die Tables und Snaparrays genau paralell zur Corearchitektur konstruieren.... Hmmm ob das klappt?

[KlangRaum]

…
Da aber jeder OP bei mir einen eigenen Filter haben soll der auch von den anderen Modulatoren "Frequenzmoduliert" werden kann und jedes Modulatorsignal vor oder hinter dem Filter abgegriffen werden kann ergibt sich schon bei 3OPs ne wilde Parameterflut.
…

Hmmmmmmm
Mit welcher Wellenform arbeiten Deine OP's ?
Irgendwie kann ich mich noch an einen Thread erinnern in dem es um FM mit beliebigen Wellenformen ging....
Bislang geht man ja von einem idealisierten Sinus aus (Parabolic klingt schon etwas „unterschiedlich“). Meine Frage dazu war damals ist, ob so etwas überhaupt sinnvoll ist.

Der ehemalige Grundgedanke bei FM/PM war ja, das sich mit diesen Prinzip ein weitaus grösseres Klangspektrum erzeugen lässt als mit herkömmlicher additiver/subtraktiver Synthese. Ein einziger OPL erzeugt ein Spektrum von Sinus über Dreieck bis Rauschen, bereits mit 3OPL lässt sich die Palette mit Rechteck/Impuls und diversen Mischformen abdecken. Man kann nun 2 3OPL parallel betreiben oder sich nun noch komplexer modulieren lassen. Wie auch immer, ich sehe jetzt nicht so die Berechtigung warum jeder einzelne OPL noch einen Filter am Ausgang haben soll, ich sehe eher das Problem das das OPL-Verhalten in sich so komplex ist, das nur wenige Leute das Ergebniss in voraus kennen oder gar gezielt einen Sound aufbauen, so wie man es mit zb einem einfachen SubtraktivSynth tun würde. Ich wage einfach mal zu behaupten das man auch ohne die Einzelfilter die selben Sounds hinkriegen kann, wenn man bei den Feedback bzw Modulator-Carrier-Zweigen die Modulationstiefe dämpft und bei einem Modulator die Grundfrequenz ändert.

Nur ist das halt wiegesagt in sich sehr komplex und oftmals schwer nachzuvollziehen, vermutlich hat Yamaha seinem DX200 genau deswegen nochmal einen Filter am Gesamtausgang spendiert. Ausserdem hat man damit auch noch einen Master-Schrauber-Knopf um seine Sounds zu von Hand zu verschrabbeln.

*schnippp*

Arbeitet man mit konventioneller FreqMod, benötigt man einen Hochpass zur Signalentkopplung vor dem Modulationseingang. (An der analogen Wohnzimmerwand tuts auch ein Patchkabel mit Kondensator) Bei PhasenMod ist das nicht nötig. Wie auch immer, der Rechenaufwand mit einem Filter am Ausgang ist relativ hoch. Richtig „interessant“ klingts jedoch erst mit einem 6OPL…

Der Knackpunkt ist folgender: Wir verwenden immer -egal ob Primitive oder Core- eine echte Audioschaltung… …mit echten einzelnen Oszillatoren… …die mehr oder weniger rechenintensiv wird. Alleine schon die Verknüpfungsmatrix ist ein Thema für sich. Mir schiesst seit längerer Zeit folgender Gedanken durch mein CoreHirn: Alternativ dazu müsste sich doch ein einfaches Modell entwickeln lassen, das über einziges einfach gehaltenes Rechenwerk (!!!) mit einfachen +-/* Operationen (!!!) einen 6OPL Phasenmodulator abbildet und dabei nur einen Bruchteil der Rechenleistung verheizt. Angenommen man geht von einer Rampe aus, bei dem ein Wertebereich von 0…1 einem Phasenwinkel 0…360° entspricht und und man liest evtl. dabei zur Wandlung in Sinus aus einer Tabelle aus………

Das schöne an Zahlen ist, das man sie beliebig interpretieren kann. In so einem Rechenwerk kann man dann mit einer einfachen Multiplikation beliebig modulieren.
…weiss nicht, ob Du grade ahnst, auf welche durchgeknallte Idee ich hinaus will …


Gruss

[MvKeinen]

. Hmmm ob das klappt?

Jau es klappt!!!

muss dazu aber einige änderungen in der Architektur machen. Wie Geil, das wird so fett.
Will nurmal kurz anschneiden was dann alles gehen wird:

1. Offset (find ich bei sequencern unerlässlich) Oft isses ja so, dass beim schrauben von Sequencen es sich herausstellt, dass die musikalische eins nicht unbedingt der erste Step ist. deswegen Offset Da muss man allerdings nachdenken wie man das mit der wählbaren Steplänge vereinbart (Also was mit den Steps passiert die sich ausserhalb der Sequenz befinden)
2. Zufall: Die vom Positioner gewählten Quellsteps werden zufällig abgespielt. Oder rückwärts (Wobei ich diese Funktion noch nie gebraucht habe bei sequencern, ich glaub das lass ich deswegen) Ich arbeite relativ wenig mit Zufall in der Musik.
3. polyrythmik: Die vom Positioner gewählten Quellsteps werden schneller, langsamer abgespielt. Das wird komplex weil sich dann für den Kopiervorgang eine neue Stepanzahl ergibt. Dazu brauch ich ein Array das die Steplängen speichert. Ich werd das erstmal nur mit doppelter bzw. halber Geschwindigkeit versuchen. Syncronisation wird da auch ein Thema...

Was aber jetzt schon gehen wird ist das individuelle Scharfstellen von Pitch, Gate und Velocity für den Kopiervorgang. Das wird glaub ich ne recht kreative sache.

Jetzt muss ich aber wohl oder übel mich mit Primary rumschlagen..... ich will endlich ins Brain zurück

[KlangRaum]

Hab Dein Ens noch nicht ausprobiert, weil ich Probleme mit dem Upgrade auf R5.5 hatte.... ist aber jetzt kein Thema.

1. Offset (find ich bei sequencern unerlässlich) Oft isses ja so, dass beim schrauben von Sequencen es sich herausstellt, dass die musikalische eins nicht unbedingt der erste Step ist. deswegen Offset Da muss man allerdings nachdenken wie man das mit der wählbaren Steplänge vereinbart (Also was mit den Steps passiert die sich ausserhalb der Sequenz befinden)

Rotate & Shift … Left-Right. Lässt sich mit Addition und Modulo des Position-Pointer sehr einfach realisieren.

Ich finde, Du bist da mit Deinem Ansatz schon genau auf dem richtigen Weg. Kennst Du den Sequencer der Yamaha RM1X ?
Da kannst Du die Pattern zur Laufzeit ähnlich bearbeiten, ohne sie zu verändern.

2. Zufall: Die vom Positioner gewählten Quellsteps werden zufällig abgespielt. Oder rückwärts (Wobei ich diese Funktion noch nie gebraucht habe bei sequencern, ich glaub das lass ich deswegen) Ich arbeite relativ wenig mit Zufall in der Musik.

Rückwärts finde ich wichtig, wenn Du das Signal zb. statt in einen Oscillator in einen Filter schickst.
Bei meinen Sequencern ist es egal, wer das Signal geschickt bekommt. Tonerzeugung oder Modulation ist absolut gleichwertig bei der Signalverarbeitung.

[MvKeinen]

hihihi da muss ich nochmal drübermeditieren.... Ich bin grad so in den Sequencer festgekrallt, dass ich da gedanklich schwer von weg komme. Werde Dein Posting aber demnächst unbedingt aufgreifen. ich werde nach dem Sequencer den Modulationsbus Beschreiben und danach kommt der Wavegenerator bei dem ich schon relativ weit bin

!!!!!> es sei denn du verdirbst mir alles mit deinem fachwissen und ich kipp das auf den Müll

SPASS,SPASS Genau wegen solchen Beiträgen wie deinem Mach ich das hier.... Ich bin da ziemlich unkompliziert, also bitte ALLES an vorschlägen Kritik und so weiter Anbringen. Ich bin extrem froh über jedes auch noch so abstruse Gedankenspiel. Ich hab insgesamt herausgefunden, dass man mehr lernt wenn man die sache von unten Betrachtet wenn de weisst was ich meine.

[KlangRaum]

!!!!!> es sei denn du verdirbst mir alles mit deinem fachwissen und ich kipp das auf den Müll

Ach was hab ich nich vor

Wäre aber nur blöd, wenn Du Dich -genau wie es mir passiert ist- auf eine fixe Idee festbeisst und später mit einem Schaltungsmonster in einer Sackgasse hängst.
Der ganze Bereich FM/PM ist halt komplex und rechenintensiv, man sollte seinen OPL einfach halten. Mir gehts halt darum, wie man mit solchen Kunstgriffen wie oben beschrieben auf einem anderen Weg einfacher oder eleganter zum selben Ergebniss kommt. Momentan fehlt mir die Zeit weiterzumachen, Du steckst aber grad drin, also geb ich Dir mal meine Erfahrungen weiter.
Ist also keine Kritik im negativen, eher ne Anregung. Es würde keinen Sinn machen diese Erfahrungen jemandem zu posten, der sich nicht auch damit beschäftigt.

Gruss