performance digital

[Quietschboy]

Hier noch das Ensemble

[Thala]

da mir die funktion des latch moduls noch nicht bekannt war habe ich das anders geloest:
core cell mit clip min max drin. eingestellt auf 0-1. funzt auch bei einem pulse lfo.
und du hast natuerlich recht, ich habe das verhaeltnis verdreht dargestellt.
danke fuer die ausfuehrung.
ich hatte folgenden aufbau:
in einem core macro befinden sich 8 multiply, die ueber den distribution bus das lfo signal bekommen. 4 weitere multiply auf 2 weitere auf 1multiply, um das ergebnis dann zu einem core ausgang zu leiten.
dieses macro wurde dann 7 mal kopiert um wieder auf 8 zu kommen. und wieder wird es zu einem ausgang...
nun laufen 127 mulply.
alles kopieren. und in ein macro tun. macros wieder vervielfachen. und zusammen bringen. das sind dann 1023. usw bis 4millionen. ich habe alle multiply in standard modus gelassen. float? bei dieser verdrahtung waren also wirklich alle multiply am arbeiten.

[Thala]

hier noch ein Paar Bilder zu meinem testaufbau:

[Quietschboy]

Aah, OK
Bilder sagen manchmal mehr als tausend Worte

Der Core Aufbau sieh sauber aus, allerdings wird alles polyphon gefahren. Auch die beiden LFOs, die auch beide immer aktiv sind. Ebenso schlucken beide Core Cell Eingänge (der Audio- und der Eventeingang) immer CPU Last. Polyphone Primary Strukturen werden automatisch optimiert (Intel SSE?), so dass die CPU Last nicht im selben Maß wie die Anzahl der Voices steigt. Bei Core kommen diese Optimierungen weniger, oder sogar gar nicht zum Zuge. Genaues weiß ich aber nicht.
Aber nichts desto trotz ist das Ergebnis eindeutig. Das AND ist günstiger als das floating point Multiply. Für eine eindeutige prozentuale Angabe müßte noch der Overhead, also alles in Primary und die Core Cell In-/Outports bestimmt und vorsichtshalber monophon getestet werden. Und wenn es sowieso nur um den Vergleich zweier Core Module geht, kann man den ganzen Primary Klumbatsch auch gleich weglassen und mit Audiorate (SR.C in Core) testen. In Core wird nämlich kein Unterschied zwischen Events und Audiosignalen gemacht. Das merkt man leider auch an der fehlenden, farblichen Trennung. Lediglich die Core Cell Ein- und Ausgänge verhalten sich für Events und Audio unterschiedlich. Stichwort "synchronous" und "asynchronous".
In meinem Testensemble oben verlässt tatsächlich exakt ein Event die Core Cell. Nämlich bei Initialisierung. Die ganzen per SR.C getriggerten Events (synchronous) werden vom Core Cell Eventausgang (nur asynchronous) gar nicht berücksichtigt - es sei denn denn du machst für den Ausgang ein Häkchen bei "Allow Audio Events" ("erlaube auch synchrone events").

In meinem Test hatte ich integer Multiplys mit AND verglichen. Kein Wunder also, daß ich auf ein deutlich abweichendes Ergebnis kam.

[Thala]

das seltsame ist nur, dass float anscheinend besser abschneidet.

[Thala]

aber mit polyphon und monophon muss ich mich auch mal beschäftigen
man man man ist das hier eine lernkurve...
bin grad dabei d3x und silverbird live zu verschmelzen. ich denke da habe ich auch schon viel performance verloren, durch das gedankenlose "einfach ein paar module einfügen".
irgendwo sind mir mindestens 10% cpu verloren gegangen... ärgerlich da ich nun schon bei 85% bin und eigentlich noch ein paar tolle effekte und einen LiveLooper hinten dran einbauen wollte.
rockt aber. und die soundqualität von D3X ist einfach hammer. Silverbird klingt durch den D3X-Mischer gleich gaaaanz anders als bei der internen mischung.
den Beat LFO konnte ich mir auf dem crossfader auch nicht verkneifen. ist einfach zu gut. der ist seine 5% CPU wert!

aprospros Live Looper. hattest du nicht mal eine loopstation gebaut?

[Quietschboy]

hehehe, die Lernkurve hört auch so schnell nicht auf
Da hast du auch nach Jahren noch was zu knabbern. Es wird also nicht langweilig.

Mein Livelooper ist leider noch nicht fertig. Das ist eine verdammt komplexe Sache. Zumindest bei den Ansprüchen die ich selbst daran stelle. Jetzt mache ich erstmal den ACEW für Reaktor 6 fertig und danach geht's mit dem Looper weiter.
Ob ich jemals damit fertig werde, steht aber noch in den Sternen. Das Problem ist einfach die Zeit. Der kleine Chef hier verbietet mir leider 12 Stunden Reaktor Sessions...

[Thala]

und dann sind da noch die neulinge wie ich, die betreut werden....

[Quietschboy]

Kein Problem. Aller Anfang ist schwer und ich denke, den meisten ohne große Programiererfahrung geht/ging es so (mir auch). Außerdem braucht man auch mal Abstand von seinen eigenen Projekten.
Mir kommen dann oft die besten Ideen. Den ACEW hatte ich vorgestern noch für fertig erklärt. Jetzt baue ich schon wieder das Panel um, da das neue Verhalten von Reaktor 6 Änderungen im Design erlaubt die ich bisher noch gar nicht gesehen hatte.

Ich habe so einige Live Looper ausprobiert und als einziger wäre für mich der Moebius (VST) in Frage gekommen. Da finde ich allerdings die Bedienung und die Oberfläche etwas zu kompliziert/hässlich, so dass ich mich damit letztendlich auch nicht weiter beschäftigt habe. Ich weiß auch nicht, ob der einen Latenzausgleich hat. Das z.B. finde ich absolut wichtig.
Hast du was Interessantes gefunden?

[Thala]

nicht wirklich...
aber das hier hat qualitativ was unter der haube, und wäre eine gute basis zum starten:
http://www.native-instruments.com/de/re ... show/7649/
beat lookup für slicing... damit es auch bei live eingespielten drums nicht glitched. toll. ich kannte von den propellerheads nichts anderes, dank vollem rex support.
und war dann erstmal total vor den kopf geschlagen, als ich zB ultraloop ausprobierte... ultraloop (wie auch der andere twisted tools kram) hat richtig tolle konzepte. aber sobald man live drumloops darauf los lässt, kommt nur glitch oder statischer kram raus. schade... kein cashflow von meiner seite.
buffeater lite (gratis) arbeitet für meine zwecke besser als die vollversion.